> In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say.
Breaking changes (at runtime no less) are the worst way to improve any language. They should have created a new count method if they wanted to change behavior in a breaking way. Forcing millions of developers to comb through their code just because some designer doesn't like the way someone else does something is just narcissistic.
p.s. Semver isn't worth the shit paper its printed on, it can't even version itself and all it does is give shit developers shit excuses to impose their own naval gazing induced shitstorms on other developers.
Perhaps ironically, this attitude towards backwards compatibility is a big part of what held PHP back for so many years and part of the reason why PHP 6 was abandoned during development and PHP 7 used none/almost none of that work.
Instead of introducing a warning and informing the community that a feature was going to change or be removed in an upcoming major update, for years PHP just added new functions. You ended up with `mysql` and then `mysqli`. You ended up with the `mb_*` functions. And in order for developers to properly interface with all of these duplicate functions that may or may not be installed on your system, you ended up with jQuery-like libraries that would wrap certain portions of the PHP language and try to make them easier to work with. The comments on this (and most PHP posts on HN in general) are pretty crappy in large part because of decisions like this. It's also why the language basically died for like half a decade in the late 00s.
It's an absurd way for a language to evolve. At some point, you MUST fix the issues break backwards compatibility. You put out documentation and upgrade guides instructing developers on what needs to be done to facilitate the change. And as developers, we accept that we need to make sure we check that documentation before upgrading and in exchange, we get a better experience for developing new applications in the future.
> And as developers, we accept that we need to make sure we check that documentation before upgrading
Not everyone does. I think I've read a couple times how people commented that Python2->3 was the worst decision made by Guido. (I'm personally grateful that Py3 makes unicode default and more sane than Py2)
With every compatibility breaking release, you run the risk of splitting the language into two. Perl suffered that fate (though not only for that reason), and Python almost did (Py2 is still used in so many places 14 years after Py3 was released in 2008).
This is true. You see this happen all the time with frameworks where the community splinters because of a major change. It doesn't happen as often with languages (perhaps because the average developer feels more removed from the development of those?), but as you pointed out, it does occur.
I think one of the differences here is how active the PHP community is. The Core devs are constantly taking ideas from the community and working those into or out of their plans for the future. They have open periods of discussion for any RFC and will engage with questions and concerns on Twitter and GitHub and Reddit and various other places. Those RFCs are voted on by 30+ different team members and requires a super majority to pass. Everything is transparent. Everything is discussed.
It's not perfect by any means (and the PHP-FIG standards group operated similarly and still splintered due in large part to egos), but it's not as one-sided as other languages and if you engage yourself in the community, you'll generally know what is coming and at least be able to voice your opinion in a forum that will be listened to.
I don't think that having two different count()s with different edge-case behavior is the way it should've been improved. If someone used the method incorrectly in the past it's part their fault for writing it incorrectly and part PHP's that it didn't fail (and "fail" is also kind of a stretch since the behavior was described in the docs IIRC).
Some of the major criticisms most frequently leveled at PHP relate it's convoluted history, the random ad hoc nature of their built-in functions, the inability to enforce types, overly flexible/dynamic, etc all of which can contribute to, among other things, disorganized code.
But then when PHP does something positive to clean things up, we get threads like this. You're damned if you do and damned if you don't.
FWIW, how PHP handled `count` was very well done IMHO. The evolution from having `count` throw a warning on non-countable objects to having `count` throw a TypeError has occurred over several years! No one should have been caught off-guard by this very gradual change.
If you upgrade without proper testing you are the only one to blame. Seems like that blaming PHP is just an excuse for poorly managing language upgrades.
PHP has one of the best track records for retrocompatibility, this is really the worst thing you could pick to blame PHP for something.
For the most part. However one person's bug is another person's feature and given the huge number of PHP users, where many aren't formally trained developers the ways in which PHP is (ab-)used is manifold. Thus sometimes things slip through as Bugfix, which then annoy people. But over recent times PHP got a lot better (maybe since I'm not involved anymore)
Why do they need to remove the whole episodes though? Can't they just put a voice over through that part of the show?
"beep.. beep.. Spotify has had to interrupt this podcast as the next few moments contain words and ideas we deem to impure for our listeners to hear.. beep beep.." and that's why you shouldn't do DMT after eating a burrito.
The answer to that can be found in a statement that Spotify's CEO made during a company town hall earlier this week[1]...
>"A publisher has editorial control over a creator’s content — they can take action on the content before it’s even published,” he says, like editing episodes, removing guests, or preventing one from publishing at all. Ek noted that Spotify does have editorial control over the properties it owns outright, like The Ringer and Gimlet, but emphasized the distinction between those studios and Rogan. “Even though JRE is an exclusive, it is licensed content. It is important to note that we do not have creative control over Joe Rogan’s content. We don’t approve his guests in advance, and just like any other creator, we get his content when he publishes, and then we review it, and if it violates our policies, we take the appropriate enforcement actions.”
So contractually speaking, they can't edit the content, essentially making it all-or-nothing when it comes to an episode. If Rogan feels strongly enough about having an episode put back up but with the kind of edit you suggested, then the onus to do so is on him, not Spotify. That's the deal that Rogan signed.
