Put the == on the ground, back away from the keyboard!

I agree with this. The problem is, the PHP developers are in an awkward position. If they fix some of the fundamental language problems they risk breaking backwards compatibility and considering in PHP we’re lucky enough to be able to download a script written in 2001 and in most cases it still work today, coupled with the fact there are many many websites running very old code. Any major backwards incompatible change they make will make people wary of upgrading. Look at how slow adoption of PHP5 from PHP4 was. It was only a month ago that PHP5.3 became more widespread than PHP5.2 and PHP5.3 has been out since 2009.

PHP can fix the problems, but it will take quite some time for the world to adapt if they do. And… the longer we leave it? The more potentially incompatible code is written and the harder it becomes for any businesses to upgrade.

I honestly don’t know what the answer is. At the moment, the implication from the PHP developers is that their attitude is “Leave it flawed and don’t break other people’s stuff”. Which is a fair sentiment, even if people here and elsewhere don’t agree with it.

.NET has gone through similar circumstances and it withstood the test. 1.1 to 2.0 had breaking changes, 2.0 to 4.0 also had breaking changes. Yes, it took time and money to ensure your application could survive, but we simply did what most businesses would do. Install both, and take your time to move over to the new version.

PHP could do that, but really, it may not be a big deal for the PHP world and the group that is complaining might purely be complaining because we work in other languages relatively often and we don’t see these idioms staring at us in those languages (granted every language has their own idioms). I personally hope sometime in the future they try and fix some of the mess contained within, let PHP become much more, the world seems to want it… as it sure took to it quickly.

The == I found amusing and also the return values of numerous functions require work-a-rounds to get the function to do what you want it to do :slight_smile:

I was familiar with C and Pascal before starting with PHP and found the non-declaration of variable types remarkably difficult to comprehend or to even use confidently. Even now after quite a few years I still think that declaring a variable type and have the compiler scream when the type was used incorrectly would be beneficial.

Also the lazy practice of assuming undeclared variables, even Visual Basic had some optional declaration that variable had to be defined before usage.

I am also surprised that nobody has mentioned the amusing and informative article referenced in the original post:

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 :slight_smile:

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.