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

261–270 of 319 posts

Re: We will try to stop fixing bugs in PHP

#261

Post by Zak »

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.

Not that I disagree, but PHP only got exceptions relatively recently. The built-in functions existed long before that. Without exceptions, the options for error handling are to return an error value or exit, writing an error message somewhere. Null seems like an appropriate error value for "you asked for some data formatted as a string, and for whatever reason, I couldn't provide it".

Re: We will try to stop fixing bugs in PHP

#262

Post by StefanKarpinski »

pbiggar wrote: post #260
StefanKarpinski wrote: post #259

Earlier quoted context omitted.

I'm happy to remove the comment. What guideline is this in direct opposition to? Genuine question, not being snarky.

Its in the footer: http://ycombinator.com/newsguidelines.html

"Be civil."?

Re: We will try to stop fixing bugs in PHP

#263

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

Re: We will try to stop fixing bugs in PHP

#264

Post by kstrauser »

psaintla wrote: post #205
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…

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 doesn't know the difference between NULL and 0. NULL is not 0. It's NULL. I don't want tax software reporting that I owe "$0" instead of "$badvalue". At a minimum, I want it to throw a giant red error dialog that scares me into double-checking all my inputs.

Re: We will try to stop fixing bugs in PHP

#265

Post by nbm »

ricree wrote: post #232
j_col wrote: post #130

Earlier quoted context omitted.

> I use it for some piddly shit because that's what it's good for So do Facebook.

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 PHP expect. With the right abstractions and code organisation, it is fairly clean and understandable even at the relatively large size (even if I'm not generally a fan of the language and would almost certainly not make the decision to use it today).

It is somewhat less interesting whether the PHP runtime is as efficient as it can be. Partly because one can use an alternative runtime like HipHop for PHP if you want to. And partly because very few people have to worry quite as much about performance/efficiency that comes with a large capital/operational cost where you have hundreds of servers.

So while "But Facebook uses PHP so it must be good" is not the best argument, neither is fighting it with "But Facebook reimplemented it!".

Re: We will try to stop fixing bugs in PHP

#268

Post by nbm »

gbvb wrote: post #221
j_col wrote: post #218

Earlier quoted context omitted.

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…

I agree. I was commenting on Facebook "the social network" and not Facebook the "technology".. :) Anything that can be made to support such large transactions (be it with duct tape and glue) has to have a core capability to support such usage.

It is important to keep in mind that Facebook isn't just a single PHP code base, and thus one can't really make many assumptions about how well PHP is suited to solving certain problems because one doesn't necessarily know about which bits are implemented in PHP, or whether PHP is just a templating/rendering stage over work done elsewhere.

Some other languages might allow you to do certain operations in the front-end more easily, but the way to approach it when using PHP might be to delegate that to a back-end service in another language. Similarly, some languages might allow you to write both most front-end and most back-end software in the same language, where PHP might be wholly unsuitable or makes certain things harder to achieve than it is worth using it for (maybe strict memory usage control, maybe where you're looking for CPU cache wins).

Re: We will try to stop fixing bugs in PHP

#269

Post by rbanffy »

MartinCron wrote: post #247
rbanffy wrote: post #243

Earlier quoted context omitted.

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

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.

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.

Re: We will try to stop fixing bugs in PHP

#270

Post by rbanffy »

adambyrtek wrote: post #248
rbanffy wrote: post #241

Earlier quoted context omitted.

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.

> 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).
Post reply on HN