Going from zero to functional web backend in less than 3 hours for a language I'm almost totally unfamiliar with made me understand just why this got so gosh darn popular. I thought building out a Flask application was fast, but PHP's initial experimentation loop is just on another level, criticisms be what they may.

A breath of fresh air in amids of thousands of "ew, such a bad language" and "a fractal of bad design", the latter being incredibly outdated and still referenced from time to time.

I love PHP, it was my first language and it's one hell of a productive ecosystem to be in. Laravel is an excellent choice for rapid prototyping and Symfony is probably one of the best web frameworks for enterprise projects. Paired with coroutines extensions such as Swoole/OpenSwoole/Swow it puts one hell of a fight performance wise with more modern languages.

Modern PHP is great, the past & some fundamental decisions are automatic tech debt that i can live with. It'd be great if PHP 8.3 gets forked with no backward compatibility, removing all the old PHP as a template engine designed functions that nobody needs & release under a new name. I just can't find the same type of joy in writing code as i do when writing PHP. But some things are truly annoying. Just not enough for me to switch or start the fork myself.

Obviously, PHP came from a place of great inconsistency, and the remains are still there, including the popularity to rant on it. PHP is getting significantly better though, and while a long one, I hugely prefer this route over something more abrupt like python 2-3. The first 3 or so points are valid, but annoyances at best. For the points about closures, statements, inline classes etc., they are just features from other languages that aren't in PHP.

The "living on a prayer" comment on serialization brought back memories. It made me acutely aware that I use this pattern in go, and there it "just works". I now have a note to go see what Valinor, PHPStan, Psalm, Serde are because they sound godlike.

Great disclaimer, since most of the points raised in this article seem very nitpicky to me. This is understandable considering that OP's PHP work is about creating a language server and some benchmarking tool, both of which are definitely not the main use-case for this language. I bet your average PHP dev has no idea about the things mentioned in this article, nor are they interested in improving them.

Same goes for container data types. All you've got is array. No sets, no hashmaps, ordered sets, sorted sets. Array is just all of this at the same time. There's also an extension for that, but its API is... not optimal. I wonder how much faster some programs could be if the array wasn't used as the universal data type.

If one could use composer to install PHP extensions, that would be awesome. I fiddled around with WASM as a language for universal PHP extensions that can be loaded via composer, but there does not seem to be a lot yet.

Although it does require some boilerplate, which may seem like pointless extra work.

Oh but they do. You should spend some time with those languages so you can do a proper comparison.

Go has had new for a while now.

In sum, the native functions should take iterators anywhere it can take arrays.

Every other valid criticism he makes and many more I can wrap in the simple statement that: psalm needs to become the runtime type system which is hopefully and appears to be the (maybe distant) future.

In the meantime you have 40% and quickly growing of those features in your IDE and 100% in your CI so it’s not a huge deal.

Main takeaway for people who haven’t looked at PHP in 10-15 years or since the fractal article and would take the length of this post, which they don’t understand, to say “yep dumb php again” no.

—————

Constructors Only had this confusion once with my UUID library and it took me 3 seconds to remember the formula.

"In attribute land this becomes:" I've never seen any code or library that uses attributes like this nor do I understand why you would. The only purpose would be static analysis, let's say with psalm, and that's just not how you use attributes in psalm. He says generics are tricky: in psalm they're trivial. The real problem is the best IDEs are still working on getting the integration right.

Nested attributes strikes me as an extreme edge case that would only come up in some meta-level tooling you're making for the language which is the provided example. However in this special case presumably this can be accomplished through an extension, xdebug for example does this.

Serialization he says is a problem then says, it's a solved problem (there are many such accepted ways to solve this) but then says it still annoys him so not sure?

"No Variadic Promoted Properties" I'd like to hear the use case for. I've done very complex things in PHP and never needed this construction. A property can't have a static single type but then also consist of a collection of random types, in this case it would just be an array. It looks like another feature that is solved by psalm.

Iterator to Array: Preserve Keys he says he doesn't know if it's wrong.

Iterators vs. Arrays this is easily fixed by using the popular Functional library versions of these functions which I agree should be the default.

Short closures cannot have statements" I have to convert between them so I kind of get it but would say this is an intentional choice. You can substitute a method call if you really want this.

"Statement Blocks in General" That would be nice when and if it's very simple though having them anywhere could turn the language into kind of a mess to read considering what those blocks could contain.

Functions that return false - basically everyone agrees on this, it's a conversion that's iterated on with each release and will just take time. The specific example he provides I have wrapped with an exception thrower for just this reason and never use the default.

Inline Classes - he says he doesn't know if it's a good idea. I'd say no, having a reliable file system convention between codebases is a plus not a minus.

That said, I'll comment on the code style this author wants to use. It's flashy, confusing, and unnecessary. This person wants to show proficiency with the language by using all its features. That's not how you write good, readable code. Come up with some personal standards for yourself and stick to them. Stop mixing every possible style. You're increasing cognitive load.

Continuing on, you want to use all the latest features of the language. That's great, but why are you trying to skin the cat three different ways in the same program? Pick one way and forget the others. If you can't fit all your code into short closures the rest will look like shit and confuse everyone else. I see this all the time with JS guys mixing bracket and dot notation. I feel like there is probably medication that can help with that.

Then we get to the fact that you want everything to throw exceptions. Like file_get_contents. No. Just no. You're not supposed to rely on that function to tell you if the file is there. That's what file_exists does. If you've made it to file_get_contents and you don't know if the file is even there, you're doing PHP wrong. You can use that function with a URL and eval to execute remote code. You're not supposed to swing it around like a broken bottle.