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

271–280 of 319 posts

Re: We will try to stop fixing bugs in PHP

#271

Post by rbanffy »

MartinCron wrote: post #249
rbanffy wrote: post #187

Earlier quoted context omitted.

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

PHP has its shortcomings, but, as in any open source product, if it doesn't work for you, you have a couple options. I personally think this guy should ask for a full money-back refund and then shut the hell up.

More than once I suggested that. I used to work at an ISP that offered free e-mail accounts and webmail.

Re: We will try to stop fixing bugs in PHP

#272

Post by zem »

josegonzalez wrote: post #2

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

are people really looking to this as a reason why php sucks? i thought the point of the post was to mock the "bug" reporter and his clueless sense of entitlement.

Re: We will try to stop fixing bugs in PHP

#273

Post by Zak »

xd wrote: post #245
spacemanaki wrote: post #239

Earlier quoted context omitted.

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

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

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.

Re: We will try to stop fixing bugs in PHP

#274

Post by j_baker »

kevinalexbrown wrote: post #79

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

Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms.

A better solution? Don't make arbitrary changes that will make months of unnecessary work for people for no reason to begin with. If you're going to eat up developer time, you should make it for a good reason.

Re: We will try to stop fixing bugs in PHP

#276

Post by nilliams »

j_baker wrote: post #274
kevinalexbrown wrote: post #79

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

Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms. A better solution? Don't make arbitrary changes that will make months of unnecessary work for people for no reason to begin with. If you're going to eat up developer time, you should make it for a good reason.

No serious developer would lose months of work to this, that claim is completely ludicrous.

Re: We will try to stop fixing bugs in PHP

#277

Post by quink »

columbo wrote: post #204
quink wrote: post #7

Earlier quoted context omitted.

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

Re: We will try to stop fixing bugs in PHP

#278

Post by gbog »

columbo wrote: post #226
gbog wrote: post #208

Earlier quoted context omitted.

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

Hrm... if you don't trust your core to that extent... then why use it?

Legacy.

Re: We will try to stop fixing bugs in PHP

#279

Post by Firehed »

psaintla wrote: post #223
wvenable wrote: post #217

Earlier quoted context omitted.

> 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. It's trivial to turn all notices/warnings/errors into exceptions in PHP (it even provides an exception class for it, ErrorException). PHP is multi-paradigm and supports many different ways of handling errors and warnings. > This is a bug in th…

I am very aware that it is trivial to handle notices, errors and warnings. The problem is that PHP does not do this by default which allows people to exploit undocumented behavior. As for handling invalid input, I think you should actually check what some of the functions output some day. For example, decbin clearly states that the input should be an integer but if I pass it a string..... Code/ctsr » php -r 'echo dec…

PHP was designed (I use the term loosely) to get dynamic websites up and running very quickly, and it's default configuration succeeds at that. So I don't think it's fair to call the loose error behavior a problem in PHP, as changing that would go against that ease of use, even if it's a problem when writing complex software with PHP.

I think a simple "use strict"-type declaration would go a long way for making software that's actually reliable rather than the barrage of set_error_handler, ini_set and related calls, but oh well, I'll file a feature request. It gets more complicated when security enters the mix (remember magic quotes?), but there are about nine thousand different frameworks which deal with that better since they're actually designed for a specific purpose.

Re: We will try to stop fixing bugs in PHP

#280

Post by ceol »

nbm wrote: post #265
ricree wrote: post #232

Earlier quoted context omitted.

Didn't facebook largely reimplement php, though?

The question is whether someone is saying that you can't use the PHP language/architecture to create a large and large-scale application like the Facebook front-end, or whether they mean the PHP runtime is unable to perform effectively at scale. The Facebook front-end code is largely just the PHP language (modulo things like XHP) and follows the shared-nothing, request-based architecture that people who program in PH…

It would be better to say Facebook begrudgingly uses PHP due to not wanting to do a major rewrite.
Post reply on HN