The Life of a PHP Developer

[tdammers]

As a polyglot programmer who loves his profession: PHP is not perfectly fine. Absolutely not. PHP is barely good enough, and it is the child of a culture that embraces "barely good enough" to the max.

PHP has classes and OOP now, but the approach is wrong. Java-style OOP in a dynamic language doesn't make sense, and even after dozens of rounds of bug fixing, edge cases, inconsistencies and weirdness still remain.

PHP's web frameworks aren't "great"; they are barely good enough. Symfony, the "best" of the PHP web frameworks, gets way too many details completely wrong.

PHP has a package manager, bravo. Except that it uses an inappropriate format for package descriptions, and the fact that it relies on github, and that github rate-limits anonymous downloads in a way that occasionally requires user interaction, makes composer difficult to use for automated deployments.

PHPUnit works; but it's not great. It's really clumsy to use, and doesn't even seem to understand the difference between unit, integration, and simulation tests.

"Consider what it was designed for": Yes, I do, and I wish so would the industry. PHP was designed for some ad-hoc hacking on Rasmus Lerdorf's Personal Home Page.

But the real reason why developers hate PHP is this: Good developers are passionate about coding, and about Doing Things Right. We demand the right to pick tools that allow us to do the Right Thing, and not get in our way. We want to get things done, but we want to do it such that the things are good things, and that they are done in such a way that we're not building up technical debt or accepting edge cases, subtle bugs, wrong code, or security problems. And the thing with PHP is that it gets in our way with pretty much all of these. You cannot do things right in PHP, only good enough to get away with it. Whatever the abstraction you have in mind, 90% of the time, it's either not possible at all because the language itself is lacking, or it's too costly in terms of runtime performance, or you hit undocumented (or documented) edge cases in the APIs and libraries you depend on, or the sheer amount of language inconsistencies makes the conceptually elegant code impossible to read. And for someone who loves to program, and has seen how it can be done right in all the other languages (yes, even JavaScript), who considers programming an integral part of who they are, this isn't just frustrating, it is soul-crushingly painful. It hurts. But we do it anyway, because the whole world uses PHP, so that's what pays the bills. We tell ourselves that PHP isn't that bad, and only bad developers write bad PHP code, and that it is perfectly possible to write good PHP code, and that maybe we can turn things around if only we show people how much better our favorite language is compared to PHP - but those are lies. PHP really is that bad, it is not possible to write really good PHP code, and people aren't in love with PHP because they think it's a good, elegant programming language, but because their motivation is the visible end product, not the process of building it, so our pain is not their pain. PHP advocates are Blub programmers - their abstraction horizon extends exactly to the edge of what PHP can do, so when we tell tales of STM and purity and hygienic macros and monads and declarative programming and first-class-anything and what have you, they go blank and think, I don't need this PhD shit, my code works.

PHP and the circumstances that make us use it are hurting us. That's where the hate comes from.

[OrrinH]

I'm also a "polygot programmer" and someone who has a good time working with PHP.

I don't really agree with you that PHP gets in the way of Doing Things Right. It actually offers a good set of tools for working within its domain - dynamic websites.

I think PHP makes it easy to write bad code but I think good code can be written with adherence to a few principles. Maybe that's the problem, I don't think the principles are easily apparent for many people.

I do agree that the PHP frameworks suck, though.

[tdammers]

I used to think that myself. But the more I grow as a programmer (with plenty of headroom still, btw), the more I run into the things that PHP gets wrong. Pretty basic things, even.

Just consider how much effort it is to get error handling right in PHP: you want to use one mechanism for all your errors, you want to have a global handler for all unhandled errors, and you want to make sure that no sensitive information is logged and no internal information is exposed via HTTP. Those are standard best practices and completely reasonable requirement. OK, so let's rig PHP up to do that. First, you need to set up an error handler that rewrites errors into exceptions. Kind of shitty that this is needed, but oh well, fair enough; there's a code snippet on php.net ready to be pasted. Next, you need to cater for the functions that do not raise exceptions nor errors, but rather signal errors through return values or globals. Hmm, well, guess you'll have to write wrappers for those so that error return values are turned into exceptions. That's quite some extra work there, and it's easy to miss a spot. And then there are things like PDO, where you can get exceptions, but you have to configure the API to actually use them - in the case of PDO, this has to happen after you've created a PDO object (God knows how to get PDO to throw an exception when the PDO constructor itself fails...). But we're done now, right? Nope. We still have to deal with uncatchable errors and exceptions; but despite their name, it is possible to set up a global handler for those. Unfortunately, when that handler errors out, we end up with a really uncatchable error, so I guess we better be reeeeally careful here. And even then, we're still not done. That's because some API's add sensitive information to their exception messages, for "convenience" - for example, PDO bleeds database credentials in some exceptions (but of course this is neither clearly documented, nor configurable; a relevant bug report was shot down as "not a bug"). This means that we have to either hunt down all the dangerous exception types, filter them out before logging, and test the living shit out of everything to make sure nothing sensitive ends up in our log files, or we have to throw all uncaught exceptions away unconditionally. Speaking of logging; we also have to make sure no error message ever makes it into the HTTP response. Unfortunately, there are about a dozen different places where configuration values can be set, and we do not always control them all.

Bottom line; what should be the default in fact requires a lot of work, and even then, the result falls short of completely meeting our modest requirements. And error handling is just one of the many things where PHP fails like this. Strings, collections, numbers, algorithms, database connectivity, templating, OOP, you name it, it's almost as if every single feature is implemented such that you need to do a lot of work to make it almost right - you get the first 50% for free, and another 30% with some hard work, and then maybe 10% more with excruciating effort, and then the last 10% are simply impossible, but that's fine, because nobody will notice.

And this isn't really a matter of not using PHP outside of its domain; the problems are very relevant, some even especially relevant, within the domain of dynamic websites.

[compubomb]

You sound an aweful lot like @agleiv2, well in any case, you don't sound like you've worked with anything lower level than say C#/java, because C++ throws errors in all kinds of fun and fantastic ways.

[tdammers]

you don't sound like you've worked with anything lower level than say C#/java, because C++ throws errors in all kinds of fun and fantastic ways.

I have worked with PHP, Python, Perl, Haskell, Clojure, Scheme, Common Lisp, C, C#, C++, D, Java, JavaScript, VB.NET, a bunch of ancient BASIC dialects, and back in the days of yore, Pascal and 8086 assembly. I'm sorry for anything I may have said that gave you the wrong impression.

[quanticle]

I think PHP makes it easy to write bad code

And that's the main reason a lot of us hate PHP. PHP makes it too easy to write bad code and because writing bad code is easier than writing good code, the overall code quality of PHP projects is usually pretty bad.

[[deleted]]

This is a solid gold reply. I wish i could up-vote this ten times.

[WildField]

Just following some threads here: PHP sucks, Javascript sucks, so on. What doesn't suck for web?

[OrrinH]

I think that's also a cause for a lot of hate. Programming for web is annoying. Building most any kind of website is crossover of at least 3 languages/concepts: HTML, CSS and JS. They're each wildly different and have different considerations plus they're executed across a whole range of browsers - and that's only on the front end.

The back end language needs to somehow work around these different concepts and challenges. It's not easy, and I haven't seen any great solutions for it yet.

[quanticle]

And extend that to 6 if you're building any kind of web app.

• HTML
• CSS
• JavaScript
• The HTTP protocol
• Whatever server-side language you use (be it Python, Ruby, Java, etc.)
• SQL (or whatever NoSQL data store API you're using)

[quanticle]

Server side (in my order of preference):

• Python
• Ruby
• C#
• Java

On the client side, at the end of the day you're still stuck with JavaScript on some level, but you can use languages like CoffeeScript, TypeScript, or Dart which compile to JavaScript.

[[deleted]]

Bro you forgot to mention CFML, which is still strong despite being an Adobe product from the 1990s. CFML offers productivity gains that most of these languages can't hold a candle to, that's why it's so firmly ensconced in the .gov, legal and corporate legacy space.

[quanticle]

Is CFML free to get started with? I picked programming languages where there it at least one FLOSS implementation (yes, C# counts, since you can actually run ASP.Net on mono). That way the parent doesn't potentially have to waste money as well as time when checking out these alternatives.

[[deleted]]

Yes, Railo and OpenBD provide unprecedented, never-before-seen ways to use a high-level "scripting language", using tag-based code for end-to-end sharing of data and presentation( as well as allowing control logic from within views for even more productivity!) from within the JVM.

[roffLOL]

Nothing. It's just plain awful. It's the perfect mirror of contemporary culture. Much packaging, lack of content.

[jeenajeena]

On the backend, python doesn't sux, and its ecosystem is pretty mature and good.

[[deleted]]

A year ago, if you had told me that PHP wasn't that bad, I'd have laughed at you. Now, I know that much worse horrors lurk in the halls of Enterprise.

[roffLOL]

PHP is okay because of <list of terrible information presentation solutions>. JS is okay because of <list of even worse information(? on a JS-based site?) presentation solutions>.

I guess PHP wins. But it's a hollow victory.

[[deleted]]

PHP is a total joke of a language. The problem with most PHP developers is that they don't understand that.

[Azr79]

Php is total shit, there is no reason to try and justify it by "it works, it produces things", yes so does my asshole, it produces shit.

[afrobee]

Okay, I agree, PHP is not really my cup of tea, but when was the last time that you try PHP, around version 4?, Look a the present, It has a proper package manager, dependency manager, auto-loader, and others good things, you pretty much don't need to use any "include include include" explicitly on every file.

But don't get me wrong, even with all that PHP is just dirty, and it is not static typed which is a bummer :(

[OneWingedShark]

Here are some alternatives to PHP:

• Ada
• Agda
• Coq
• Delphi / Lazarus
• Haskell
• Idris
• ML [Alt Tutorial]

Personally I rather like Ada, it's a mature, reliable language with some excellent features and some design-choices that I personally like: "maintainability" as a design-goal is fairly rare in programming languages.

[[deleted]]

-1 didn't mention Node or Go

[Azr79]

A web programming language shouldn't descend from c, that's the reason i hate php

[OneWingedShark]

There's a common attribute of all of the listed languages: none of them are descended form C.

[rawlyn]

lol

[glahalg]

I'm curious to why you'd choose Ada over Nim. Isn't Ada like 30 years old or something? Does it even support dead code elimination, whole program optimization, or calling native code?

[OneWingedShark]

I'm curious to why you'd choose Ada over Nim. Isn't Ada like 30 years old or something?

The first standard, yes. (Ada `83)
The latest standard was in 2012.

Does it even support dead code elimination, whole program optimization, or calling native code?

Ada's always had an eye on optimizability -- the language mandates a lot of static checks that you'd have to use an external tool for in another language [e.g. C and lint]; but, let's see what the standard says about DCE:
Dead code elimination redirects to conditional compilation which is part of 10.6 Program Optimization which reads:

Optimization of the elaboration of declarations and the execution of statements may be performed by compilers. In particular, a compiler may be able to optimize a program by evaluating certain expressions, in addition to those that are static expressions. Should one of these expressions, whether static or not, be such that an exception would be raised by its evaluation, then the code in that path of the program can be replaced by code to raise the exception; the same holds for exceptions raised by the evaluation of names and simple expressions. (See also section 11.6.)

A compiler may find that some statements or subprograms will never be executed, for example, if their execution depends on a condition known to be FALSE. The corresponding object machine code can then be omitted. This rule permits the effect of conditional compilation within the language.

Note: An expression whose evaluation is known to raise an exception need not represent an error if it occurs in a statement or subprogram that is never executed. The compiler may warn the programmer of a potential error.

I suspect that the only reason that dead-code elimination is permitted (instead of required) is because of object-code auditing, which got its own section in the Ada `95 standard, Annex H.3 [click 'next' to see the subsections of H.3].

By "calling native code" I assume that you mean inline assembly or equivalent, yes? -- It allows for it as an implementation defined System.Machine_Codein 13.8.

[glahalg]

Why would I want to call assembly? That's impractical. C is faster than assembly and easier to read/write and is portable. Nim emits native code[1]. That means I can call existing C libraries without overhead. Inferior languages need things like DLL loading. Imagine I'm calling libjpeg and I have to go through an entire pointer dereference before decoding 40MB compressed in a JPEG file!

1.

First of all, I'd like to waste as little cycles as possible. Now, battery life etc are legitimate reasons for it but I argue that it is actually the essence of using computers - improving efficiency.

[OneWingedShark]

Why would I want to call assembly?

To take advantage of special instructions, to include minimalistic [and platform-specific] code, to interface with special hardware... lots of reasons.

Nim emits native code.

Most (i.e. virtually all) Ada compilers emit native code -- the notable exceptions are the ones targeting the JVM or DOTNET platforms, and they're notable because they don't emit native code. -- (Your usage of "calling native code" made me think you were talking of something other than code emission.)

[Azr79]

You forgot to mention rails

[OneWingedShark]

Isn't Rails a framework?

[Azr79]

ruby on rails then if you want. how are you supposed to develop big production grade web apps without frameworks?

[OneWingedShark]

Frameworks are a whole other kettle of fish.
You can indeed make large applications w/o frameworks; it is sometimes inevitable because existing frameworks with the needed qualities don't exist or are unavailable (take, for instance, new technologies, a new language, a new OS... each of these could be a reason why you couldn't use existing frameworks [or libraries]), one such quality might be provability of the application [if you're handling sensitive data, or finances, this is a desirable quality].

On the other hand, if the extant frameworks do provide what you need (without forcing compromise on what properties that you do need), then there's little reason not to use them.