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

301–310 of 319 posts

Re: We will try to stop fixing bugs in PHP

#301

Post by secoif »

blindhippo wrote: post #210
xd wrote: post #127

Earlier quoted context omitted.

"I use it for some piddly shit because that's what it's good for." The bigotry from this community when it comes to PHP has left me sick to my stomach.

Use the best tool for the job. Often, the best tool in web software is the one you can get the most/cheapest labor for so you can actually get your product completed and on the market. No one cares if your software is programed in the latest tech with the very best techniques - all they care about is if your business is viable. PHP fills this niche excellently. As a developer I make my living off PHP. I'd rather play…

Every php job can be turned into a rails/django/whatever job, you just need to sell it.

Re: We will try to stop fixing bugs in PHP

#302

Post by tubbo »

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…

It's really hard to not blame the creators when SO MANY things in PHP are fucked up. I would wager a good bit of cash that this isn't the only "wtf-moment" this guy's dealing with in terms of his day-to-day PHP adventures, and it was simply the straw that broke the camels back. Couple that with an innate misunderstanding of how open source works and a bit of idiocy, and you got the motivation for this bug report.

Re: We will try to stop fixing bugs in PHP

#303

Post by tubbo »

jbm wrote: post #129
xd wrote: post #127

Earlier quoted context omitted.

"I use it for some piddly shit because that's what it's good for." The bigotry from this community when it comes to PHP has left me sick to my stomach.

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

Well that's the biggest piece of bullshit I've ever seen spewing out of someone's keyboard here on HN. I've been developing in PHP pretty much since it came out. At least, since it was stable/useful enough for people other than Rasmus to use. I've been using it for so long that I absolutely hate it. The inconsistencies, the "bolted-on" OOP, the amount of time I'm just sitting there scratching my head wondering where the fuck my data went to, and not even being able to test the thing since there's no good testing libraries built for PHP. It's all a confusing mess that I refuse to even be paid for at this point.

Re: We will try to stop fixing bugs in PHP

#304

Post by memset »

Jach wrote: post #242
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…

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

I would be interested in reading a blog post which details your experiences and business decisions behind all of the frameworks you have mentioned.

I often find myself wanting to start new projects in $new_platform but have no idea how to really compare them before I get started, save for looking at their documentation or advertised features.

Re: We will try to stop fixing bugs in PHP

#305

Post by gurkendoktor »

Xylakant wrote: post #195
Tloewald wrote: post #151

Earlier quoted context omitted.

So you dismiss a bunch of valid breaking changes because you weren't affected by them and then cite one you know about. Well played, sir.

Well no, all I'm saying is that they indeed were breaking changes, but not "obscure design decisions". All of them were made for a reason and the reasons were public. Some of them had easy workarounds (like a commandline switch) Most of them happened at the transition of a major release and made the introduction of major features possible. Ruby 1.8.6/7 was supported for years after the transition for people that had…

Looking at the sibling comment, I'll happily take back the word "obscure" if it sounds too negative and subjective. But I stand by my opinion that Ruby is unstable because most of the above changes could have been handled in a backwards compatible way (for non-pathological cases). That should-be 2.0 was turned into 1.9 does not help :)

Not that stability is always the right choice, I wish C++0x would have been more radical, for example. It does matter for long-lived codebases though.

Re: We will try to stop fixing bugs in PHP

#306

Post by soc88 »

xd wrote: post #197
soc88 wrote: post #164

Earlier quoted context omitted.

Why? He said that the design principle of this method is in line with the rest of PHP, that's a correct and valid observation.

So how would you propose changes are made to an "API"? Never? The change was made in a new version, with the changes clearly laid out in the changelog .. what more do you want? It's funny. PHP gets a bashing for the rotten bits .. when the rottern bits get patched up it gets a bashing for breaking BC. Anyway, I don't think you understand just how empty that attack was. Frankly it was nothing more than the ramblings o…

“Patching up” would suggest that they actually improved the situation.

If you had read the diff you would realize they did not.

Re: We will try to stop fixing bugs in PHP

#307

Post by nilliams »

Firehed wrote: post #279
psaintla wrote: post #223

Earlier quoted context omitted.

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

I agree with you there and I'd be happy to see "use strict" in PHP.

Re: We will try to stop fixing bugs in PHP

#308

Post by xd »

soc88 wrote: post #306
xd wrote: post #197

Earlier quoted context omitted.

So how would you propose changes are made to an "API"? Never? The change was made in a new version, with the changes clearly laid out in the changelog .. what more do you want? It's funny. PHP gets a bashing for the rotten bits .. when the rottern bits get patched up it gets a bashing for breaking BC. Anyway, I don't think you understand just how empty that attack was. Frankly it was nothing more than the ramblings o…

“Patching up” would suggest that they actually improved the situation. If you had read the diff you would realize they did not.

The change was an improvement .. I'm not sure what point you are trying to make? Maybe I misunderstood you or you don't understand the change.

Re: We will try to stop fixing bugs in PHP

#309

Post by [deleted] »

Zak wrote: post #273
xd wrote: post #245

Earlier quoted context omitted.

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

[deleted]

Re: We will try to stop fixing bugs in PHP

#310

Post by fragmede »

aniket_ray wrote: post #98
kyberias wrote: post #96

People have been wondering "what would Linus have said?" I'm pretty sure he wouldn't have broken the existing (undocumented) behavior in the first place "because it breaks applications and the one and only reason for kernel is to allow applications to run". But then again, PHP is not a kernel. :)

I think you are entirely right. As Linux says "Kernel exists for its users". Pretty similarly, a platform (php/zend) exists for its applications. Linus has always been pretty adamant about not breaking API behaviour even undocumented ones. But in this case, undefined behaviour had been previously documented. Also, was it him or Ulrich Drepper who were against changing memcpy undocumented behaviour. (mempcy used to wo…

Yes, eg: https://lwn.net/Articles/494993/

Linus took extra steps to no break autofs behavior, even though it was (more) due to a bug in GCC than anything else.

Post reply on HN