Live data from Hacker News

We will try to stop fixing bugs in PHP

bugs.php.net

311–319 of 319 posts

Re: We will try to stop fixing bugs in PHP

#311
post #294
post #44

Earlier quoted context omitted.

Can you imagine how many fools like this Rasmus Lerdorf has to deal with, every. single. day. since he created PHP? Same for Linus Torvalds. After a while, you just stop trying to sugar-coat idiocy, and just tell them as it is.

Perhaps it was not like this when PHP was created, but it surely has been for a long while now: Idiots are now PHP's target audience be it by design or by its own faults. So if Rasmus Lerdorf still maintains PHP then he should not get angry by the kind of users he chose and/or deserves.

That's a bit harsh. Like with Java or Perl, there's an enormous installed base of PHP apps which need maintaining and upgrading (and replacing, wherever possible); a lot of people end up inheriting systems they didn't build, and having to keep them up _ad libitum_.

Re: We will try to stop fixing bugs in PHP

#312

Love this snippet: > > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com > Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net

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…

"Perhaps it isn't about being paid, but about taking pride in the work you do."

Even if you take pride in what you do you expect to be treated with a certain level of respect. ( Not that being paid means you should be disrespected of course. )

Re: We will try to stop fixing bugs in PHP

#313
post #311
post #294

Earlier quoted context omitted.

Perhaps it was not like this when PHP was created, but it surely has been for a long while now: Idiots are now PHP's target audience be it by design or by its own faults. So if Rasmus Lerdorf still maintains PHP then he should not get angry by the kind of users he chose and/or deserves.

That's a bit harsh. Like with Java or Perl, there's an enormous installed base of PHP apps which need maintaining and upgrading (and replacing, wherever possible); a lot of people end up inheriting systems they didn't build, and having to keep them up _ad libitum_.

Sure, but those who inherit PHP systems may not belong to the PHP's target audience that I was referring to. Neither must all people who choose to use PHP necessarily idiots, because PHP does have some legitimate use cases. But all in all I don't think PHP maintainers can expect sanity from their users as a general population nowadays. I know it sounds harsh, and it probably is a bit judgmental on my part too, but I hope you get the idea.

Re: We will try to stop fixing bugs in PHP

#314

Earlier quoted context omitted.

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.

Relying on a brain damaged non documented edge case was unanticipated, not the change --which had also been in beta before release. What kind of programmer passes "" and null on a function such as this and expects ....zero in return? And what kind of programmer does it --as he admits-- "all around the place"? If you give right to this guy, that's a very very short and accurate interview question --no hire.

You mistake my use of anticipated. I agree with you, I meant the change was anticipated as in "It was expected to happen". It was in the cards to happen eventually, whether it was intelligent or not.

Returning null in the math library at all just seems counter-intuitive.

Re: We will try to stop fixing bugs in PHP

#315

I understand that the bug reporter is in a bad situation but this is definitely an edge case and passing an empty or whatever non-numeric string to a function that is clearly meant for formatting numbers doesn't really seem like good style. is_numeric(), is_float() and casts are available for a reason. So I guess the answer is ultimately 'deal with it'. That said, I don't see this taking 'months' either, they could j…

A wrapper function is absolutely the right way. Instead, he decides to modify the PHP source and recompile it , effectively forcing him to maintain a fork of PHP, as if somehow that magically takes less effort to develop and QA resources to maintain. Wow.

"Instead, he decides to modify the PHP source and recompile it, effectively forcing him to maintain a fork of PHP, as if somehow that magically takes less effort to develop and QA resources to maintain."

hehe, exactly the same sort of mentality that lead the person/team to somehow write code that end up depending on obscure parts of the api!

Re: We will try to stop fixing bugs in PHP

#316

Earlier quoted context omitted.

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

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

Sounds an awful lot like you are just ignoring the things you don't want to hear. It isn't just that PHP is weakly typed, it is that it has absurd type conversions that no other weakly typed language does, that aren't even consistent, and explicit casts don't serve the expected purpose of forcing the correct type:

    "1e1" == "10" => True

    $a = "foo"; $b = 0; $c = "bar";
    $a == $b => True
    $b == $c => True
    $a == $c => False

    "22 cream puffs" == "22 bullfrogs" => False
    "12 zombies" + "10 young ladies" == "22 cream puffs" => True

    (string)"false" == (int)0 => True
PHP is full of bugs. Ancient bugs that have existed since PHP3, and which are still there. Serious bugs where the lexer or parser is outright broken:

    $ perl -le 'print 07'
    7
    $ perl -le 'print 08'
    Illegal octal digit '8' at -e line 1, at end of line
    Execution of -e aborted due to compilation errors.
    $ python -c 'print 07'
    7
    $ python -c 'print 08'
     File "", line 1
        print 08
              ^
    SyntaxError: invalid token
    $ php -r 'print 07;'    
    7
    $ php -r 'print 08;'
    0
    
    $ perl -le '$foo = 1; print(($foo == 1) ? "uno" : ($foo == 2) ? "dos" : "tres");'
    uno
    $ php -r '$foo = 1; print(($foo == 1) ? "uno" : ($foo == 2) ? "dos" : "tres");'
    dos
PHP is written by absolutely incompetent developers. There were 37 exploitable vulnerabilities in 2011. Compare that to 3 for python, 3 for perl, and 7 for ruby. Steffan Esser was the only person attempting to make the PHP project give a shit about security, and he ended up giving up on it because the other PHP devs absolutely refused to consider security as important.

These are not problems that are fixed in recent versions of PHP. They are not misinformation. If you want to revel in your ignorance, feel free. But don't expect the rest of the world to tip toe around the facts to avoid inconveniencing you with reality.

Re: We will try to stop fixing bugs in PHP

#317

Earlier quoted context omitted.

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

Well, 1.9 was the "unstable" branch leading up to 2.0, that's why that actually matters. And that's why most of those changes were made at that point - they were intended to land in 2.0. Later the decision was made to roll 1.9 as a stable release since 2.0 would take another couple of years and encoding support was an important feature that people wanted to ship. So a lot of changes that could not be handled in a BW-Compatible way landed in 1.9 since encoding support required those changes. String all of sudden was not enumerable any more since there was now String#each_byte and String#each_char which did something different. Require was changed because loadable encodings were an attack vector, ... But for people that needed the old behavior 1.8 was supported until lately and REE (1.8 patched) is still supported.

The breakage in 1.8.6/1.8.7 was widely regarded as a massive failure on the maintainer side - a bugfix for a security vulnerability that had other changes land in the release (and subsequently segfaulted, sigh). That's however not a design change. Something like that has never happened ever since.

I actually agree with you up to a certain point: The ruby ecosystem is was and still is pretty unstable. Things have settled a little lately, but gems still appear and disappear, are superseeded by newer versions or other gems that do things differently. That's good in some ways, since stuff evolves and improves, bad in other ways - the lib you depend on just disappears or falls out of maintenance. However, none of this is the core-languages fault. Behavior of ruby as a language has been pretty stable during the last couple of years.

Re: We will try to stop fixing bugs in PHP

#318
post #218
post #206

Earlier quoted context omitted.

And his point still stands. :) Could not resist.

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…

It is too bad if people complaining about PHP makes someone feel bad.

What's really important here is that people need to be aware when they are adopting a tool which brings this much technical liability.

People should not be unknowingly exposed to this relentless stream of years-old, fatal bugs. Life is too short and it's even more unfair to newbies to make them deal with nutty, random issues like 'can't use a Turkish locale'. This isn't just picking on PHP. These bugs are epic and breathtaking and impose an exceptionally high amount of effort to work around.

It is clear by now that (A) these are not just a few isolated bugs but a big pile (B) most of this pile is old and already known for years (C) the PHP team is not fixing the pile despite lots of time (D) it would be such an epic amount of work to fix that you could never reasonably expect others to do it, especially if they have no reason to be invested in PHP (how is that reasonable?) (E) you could never get the fixes and cleanups published because of all the existing code which would be broken, unless PHP adopted a risky, even more labor-intensive backward-incompatible renovation project (F) there are already multiple well developed alternatives which do not have these problems, so why would I wait for PHP to get its house in order?

I'm not saying that PHP sucks and could never be fixed.

I'm saying that PHP doesn't have enough positives to justify the huge time and effort to fix it... or to suffer through using it for years. There is no third choice.

Why on Earth would I bust my butt trying to fix this pile of bugs when I can just use anything else?

Just because I feel sentimental about the name 'PHP'?

This is a slowly sinking ship, it is not responsible to tell newbies to get on it.

Re: We will try to stop fixing bugs in PHP

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

In all fairness with enough hardware you could serve ~1 billion users using virtually any language which supports development of web applications. Just because you can develop a hugely successful system using a language doesn't prove (or disprove) that said language is necessarily the best tool for the job. It just happens to be what FB picked.

Right, you could use BASIC or any Turing-complete language.

Actually, BASIC has been written so many times that you would probably get a pretty sane and systematic experience out of a web BASIC. Relatively speaking.

Post reply on HN