[1] https://mobile.twitter.com/antirez/status/122328600521977446...
* If you wanted to scale it horizontally, it was ready to do that 15+ years ago
* No problem running it completely stateless
* Deploys are completely sane and predictable, it's just a bunch of files, and even when composer came along it didn't really change that too much
* Performant enough as far as the interpreted web languages go
* No problem writing a RESTful backend in it and fronting completely "modern" client facing tech on the top if you want
* Server side rendering since day 1
Like, it came down to people complaining about some function names / param orders as if it were the end of the world. I think a certain subset of people (shall we call them hipsters?) are just keen on finding new ground where they can rewrite the same boring things instead of working hard to improve the ecosystem of something existing.
I moved on from PHP aeons ago because it got this undeserved bad rap, but I still follow it and would welcome the chance to run it again.
There was plenty of wrong with PHP. There were very unsafe defaults, poor API choices, poor coding standards, inconsistent syntax, paper-thin C bindings that didn't provide the level of abstraction you'd expect from a scripting language etc... If you've forgotten what PHP used to be you can just take a trip down memory lane by browsing through this classic: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ . Lest we forget PHP was started as a templating engine that evolved haphazardly into a full fledged programming language, and it showed.
If you think PHP is a good language today then say that, but let's not pretend that the complaints and ridicule were always undeserved.
It's a question of when do you let that go?
The bitter truth for PHP stans is that it is what it is, you can get things done, and you can have valid reasons for using it (like legacy reasons, job market, etc.), but it's rightfully trending down and will continue to.
This was absolutely the killer app for PHP. It was lucky enough to be well integrated with Apache, and crucially could run as a non-persistent per-user interpreter behind the web server. This made it exactly ideal for deployment in shared hosting environments. The fact that you can't do this with e.g. Node forces all sorts of containerisation yak-shaving on us.
People tried to do this with a few other languages, such as Apache mod_perl, but PHP was the one that thousands of cheap shared hosting providers made available, letting people get started with web development.
It succeeded, as it's often the case in IT, not because it was the best, or even very good, but because it was easy to adopt and had a killer feature.
"Messy Api" is discussed above ("it came down to people complaining about some function names / param orders as if it were the end of the world") so I won't comment.
"terrible default": would be interested in specifics here
"wonky typing": every scripting language had wonky typing 15 years ago, and many of them still do today. This has never been a valid criticism of PHP when comparing to it's primary competitors.
"no namespace": THIS is a very valid criticism. PHP really wasn't a sane language before they added namespaces. But... they added namespaces 11 years ago.
Or multi-byte compliant methods that are a variants, and not the standard method, thus biting anyone who just thought utf-8 would be default.
"terrible default": the poster child for this is register globals, which it took ages to have off by defaults. That's just a single line to set it properly, but that was part of the boilerplate that could have been avoided way earlier.
Overall developing for PHP meant to defensively remember a ton a weird stuff, just like javascript was for a while. I am so glad we mostly got past that, even if I am not in PHP anymore.
String encoding though is, again, something other languages had similar gotchas with. Remember we're comparing PHP to its popular alternatives at the time, not to our hypthetical ideal runtime.
The bad defaults you and a sibling commenter are referring to (magic quotes) are, again, from 11 years ago.
Sure, 15 years ago PHP had serious issues, but here we are today acting as if they didn't fix most of them over a decade ago.
Recall that the defense of PHP in this tree leads with "There was never anything wrong with PHP, really."
That's because the context was the state of PHP 15 years ago.
Magic quotes would be the first one I can think of off the top of my head, which incidentally, was made a default because the mysql api in PHP was so prone to sql injections, that PHP decided to automatically escape all user input as a way to protect inexperienced programmers.
Pretty much everyone agrees magic quotes were a bad idea and they were eventually deprecated in 5.3 and removed entirely in 5.4.
How many scripts continue to prohibit apostrophes in passwords because there used no way to reliably instruct devs on how to handle apostrophes in strings? People named O'Brien still can't enter their names in forms and expect to get it back despite magic quotes being gone years ago.
Nowadays, modern php is conservative but fine. But it was really a terrible choice in its early days, when every one of its selling points was a misfeature.
Thankfully this problem was solved back in 2004/2005, but unfortunately shitty code was already pervasive and the “right way” wasn’t heavily communicated enough.
Broke in 7.x because it would now warn now... I don't remember what it returns now but that was a thing...
This release is another step in resolving these problems.
The first Java web shop I worked for had a homegrown version of magic_quotes_gpc. That’s when I realized that those who had gone through making PHP installs and apps secure had very valuable experience.
When I switched from PHP to Python it was an amazing, liberating feeling for me that I will never forget.
"That is the difference between having to look something up" PHP (for 15 years?) has had IDEs that fill it in for you.
https://www.python.org/dev/peps/pep-3000/
No one had to have any problems with the transition. If they did, they had to willingly ignore the in-your-face documentation on the migration process.
I am not against making something not backwards-compatible. I am in favor of throwing old, bad things away even at the risk of having to rework some stuff... But how crazy legacy is at every damn company is just making it so frustrating. They will happily just wait it out for 14 years and then complain about their Python2 being desupported
Looking at the Python standard libs vs the PHP standard libs, PHP used to be a bad mess. Other than that, it's still brilliant.
- the way mutable default arguments are handled
- the weird behavior of closures referencing loop variables
- leaking variables out of if/for/with (yes, i know it's convenient, but can bite sometimes)
- GIL stuff
- exec not being able to introduce new local variables (yes, i know code-objects have their local variables decided at compile time, but it's surprising if you don't care about that implementation detail)
other than that i can't think of many "insane" behaviors that can bite you. i'm curious what you're referring to!
and sure, i'd change a lot of the language to make it more FP-friendly if i could, but being what it is, the semantics seem pretty unsurprising most of the time
Yes, nice you can have Python-adapted editors where ident levels can be tuned, but no, it's still a big defect
Your editor can help you with the editing. (And the problem you mention are exactly the same, if you write production code in other language. Your teammates will hopefully insist on consistent indentation in C or Java as well.)
It's a problem for some use cases, and even in the web use case, reusing connections to databases and services can be a pain with PHP because it's completely stateless.
pgBouncer and ProxySQL are going to give you a better bang for the buck than a stateful web app will.
You can have an awful implementation of a connection pooler, sure, but opening an authenticated socket is more expensive by far than just referencing one.
Less so for a unix socket/named pipe- but still much slower than a memory lookup.
Of course you probably don’t care until you hit a certain scale or number of backend system accesses.
I'm not arguing for a truly stateful webapp, but the connecting pooling you get for free (or some library wrangling) with a long-lived process does a lot for performance and scalability.
Btw, I do agree with most of the changes Facebook's Hack made to PHP.
Arrays go (needle, haystack). Strings go (haystack, needle). There might be a couple of exceptions but that's basically it.
It’s funny folks pick on the “Magic” in PHP, yet overlook all of it in Ruby. I’m not a PHP guy anymore really (now Python/Rust/Java/Ruby mainly), but I’m still continually annoyed reading Ruby code. Here’s an example:
- find a method being called on a class, so want to find out details on said method
- grep through codebase, find no definition for said method
- grep through all gem dependencies, find no definition for said method
- search web, don’t find any obvious leads
- cry in despair
- finally find that method is handled by a method_missing on a dynamically generated class and never has anything related to the method name even as a string
- flip desk and go home for the day
I mean, your listed points are arguably correct, but this sentence is quite incorrect.
edit: downvoted by PHP fans. It's OK, I get it, nobody likes it when others dunk on their favorite language. :)
FWIW though, you're absolutely right - there was (maybe still is?) an enormous amount wrong with PHP. The only real rebuttal core-questions needs is a link to the classic essay, "PHP: a fractal of bad design" [1], which lists far, far more problems than just issues with function names or parameter order, and does it more comprehensively and with more style than you or I could hope to.
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Edit: I can also imagine this design decision must have had context. Perhaps it was a common technique in low-level programming, as a practical way to save time/space.
On the other hand, if you’re trying to nerd-snipe me into a debate over the meaning of the word “classic”... :)
I’ve gotta disagree with your characterization. At least in the field of jeremiads, surely the criteria can’t solely be timelessness - that’d imply that an essay that successfully inspires change couldn’t be a classic (not that that’s what happened here, I’m not directly attributing anything to anyone). Words are hard to pin down, but I think when it comes to screeds, what’s “classic” could be, in fact, whether it provoked some kind of change - if at the time it won hearts and minds. Or, what’s “classic” could be not necessarily about the specific thing it’s arguing against, but instead about the underlying principles guiding that argument. Or maybe it’s about the style, panache, humour, or clarity with which those principles are argued. Maybe some combination of all of the above.
No one programs with gotos much anymore, but “Go To Statement Considered Harmful” is probably safe to call a classic. America is an independent nation and King George no longer holds the British throne, but nevertheless the Declaration of Independence is certainly a classic text. For reasons of style, persuasiveness, its underlying principles (I think anyone designing a PL should have read it), and its widespread popularity and influence at the time it was written, I think the PHP essay counts as a classic too. YMMV.
If you've got some counterpoints or arguments, please give them. Going "lol php bad" is just dumb.
This isn't contrasting Ruby to PHP, this is contrasting the web that was with the web that is.
And actually, even when Rails was founded the PHP stack was inadequate for this -- which is why current practice includes all the parts that antirez is complaining about? Gems? PHP has composer, barely any serious project doesn't use it. Rack? Granted, once the PHP server is setup you don't have to account for an abstraction layer. Rakefiles? I don't think there's a standard task runner for PHP, but e.g. Laravel has envoy and I would assume that almost any project needs some kind of shim there, even if it's just shell scripts. YAML? Well, erm, ok, I won't defend that…
The times where PHP means directly accessing a `.php` file for every "page" have passed by. If you look for simplicity there, oh traveler, beware…
It's not even a Rails app. No idea what he was complaining about exactly, but certainly not Rails.
Looking at the original app, the Rakefile for example seems mostly to be there to start Redis? How would we have done this in the olden days of the *AMP stack, assuming the task has to run on both Windows dev machines and the Linux server? Heck, we might not have been able to do this at all, if we just had file and not shell access...
> rake
As you say it's a simple task runner like make. Maybe use a shell script instead, but appart from that, hard to be any simpler.
> rack
That's just an interface, the equivalent would be mod_php & co, not any simpler in my book.
> gem
Not sure what's there is to complain about here. It's a fairly straightforward package manager. Unless you stick to the stdlib, I doubt PHP packages are any easier.
> yaml
Many people hate it, but for simple configuration it's not any worse than JSON or XML. Matter of taste I guess.
I'd be happy to hear or more detailed complaint from antirez, but I don't think anything can be inferred from that single tweet. This reads like someone who hasn't worked with Ruby in a while, and is grumpy he has to figure a few things out again.
Wait, are we really calling Ruby/Rails the "is" of web development in 2020?
I've also started looking at Flask and Django of Python, can't help the feeling, that the Python frameworks are a bit more mature in terms of breaking changes.
It has a heap of problems due to mistakes made in the past and - perhaps more worrying - a LOT of misinformation posted on the internet. Then there's the trope of PHP developers always building their own frameworks and CMSes and the like.
And I'm dealing with a big legacy codebase where the original author did not understand separation of concerns (or sql injection for that matter), with constructs like a switch returning a different SQL query depending on a string value, globals to store the result in (which is concatenated XML transformed to JSON at the bottom of the 5000 line file, which in turn includes thousands of lines of additional code). And the project was started in 2012, when modern PHP and frameworks were already a thing.
I'm doing new work in more neatly organized classes at least.