Live data from Hacker News

We will try to stop fixing bugs in PHP

bugs.php.net

111–120 of 319 posts

Re: We will try to stop fixing bugs in PHP

#111
post #89
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?

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

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

Re: We will try to stop fixing bugs in PHP

#112
post #40
post #22

Earlier quoted context omitted.

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.

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.

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.

Re: We will try to stop fixing bugs in PHP

#114
post #105

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…

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

Re: We will try to stop fixing bugs in PHP

#115
post #114
post #105

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…

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

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.

Re: We will try to stop fixing bugs in PHP

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

Re: We will try to stop fixing bugs in PHP

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

Re: We will try to stop fixing bugs in PHP

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

Re: We will try to stop fixing bugs in PHP

#119
post #46

Earlier quoted context omitted.

I'm honestly chuckling at the thought of Linus responding to this one in Rasmus' place. If you need the features of an old version, use the old version. Simple as that. Don't expect the rest of the world to be stuck with dealing with backward compatibility just so you aren't inconvenienced. Upgrade, pay for support, move to another platform, or stop complaining.

Linus would have called the guy an idiot for not using straight C.

And being rusty in it no less.

Re: We will try to stop fixing bugs in PHP

#120

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

"Also, when dealing with something as important as that, you ought to know better than to base our technology on top of PHP."

Upon reading the conversation I was amazed he didn't get that response right away.

Post reply on HN