Love this snippet: > > 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
Rasmus comes across as a little kid. 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 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…
The behavior was deprecated with a warning for how many versions?
Absolutely agree, and that's PHP's biggest issue. It is constantly doing things like this instead of simply complaining and stopping things down like any sane system would. If I were in charge of PHP, release 6 would be 5.4.4 with the standard library happily throwing exceptions on invalid input. That's it. The language would be 100% more useful instantly.
As mentioned to parent: then you'd have a lot of work to do to clean up one even more widely used language : )
You mean JavaScript, right? Reading this conversation I was wondering how no comment would point at the same or bigger similar issues in JavaScript.
I think there are two bigger issues: 1.) Things like this should not be warnings in the first place. There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways. 2.) The php.net documentation for number_format doesn't even state that NULL is a possible output value. And I can't find anything in the change…
I don't have a strong opinion either way, but I don't think #1 is a given. You describe one reasonable approach to building things: bad shit should blow up quickly, forcing fixes. But another reasonable way is working to make sure something reasonable happens. E.g., Postel's Robustness Principle: http://en.wikipedia.org/wiki/Robustness_principle My understanding is that PHP started out as a noob-friendly page scripti…
If they were going to take that approach, it should have returned 0 then.
I think of this as "garbage in, garbage out". The function will return a numeric value -- if you give it proper input.
On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
Here's to not using PHP for anything serious! The whole point of a dynamically typed language is that arguments could be of any type. Language built-ins should account for this. Of course PHP doesn't and shouldn't be expected to. The fact that Facebook, MediaWiki, and WordPress are so successful is still a mystery to me.
> The fact that Facebook, MediaWiki, and WordPress are so successful is still a mystery to me.
The fact that some developers think the language chosen has much effect on the success of a site is still a mystery to me.
There are countless reasons to bash on PHP because, frankly, it is a pretty terrible language[1]. However, this is not a valid reason. The bug reporter is being idiotic and needlessly disrespectful, and is making a big deal out of something that can be easily fixed with a simple `sed` command, as Rasmus demonstrated. And, to be honest, he is clearly demonstrating the fact that he's a pretty poor developer, and that h…
A bit off-topic: As someone who has built a decent web company on top of PHP, I'm curious to know if you decided to leave it for something else and if so, what was your reasoning?
I'm of the mindset to stick with what I know best when I'd rather build a working product and get it out the door quickly. I don't actually personally care too much what language I use (I feel like database selection is more crucial) but I read about so many startups running on Python or Rails that I'm starting to wonder if there's something I'm missing and if there are business advantages to using other languages/frameworks.
Don't sweat it. 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 w…
> 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 someth…
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.
Headline of this post is totally false and this is not even a bug in PHP, it's clearly a bug in the poster's code, so Rasmus response is right. If you actually try doing this in PHP you get this: print number_format("",0); Warning: number_format() expects parameter 1 to be double, string given in Command line code on line 1 So the poster willfully ignored the warning. You can fix this simply by casting the first arg…
I think there are two bigger issues: 1.) Things like this should not be warnings in the first place. There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways. 2.) The php.net documentation for number_format doesn't even state that NULL is a possible output value. And I can't find anything in the change…
> There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways.
It's trivial to turn all notices/warnings/errors into exceptions in PHP (it even provides an exception class for it, ErrorException). PHP is multi-paradigm and supports many different ways of handling errors and warnings.
> This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily.
This change was to make the output of functions consistent based on invalid input. It's specifically addressing this point. It's also the very first point listed in the migration documentation
> I use it for some piddly shit because that's what it's good for So do Facebook.
And his point still stands. :) Could not resist.
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.
I think there are two bigger issues: 1.) Things like this should not be warnings in the first place. There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways. 2.) The php.net documentation for number_format doesn't even state that NULL is a possible output value. And I can't find anything in the change…
I don't have a strong opinion either way, but I don't think #1 is a given. You describe one reasonable approach to building things: bad shit should blow up quickly, forcing fixes. But another reasonable way is working to make sure something reasonable happens. E.g., Postel's Robustness Principle: http://en.wikipedia.org/wiki/Robustness_principle My understanding is that PHP started out as a noob-friendly page scripti…
I'm perfectly fine with the robustness principle being applied, but it seems as if it gives people who write poorly thought out projects a convenient excuse for bad design decisions. I've been using PHP since the early 4.x days, so I've seen the project change over the years and I can honestly say I don't think the robustness principle was ever consciously applied across the project, it just ended up that way. If it was a conscious decision then there would be at a very minimum a standard output for invalid input across all functions. Instead, every function returns something different (FALSE, 0, '', '0', NULL). Sometimes the output for invalid data is documented, sometimes it isn't, sometimes it changes without any notice or modification of the documentation. This doesn't seem like a design choice to me.