Ah, finally, John came along and posted the best What’s-Wrong-With-PHP rant I’ve ever read. However the article does list it at the end as an update.
So, looking at those, let’s say a New Wave of PHP devs (core devs) came along and mutinied and decided to pull a Guido. Would that be so bad?
Honestly I don’t see Python suffering from having a 2x and a 3x branch. Fixing unicode and a few other big things in 3x just allowed Python to get so many more things added to it. The users are today usually split by framework, or up-to-dateness: if your framework doesn’t support 3x yet, or nobody’s upgraded your machine yet, then you’re still using 2x. Most machines are running both the 2x and 3x interpreters now. Someone started a wall-of-shame listing frameworks who still aren’t 3x compliant yet… that number is growing pretty steadily. PHP surely has a larger userbase and prolly larger dev-base… could be done quicker maybe?
PHP has enough wrong with it that, even if most experienced PHP devs feel more than confident that they aren’t bothered by these wrong things because they know the language well, a break in backwards compatibility with PHP6 could be accepted. If anything, the more experienced devs would accept it and probably the newbies or lower-level devs would be the ones most against it. And maybe hosters
Since I started in Javascript, == was in fact nice to use with form data. Everything inputted in forms is a string, even if you asked the user for a number. Since JS is on the front and your backend should always really be checking tainted data, letting == just check if the user’s “2” is equal to 2 was useful and nice. No, we don’t want to be told that string"2" is not the same as number2 — we know that already in this case. Sometimes you really just want to know if two things are equal, even if they are not the same. The mistake is probably using similar-looking operators. == vs ===? Python decided, use == to check for equality, use is to test if they are the same thing. How many times have we seen new Javascripters saying exactly what the OP said? Lots of times “Wow, I really should be using === whenever I can” etc. Usually after reading The Good Parts or after getting bitten.
At work, we just manually convert things before trying a comparison anyways. We’ll never take some form control’s “2” and test equality: we’ll try int(theFormData) except (whoops it’s not even really a number in any way shape or form) and then compare, which is slow and safe(r). With strings we’re always worried about unicode anyway (using 2x) so depending on how much work we want to do, there’s stuff going on before comparisons there as well. But otherwise, assuming I know what I’m doing, I should be able to ask if two strings are equal (even if they are stored as separate objects in two separate memories), right?
One little hiccup in Python tho, dunno if PHP does this: sometimes small values are sort of “cached” (they’re called interned strings, some sort of compiler optimisation) where if you say x = 2 and y = 2, they may indeed be referring to the same object in memory, so x is y will return True. Whoops. This is usually small values and only when in the same scope, but still…
What the article states PHP is doing, though (converting two strings to longs and doubles) is definitely wtf material. You’d think it would check type first, and only attempt interpolation after seeing they are not the same type? I thought Javascript did this. Perl does this: tries to compare, oh can’t they’re not the same type, sees if it can convert one of the things so they then are the same type, try compare again. Javascript seems to have crappy rules for who it converts to what, resulting in cool stuff as seen in the WAT talk.