PHP 8.1 Benchmarks - Continuing The Nice Performance Trajectory

[Gass]

So, after some PHP debating for how bad it is ... what language do you use to do web backends?
Python + whatever framework?

In my point of view there are two streghts in PHP that other languages don't:
1 - The way http requests are dismantled and passed to the programmer in variables or easilly accessible.
2 - Session management
3 - sheamless integration with html and css.
3 - standard C like syntax (like c++ or c#, i enjoy python, but i miss the braces)

From what i experienced in other languages, the one that have these features is asp.net but ... again ... a CGI approach.

[grigi]

What's wrong with it?

I think a lot was expectations. I expected something more consistent, less verbose, and more dynamic typing like e.g. Python.

Instead it has an autoloader functionality that is surprising in that sometimes things need to be explicitly imported, but sometimes defining a namespace will break code (e.g. phpunit). Everything is camelCase, except it's not. There is no way to introspect an entire object that you have. (e.g. you get some object, but it isn't clear what you can do on it). Typing gets enforced on method calls, but everywhere else it's a type hint. It's REPL functionality is a different language, so you can't do small quick prototypes in the REPL, because they don't translate directly. The class system reads almost exactly like Java/C#, but feels completely unnecessary as you can break interfaces with almost no penalty, so its brokenly used in nearly every library. Tracebacks are... just about useless. Especially if more than one exception got thrown you end up with a literally broken traceback that doesn't even flow. Low level global methods are sometimes missing, due to e.g. a compile flag, the OS you are running on, or the bloody php.ini file. Missing in a useles way as in calling them will just return a null sometimes, and sometimes resolve as a null (and throw an exception at the right place). surprising behavior where an optional type is inconsistently either X|null or X|false.

It betrays the law of least surprise far more than I feel it should.

[uid313]

I think a lot was expectations. I expected something more consistent, less verbose, and more dynamic typing like e.g. Python.

Instead it has an autoloader functionality that is surprising in that sometimes things need to be explicitly imported, but sometimes defining a namespace will break code (e.g. phpunit). Everything is camelCase, except it's not. There is no way to introspect an entire object that you have. (e.g. you get some object, but it isn't clear what you can do on it). Typing gets enforced on method calls, but everywhere else it's a type hint. It's REPL functionality is a different language, so you can't do small quick prototypes in the REPL, because they don't translate directly. The class system reads almost exactly like Java/C#, but feels completely unnecessary as you can break interfaces with almost no penalty, so its brokenly used in nearly every library. Tracebacks are... just about useless. Especially if more than one exception got thrown you end up with a literally broken traceback that doesn't even flow. Low level global methods are sometimes missing, due to e.g. a compile flag, the OS you are running on, or the bloody php.ini file. Missing in a useles way as in calling them will just return a null sometimes, and sometimes resolve as a null (and throw an exception at the right place). surprising behavior where an optional type is inconsistently either X|null or X|false.

It betrays the law of least surprise far more than I feel it should.

I believe PHP is just as dynamic as Python, any typing in PHP is entirely optional.

PHP just defines a hook for the autoloader, it is up to the project implementing it to define the behavior. I am not sure that had anything to do with your autoloading problems. On the other hand, I think it would be nice if PHP had a default autoloader implementation so it was easier to use PHP without having to use include statements when not using a framework or having to write your own autoloader.

Yes, there are some things that are inconsistently named, things sometimes camelcase, sometimes underscore, sometimes without underscore, like str_replace and strpos, but its is very old stuff from the early days of PHP.

As for introspection, you can use the print_r() function to get information about an object. There is also reflection.

As for the other stuff, I wasn't aware of it, thanks for bringing it to my attention You have some good points.
It seems PHP definitely still have some flaws, but on the other hand, it has improved a lot from the old days.

[Alex/AT]

- Euhm, autoloader functionality is totally not surprising if you expect it - and it's not builtin, you need to code it explicitly for it to work. Yes, PHP is dynamic language, it is not railed to pre-built bunch of code governed by static makefile, and so it can load modules on demand without much hassle. Loading dynamic modules in railed languages is usually a bunch of hell. Especially if you need i.e. different flavor of some module per request.
- Everything is camelCase - if you want it. If you don't, it's not. It's okay, man, no need to rail anything there. Not everyone favors camelCase contrary to the belief.
- Enforcing types is only for those who can't live without it. I never ever had any urge to do types enforcement in PHP, as it is designed as dynamically typed language, and having dynamic types comes VERY handy where you need it. I can pass specific object instead of array into method accessing array keys and be sure it WILL work how I want it if the both parts are designed with this possibility in mind.
- Interfaces are kinda supplementary, yeah, and it's rather easy to overextend them indeed, but again remember it's a dynamic language where parts are subject to easily change without rebuilding the whole project. Interfaces are more like hints in PHP, and I hope they'll stay just as such.
- Exception tracebacks are single path tracebacks, so you indeed must make sure you don't override exception in exception handler. PHP is no Java, and as the typical model is per-request handling, you usually don't need to propagate your FATAL exception up to the topmost handler stack, transforming it a lot of times. Although I indeed wish for some easy way to throw another exception preserving and continuing the traceback from another one.
- Missing methods is different thing. If you have your own project running on your own infrastructure, this is no problem at all as you can have a PHP runtime build suited exactly for your own needs. If you run your project on third party runtimes and servers, then indeed you must take care some features may be missing or be disabled as insecure. This comes from the runtime flexibility: it's a glue towards dozens of C libraries, and of course missing some library (runtime 'compile option') will make your calls to it fail. You install dependencies when you deploy some project, don't you? The same is with PHP runtime, to use some extension or feature, you need to install it as dependency. If someone doesn't, go with your own VPS and build and the problem will disappear. PHP also allows flexibility of disabling potentially dangerous methods, but most people around have enough understanding to avoid or conditionally use/replace/emulate these.

So in short, most of the expectations come from disregarding the language dynamic nature. These expectations can be applied to 'classic' railed compiled languages, but no, PHP is not one of these.

[Alex/AT]

For builtins naming, that's actually what you get when tying C naming with camelcase naming
C programmers utilize legacy underscore naming scheme mostly up to nowadays, and as big part of PHP is wrapper glue around C code, you should expect it.
Also, changing builtin naming is almost impossible, I hope you understand why It can be duplicated with other naming, but that usually ends in a naming ambiguity and was chosen not to do it seems.

[grigi]

As for introspection, you can use the print_r() function to get information about an object. There is also reflection.

Its way less introspectable than a Python object.

So in short, most of the expectations come from disregarding the language dynamic nature. These expectations can be applied to 'classic' railed compiled languages, but no, PHP is not one of these.

I came from Python most recently. The issue is that modern PHP is trying to be Java, they implement very Java-like features in the class structures, whereas its actually a dynamic language, so much of the features serve no benefit.


But more importantly, I was asked why *I* found PHP disappointing. I answered. Then immediately was told that I should have expected less within minutes by 3 posts within minutes...

[Alex/AT]

It's not about 'expecting less'. It's about 'expecting different'. PHP is not Java, nor trying to be Java, that's it and that's why.

[Degra]

So, after some PHP debating for how bad it is ... what language do you use to do web backends?
Python + whatever framework?

In my point of view there are two streghts in PHP that other languages don't:
1 - The way http requests are dismantled and passed to the programmer in variables or easilly accessible.
2 - Session management
3 - sheamless integration with html and css.
3 - standard C like syntax (like c++ or c#, i enjoy python, but i miss the braces)

From what i experienced in other languages, the one that have these features is asp.net but ... again ... a CGI approach.

As far as jobs are concerned, Java backends are the leader, at least in Europe / Germany.
The line between simple "web backends" and "enterprise applications" gets kind of blurry, since enterprise apps these days are developed with web technologies in mind, but they provide the bulk of (especially well paid) jobs.

[curfew]

Maybe Python, Node.js (JavaScript), and Ruby? If one really wanted to push it, then maybe Perl and Tcl.

Obviously they aren't viable alternatives when you have to list every single language that you know of just try to cover some ground.

[sicilian_najdorf]

You start a project and you have to install Node, then Next, then write nextconfig in your root directory. Then there is another package for styling. The package requires you to write another config file in your root dir. Then you have to go to node's config file and import a function there and wrap the whole configuration with that function that comes from the styling package.

JS is still very much behind PHP when it comes down to the environment. It is not as developer friendly and the frameworks are not as opinated which adds to the configuration hell since you have to choose your own ORM and such and, with all those choices, comes a myriad of configurations.

In general, PHP frameworks are still miles ahead of what javascript has to offer IMO.