We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs.
I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide
critical pieces of your money-making infrastructure."
Perhaps it isn't about being paid, but about taking pride in the work you do.
PHP is convenient. I use it for some piddly shit because that's what it's good for. This bug report highlights the problems you run into if you use it for serious work.
Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress).
I mostly program in Python these days, but I used PHP for years beforehand without much drama. I even enjoyed it at times. Yes, I do have a Comp Sci bachelors degree and I probably should care more - but I found it a lot more interesting not to have to deal with fiddling around with servers in order to perform my job.
The critiques of the language aren't baseless, but plenty of large startups manage to do just fine with PHP.
TLDR: Languages are meaningless penis measuring contests of the IT world. If you will ship faster and better with language X, go ahead and use it.
> If you will ship faster and better with language X, go ahead and use it.
Absolutely, by all means, go for it. Godspeed.
> Languages are meaningless penis measuring contests of the IT world.
No they're not, and this is just insulting. I'm only an amateur PL nerd but there are people who have devoted their lives and careers to studying languages and thinking about the differences between them and how to design something practical, consistent, logically sound, beautiful, etc. To brush aside that work as meaningless is pretty narrow-minded. After all, some of that work helped even lowly PHP to stand taller on the shoulders of giants, and make it even possible to be a reasonable tool.
He meant that not in the context of Language Research, which is super-awesome and every developer should be super grateful to researches in this space, but in applied programming, where people piss on whatever language they aren't used to using/think sucks for some arbitrary reason.
But the lines between research and industry or "applied programming" aren't that clear cut (look at how much Rich Hickey's been able to mine the veins of research and bring awesome ideas to a practical and well-designed language like Clojure). I think some healthy debate, which includes pointing out languages that have severe flaws, is important and I wouldn't want to discourage it from happening, especially not on HN. I certainly don't think it needs to be dismissed as "meaningless penis measuring contests". That debate should definitely be carried out politely, of course. I'm not defending incoherent language flame wars.
I'll bite. PHP's automatic type conversion is a severe flaw.
The intent was to make it easier for beginners to pick up the language without worrying about technical details like types, but it violates the "fail fast" principle. It might make it easier for beginners to write code that works some of the time, but at a cost of making it harder to write code that doesn't break in surprising ways later. It's not just that automatic coercion exists, but that the behavior is biased toward returning values that don't produce errors. Treating the string "three" as equal to the number 0 is very unlikely to be the desired behavior. Even if not emitting an error is desired, a contagious NaN value would make a lot more sense.
There are certainly ways for an experienced user to mitigate the problem, but beginners don't know them, using them effectively requires discipline and a great deal of production code doesn't use them. The latter problem is cultural, but the language being tolerant of sloppy code naturally attracts people who write sloppy code to the language.
No, I absolutely was not defending language like "piddly shit". I was attacking language like "meaningless penis measuring contest". I think neither has a place on HN.
I have nothing to say about PHP (because I've never used it) I was reacting to a specific comment in jbm's post, which generalized languages and debates around them. Sorry for derailing the thread from the topic of PHP, and I probably shouldn't have made a little dig with "severe flaw".
>Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress).
That's clearly nonsense. The people who point out how terrible PHP is have huge, very detailed and very accurate lists of the problems with PHP. They don't get that from "never dealing with it".
>If you will ship faster and better with language X, go ahead and use it.
We do. Why do you think that means we shouldn't point out how bad PHP is? Did you know that for every stubborn dumbass that sticks his fingers in his ears and screams "LALALALA I CAN'T HEAR YOU!", there's an inexperienced developer who didn't know how bad PHP was or why, who was inspired to learn more because of that "PHP bashing" post, and who subsequently saved years of hardship by switching to a sane language? Just because you don't want to hear about how shitty PHP is, doesn't mean nobody else does.
Actually, most of those lists are based on PHP4 or older (meaning their opinions are fully eight years out of date; a LOT has changed) or are made irrelevant by changing one or two quite well-documented confit settings. The little that's left over are mostly complains that PHP isnt something that it's not trying to be (strongly typed, most commonly)
The only legitimate complaints I read as someone who uses an up-to-date version tend to revolve around the wildly inconsistent naming conventions, and a couple of extensions with rather poor documentation. The recent releases (5.3, 5.4) really did a lot to make it just as feature rich as other scripting languages.
If you want to use something else, be my guest. But I for one am tired of the misinformation that PHP bashers spread. I happen to like a language that doesn't get in my way, has extremely thorough documentation, and almost any question is answered in the first search result. At the same time, I hate the lack of documentation on the actual source (I have a few things that are a huge pain to do in user land, so writing a native extension is a huge pain), and of course the wacky parameters and return values on the old functions.
>Actually, most of those lists are based on PHP4 or older (meaning their opinions are fully eight years out of date; a LOT has changed) or are made irrelevant by changing one or two quite well-documented confit settings. The little that's left over are mostly complains that PHP isnt something that it's not trying to be (strongly typed, most commonly)
Sounds an awful lot like you are just ignoring the things you don't want to hear. It isn't just that PHP is weakly typed, it is that it has absurd type conversions that no other weakly typed language does, that aren't even consistent, and explicit casts don't serve the expected purpose of forcing the correct type:
PHP is full of bugs. Ancient bugs that have existed since PHP3, and which are still there. Serious bugs where the lexer or parser is outright broken:
$ perl -le 'print 07'
7
$ perl -le 'print 08'
Illegal octal digit '8' at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
$ python -c 'print 07'
7
$ python -c 'print 08'
File "", line 1
print 08
^
SyntaxError: invalid token
$ php -r 'print 07;'
7
$ php -r 'print 08;'
0
$ perl -le '$foo = 1; print(($foo == 1) ? "uno" : ($foo == 2) ? "dos" : "tres");'
uno
$ php -r '$foo = 1; print(($foo == 1) ? "uno" : ($foo == 2) ? "dos" : "tres");'
dos
PHP is written by absolutely incompetent developers. There were 37 exploitable vulnerabilities in 2011. Compare that to 3 for python, 3 for perl, and 7 for ruby. Steffan Esser was the only person attempting to make the PHP project give a shit about security, and he ended up giving up on it because the other PHP devs absolutely refused to consider security as important.
These are not problems that are fixed in recent versions of PHP. They are not misinformation. If you want to revel in your ignorance, feel free. But don't expect the rest of the world to tip toe around the facts to avoid inconveniencing you with reality.
"Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress)."
Well that's the biggest piece of bullshit I've ever seen spewing out of someone's keyboard here on HN. I've been developing in PHP pretty much since it came out. At least, since it was stable/useful enough for people other than Rasmus to use. I've been using it for so long that I absolutely hate it. The inconsistencies, the "bolted-on" OOP, the amount of time I'm just sitting there scratching my head wondering where the fuck my data went to, and not even being able to test the thing since there's no good testing libraries built for PHP. It's all a confusing mess that I refuse to even be paid for at this point.
Often, the best tool in web software is the one you can get the most/cheapest labor for so you can actually get your product completed and on the market.
No one cares if your software is programed in the latest tech with the very best techniques - all they care about is if your business is viable. PHP fills this niche excellently.
As a developer I make my living off PHP. I'd rather play with nicer languages, but frankly that isn't where the money is where I am.
Don't get me wrong, PHP is a joke of a language, but I don't see Rasmus as the one behaving childishly here, and I also don't think he's in the wrong. APIs are allowed to change in major releases, and the behavior the plaintiff was relying on was so clearly broken it boggles the mind that he would riddle his code with dependencies on it.
Even given that it was undefined behaviour to start with, it's the very first incompatible change listed at http://au2.php.net/manual/en/migration53.incompatible.php — you'd hope a professional developer would at least glance at that document when migrating a codebase to 5.3.
> Even given that it was undefined behaviour to start with
On the other hand, 1. high-level languages have no reason to have UBs, especially for the trivial calling of a core function and 2. one could expect behavior in this context to be coherent with behavior in userland contexts. In PHP, using strings in a numeric context wasn't — last time I checked — considered abnormal, no matter how little sense it makes. One could therefore expect the relevant coercitive calls to be performed as they would usually be.
> it's the very first incompatible change listed
It is very ambiguously worded: the clause states functions will return NULL when passed incompatible parameters, but in all of PHP's userland code strings are very much compatible with floats. I would therefore submit that — in the context of being a user of PHP — the clause does not apply to this case as the value passed in is absolutely compatible with parameter expectations.
> When a string is evaluated in a numeric context, the resulting value and type are determined as follows [...] The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero).
> 0 is hardly the standard identity value.
0 remains the standard and defined numeric value of an arbitrary string not prefixed with numeric data in PHP.
If a function in case of bad inputs returns a value in it's codomain, you can't distinguish it from a value returned by a normal call (except in cases where it falls outside of the functions image). This in my opinion is same as undefined behavior. Don't trust the value returned, if inputs were bad.
You know, I didn't actually know that. Thank you for enlightening me.
tools shouldn't rely on undocumented behavior when passing out-of-spec parameters into functions. Relying on such behavior eventually gets you what you deserve.
Or one could expect the language to behave coherently (tall orders for PHP, I know) and consider that it will use whatever is provided to it in the usual manner in which it treats non-numbers in a number context. Especially when the function has behaved in this manner for a decade.
As you note, one of the problems most cited with PHP is core language functions behaving in a non-coherent/non-consistent manor. This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently. It was documented, done in a major release, and done alongside a number of other (well publicised) breaking changes. Not everyone is going to be happy when things change, but I think this was a sensible development decision for the PHP team.
> This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently.
Well technically I believe it was done to unify argument parsing, but so far so good.
> to make it behave more coherently/consistently.
except this made all argument parsing (and especially this function) less coherent and consistent with PHP-the-actual-language: in PHP userland code, a string in a numeric concept will be implicitly converted to a number (to 0 if it is not prefixed by digits). This function used to behave coherently with PHP itself, as a language. Now it doesn't anymore. So all built-ins behave one way, the language itself behaves in the opposite way.
> It was documented
Not really, there was a note indicating plenty of shit broke (and it was ambiguous, the note says things about passing in incompatible parameters, but as far as PHP-the-language goes strings are compatible with floats), not listing functions which broke and in which manner.
With regards to consistency, aside from the fact that I don't think its easy or necessary to compare how functions deal with arguments to how syntax operators etc. deal with values, the situation prior to this change was that there was no consistency even within core functions themselves, before you even start to consider the rest of the language. This could have been resolved by changing all the other functions rather than these few, but that would have messed up a lot more userland code than this change did. I think it was the most pragmatic way of dealing with the issue.
With regards to the documentation, I'll concede that it could have been better. The previous behaviour was undefined and completely undocumented, so I think there are lessons for both "sides", 1) for the PHP team : fully document all changes, even to previously undefined/undocumented cases 2) for the users : don't implement functions in ways that are not documented (and/or santize input/validate output from functions used in such ways).
Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.
> This could have been resolved by changing all the other functions rather than these few
What "these few"? As far as I know there is no list of the functions impacted by the change, how do you define that there's just a few versus not just a few of others?
> but that would have messed up a lot more userland code than this change did.
Because ponies? Where does that arbitrary and unsupported assertion come from exactly?
> I think it was the most pragmatic way of dealing with the issue.
Why? And why was it an issue in the first place?
> The previous behaviour was undefined and completely undocumented
The previous behavior was implementation-defined (as pretty much all of PHP is) and had been stable for a decade. And as I noted above, it was also coherent with userland behavior of PHP when dealing with strings in numerical contexts.
> Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.
Which, for all intents and purposes, mean they're compatible with floats in most numeric contexts.
From the bug thread that this story refers to, Rasmus states "Most of PHP was using this already, but there were still some stragglers like number_format()". I think my arguments regarding impact of the change are a reasonable extrapolation from that.
Why was it pragmatic? Why was it an issue? There was inconsistency in the ways that functions handled parsing, and many people didn't want that feeling it made it harder to code correctly/consistently, thus it was an issue (part of the greater issue of inconsistency across a number of aspects of PHP). For others it wasn't an issue, which is why a pragmatic solution is the best that could be hoped for, not everyone would agree/like the outcome whatever was done (or not done). I can't see any other way of taking the language forward whilst causing minimum impact to users, which is why I (not you) think it was the most pragmatic way.
Every piece of code we write is "implementation-defined", including the bugs. It wasn't coherent with most other function implementations. Users couldn't reliably treat functions in the same way. I agree it wasn't coherent with numerical operations, but to get that consistency you would have to change a whole load more functions, and you would get many more complaints like this one.
"For all intents and purposes" - I think this discussion (and the many others that have featured on HN talking about similar issues of the weakly typed nature of PHP, such as == vs === ) show that it there are real world consequences to treating strings and numbers as compatible.
> We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs.
Well that's pretty much PHP in a nutshell, no news there.
I'm pretty disappointed to see comments like these around here, and not getting downvoted. This comment adds nothing to the conversation, and criticizes PHP with no factual basis or explanation.
So how would you propose changes are made to an "API"? Never? The change was made in a new version, with the changes clearly laid out in the changelog .. what more do you want?
It's funny. PHP gets a bashing for the rotten bits .. when the rottern bits get patched up it gets a bashing for breaking BC.
Anyway, I don't think you understand just how empty that attack was. Frankly it was nothing more than the ramblings of an obviously very inexperienced developer.
Bad code style will eventually get you in trouble in any language or environment, bugs can occasionally turn into features and updates will always require testing, this is not a PHP specific problem at all.
"This bug report highlights the problems you run into if you use it for serious work"
Why? Because they fix bugs that break backwards compatibility? What's your point? That to do "serious work" you need a language that never changes or that you need a language that gets everything right the first time?
Of course can do whatever you want in PHP, you just need to account for its faults and shortcomings. If you cant do that, no language is going to save you.
Unfortunately PHP is consistently inconsistent. It lets people do that, and it won't ever break. Until they "make it right".
Sure the guy didn't test the parameter as being empty, but if you pass a string instead of a float, an error should be raised, and that never happened until the fix. That's the big problem with PHP :/
"Sure the guy didn't test the parameter as being empty, but if you pass a string instead of a float, an error should be raised"
Just like you should not pass strings in place of numbers, in accounting software of all things. Why can't just everbody get it absolutely right the first time?
Any language that can do anything also allows you to shoot yourself in the foot. And I think that was the case here, brainless programming; PHP hardly pulled out the rug under something reasonable in this case, they simply defined previously undefined behaviour... and when that happens, that always breaks crappy programs that depended on it, no matter in what language they're written. It's the big problem with idiots; PHP has nothing to do with it.
>Just like you should not pass strings in place of numbers, in accounting software of all things. Why can't just everbody get it absolutely right the first time?
Because the input is a text box? Text is, after all, the way for people to input data into a computer.
It stills shows a lack of rigour on the part of the developer. A simple "empty()" and "is_numeric()" check should be done on any user input expecting a float BEFORE you pass it off to a number formatting function expecting a float.
I think the actual translation is: "You're writing retirement planning software and you can't even handle changing a method call that's been patched to a version of your own creation which preserves the legacy behavior? Get a new job."
I know you're joking, but his point is very badly made. Anything that can support ~1 billion users is not piddly. Facebook are doing amazing work with PHP, as are many others at a very large scale.
Why the unpaid work of Rasmus and many, many other open source contributors like him, who's hard work facilitated the growth of massive web sites like Facebook, is constantly being ridiculed on threads like this is sickening.
"Facebook uses it, it can't be all bad!" is a stupid argument. Because the rest of us have to deal with PHP's not-Facebooks, whose flaws are made more frustrating because of shit tooling and the systematic encouragement of shit practices in the writing of code.
It is too bad if people complaining about PHP makes someone feel bad.
What's really important here is that people need to be aware when they are adopting a tool which brings this much technical liability.
People should not be unknowingly exposed to this relentless stream of years-old, fatal bugs. Life is too short and it's even more unfair to newbies to make them deal with nutty, random issues like 'can't use a Turkish locale'. This isn't just picking on PHP. These bugs are epic and breathtaking and impose an exceptionally high amount of effort to work around.
It is clear by now that
(A) these are not just a few isolated bugs but a big pile
(B) most of this pile is old and already known for years
(C) the PHP team is not fixing the pile despite lots of time
(D) it would be such an epic amount of work to fix that you could never reasonably expect others to do it, especially if they have no reason to be invested in PHP (how is that reasonable?)
(E) you could never get the fixes and cleanups published because of all the existing code which would be broken, unless PHP adopted a risky, even more labor-intensive backward-incompatible renovation project
(F) there are already multiple well developed alternatives which do not have these problems, so why would I wait for PHP to get its house in order?
I'm not saying that PHP sucks and could never be fixed.
I'm saying that PHP doesn't have enough positives to justify the huge time and effort to fix it... or to suffer through using it for years. There is no third choice.
Why on Earth would I bust my butt trying to fix this pile of bugs when I can just use anything else?
Just because I feel sentimental about the name 'PHP'?
This is a slowly sinking ship, it is not responsible to tell newbies to get on it.
I agree. I was commenting on Facebook "the social network" and not Facebook the "technology".. :) Anything that can be made to support such large transactions (be it with duct tape and glue) has to have a core capability to support such usage.
It is important to keep in mind that Facebook isn't just a single PHP code base, and thus one can't really make many assumptions about how well PHP is suited to solving certain problems because one doesn't necessarily know about which bits are implemented in PHP, or whether PHP is just a templating/rendering stage over work done elsewhere.
Some other languages might allow you to do certain operations in the front-end more easily, but the way to approach it when using PHP might be to delegate that to a back-end service in another language. Similarly, some languages might allow you to write both most front-end and most back-end software in the same language, where PHP might be wholly unsuitable or makes certain things harder to achieve than it is worth using it for (maybe strict memory usage control, maybe where you're looking for CPU cache wins).
In all fairness with enough hardware you could serve ~1 billion users using virtually any language which supports development of web applications. Just because you can develop a hugely successful system using a language doesn't prove (or disprove) that said language is necessarily the best tool for the job. It just happens to be what FB picked.
Right, you could use BASIC or any Turing-complete language.
Actually, BASIC has been written so many times that you would probably get a pretty sane and systematic experience out of a web BASIC. Relatively speaking.
The question is whether someone is saying that you can't use the PHP language/architecture to create a large and large-scale application like the Facebook front-end, or whether they mean the PHP runtime is unable to perform effectively at scale.
The Facebook front-end code is largely just the PHP language (modulo things like XHP) and follows the shared-nothing, request-based architecture that people who program in PHP expect. With the right abstractions and code organisation, it is fairly clean and understandable even at the relatively large size (even if I'm not generally a fan of the language and would almost certainly not make the decision to use it today).
It is somewhat less interesting whether the PHP runtime is as efficient as it can be. Partly because one can use an alternative runtime like HipHop for PHP if you want to. And partly because very few people have to worry quite as much about performance/efficiency that comes with a large capital/operational cost where you have hundreds of servers.
So while "But Facebook uses PHP so it must be good" is not the best argument, neither is fighting it with "But Facebook reimplemented it!".
This is example of the PHP team working to fix a common criticism of their language: that it's full of inconsistencies. And when encountering push-back from users who depend on those inconsistencies, the developers have stuck to their guns.
i think you miss the larger point... any half way decent developer would never have this issue - breaking changes happen on every platform - or you should assume they will. use encapsulation properly (i.e. actually encapsulate, not just use a keyword meaning 'class' in the OO sense) and problems like this require single line of code changes to fix.
even if you have them scattered across your code base what you then do is realise that you have failed to encapsulate a platform dependency, then encapsulate it, then fix. even on multi-million line code bases this will not take a month. inexperienced programmers are terrible at estimating tasks like this, which often take less time than you think, and less time than it feels has passed as you are doing them.
php is a fine language - the various arguments i've heard against it boil down to "i'm to shit of a programmer to do my job", either by choosing the wrong technology or not being able to just suck it up and get on with making stuff work.
> even if you have them scattered across your code base what you then do is realise that you have failed to encapsulate a platform dependency
Take this line of reasoning far enough, and you're saying wrap every PHP function in your own function, so your programmers program in your synonym language instead of PHP, something like CoffeeScript vs JavaScript, perhaps.
I don't think using PHP (or any language) directly means you're a "shit programmer".
I think the care Python has taken between 2.x and 3.x is a better example of the type of care and concern and community awareness building around this exact sort of change that a language's benevolent dictators (Larry, Rasmus, Guido) should take when altering the philosophy of how the language should behave.
"Perhaps it isn't about being paid, but about taking pride in the work you do."
Even if you take pride in what you do you expect to be treated with a certain level of respect. ( Not that being paid means you should be disrespected of course. )
>Here's how I read it:
We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code
Really? You read it wrong. It is "he have a public API that had a bug --that only surfaced when using it in a brain damaged way, anyway-- and we fixed it along with doing several DRY improvements to our code base. We also gave ample time of advance warning with our beta releases".
"so if it breaks your stuff then tough shit because we're a bunch of amateurs."
An ad-hominem? And its Rasmus that cones out as a little child, to your "mature" reading of the situation? Priceless.
>I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure."
Perhaps it isn't about being paid, but about taking pride in the work you do.
That includes fixing bugs and brain damaged edge cases of the public API.
The complainer and your reading are so off the mark, I can't even begin to comprehend such attitudes exist...
> > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com
> Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net