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

241–250 of 319 posts

Re: We will try to stop fixing bugs in PHP

#241

Post by rbanffy »

jiggy2011 wrote: post #230
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…

Problem is, at that point you have built a lot of business on top of it. So the issue of whether or not it is "free" is moot because it has a very real dollar value to you and also probably to the boss who is breathing down your neck.

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.

Re: We will try to stop fixing bugs in PHP

#242

Post by Jach »

jadoint wrote: post #215
kenneth wrote: post #103

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…

A bit off-topic: As someone who has built a decent web company on top of PHP, I'm curious to know if you decided to leave it for something else and if so, what was your reasoning? I'm of the mindset to stick with what I know best when I'd rather build a working product and get it out the door quickly. I don't actually personally care too much what language I use (I feel like database selection is more crucial) but I…

This essay has been referenced over and over here, but have yet another link: http://paulgraham.com/avg.html Check out the whole thing, the money quote for this context is: "Back in 1995, we knew something that I don't think our competitors understood, and few understand even now: when you're writing software that only has to run on your own servers, you can use any language you want."

Contrary to the other comment, there are business advantages to using a particular language. (Though I would concede if your only choices are Ruby's Rails, Python's Django, and PHP's Yii, for many problems there isn't much to compel you to one or the other besides your preference and available talent.) I could write a large comment going over the pros/cons for different use-cases of PHP (plain or with a framework like Yii), Python (with Flask), Java (with enunciate), and Node.JS (those are the only languages/environments I've built larger-than-toy webapps with; I still need an excuse to use Clojure's Noir for something). My list would not just be language-war pros/cons but business value considerations and hypothetical consequences. It's not the most important choice you can make, but it should be considered if there's more than one option because the type of problem you're solving can be made much simpler or easier with the right tool.

I think you've got the right mindset, and that's to use what you know for anything important you need to finish soon, but I'd recommend checking out the other environments on your own time just for fun. Also before starting a project, research to see if it's a solved (or mostly solved) problem for another framework/language. Even if there's a learning cost to something brand new, depending on the problem it can be well worth it for the overall cost reduction that the tool provides. There are a lot of "We learned and used/migrated to Erlang" stories out there because Erlang solves particular problems very well.

Re: We will try to stop fixing bugs in PHP

#243

Post by rbanffy »

jerf wrote: post #190
pacifika wrote: post #136

Earlier quoted context omitted.

A possible solution to this would be to put a policy together to only fix things like this in the next major version, not on the current line. As long as it's known that these are long term fixes people can prepare for them.

"The first PHP 5.3 release candidate was back in March 2009. We put these release candidates out there so people who "will have MONTHS of work" because of small changes can chime in then and make their case. The release candidate period lasted until July." I love to hate PHP-the-language as much as the next guy, and I don't particularly love their design decisions for the language, but let's face it, on basic release…

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-off thing. I should have used something like buildbot or jenkins.

Re: We will try to stop fixing bugs in PHP

#244

Post by nathan_long »

Mikushi wrote: post #233
jadoint wrote: post #215

Earlier quoted context omitted.

A bit off-topic: As someone who has built a decent web company on top of PHP, I'm curious to know if you decided to leave it for something else and if so, what was your reasoning? I'm of the mindset to stick with what I know best when I'd rather build a working product and get it out the door quickly. I don't actually personally care too much what language I use (I feel like database selection is more crucial) but I…

There is no business advantages at using Python/Rails over PHP. (and vice versa) You should only use the technology that suits your company the best (in terms of needs and knowledge -never EVER start a company based on a tech you don't understand or know)

Depends. The availability of open-source libraries in a language can be a big advantage.

Re: We will try to stop fixing bugs in PHP

#245

Post by xd »

spacemanaki wrote: post #239
josegonzalez wrote: post #216

Earlier quoted context omitted.

He meant that not in the context of Language Research, which is super-awesome and every developer should be super grateful to researches in this space, but in applied programming, where people piss on whatever language they aren't used to using/think sucks for some arbitrary reason.

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.

Re: We will try to stop fixing bugs in PHP

#246

Post by Groxx »

wccrawford wrote: post #158
Groxx wrote: 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…

3) He said they changed hosts and very few hosts offer old versions of PHP. I don't know if that's correct, but that's what was used as an excuse.

Ah, I must have missed that part, thanks. Though changing hosts is equivalent-enough to upgrading software that I think the point still stands. They probably changed hosts to save money - either go back, or fix what the changes broke, it's part of the standard expectations of changing things.

edit: actually... no, that still doesn't work. They clearly have 100% control over the interpreter since they can patch the source and use the patched version.

Re: We will try to stop fixing bugs in PHP

#247

Post by MartinCron »

rbanffy wrote: post #243
jerf wrote: post #190

Earlier quoted context omitted.

"The first PHP 5.3 release candidate was back in March 2009. We put these release candidates out there so people who "will have MONTHS of work" because of small changes can chime in then and make their case. The release candidate period lasted until July." I love to hate PHP-the-language as much as the next guy, and I don't particularly love their design decisions for the language, but let's face it, on basic release…

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.

Re: We will try to stop fixing bugs in PHP

#248

Post by adambyrtek »

rbanffy wrote: post #241
jiggy2011 wrote: post #230

Earlier quoted context omitted.

Problem is, at that point you have built a lot of business on top of it. So the issue of whether or not it is "free" is moot because it has a very real dollar value to you and also probably to the boss who is breathing down your neck.

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.

Re: We will try to stop fixing bugs in PHP

#249

Post by MartinCron »

rbanffy wrote: post #187
kenneth wrote: post #103

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…

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.

Re: We will try to stop fixing bugs in PHP

#250

Post by Domenic_S »

GlennS wrote: post #235
thought_alarm wrote: post #63

Earlier quoted context omitted.

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…

I disagree completely. This is example of the PHP team working to fix a common criticism of their language: that it's full of inconsistencies. And when encountering push-back from users who depend on those inconsistencies, the developers have stuck to their guns. Well played to Rasmus.

Indeed.

"PHP is full of inconsistencies! What a terrible, amateur language!"

fixes inconsistencies

"PHP broke their functions! What a terrible, amateur language!"

Haters gonna hate.

Post reply on HN