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

291–300 of 319 posts

Re: We will try to stop fixing bugs in PHP

#291

Post by Tloewald »

Xylakant wrote: post #195
Tloewald wrote: post #151

Earlier quoted context omitted.

So you dismiss a bunch of valid breaking changes because you weren't affected by them and then cite one you know about. Well played, sir.

Well no, all I'm saying is that they indeed were breaking changes, but not "obscure design decisions". All of them were made for a reason and the reasons were public. Some of them had easy workarounds (like a commandline switch) Most of them happened at the transition of a major release and made the introduction of major features possible. Ruby 1.8.6/7 was supported for years after the transition for people that had…

Fair enough, I apologize for the snark, but then everything you've said hinges on your interpretation of the word "obscure".

Re: We will try to stop fixing bugs in PHP

#292

Post by arde »

quink wrote: post #277
columbo wrote: post #204

Earlier quoted context omitted.

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

> I disagree with (A). Since you quite clearly have no idea what function we're even talking about or what it's supposed to do, I will just point you to the documentation rather than more explicitly explain on how many levels you are wrong: http://www.php.net/manual/en/function.number-format.php

Pointing to the documentation does not work in this case. The documentation shows the user was not sticking to the function specs, yes, but neither does PHP most of the time. If PHP were a consistent (serious) language, I might see your point. It's not: it generally aims for leniency and minimum (well, small) surprise but doesn't seem to be doing it this time. I think you should make your argument clear.

Re: We will try to stop fixing bugs in PHP

#293

Post by arde »

chavesn wrote: post #39

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?

It's bad code alright. But I would argue that any code you write in a bad language turns into bad code, no matter how you do it. It might be good enough for your application, so that's fine. But it would be bad nonetheless. And PHP is not a sane language by any measure. So here we have a bad code author dealing with it's bad languague's shortcomings and expecting that they be solved by the very people who created said bad language in the first place. Quite entertaining.

Re: We will try to stop fixing bugs in PHP

#294

Post by arde »

toyg wrote: post #44
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…

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.

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.

Re: We will try to stop fixing bugs in PHP

#295

Post by arde »

buster wrote: post #253
masklinn wrote: post #148

Earlier quoted context omitted.

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

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

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.

Re: We will try to stop fixing bugs in PHP

#296

Post by aaronh »

kstrauser wrote: post #264
psaintla wrote: post #205

Earlier quoted context omitted.

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…

Quotes like this keep me from sleeping well at night: > It's not a number definition, but FORMATTING. How do you format nothing in the numerical system? By having it be zero. You don't have NULL dollars in your bank account, do you? He goes on to say that "this is tax data and has to be precise for tax planning and retirement planning." Think about that for a minute. A guy claiming to write tax planning software does…

I think he knows the difference which was why he had a problem with it. But of course the problem is not that some arbitrary function no longer returns him a preferred default value, the problem is that he is sending it garbage to begin with (and he claimed this was used in "thousands" of places...shudder).

Re: We will try to stop fixing bugs in PHP

#297

Post by batista »

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…

>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

Really? You read it wrong. It is "he have a public API that had a bug --that only surfaced when using it in a brain damaged way, anyway-- and we fixed it along with doing several DRY improvements to our code base. We also gave ample time of advance warning with our beta releases".

"so if it breaks your stuff then tough shit because we're a bunch of amateurs."

An ad-hominem? And its Rasmus that cones out as a little child, to your "mature" reading of the situation? Priceless.

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

That includes fixing bugs and brain damaged edge cases of the public API.

The complainer and your reading are so off the mark, I can't even begin to comprehend such attitudes exist...

Re: We will try to stop fixing bugs in PHP

#298

Post by batista »

cldrope wrote: post #287
snorkel wrote: post #180

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…

This stuff happened over 2 years ago, and what he was referring to was an ANTICIPATED change sir. Not one he'd run into at the time, since it had yet to be changed to something random and unexpected.

Relying on a brain damaged non documented edge case was unanticipated, not the change --which had also been in beta before release.

What kind of programmer passes "" and null on a function such as this and expects ....zero in return?

And what kind of programmer does it --as he admits-- "all around the place"?

If you give right to this guy, that's a very very short and accurate interview question --no hire.

Re: We will try to stop fixing bugs in PHP

#299

Post by thebluesky »

j_col wrote: post #218
gbvb wrote: post #206

Earlier quoted context omitted.

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

In all fairness with enough hardware you could serve ~1 billion users using virtually any language which supports development of web applications. Just because you can develop a hugely successful system using a language doesn't prove (or disprove) that said language is necessarily the best tool for the job. It just happens to be what FB picked.

Re: We will try to stop fixing bugs in PHP

#300

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

Post reply on HN