The problem is that PHP wasn't designed as language-first but as a tool to make web development more accessible. Hence the acronym for "Personal HomePage". PHP was merely a native interface to modules written in C (e.g. MySQL), with the interface hosted in a simplified version of Perl.
The draw of PHP was that you didn't need the CGI bin, and it was easy to deploy with Apache.
Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.
If you are still writing PHP in 2019, you are either very unfortunate or just very lazy.
As you said, PHP was merely an interface to (many already existing) modules written in C. When people complain about mysql_real_escape_string() in PHP they don't realize that that is the actual name of the function in the MySQL C API. Same with the image functions (imagemagik). And so on. Some are named directly after the corresponding C standard library function.
This was actually part of the huge success of PHP -- it made available, for the web developer, a huge library of existing open source technology. This did not exist, in a scripting language, before PHP. The open source community wasn't as large.
But PHP does have high-level abstractions and, like with other languages, you would also use a framework that has high-level abstractions.
If you compare PHP to JavaScript, PHP's standard library is far superior. But it's a ridiculous comparison there as well.
> The problem is that PHP wasn't designed as language-first but a tool to make web development more accessible.
Yes, but all the ways that PHP as-a-language were less than ideal most of those have been solved now. So unless you're complaining about the standard library, there isn't much left.
> Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.
Nowadays there really just isn't that much difference in design or performance between PHP and the majority of languages you would suggest.
Lexical scoping
Coroutines
Generators
Decorators
Generic type containers
A functional API (e.g. something like Java 8 streams)
An extensive selection of data structures (collections) included in the standard lib
?
Yes.
> Coroutines
No.
> Generators
Yes.
> Decorators
No.
> Generic type containers
In progress. But also PHP has dynamic/weak typing and static/strong typing so this isn't strictly necessary.
> A functional API (e.g. something like Java 8 streams)
Available as a 3rd party library.
> An extensive selection of data structures (collections) included in the standard lib
My opinion remains unchanged. Using PHP in 2019 only puts you at a disadvantage when compared to the alternatives.
Coroutines are not necessary in PHP. In fact, the share nothing architecture of the LAMP stack is one of it's advantages if that suits your needs.
The setup of a Java web stack alone is painful enough to make PHP a viable option in comparison.
What is PHP's concurrency model? Is it still a forked process pool via something like PHP-FPM, or has it changed?
Does the VM enforce a GIL? I'm assuming there is some kind of threading API?
Can you run an event loop using epoll, and is the standard library well supported in that execution model?
FYI, I was a PHP developer from 2003-2011. I did enjoy it back then. I never bought into the Rails hype at the time, opting instead for copycats like Yii and CI.
But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.
It may be the nature of the work, but I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.
As far as I'm aware PHP is still mostly run PHP-FPM. It also does have a threading API: https://www.php.net/manual/en/class.thread.php
> But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.
I haven't done PHP seriously in a very long time. I currently work in C# and ASP.NET for web and I do C++, Python, and JavaScript. Personally, I'm doing work in Python right now and I don't enjoy it very much -- I'd much rather work in PHP for web development over Python. I prefer a good strongly typed language.
> I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.
I don't know. PHP has Lambdas. It has generators. It was strong typing. From a CS perspective, there isn't much PHP does not have for the purposes of web development. It's limitations, in my opinion, mostly come from being a dynamic scripting language but those same issues befall Python and Nodejs as well.
If I had to code in PHP again, my code wouldn't look much different from my code in any other language.
I think if you're building CRUD apps over and over again, then yeah, there isn't too much difference.
But if you're building a web service with more complicated business logic and you need more control over your concurrency model, then other languages look more appealing.
And it looks like PHP doesn't have JIT yet, which is another huge mark against it.
So PHP is probably fine for passing params and rendering back HTML. But anything sitting in between that's more interesting should be built in something else.
To be fair, we are talking about standard library consistency and not language consistency. PHP is a consistent language but it's standard library is very low-level. In Python, you don't call the mysql C library functions directly, you use an object-oriented abstraction. In PHP, you can call those mysql C library functions directly or you can use an object-oriented abstraction.