Reading the list of things that worry them makes it clear that it's not so much php is breaking bc than it is wordpress lack of cleaning and linting for so long catching up to them.
I mean seriously the first thing they list as a worry is that arithmetic operators will now throw an error when one (and only one) of their operand is an array or resource (eg array + array support remains, it's really int + array or string + file_descriptor, things like that). This is literally a case that makes no sense in the code ever, not one of the "php used to do something magical for us" but "php used to keep silent about this buffonery", so if your code does that you have bigger worries ...
Almost every single one of those things are easy to fix, in that it requires mostly time not much if any redesign, and almost every single one of those things are also deprecated or on their way out since at least a decade.
> it's really int + array or string + file_descriptor, things like that
I haven't personally used PHP in years, but was curious about this. Based on some quick/dumb experiments it appears int + array has thrown errors as far back as PHP4:
int + array has indeed been throwing errors for a while for the basic arithmetic operations, but not for slightly more complex operations such as modulo, and there are plenty more weird combinations that used to work:
It also sounds as though the internal type checking is going to be a large developer load as well. In PHP7, internal functions return null for type mismatches, and in PHP8, they raise a TypeError. This means going back through every case where they call an internal function and wrapping it with a try/catch for TypeError, in addition to checking for null. That sounds like a pretty significant workload change.
> This is literally a case that makes no sense in the code ever,
Speaking as someone that hates PHP but still appreciates that it has its uses: You’re speaking from one perspective. There are others. That operation is perfectly valid and well-defined in Matlab where it increments all members of the matrix/vector by the scalar.
This is actually a perfect example of why I don't like these magical overloads for what looks like basic mathematical operations.
It's perfectly obvious to everyone what adding 2 numbers does. It works the same in basically any computer language. What happens when you add a number to an array though? There is no universal obvious rule, it depends on whatever was convenient for whoever initially wrote that overload. You just have to remember what it does in this language. Maybe it appends it to the array, maybe it does the operation on the first or last entry of the array, maybe it does it to everything in the array, or does something else entirely. Does it modify the array in place, or create another copy with the change? Woe betide anyone who forgets what it does there or gets it mixed up with another language. Better IMO to at least have functions with clear names for doing these sorts of things.
> There's a long report on Wordpress and PHP 8 and it's not pretty
This is an awkward side-effect of WordPress core team largely neglecting PHP code quality issues for the last decade or so. With good reason – improving such a large codebase is a massive, mostly-thankless task.
I worked at WordPress for half a year, and I'm no expert, but the code reviews there were more intense than any I've ever experienced. Every line of code gets reviewed before it gets committed, and if the commit is longer than 20 lines or so, it undergoes an additional scheduled review as well as pre-commit review. They also have pretty good code sniffers that ought to catch errors like OP mentioned.
The reason they're concerned, I think, is because they try to protect users who have plugins that came from their plugin repository, where the same code quality rules don't apply. WordPress has always been huge on backward compatibility.
> A fear of breaking things means WP shies away from large-scale changes that would help it become a modern-looking PHP app.
They are strongly advocating Javascript as the future of WordPress right now, so I'm not sure if they would like it to become a modern looking PHP application.
I'm working on some of these "future of WordPress" projects right now, and I don't think PHP is going away any time soon. The JS-future for WordPress is more to do with the editing experience than anything else -- the entire rendering pipeline, backend, and rest API is still PHP, and I'm not aware of any plans to change that.
The main difference with the future of WordPress is that instead of templates (which describe the structure of a site) being written in PHP, they will be written as blocks so that they are user-editable. I would say it's more apt to say that "blocks" are the future of WordPress. The block editing experience is written in JS, but serialized block markup is backwards compatible with HTML, so no JS is needed to render blocks once they are serialized.
> The reason they're concerned, I think, is because they try to protect users who have plugins that came from their plugin repository, where the same code quality rules don't apply.
Then start making the quality rules apply. Or produce code quality ratings for plugins and display them for people to make decisions on.
Making sure that WP can keep working with lower-quality plugins in the name of 'compatibility' just ensures that WP is, at best, a mixed-bag.
It's a tradeoff they've made. Allowing the plugin store to be a free-for-all creates a very low barrier for entry, and the marketplace is thriving and well populated as a result. They've added metrics you can use to assess quality, in the form of compatibility reporting, user reviews, stars, etc.
> And so people who ... wish PHP was a different language are the ones influencing language development.
That's definitely been my impression. I used to be a professional PHP developer, still use it occasionally for personal projects, and appreciate the language, warts and all, even if I can't truly say I love* it -- but I'm only half-joking when I quip that PHP has evolved from its roots as a cargo cult version of Perl into a cargo cult version of Java.
> - but I'm only half-joking when I quip that PHP has evolved from its roots as a cargo cult version of Perl into a cargo cult version of Java.
It's a joke in so far as it is funny - but it's absolutely correct. When you only look at the language... When looking at the VM, Java has an absolutely world class VM, with great engineering and decades worth of research poured into it.
I was definitely talking about the syntax. I'm not a huge fan of Java (as I suppose the joke already demonstrated), but I also notice how many places start out with PHP or Ruby or Python and end up moving to, if not Java, a language running on the JVM. So I still appreciate it. :)
To give PHP its due, it can be very fast -- although the more you use it "the modern, right way," the slower it seems to get. I can't help but wonder how much of that is an impedance mismatch between "your program starts over from scratch with every HTTP request" and "structure your program so that by the time every class is instantiated and interface is implemented, ten thousand lines of code have been processed with each request." No matter how great its optimization and caching may be, a Laravel or Symfony app just has a whole lot of overhead relative to any framework in another language that doesn't have PHP's zero-state approach.
"by the time every class is instantiated and interface is implemented, ten thousand lines of code have been processed with each request."
Haha so true... the first time I stepped through a running Laravel app line-by-line in debug mode in order to understand it better, I was worried my F11 key was going to wear out ;)
The JVM is not tied to Java, which I think was a large part of adimitrov's observation. Kotlin, Scala and Clojure immediately come to mind. JRuby is also a fairly popular platform for Ruby. There's actually a huge list of other languages that run on the JVM, though.
What are you talking about? Java has raw strings (autoescaping) https://openjdk.java.net/jeps/378
Moreover Kotlin allows to have a state of the art language in a state of the art vm
Having no stake in this, I think that's a mistaken way of going about things. Wordpress is PHP's killer app. If people aren't getting involved, php team should consider outreach.
Part of the problem is PHP has no team. It's determined to be a meritocratic loose organisation of individuals, and so there's no entity to do outreach.
It's not my favoured governance model, but it is what it is.
I think the other reason non PHP devs think we are in the dark ages is because when they google it, our documentation looks like it's from 2010. It's a bit of a joke really.
One other thing I always found iffy is the comment section. Why is the information there not reviewed and back-ported into the documentation? Sometimes, as on the page of the `DateTime` class, they actually contain crucial details!
Why would you expect performace improvements? Because of JIT? There's no reason to hope that JIT would help with that much, because it's I/O-bound anyways. And function calls in PHP are pretty efficient.
Oh, come on. Did you see the benchmarks? This is CPU-bound code, like multiplying numbers 100 000 times over. This has nothing to do with your typical use case.
And, yeah, performance improvements are always advertised.
Wow, that Wordpress blog is bad. I have seen a lot of projects add support for PHP 8 in recent weeks and they were all kind of easy. Mostly waiting for upstream packages to be ready.
You get nice warnings for years about stuff to fix. If you ignore them because that is easier, there comes a point where it is so bad that you cannot recover.
I know the Wordpress codebase is nasty. But how and when are they going to fix these things? It is going to be so hard.
I mean seriously the first thing they list as a worry is that arithmetic operators will now throw an error when one (and only one) of their operand is an array or resource (eg array + array support remains, it's really int + array or string + file_descriptor, things like that). This is literally a case that makes no sense in the code ever, not one of the "php used to do something magical for us" but "php used to keep silent about this buffonery", so if your code does that you have bigger worries ...
Almost every single one of those things are easy to fix, in that it requires mostly time not much if any redesign, and almost every single one of those things are also deprecated or on their way out since at least a decade.