
We will try to stop fixing bugs in PHP - robbiet480
https://bugs.php.net/bug.php?id=50696
======
kevinalexbrown
Leaving aside the irony of asking Rasmus to escalate the issue (this would be
like complaining in an "Ask HN:" and suggesting that pg escalate the issue up
the ycombinator chain), or whether the change was logical or not, I learned
something cool from one aspect of Rasmus' response:

 _... there are many many people out there affected by these changes, we
recognize that. That is also why we are not likely to reverse a change like
this that others in your situation have now accounted for, tested and deployed
in production for many months ..._ \-- rasmus.

Good decisions don't always mean everyone goes home happy. Whether or not the
change was good or bad, reversing it _now_ could negatively impact anyone else
who already adjusted. If it means "MONTHS" of work for this guy, in order to
save "MONTHS" of work for 100 others who use PHP, so be it.

Even if we were to take a leap of faith and assume it was a bad decision by
Rasmus to make the change in the first place, it's been done. Responding to
inconsistency with more changes seems like trying to regain your balance by
making wilder and wilder swings of your arms.

~~~
pacifika
A possible solution to this would be to put a policy together to only fix
things like this in the next major version, not on the current line.

As long as it's known that these are long term fixes people can prepare for
them.

~~~
jerf
"The first PHP 5.3 release candidate was back in March 2009. We put these
release candidates out there so people who "will have MONTHS of work" because
of small changes can chime in then and make their case. The release candidate
period lasted until July."

I love to hate PHP-the-language as much as the next guy, and I don't
particularly love their design decisions for the language, but let's face it,
on basic release management grounds there's nothing to complain about. On
general principles I'm of the opinion that the PHP project did everything
called for here and the fault is pretty much 100% on the user's side here,
with the only possible counterargument being that they apparently may not have
called this exact change out quite as precisely as they could have (though
that implies they knew, which, well, in a sloppy-type language like this this
sort of thing is easy to miss). Languages don't get to version 5 without some
breaking changes, but the alternative of every language being stuck with every
bad decision made in version 1 forever is worse.

~~~
rbanffy
I once played with continuous testing using a python fresh from the Hg repo.
Once you set up your CI/CT box with enough compute power there is no reason to
always check your product against the upstream pre-release components.

Now that I remember it, it was a pretty nice setup - creating OpenVZ
partitions from a template, making python from sources and testing the
application within the machine. Too bad it was a one-off thing. I should have
used something like buildbot or jenkins.

~~~
MartinCron
That is a wonderful idea. Knowing _now_ if your stuff will or will not break
in the "future" seems worth the investment. If anyone else is doing this, I
would love to see details.

~~~
rbanffy
There will be a couple false positives, but, in any case, you can measure the
upstream development quality, and use that as an input to guide your
decisions.

------
kenneth
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 he doesn't have the necessary qualifications to be
writing software that manages people's retirement funds. Also, when dealing
with something as important as that, you ought to know better than to base our
technology on top of PHP.

[1]: Coming from somebody who built a very successful startup on top of PHP.

~~~
rbanffy
What shocks me most is the sense of entitlement. They downloaded PHP, its
behavior changes and they'd rather complain to those who changed it and annoy
them until the thing works for them again than fix the bug in their code. If
they are not happy with the free product and the free support, there are other
options.

PHP has its shortcomings, but, as in any open source product, if it doesn't
work for you, you have a couple options.

~~~
jiggy2011
Problem is, at that point you have built a lot of business on top of it. So
the issue of whether or not it is "free" is moot because it has a very real
dollar value to you and also probably to the boss who is breathing down your
neck.

~~~
rbanffy
Then they have a couple options: fork and keep their own fork, they can pay
the PHP community (or someone in it) to change it back (or to provide a
backwards-compatibility mechanism) or pay developers to change their software
to work with newer versions of PHP.

They can't bully their way like they tried.

~~~
adambyrtek
> they can pay the PHP community (or someone in it) to change it back

The decision was defended on its own merit, so I would be really disappointed
if bringing money to the table affected the outcome. Funding open source
development is great as long as meritocracy is maintained. That's why Linus
never accepted a job at a company that had a stake in pushing Linux in a
certain direction.

~~~
rbanffy
If they could prove that the change would create a really huge expenditure and
would thus damage the community, I assume a workaround could be reached
through the normal democratic decision process. I imagine a config option to
restore the original functionality would be a nice solution, but I'd suggest
the company should fund its development (along with proper tests and
associated code).

~~~
jiggy2011
If they kept config files to control every altered behaviour PHP configuration
would be an even bigger mess than it is already.

------
damian2000
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_

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

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.

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

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

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

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

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

~~~
xd
"healthy debate" Yes! This is what we do need, what we do NOT need is bullshit
like "piddly shit" which you seemed to be defending.

But please, tell me of one, just one, "severe flaw" you find in PHP, as it is
today. And I will enter into a healthy debate with you.

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

------
soulclap
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 just write a
wrapper function that mimics the old behaviour and their tests should cover
it. If their quality control or inner workflows make changes like this take
months, I'd expect that upgrading to a new PHP version and the related testing
and QA should take them years.

~~~
reitzensteinm
A wrapper function is absolutely the right way. Instead, he decides to _modify
the PHP source and recompile it_ , effectively forcing him to maintain a fork
of PHP, as if somehow that magically takes less effort to develop and QA
resources to maintain. Wow.

~~~
blantonl
Spot on. He doesn't want to update his 50+ applications, but he wants to patch
PHP and deal with the deployment of that to all the servers that support those
50+ applications. And he admits that he's not a C++ coder.

Sounds like a change management nightmare.

~~~
lnguyen
But it's only one change.+

\+ Technically true. The scope will be equivalent to 50+ change tickets. And
he'll be able to blame someone else for any issues that result.

------
snorkel
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 as a numeric type:

    
    
       print number_format((int)"",0);
       0
    

Please, if you're this bad at programming and you willfully ignore warnings,
don't file bugs, and please do not take a programming job at some place that
does important things like air traffic control, banking, or life support
systems.

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

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

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

------
josegonzalez
Upvoting, because the issue at hand is so old that I find it funny people will
use this as a reason as to why "PHP sucks".

For the record, the version in question was 5.3.1 vs 5.1.6, two releases away
and three years apart. Of course you'll need to test updates to your app with
such version changes. Yes, using semver means this is a minor version release,
but if we do that, I'll be first to note the lovely hash syntax changes in
Ruby 1.9.

In any case, the current release is 5.4.4.

~~~
rurounijones
Sorry I couldn't grok what your opinion on semver was.

Ruby 1.9 introduced new hash syntax but did NOT break the existing syntax one
so it was a minor version release (backwards compatible).

PHP made an backwards incompatible change in their code so it should have been
a major version increase.

So as far as I can see Ruby is in the right and PHP is in the wrong with
regards to adhering to semver.

Is that not your opinion?

~~~
gurkendoktor
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 statements. Files also started needing "#
Coding: UTF-8" comments. And then there are subtle changes that probably
aren't even documented, like [Math.sin 0] not being valid syntax anymore.
Block variable scoping and automatic splitting into Arrays is different.

Ruby 1.9.2 (!) changed the way require() works and added require_relative()
which is impossible to properly backport.

And Ruby 1.9.3 fixed a parser bug again, breaking code that worked on 1.9.2.
(I think you could have a superfluous "do" in one place.)

Those are the breaking changes that I can remember from first-hand experience
now, only the last one is second-hand over IRC. And this is excluding Rake,
Rubygems and all the other crap that breaks at every other git commit.

Ruby is a bad example.

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

~~~
iamumassthrower
Hahaha. People wouldn't complain. That's a knee slapper.

~~~
sirclueless
No more preposterous than software without bugs.

------
moot
> 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 :(

~~~
jsilence
You should escalate that up at 4Chan!

------
Groxx
So the options are:

    
    
      1. Change thousands of lines of code (probably `sed`-able)
      2. Patch PHP to re-introduce the original bug/feature
      3. Downgrade PHP back to the version that had the
         bug/feature you were relying on
    

Why is option 3 not considered in this thread? It was working before, and
evidently they can control the version of PHP (since they can patch it). If
upgrade breaks X, and you rely on X, don't upgrade. If you need to upgrade for
Y, do so, and fix X. That's just how such things work.

~~~
sold
Problem 1: The old versions do not get security patches. For example, entering
the number 2.2250738585072011e-308 hangs the interpreter in old versions, as
far as I know this is unpatched in PHP <=5.1. This allows a very effective
denial of service.

Problem 2: You are delaying the unevitable; it's nice to use new features of
the language, having to code in old versions is a pain for developers. Small
continuous upgrades are easier to handle than rare gigantic ones.

~~~
Groxx
Small continuous upgrades without ever changing your code is the same cost as
a gigantic one without ever changing your code - they either work, or they
don't, in variously subtle or spectacular ways. The tipping point lies at some
changeset, you just need to hit it.

You upgrade, you may need to change things. It's just a fact of life. Or, you
pick a library / language / framework / everything that guarantees 100%
backwards compatibility as documented, that never has bugs (since fixing those
breaks 100% backwards compatibility), and you _never_ use features in even
remotely-unexpected ways. Like in this case.

~~~
Kabacaru
This is why having a good suite of unit tests is so important.

------
justindocanto
"This is going to cause us MONTHS (to fix)". Whether he is right or wrong, you
cannot say he's not over-exaggerating and being a pain in the ass. Also,
expecting "" to == 0, when it's easier and proper to enter 0 just doesnt make
sense. That's like saying "i expected your software to make up for me not
using it correctly". Sass or not from the guy who wrote PHP, this guy is just
a pain in the ass and his complaint is ridiculous.

ADDITION: As the creator stated, it's been issuing warnings for some time now
and was changed LAST YEAR. there's just no foundation to this complaint.

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

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

~~~
lmm
Ulrich Drepper was vigorously in favour of it. If your application breaks,
it's because it was written wrong.

~~~
Draiken
Exactly. The only reason this bug got to production, is because the function
accepted an empty string parameter in the first place.

------
josephcooney
The "is there anyone you can escalate this too" reminds me of a PERL newsgroup
thread I saw where someone tried to rip Larry Wall a new one, asking (in a
condescending way) him if he knew anything about PERL.

~~~
aidenn0
Or the time I suggested on HN that cperciva use scrypt (not noticing the
username on the comment).

------
gmedel
To standardize PHP code is good, let's be clear... There's a lot of
"misbehaves" in PHP. And if you're not casting or checking all the time you
can get a wrong result, without even knowing. At least now/then (it's an old
topic) number_format WILL tell you that you're not formatting a number and
that's GOOD.

~~~
ahi
To standardize PHP is to create a new language not named PHP.

~~~
phaus
If you read it until the end you will find out that the technical support
representative talking to the irate customer is the creator of PHP. As the
creator, PHP can be whatever he decides he wants it to be.

~~~
fffggg
And he has decided it is not a standardized language, by any stretch of the
imagination. That's the guy's point, and it's spot-on.

As an aside, I didn't realize there would be people on HN who wouldn't
recognize rasmus@php.net immediately.

~~~
phaus
While there are some industry veterans here, there are also a good amount of
CS students and other beginners. I myself didn't know who he was until I got
to the end of the article.

------
wanderr
I have to agree with the bug submitter in concept, if not in attitude. PHP is
a dynamically typed language. As such, methods should expect surprises about
the types of data received. Seriously, I've had PHP treat the same input as a
string one time, an interface another, it's like it uses whatever is
convenient at the time. If you neeeeed that data to be an int, cast it as an
int, don't punish the user because type system chose a different type this
time.

Additionally, and more to the point, in PHP 0 == "" == null == false, so it
shouldn't be unreasonable to expect them to be treated as equivalent. It's
also a nice thing when a method can always be trusted to return the same type,
or these types of issues can end up cascading.

In any case, 'should' and 'nice' things are hard to rely on in PHP, that's why
you should always have the docs open and read everything when writing PHP,
making even basic assumptions about a method being well behaved will likely
screw you over. :)

~~~
Terretta
Especially for a novice, formatting a field on a web form into a number, and
seeing PHP format an empty field as zero, so you can carry on with your math,
makes sense. "Oh, web parsing language, sees empty number field as zero,
great!"

Principle of least surprise _"for the novice web developer"_ says empty string
to zero makes sense in this case.

Meanwhile, empty string with zero decimal places returning null would be less
surprising to a pro, but in PHP, the first behavior would also be unsurprising
to a pro.

------
pippy
So developers complain that PHP is not standardised, but when it is in a major
version upgrade developers complain that it's becoming standardised?

~~~
icebraining
Are you somehow under the impression that developers are the Borg? Different
developers can have different opinions on what PHP should be.

------
chavesn
Having _number_format_ in so many thousands of places across so many products
is indicative of pretty poor code. If you have bad code, you can hardly expect
to be able to upgrade to new versions of the language seamlessly.

Speaking of which, are they going to upgrade to 5.3 _without_ testing all
those thousands of places across all their products?

~~~
enjo
How is that indicative of bad code? That seems like a very big jump to make.
If you're using PHP at the presentation layer you are probably doing a lot of
this. Why would you write some sort of abstraction around number formatting
when there is an abstract function to just do it for you?

This is particularly true if your applications are older and written before
modern template systems made it a bit easier to abstract these concepts to
filters and the like.

~~~
chavesn
I'm just saying it's a sign, or a smell.

Just as you say older/pre-modern -- bad code or not, the same caveat applies
about upgrading core language platforms. Even a strictly typed language with a
much more standardized API like Java can be hard to upgrade major versions
(where I would consider 5.3 a new major version).

------
mparlane
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 ?

~~~
quink
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 a string into a function that's usually returning a string
without at least casting to a string when part of its intended behaviour is at
times not returning a string. Casting in this case even before the function
even changed would have been an exceedingly good idea.

F) (edit) I vote we burn in hell PHP developers who tack on comments to a long
closed bug report to offer their opinions like joezimjs did. Especially when
they display a basic ignorance in saying crap like "NULL is neither a string
nor a number."

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

~~~
steve8918
I don't agree with your analogy. The question is more similar to "Can you
please tell me the number format of <silence>".

How can the answer to an unfinished question be "0"? 0 is an actual valid
answer, when people are asking for number_format(0, 0).

In this case, NULL is definitely more appropriate, because the input is
invalid.

~~~
phene
What's the numeric representation of the volume of <silence>? 0 dB

~~~
mturmon
Since dB are a log scale, more properly, it would be -Inf dB.

~~~
exDM69
0 dB = atmospheric pressure. -Inf dB = vacuum of space.

------
loup-vaillant
> _Find the dependencies —and eliminate them_

Excel team motto.[1]

While I understand Rasmus' response is legitimate, I also see that depending
on something as crucial as a programming language implementation is less of a
good idea than it might seem at first. Makes things like Maru (the programming
language[2], not the cat) much more appealing: if there's something you don't
like in your compiler, at least you stand a chance at fixing it (Maru is less
than 2K lines, and counting down).

[1]: <http://www.joelonsoftware.com/articles/fog0000000007.html>

[2]: <http://piumarta.com/software/maru/>

------
FuzzyDunlop
> _Each of those changes will have to be coded, tested, written-off, released,
> tested by the clients since this is tax data and has to be precise for tax
> planning and retirement planning._

Considering the filer of the report goes on to say this, at what point did
they fail to realise that moving from an " _old PHP 5.1.6 Solaris 8 box_ " to
an " _RHEL5 with 5.3.1_ " should have required the same level of testing and
signing off?

No sympathy for a developer who completely changes their environment (OS, PHP
version, at the very least) and then bitches about stuff they failed to
anticipate not working. This is not a reflection on PHP, for once.

------
cldrope
I think the guy wasn't thinking the situation through entirely, but someone of
(relative respect I suppose, creator of PHP is still the creator of something
widely used) respect shouldn't be acting like this. It's always a shame to see
people who have promise and talent show how childish they CAN act. Having his
underling (someone who works on his language of no known note) make a
smartassed response was in turn also pointless and negative whether he
requested/urged it passively or not.

------
soulclap
Related article about the same bug report: "When does a bug turn into a
feature?"

<http://lwn.net/Articles/369505/>

------
josephcooney
Way to jump onto a thread that hadn't had any comments in 10-month-old
joezimjs and add pretty much zero to the conversation.

------
gedrap
It was really to read that conversation. I do not care whether it was a good
or bad decision to make those changes in PHP but you simply can not talk like
that to a person who has put thousands of hours of unpaid work (while he could
get a fat pay check easily) and you are making living because of what he has
done. It's just immature.

------
lnanek2
This is pretty standard with large production software. You often see grids in
the documentation, e.g. this version of the app server is only certified for
these brands and versions of Java. Even if you have a paid support contract
with us, do not contact us re using it on something else. So in the reporter's
case, their software just isn't certified for the new version until updated.
No big deal.

I remember working at a company where the servers were Ubuntu, the auto-update
mechanism replaced Sun Java with OpenJDK which broke countless apps and web
servers, like the Concur app, the build system, etc.. God that was a
nightmare. A real setup like at bigger companies I've worked at would have
tested that update on developer boxes, integration boxes, testing and training
boxes, and only then sent it to production.

------
timtrinidad
This reminds me of <http://news.ycombinator.com/item?id=3860361>. Ignoring
something that needs to be fixed because it might break workarounds is a lot
to expect, and it likely why the IEs stayed broken for so long.

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

------
sneak
In April 2010 Rasmus Lerdorf joined WePay (a YC startup) in a senior position.

[http://techcrunch.com/2010/04/27/php-founder-rasmus-
lerdorf-...](http://techcrunch.com/2010/04/27/php-founder-rasmus-lerdorf-
joins-group-payments-startup-wepay/)

He's always been like this, best I can tell.

------
Darkstar
Everybody was in the wrong here. The developer should've written better code.
I'm a PHP developer and I've learned that if the input is that important, I
need to cast it. I've used C++, C#, and Java and I like strict typing. If your
application is that sensitive then maybe it should've casted the input to
ensure the output is consistent.

As for Rasmus, I think he could've explained why it's a "won't fix" type bug
in a slightly more diplomatic fashion, though I can't say I would've handled
it any differently. He's completely right as to why the behavior shouldn't
change. Finally, bjori's response was completely unnecessary, inflammatory,
and downright rude.

This has shown me the worst of the PHP community. I'm not ashamed, just more
wary.

~~~
ericingram
This is exactly how I feel about it.

I think it's an example of how not to interact in a community, from both
angles. Also, I can't stand the notion that open source developers are
"volunteering" their effort. All programming is voluntary in the sense that
you are making a free choice to do it and most likely gaining capital (social
or financial) in the process. I voluntarily build software and give or sell it
to others all the time.

------
ivanhoe
Issue here is not whether it can be fixed, anything can be fixed. Issue here
is why in the world they have changed things in a such way to break the old
code?! Was it necessary? I don't think so... I understand the need to re-
factor, and making some old stuff obsolete along the way, of course, but it's
not the case here. It's just that someone wasn't really playing attention to
this. And this type of negligence to the details is really killing php as
language. If after 10+ years in php I need to re-read the manual every now and
then to make sure if the things are still working like the last time, it's
just crazy..

------
methodin
Blaming your problems on the person making something you are consuming is
always a useless endeavor. Make a function if you are using something in
hundreds of places that relies on user input. Not terribly difficult.

------
Killswitch
| ^ 0 isn't some magic all-encompassing number. It means 0. NULL means no
number based on your shitty incorrect input, and is the correct choice.

Best response to the whole thing except for Rasmus' awesomeness.

------
deepGem
"Please escalate this to someone who can answer the question as to why this
was changed. If no one knows, then why was default behavior changed?"

Mr.Rasmus, respect, for not ending the thread at this statement.

------
jister
In this kind of situation where there's a bug or limitation or some kind of
issue with a language function we usually create a wrapper to handle the
whatever rules we have internally within the company. In this case the empty
string that is supposed to be NULL should be handled within that wrapper
function. One function to modify instead of several places in the application.

------
robryan
You can't win, people on one side want this weird behaviour made backwards
compatible whereas people complain that the language has a large amount of
weird edge cases and should be better standardised around more sane expected
values.

In this case they were standardising parameter parsing code, which I think is
definitely the direction you want to head.

------
billpg
PHP is doing the right thing here. Way back when I first tried PHP out, I
tried joining strngs together with a + operator.

I made a mistake, but I kept getting back zeros instead of some sort of NULL
or an exception. This is a bug, in the sense of its not how _I_ wanted PHP to
behave. I'm glad PHP is fixing its string-to-numeric bugs.

------
buster
All the discussion aside, there is so much wrong with it:

First of all, why does the function even accept strings? There should be some
eception happening. Second, why does it return 0, i could understand NULL but
not 0 (for a function that is supposed to handle numbers, having it return a
number in the invalid case, what is that?)

~~~
masklinn
> First of all, why does the function even accept strings?

Why not?

> There should be some eception happening.

PHP's built-in functions do not _ever_ throw exceptions.

> Second, why does it return 0, i could understand NULL but not 0

Well it doesn't anymore, but it used to, and that kind-of made sense _in the
context of the language being PHP_ : in PHP (userland), when using a string in
a numeric context that string will automatically be converted to a number:

    
    
        > php -r 'print (1 + "3") . "\n";'
        4
    

when the string _can not be parsed to a number_ (meaning it is not prefixed by
something which looks like a number), it's just converted to `0`:

    
    
        > php -r 'print (1 + "whelp") . "\n";'
        1
    

And I expect that is the former behavior of the function: it coerced whatever
it got to a number, so an empty or non-numeric string would get converted to
the float 0.0, which would then get formatted as usual.

~~~
buster
Just shows me how broken this language is to the core.

~~~
arde
I don't think you got to the real problem here. Weak types are quite useful
for some tasks, and of course they are nothing new. Languages that convert
between integer and string types automatically are well suited for text
processing in general (including generating web pages dynamically).

The problem with PHP's weak typing is PHP's hit-and-miss implementation. Check
out AWK, another weakly typed language, for example:

BEGIN{printf "%5.2f\n", ""}

prints "0.00" as would be reasonable.

------
robryan
In the same way that projects enforce a certain subsection of c++, it is
probably best in PHP to not code anything in a way that relies on unusual
quirks of the language to work. None of my code gets bitten here because I
never passed number_format anything but numbers.

~~~
andreasvc
In my opinion weak typing is an unusual quirk, but there's no way to get
around that. I really wonder kind of reasons could be given to defend it; I
don't think a strongly typed language like Python is any harder because of its
types.

~~~
robryan
I tend to agree, these days where possible when working in PHP I try not to
rely on PHPs magic type conversions behind the scenes for things like
comparisons.

~~~
andreasvc
You can't really avoid weak typing; e.g., making a mistake in a strongly typed
language would raise an error, whereas in a weakly typed language it can
silently screw up everything.

------
prisonguard
a pal of mine recently upgraded a big corp's pcs from win xp to win 7 . the
long wait was due to excel macros which could not run in the latter os. they
couldnt switch even after him rewriting and testing them to run. [edit] typo

------
strictfp
Stop doing automagical conversions and all these problems will go away.

------
peterkelly
... and that's why you don't use PHP.

------
TwoBit
In most mature programming languages we resolve this kind of dispute by
pointing to the Standard. Is that not possible with PHP?

~~~
johnny22
Well that's what happened to this guy. He relied on unstandard/undefined
behaviour and when php switched to a standard parameter parser it broke his
app.

------
10098
Ah, the joys of dynamic typing.

~~~
andreasvc
No, this is about _weak_ typing (as opposed to strong typing). Static vs.
dynamic is another matter.

------
Evbn
Wait, endosquid writes tax software and expects that whenever a bit of data
gets corrupted it should display an account balance of 0? Please share the
name of this phenomenal software product.

~~~
Yver
Indeed, it's amazing that the same person could say "We are passing a
(possibly uninitialized, or null-valued) variable to the function, in hundreds
of places and web pages" and "Each of those changes will have to be coded,
tested, written-off, released, tested by the clients since this is tax data
and has to be precise for tax planning and retirement planning."

They are very thorough with testing their super-important tax software. Well,
except they ignore uninitialized variables, but I hear those are A-OK in
accounting.

~~~
jdjb
Yes this. A million times this.

Anyone who uses PHP seriously knows when accepting user input you have to do
type checking rigorously. The manual states the input has to be a float. Of
course in PHP this means it SHOULD be a float but why risk sending it a
variable who's type is still undecided?

------
Evbn
Heh, if your steps to reproduce include redirecting error messages to
/dev/null, it is hard to take your report seriously.

------
fink0136
This makes me so excited to be a budding Perl dev.

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

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

------
jconley
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 just as long to write:
"Sorry about the inconvenience. We changed this undefined behavior for
consistency's sake. You could cast the first argument to a float like:
'[sample code]' and you'll get the old behavior back. One of our consulting
partners [link] could help you with that if you'd like." Instead, Rasmus set
the tone that he was superior from the onset.

~~~
toyg
Can you imagine how many fools like this Rasmus Lerdorf has to deal with,
every. single. day. since he created PHP? Same for Linus Torvalds. After a
while, you just stop trying to sugar-coat idiocy, and just tell them as it is.

~~~
arde
Perhaps it was not like this when PHP was created, but it surely has been for
a long while now: Idiots are now PHP's target audience be it by design or by
its own faults. So if Rasmus Lerdorf still maintains PHP then he should not
get angry by the kind of users he chose and/or deserves.

~~~
toyg
That's a bit harsh. Like with Java or Perl, there's an enormous installed base
of PHP apps which need maintaining and upgrading (and replacing, wherever
possible); a lot of people end up inheriting systems they didn't build, and
having to keep them up _ad libitum_.

~~~
arde
Sure, but those who inherit PHP systems may not belong to the PHP's target
audience that I was referring to. Neither must all people who choose to use
PHP necessarily idiots, because PHP does have some legitimate use cases. But
all in all I don't think PHP maintainers can expect sanity from their users as
a general population nowadays. I know it sounds harsh, and it probably is a
bit judgmental on my part too, but I hope you get the idea.

