Live data from Hacker News

We will try to stop fixing bugs in PHP

bugs.php.net

201–210 of 319 posts

Re: We will try to stop fixing bugs in PHP

#201

Earlier quoted context omitted.

"This bug report highlights the problems you run into if you use it for serious work." Indeed. Passing an empty string for a parameter which is expected to be a float is SUCH serious work. "if it breaks your stuff then tough shit because we're a bunch of amateurs." You say that, but it rather seems like it broke amateur code.

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.

Re: We will try to stop fixing bugs in PHP

#202
post #129
post #127

Earlier quoted context omitted.

"I use it for some piddly shit because that's what it's good for." The bigotry from this community when it comes to PHP has left me sick to my stomach.

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…

>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.

Re: We will try to stop fixing bugs in PHP

#203
post #129

Earlier quoted context omitted.

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…

Another way of putting it would be: "size DOES matter".

Re: We will try to stop fixing bugs in PHP

#204
post #7
post #3

I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold). It returned 0 previously for "", why change it now? Was "" == 0 a bug ?

A) The new behaviour makes more sense. B) The change was discovered as a difference in behaviour in two major releases that were three years apart. C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful. D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix. E) You don't pass…

I disagree with (A).

According to the php docs

floatval('122.34343The') == 122.34343

floatval('BLARTLBARTFAST') == 0

Why should it take the input and choose a different response than what floatval would respond with?

If floatval returns null on 'BLARTLBARTFAST' and '122.34343The' then this function should return null. If floatval returns 0 (or whatever) than this function should return the same.

It's inconsistent behavior.

Re: We will try to stop fixing bugs in PHP

#205

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 changelogs stating when this change was made (admittedly I glanced quickly so I may have missed it)

You state that it is a bug in PHP, but I respectfully disagree. 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 really should end, invalid input should result in standard exceptions being thrown so they can be handled.

Re: We will try to stop fixing bugs in PHP

#206
post #130

Earlier quoted context omitted.

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…

> 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.

Re: We will try to stop fixing bugs in PHP

#207

Earlier quoted context omitted.

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…

"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…

It is not about getting everything right the first time,it's about getting the basic things right the first time.

Re: We will try to stop fixing bugs in PHP

#208

Earlier quoted context omitted.

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 d…

> 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 me…

> wrap every PHP function in your own function

That's what I did or tried to do when working with PHP. At least on sensitive parts (date, string, database functions).

Re: We will try to stop fixing bugs in PHP

#209

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…

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 scripting language. For that kind of system, do-what-I-mean coding is reasonable. You're not trying to force amateurs to be pros; you're just trying to help them get something up and working. But maybe the PHP audience has shifted enough that the break-early-break-often approach is the right one these days.

Re: We will try to stop fixing bugs in PHP

#210
post #127

Earlier quoted context omitted.

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…

"I use it for some piddly shit because that's what it's good for." The bigotry from this community when it comes to PHP has left me sick to my stomach.

Use the best tool for the job.

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.

Post reply on HN