Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We will try to stop fixing bugs in PHP

bugs.php.net

Post reply on HN
Print view View original

161–170 of 319 posts

Re: We will try to stop fixing bugs in PHP

#161

Post by [deleted] »

Beltiras wrote: post #144
jbm wrote: 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…

Which is why you should use Python, not PHP ;) (Penis submitted for measurement)

[deleted]

Re: We will try to stop fixing bugs in PHP

#162

Post by mcrittenden »

masklinn wrote: post #72
thought_alarm wrote: post #63

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…

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

Re: We will try to stop fixing bugs in PHP

#163

Post by ndrw »

The documentation is right and the "engineers" are wrong! And it's also a good example why you should stay away from using undocumented stuff. If the documentation says "float $number" you best better give it a float, dammit! Engineers, my a$$...

Re: We will try to stop fixing bugs in PHP

#164

Post by soc88 »

mcrittenden wrote: post #162
masklinn wrote: post #72

Earlier quoted context omitted.

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

Why? He said that the design principle of this method is in line with the rest of PHP, that's a correct and valid observation.

Re: We will try to stop fixing bugs in PHP

#165

Post by soc88 »

martenshinwarts wrote: post #110
thought_alarm wrote: post #63

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

In PHP every code is amateur code.

Re: We will try to stop fixing bugs in PHP

#166

Post by to3m »

jconley wrote: post #17

Regardless of merit on either side, the attitude presented by the creator of PHP in this post makes PHP and open source in general look bad. Seriously? I still can't believe that's how the situation was handled. EDIT: Rasmus calls the bug reporter an idiot in the first reply. It's probably some sysadmin that has been tasked with upgrading the infrastructure and really has no idea what to do. So rude. It would take ju…

I quite agree. It doesn't cost a thing to behave like a gentleman, and people usually respond well to it. And if they don't, being rude is unlikely to work any better, and could just leave them feeling justifiably resentful. Rudeness is not the winning strategy.

Re: We will try to stop fixing bugs in PHP

#167

Post by RobAley »

masklinn wrote: post #159
RobAley wrote: post #152

Earlier quoted context omitted.

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

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

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.

Re: We will try to stop fixing bugs in PHP

#168

Post by ranza »

damian2000 wrote: post #23

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

Gotta love Rasmus. He makes me proud to be danish :D

Re: We will try to stop fixing bugs in PHP

#169

Post by Draiken »

martenshinwarts wrote: post #110
thought_alarm wrote: post #63

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." 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 :/

Re: We will try to stop fixing bugs in PHP

#170

Post by jheriko »

thought_alarm wrote: post #63
damian2000 wrote: post #23

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…

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.

Post reply on HN