Inconsistencies in the standard library. When PHP was young, its audience was most familiar with C, and many APIs used the C standard library’s design language
They don’t mention this bit of hilarity about why some functions are named the way they are. Of course mentioning that probably wouldn’t help in their goal of taking PHP seriously.
Holy shit. That explains so much.
I last used PHP 10+ years ago and haven’t looked back. I did not find this post very compelling. Most of it was just assertions, “php does X and X is good”. The thing is, if Slack wants to use PHP, that’s fine, I don’t care. But everybody doesn’t need to write a blog post about why they made every decision. Some decisions don’t have a particularly cogent argument behind them, it was just what was chosen at the time. Blogs like these try to make it sound like every decision was well chosen and considered all the variables when, in reality, whoever was at Slack at the time probably just knew PHP and that was that. I worked for a company that was a big user of Erlang and they had talks at conferences about how their problem fit Erlang particularly well and it’s a great asset, and oh come work for us if you want to work for a company that values Erlang. The reality is: the people who were hired to write the first version of the service only knew Erlang so they wrote it in Erlang. All these talks are just trying to back-rationalizing an arbitrary decision.
Lots of newbies won’t even look at PHP because some higher-up is screaming down their throat about how it’s a bad language. This post isn’t going to work for people who already discounted the language, but it may inspire someone who didn’t even bother with it.
This post isn’t going to work for people who already discounted the language, but it may inspire someone who didn’t even bother with it.
That’s a shame.
Which part is a shame? The first clause, or the second clause?
I agree with you, but I would further posit that the real takeaway here is that language doesn’t really matter most of the time.
To some degree I agree. But to take a wider view, of the thousands of languages that exist, almost none of them are suitable for production use, so in that sense the language does matter. What you probably mean is something along the lines of languages with a big enough community aren’t as much of a risk as people would like to believe. And that is probably true. I think PHP is a story not of a bad language not being as bad as people like to say, but of a bad language that has enough determination behind it can be tolerable.
I think Tony Hoare is informative here:
At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way — and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
“The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.”
The most reliable systems ever made for running business apps include AS/400, VMS, and NonStop. They huge monoliths. QNX was one of best, high-reliability microkernels. It was simpler but not simple. The RCA 1802 was a high-reliability device for embedded that was fairly simple. Ran slow as hell (3.6MHz). Recently, AAMP7G by Rockwell-Collins implements secure, stack machine with fault-tolerance inside that’s much faster (100MHz). Takes over a million transistors.
I think making high-reliability stuff takes more complex design and code since you have to be more explicit + prevent many failures + handle erroneous input + maybe add stuff for syncing redundant hardware. Hoare’s advice is good for correctness of individual components or modules but not overall reliability.
As with any pithy statement, one shouldn’t take it too seriously. I included the whole quote for completeness, but the important part is the bit about determination. People will push through a lot to make something terrible now less terrible. On top of that, I’ve noticed that once someone makes it out the other side and survives, they’ll do back flips to somehow make the whole thing seem positive. I first noticed this a few jobs ago where one team kept on making fires and putting them out and people insisted this was evidence of how good they were.
For your actual statement on simplicity vs reliability, I cannot speak to the hardware situation, but in the software systems I have worked on it has been clear that those systems which are generally believed complicated were much less reliable than the simpler systems I used/designed. For example, the team above I mentioned had layers on layers of complex code. The team I was on put a lot of work in trying to keep the system simple enough to keep in ones head (we failed but the effort was useful) and we had far fewer incidents and they were almost always small in nature.
Maybe what you are seeing is the fifth 9. At this point getting 4 9’s out of a system is often pretty straight forward, but that 5th or 6th nine can require some pretty significant changes that probably increase the complexity to some degree, but I don’t know.
Oh I agree that simplicity helps. It’s a standard part of high-assurance engineering. That’s for correctness, though. Just adding the components that deal with failures and attacks drives complexity up quite a bit over a simple, non-checking, let-it-fail solution. The functionality and safety mechanisms can also interact in strange ways where they become like their own program to test. Much like distributed or multithreaded systems.
“At this point getting 4 9’s out of a system is often pretty straight forward, but that 5th or 6th nine can require some pretty significant changes that probably increase the complexity to some degree, ”
I don’t know either. Interesting idea. Is this a maxim somewhere other than the 80/20 rule? Because one of INFOSEC’s founders, Roger Schell, said the something similar about the A1 requirements GEMSOS had to meet vs retrofitting an existing solution for high-security. He said the first 90 percent might be easy but the last 10% of requirements will be hard or maybe even impossible if not baked in from the start. Seems to be a recurring theme.
Just adding the components that deal with failures and attacks drives complexity up quite a bit over a simple
I think this is the difference between “simple” and “as simple as it needs to be”. This goes to the whole essential vs accidental complexity. To bring it back to this specific thread: PHP has a lot of accidental complexity.
Is this a maxim somewhere other than the 80/20 rule?
The way I see it is that 4 nines availability is kind of an industry standard, so most of the technology stack has been, either by design or the invisible hand, gotten to the point where stitching them together to get 4 nines is pretty well understood and it works. But I’m kind of making this up, it’s just my intuition telling me that.
I tend to agree, it’s more often large differences that will really matter (typing system, major development environment…), saying that, I’m a huge language geek, and php does not float my boat ( Even if it’s my day job)
Everything written in the “Virtues of PHP” section is not specific to PHP, but it applies to all CGI based approaches.
PHP, by being embedded in the webserver (classically, and now logically) has performance & deployment advantages over pure CGI.
I have a hard time trying to take this post seriously. Have we jumped back a decade when it was cool to hate on php? Dirty little secret everyone, 9 times out of 10 end users don’t care what your application / website / service is written in. If you (and possibly your team) think you can use X tool / technology / architecture and it won’t come back to bite you, by all means use it.
Yup. End users don’t care, but developers you try to hire to maintain your code surely will.
End users don’t care what technologies you use to implement, but they do care how easy it is to react to demand for new features, how quickly the site loads, how often the site is down, etc.
Which is why a high developer performance language like PHP wins.
I don’t like PHP but this post helped me to take it seriously.
Honestly I found PHP’s syntax and control surfaces to be maddening - file-get-contents() etc just drove me nuts. It’s the naughties - we have objects for that. Why is there still a procedural API for 99% of what you do with the language day to day?
That said, I can’t deny the respect I have for the people who use it and use it well. I worked for a company that was the software vendor behind the donations processing for the Obama campaign in 2012 - PHP stem to stern.
The problem isn’t that you can’t write software in PHP (you can achieve everything with enough determination), it’s that you are restricting your hiring pool to low-quality developers (might not matter if you never need to hire anyone).
PHP 4 and 5 were terrible languages. It looks as though they’ve made many improvements, but I’m still hesitant to try it again. On the other hand you can build great software in any language. The Symfony framework for instance is a beautiful piece of engineering.
Also, uniquely among the MPDPLs, there is a clear migration path to a higher performance, safer and more maintainable medium in the form of Hack and HHVM.
Umm. No. Ready counter-examples include Cython and Pypy in the Python space.
On the whole though I thought it was a well written article. He actually makes some salient points about why one would want to use PHP despite the fact that it’s a hodge podge of paradigms all mashed together in a giant ball of goo.
I think phabricator uses PHP and lots of people hold that in high regard.
I like how he mentions the HHVM and Hacklang. I haven’t actually run any PHP on HHVM (benchmarks make PHP7 look better anyways, but I should still probably give it a shot). I have dabbled in some Hack and I really enjoyed it. If you come from PHP, you get all the comforts you remember from the SPL, and if you come from other languages you don’t have to deal (so much) with all the stuff that can leave a bad taste in your mouth from PHP.
The three main arguments in favor of PHP are: no shared state, concurrency, and programmer workflow. The deficiencies are mostly around the language itself but HHVM fixes this. Couldn’t one make the same argument for other languages? You could use Openresty with NGINX and write your embedded server in Lua. PHP definitely has a much bigger ecosystem than Lua but the ecosystem is hardly mentioned and I think that’s a big factor when choosing a language.
Also what server do you have to run PHP in? Apache?
Also what server do you have to
Recently I came across this comic strip, How to Save the Princess in 8 Programming Languages, which one of the languages is PHP.