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

281–290 of 319 posts

Re: We will try to stop fixing bugs in PHP

#281

Post by Firehed »

papsosouid wrote: post #202
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…

>Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress). That's clearly nonsense. The people who point out how terrible PHP is have huge, very detailed and very accurate lists of the problems with PHP. They don't get that from "never dealing with it". >If you will ship faster and better with language X, go ahead and use it. We do. Why do you think th…

Actually, most of those lists are based on PHP4 or older (meaning their opinions are fully eight years out of date; a LOT has changed) or are made irrelevant by changing one or two quite well-documented confit settings. The little that's left over are mostly complains that PHP isnt something that it's not trying to be (strongly typed, most commonly)

The only legitimate complaints I read as someone who uses an up-to-date version tend to revolve around the wildly inconsistent naming conventions, and a couple of extensions with rather poor documentation. The recent releases (5.3, 5.4) really did a lot to make it just as feature rich as other scripting languages.

If you want to use something else, be my guest. But I for one am tired of the misinformation that PHP bashers spread. I happen to like a language that doesn't get in my way, has extremely thorough documentation, and almost any question is answered in the first search result. At the same time, I hate the lack of documentation on the actual source (I have a few things that are a huge pain to do in user land, so writing a native extension is a huge pain), and of course the wacky parameters and return values on the old functions.

Re: We will try to stop fixing bugs in PHP

#282

Post by jiggy2011 »

rbanffy wrote: post #270
adambyrtek wrote: post #248

Earlier quoted context omitted.

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

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

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

Re: We will try to stop fixing bugs in PHP

#283

Post by jodrellblank »

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.

"The change was part of standardizing all of PHP on the same parameter parsing code." is not an 'arbitrary change' 'for no reason'.

Even if the reason is making PHP more consistent and paying off technical debt for future PHP maintenance, instead of benefitting you directly, it's still a reasonable change for a reasonable reason.

Re: We will try to stop fixing bugs in PHP

#284

Post by jdjb »

cube13 wrote: post #224
martenshinwarts wrote: post #201

Earlier quoted context omitted.

"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" Just like you should not pass strings in place of numbers, in accounting software of all things. Why can't just everbody get it absolutely right the first time? Any language that can do anything also allows you to shoot yourself in the foot. And I think that was the case here, brainless prog…

>Just like you should not pass strings in place of numbers, in accounting software of all things. Why can't just everbody get it absolutely right the first time? Because the input is a text box? Text is, after all, the way for people to input data into a computer.

It stills shows a lack of rigour on the part of the developer. A simple "empty()" and "is_numeric()" check should be done on any user input expecting a float BEFORE you pass it off to a number formatting function expecting a float.

Re: We will try to stop fixing bugs in PHP

#285

Post by jdjb »

Yver wrote: post #104
Evbn wrote: post #42

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.

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

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?

Re: We will try to stop fixing bugs in PHP

#286

Post by piggity »

TylerE wrote: post #189
methodin wrote: post #157

Earlier quoted context omitted.

Not for user-provided input. That's just a dumb thing to do in any language.

Probably. But then again, we're talking about a language where THIS happens: php> echo "2coolforschool" + 1; 3 php> echo "2.1coolforschool" + 1; 3.1 php> echo "coolforschool" + 1; 1 So treating all kinds of garbage as valid numbers is absolutely part of PHP.

That's just the general design philosophy of the MP components of the LAMP stack.

Do the stupidest thing that could possibly work; and it probably will. For now.

Re: We will try to stop fixing bugs in PHP

#287

Post by cldrope »

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.

Re: We will try to stop fixing bugs in PHP

#288

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

Re: We will try to stop fixing bugs in PHP

#289

Post by arde »

gcb wrote: post #81
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…

if you can't do that trivial change on some convulated release system... You don't change php version either. Unless you are addressing security changes. I think its very professional to not bump versions just for the sake of it. release notes exist for a reason.

Well, of course they must be addressing security changes! It's PHP, remember? ;)

Re: We will try to stop fixing bugs in PHP

#290

Post by arde »

Yver wrote: post #104
Evbn wrote: post #42

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.

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

They probably only care about the presentation aspect of it, and not doing any calculations with uninitialized variables. The users are probably worried about showing NULLs instead of zeroes on empty fields.
Post reply on HN