We will try to stop fixing bugs in PHP • Hacker News Board

Re: We will try to stop fixing bugs in PHP

#91

Post by aklofas » Fri, Jun 22, 2012, 5:45 AM UTC

pelotom wrote: post #69

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…

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.

sed s/PHP/Ruby/g :)

Re: We will try to stop fixing bugs in PHP

#92

Post by gurkendoktor » Fri, Jun 22, 2012, 5:46 AM UTC

josegonzalez wrote: post #34

gurkendoktor wrote: post #20

Earlier quoted context omitted.

Somewhere around Ruby 1.8.6, the stdlib Digest::MD5 syntax changed without any explanation that I know. In one patchlevel of 1.8.6, they've added a check against creating new Ruby objects while the GC is running (I hope I remember this right), breaking all SWIG extensions at once. Ruby 1.8.7 changed the C extension API, I think? I'm not sure if 1.8.7 broke the old one or if 1.9 did. Ruby 1.9 broke "when 5:" in case s…

I used it as the example simply because it is normally a language that is touted quite superior to PHP. I think it is better in some regards - building/using Ruby DSLs is awesome - but not all. Languages are subject to bugs. If they didn't have bugs, people wouldn't complain.

I just wanted to reinforce that Ruby and PHP are equally unstable languages. Most changes in my list aren't bugs at all, just obscure design decisions. Even the new Hash literals are likely complicit in breaking the "when X:" syntax that I'd heavily relied on.

The bigger question is probably whether Ruby is any safer from this now, thanks to the ISO (ANSI?) standard.

Re: We will try to stop fixing bugs in PHP

#93

Post by dekz » Fri, Jun 22, 2012, 5:46 AM UTC

soulclap wrote: post #19

I understand that the bug reporter is in a bad situation but this is definitely an edge case and passing an empty or whatever non-numeric string to a function that is clearly meant for formatting numbers doesn't really seem like good style. is_numeric(), is_float() and casts are available for a reason. So I guess the answer is ultimately 'deal with it'. That said, I don't see this taking 'months' either, they could j…

It's also really bad style for TAX Software. He should be sanity checking all his numeric data, wow.

Re: We will try to stop fixing bugs in PHP

#94

Post by astrodust » Fri, Jun 22, 2012, 5:47 AM UTC

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

Re: We will try to stop fixing bugs in PHP

#95

Post by jsilence » Fri, Jun 22, 2012, 5:47 AM UTC

moot wrote: post #70

> After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue. I am sad I was not invited :(

You should escalate that up at 4Chan!

Re: We will try to stop fixing bugs in PHP

#96

Post by kyberias » Fri, Jun 22, 2012, 5:50 AM UTC

People have been wondering "what would Linus have said?" I'm pretty sure he wouldn't have broken the existing (undocumented) behavior in the first place "because it breaks applications and the one and only reason for kernel is to allow applications to run". But then again, PHP is not a kernel. :)

Re: We will try to stop fixing bugs in PHP

#97

Post by eitland » Fri, Jun 22, 2012, 5:57 AM UTC

Too wrote: post #77

TylerE wrote: post #15

Earlier quoted context omitted.

I disagree with point A. The old behavior makes a LOT more sense symbolically. I tell you that you have no apples. Write the number of apples you have on a piece of paper. What did you write? I bet it was 0, not some arbitrary, non-writable symbol for an abstract concept that could mean "nothing" or "error" or "empty" or ..

BOTH behaviors don't make sense. The right behavior is to throw an exception.

This depends on language. Or you'd have to dismiss at least on widely used systems programming language as well. : )

Re: We will try to stop fixing bugs in PHP

#98

Post by aniket_ray » Fri, Jun 22, 2012, 5:58 AM UTC

kyberias wrote: post #96

People have been wondering "what would Linus have said?" I'm pretty sure he wouldn't have broken the existing (undocumented) behavior in the first place "because it breaks applications and the one and only reason for kernel is to allow applications to run". But then again, PHP is not a kernel. :)

I think you are entirely right. As Linux says "Kernel exists for its users". Pretty similarly, a platform (php/zend) exists for its applications.

Linus has always been pretty adamant about not breaking API behaviour even undocumented ones. But in this case, undefined behaviour had been previously documented.

Also, was it him or Ulrich Drepper who were against changing memcpy undocumented behaviour. (mempcy used to work with overlapping regions too.)

PS. This mailing thread is from 2010. It's really old.

Re: We will try to stop fixing bugs in PHP

#99

Post by chris_wot » Fri, Jun 22, 2012, 5:59 AM UTC

Uh, so let me get this straight. They are using number_format, which according to the documentation takes a number and formats as a string, and giving it a string as the input parameter?

They were never using the function correctly in the first place! Not sure what they have to complain about here...

Re: We will try to stop fixing bugs in PHP

#100

Post by eitland » Fri, Jun 22, 2012, 5:59 AM UTC

enjo wrote: post #90

Too wrote: post #77

Earlier quoted context omitted.

BOTH behaviors don't make sense. The right behavior is to throw an exception.

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