[wvenable]

> The thing that matters is language consistency.

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.

[codesushi42]

That's irrelevant. When talking about language consistency, we should also be including the language's standard library.

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.

[wvenable]

> That's irrelevant. When talking about language consistency, we should also be including the language's standard library.

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.

[codesushi42]

Genuine question, because I do not know the answer. Does it support:

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

?

[wvenable]

> Lexical scoping

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

https://www.php.net/manual/en/book.spl.php

[codesushi42]

Thanks for the thoughtful response. But based on your answers, PHP does lag significantly behind other modern languages. FYI the SPL you linked is quite meager compared to languages like Python and Java.

My opinion remains unchanged. Using PHP in 2019 only puts you at a disadvantage when compared to the alternatives.

[wvenable]

Honestly nobody uses the SPL. PHP's array type is more than powerful enough for the vast majority of data structure tasks and the standard library has functions for treating it as a stack, a list, etc.

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.