I can understand why people make this into such a pain point, but quite frankly it isn't for anyone who works day in day out with PHP.
Yes, it's technically a non-zero problem. I get it. Having spent several years in the Java/Spring world, the classic ASP world, and the Perl world... they all have problems, both with the languages and the ecosystems. There will always be people who will throw out Rust or Go or Erlang as 'better' by some metric.
For the types of projects I work on, the modern PHP stacks of the last 5-6 years are all probably the best ROI. Colleagues/friends are running medium-sized SaaS on Rails, and it works, but we compare headaches sometimes, and it's not carefree in the Rails world. There's issues there. Regardless of whether your language is 'clean' or 'discoverable', the rest of the ecosystem can still present problems.
That said, I don't have is a lot of experience with other frameworks in other languages to compare it to, so I don't exactly know how it compares.
Anyone that works with PHP on a daily basis very quickly gets used to some of the naming differences or inconsistent signatures. Anyone that works with PHP rarely is almost assuredly going to have to look it up regardless of how inconsistent it is. (do people really guess at function names, signatures, and return values in other languages!? I've guessed that they exist, but I don't ever think i've tried something without first checking the docs just to see about any surprises or differences)
Consistency is nice to have, but it's pretty far down the list of requirements in my opinion. If it's different for some, I can see how they wouldn't like PHP, but calling for it to "clean up" it's syntax in a giant "python-3-esque" move seem really misguided. People who program in PHP regularly don't really mind the warts, and the language has improved significantly in areas that it's users found most important. Types slowly working their way into the language, easy closures, traits, nice new operators, and the massive speed and memory usage improvements have all been very welcome improvements that have made me more productive in the language.
The time spent on "cleaning up" the standard library would be a welcome change by most, but it wouldn't really have any material impact for me or any of the other PHP devs I know.
IMO pragmatic is good, especially when you have to use an existing code base and you have to upgrade it to the latest supported version you don't want a Python 3 migration story(I migrated a medium project to latest version and the only problem was a cryptographic function that was used to generate some random looking strings that was deprecated, I replaced with the new safer function and done , my project is now compatible with the older and the new version).
Have a look for example http://image.intervention.io/getting_started/installation how you would resize an image if you used a framework, it is much different then you would see in a code that was written 20 years ago.
And that still doesn't solve the problem of bad blog posts... You can't control what others write about the language, and if someone writes some posts or has a website with bad information, the maintainers of the language can't "fix" that. The best they can do is what they already do, make sure the PHP documentation is among the best and most approachable of the languages that I've used.
Though if you work on a new project or existing project that uses a framework you will not even need to do the bad search queries like "how to insert an user in a mysql table", the framework is forcing you to use the correct/safe patterns.
Most beginning level tutorials are super simplified and are not following the correct patterns, like they don't check for errors, don't clean user input etc.
If you are an anti OOP person then I would prefer not to debate here religions.
People keep saying it was a huge failure, but honestly, I don't see how it was supposed to be done better otherwise. Either you make breaking changes that will impact your entire ecosystem or you don't and live with the same cruft from 20 years ago.
Then once someone had (say) python 2. 6 I'd know they also have python 3.2, and I wouldn't have to figure out that name of the executable to call, it would just be python, with (perhaps) either a command line option or a comment at the top of the file.
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.
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.
And yet, here we are over a decade along and the Python project is still maintaining Python 2 and I still need to maintain a copy of Python 2 on my computer because of the number of actively maintained projects still using it. How many developer-hours that could have gone into doing something else have instead gone into this "language consistency" project?
At any point in the past 25 years someone could have forked PHP to clean the syntax up and accomplished the exact same thing -- and yet apparently nobody has seen the inconsistency as a big enough issue or time sink to do so. I would take that as prima facie evidence that this isn't nearly as important as you seem to think it is.
Meanwhile, one of the strengths of PHP in my opinion has been how carefully they have maintained and managed backward compatibility. While "move fast and break things" might be the new norm, there is still a huge contingent of developers and businesses that see value in slower, more considered change.
So, it's apparently a good reason to hate, but by no means a reason not to use PHP.
Yes, PHP has been "cleaned up" and you have always had the option to use clean, concise way of coding without language interfering or hindering you in any way.
There's no programming language out there that makes up for the sloppiness and inability of the person behind the screen.
str_replace(old, new) vs. stri_replace(new, old) kind of thing.
Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.
The only thing that would have really interested me in this post would have been to hear that PHP had been cleaned up into a consistent syntax, but that's not what this article says.