PHP Must Die | Hacker News Reader

PHP Must Die

steike.com

37 pointsnreece46 comments

PHP like any other language has its shortcomings and its strong points.

The market place decides. If you want to get rid of PHP (or 'kill' it) you will have to displace it with something better.

The other alternative is to send in a patch for this bug or simply report it. I've used PHP for many years and while I certainly don't love some of its more subtle problems you can build an amazing amount of stuff in it.

I have personally had good success reporting bugs to the PHP devs.

That's a lot more productive than 'blogging' about it.

In case it isn't clear why the 08 does not print anything, the 8 is an illegal character in an octal string and is discarded.

A suitable error message would be 'invalid character in octal sequence' instead of a silent discard.

$I $use $PHP $on $a $daily $basis $too... ;-)

Mainly because I have to. And I often have to, since many el-cheapo web providers only offer PHP+MySQL. PHP isn't too bad, I don't get bitten often by strange bugs. I see PHP as a common workhorse.

In recent memory I ran in to two real bugs, the one was where a ' in a comment would cause strip_tags to malfunction:

http://bugs.php.net/bug.php?id=46578

Fixed within 6 days, with an email to my address about where to get and how to apply the patch, which was a nice touch.

The other one was technically my fault but it would have been nice to see the 'expected' response from a language I've been using for such a long time.

If PHP is to be improved, the new language must be easy enough a 13 year old can do it and web oriented.

These are I think its two strongest points.

That and the ease of deployment, which is possibly the strongest factor. Most hosting companies will provide you with PHP on apache even if you don't ask for it.

Oh, and good documentation too. PHP.net is awesome. It's probably the largest contributing factor to PHP being easy to use.

I'd say that greatest data structure in all languages is PHP array().

It's actually an ordered dictionary with default implicit natural number keys. Efficient enough to represent concepts such as arrays, sets, queues, stacks, trees, graphs without bothering with hashtables, linked lists, reallocations and other underlying data structures tailored for specific purpose.

You must be joking.

Nope. I honestly think that that this is one of the main reasons PHP is popular and is able to power even the most complex websites with ease.

Before PHP I did Basic (Atari), 6502 Assember, Logo, ACTION!, Pascal (Kyan, Turbo), C++ (Turbo, Borland) , Java, C#. After PHP I did JavaScript and Python.

First I've met PHP-like arrays in awk and was astonished with its versatility.

I still believe that data structure that allows person to make a queue, stack, tree, even graph easily without knowing any theory and planning anything is one of the greatest things I've encountered in programming languages.

I am very dissatisfied that python does not have standard ordered dictionary and strongly differentiates between tuple, array, set and dict even though they provide just overlapping subsets of odict functionality.

It's not just a bug with an associated patch. It's a language misfeature, in a 15 year old language. You can very probably fix it without breaking existing code.

I think they just simply overlooked it.

And since a probable fix without breaking stuff is likely a patch would be all it takes (and a note in the changelog, for the unlikely case that someone did depend on it, not that they'll read the changelog ;) ).

Octal not being the popular thing it once was I doubt it would matter much.

I think more people are 'bitten' by this totally unexpected behaviour of leading 0's suddenly doing wildly interesting things to numbers (what?? there are more numberbases than just decimal???) than there are that expect illegal characters in octal numbers to throw errors.

The site itself is implemented with PHP. Why doesn't the author draw a conclusion from his insight, abandons PHP, and starts eating his own dogfood?

In a world where you have to eat, sleep, and work, sometimes you have to live with a bit of imperfection. If the code works, and you will never need to modify it, it doesn't matter how clean it is. (This is why I use UNIX. It sucks, but it is pretty easy to paper over the suckage. If I used a properly-designed OS, I wouldn't be able to browse the web, program, etc., etc.)

I think there's a more relevant issue here: can we please stop designing languages that use prefix-zero to signify octal? It's a horrible trap lying in wait for those just learning their first language, and then you have to keep it in mind whenever you learn another one, to see whether it's "supported" in this new one as well.

Perhaps, instead, we can come up with some unified representation of a way to attach a base to a number, such as, say, [base]b[number], e.g. 2b0110001 or 16bFF, and use it in every language? (I'd say something about subscripts and their natural use née mathematics, but I'll hold that comment until the iTablet's soft keyboard layout makes people start rethinking APL-like languages.)

In common lisp 08 is the number 8.

clisp -q -x "(print 08)" 8

An octal number has the prefix #o, as in #o3

Python 3 has, I believe, done away with the 0 prefix for octal and uses a consistent prefix system for different-base literals: "0x" for hex, "0o" for octal, "0b" for binary.

I think "PHP Must Die" is a lot exaggerated, I think "PHP should be improved" is a better title!

Yes, but so much would have to be improved that starting off with a clean slate might be easier, yes?

What does "the slate" mean here? There's not one master language out there, so "killing PHP" means one of two things:

1. Using something else for an individual project (maybe a good idea) 2. Replacing all PHP with something else (impossible)

Since a massive amount of the web runs on PHP, "starting off with a clean slate" would definitely NOT be easier. In fact, it would be impossible.

The problem is most of the broken behavior in PHP is never going to be fixed because it would break compatibility.

Printing a warning would be easy enough, you could disable the warning if you want it to work like this. Leave that for one generation with a 'deprecated' attached to it, remove in the major release after that.

Lots of things that were wrong have been changed like that.

The biggest one remaining of the 'old' bugs which I think really would break too much is the strpos return value in case of no match (which is 'false' but 0 is a legal return value as well, -1 would have been a far better choice).

The improved version of PHP is Perl. Which has been around longer than PHP...

I write Perl daily - and sometimes I'd rather deal with PHP...

You're doing it wrong.

If you don't like PHP, you're allowed not to use it.

I disagree. One who must use it on a regular basis has every right to despise it.

On the other hand, if you've never used it, you have no right to an opinion in the first place.

So long as your opinion is tempered with experience, you have every right to it.

But, then, I'm also of the opinion that if you like PHP, you have no right to write code of any sort.

PHP's yacc grammar is a good read, just as an example of how not to implement a yacc grammar. Changing one constant, for example, would make PHP's parse error messages about 1000x easier to understand and resolve. (I sent a patch for this many years ago, but it apparently never made it in.)

The number of things that work by coincidence, like support for octal numbers, is shocking. It's clear that PHP is optimized for something other than correctness.

Hehe, don't get me started :) How about:

- naming conventions

- globals (or, better yet, scope in general)

- 'objects' (I use the term lightly)

And a host of other things.

They could do a lot better still, but as long as nobody comes along and starts to make serious inroads into their user base I doubt this will change much.

What is surprising is not how much is broken, but how far they made it with so much stuff as broken as it is.

I've always thought that if python would have used braces, dropped the whitespace bullshit and came with a ready to go plug-in for apache with a similar ease of deployment that it would have kicked PHPs ass long ago.

PHP appeals to the people that don't really understand programming, so I doubt making the language better in a programming-language-designer way is going to convert users. The next language that's as popular as PHP will be "easier" in some way that's appealing to average users.

Perl was there first; you could "require 'cgi-lib.pl'" and start writing a web application.

Then PHP made that even easier, by making HTML pages valid programs. (You could add code "later"; your scripts didn't have to live in cgi-bin isolated from plain HTML files.)

The average users jumped ship from Perl to PHP pretty quickly, despite Perl having more features, more modules, a better runtime, etc. They wanted to know as little about programming as possible, and PHP got them there. Inexperienced programmers want to micro-optimize for things like deployment or runtime speed, and PHP gives them that.

The next Popular Language will make one of those things even easier.

(Ruby on Rails almost did this, but it went overboard with the advanced programming language concepts, and is now a small niche again. It alienated the experienced programmers, who went with Merb, and the inexperienced programmers, who couldn't wrap their head around concepts like exceptions and just stuck with PHP, which lets you ignore errors if you prefix the line with an @ sign.)

Anyway, what I'm getting at is, "just leave the PHP users alone". Those that want something better will find it. Those that don't, won't.

PHP is used by plenty of people that (at least think they do, looking at myself ;) ) do understand programming, they just use it because they literally got used to it.

The perl community was pretty abrasive when I first looked in to it, the PHP community was the opposite so I ended up programming a large amount of stuff in PHP.

But before that I already coded my way around for about 15 years or so in lots of other languages, projects including cad systems, low level communcations drivers for weird bits of hardware, an OS and a whole slew of other stuff.

Basically my take on it was 'it's good enough for what it's for', web programming and making money.

To this day a good part of http://ww.com/ (possibly nsfw so don't go there if you are on your boss' line) is written in PHP, I've recently gone over the whole thing in order to clean it up readying it for a port to something a little bit more clean.

It was quite amusing to see how many hoops we had to jump through 11 years ago when it was first built compared to how easy you could do some of that today.

For plenty of people it is just a means to earn a living, language aesthetics and purity or expressiveness don't enter in to the equation, it is whatever their boss tells them to use, C#, PHP or Java.

And perl definitely suffered because of the attitude perl aficionados take, both with respect to other languages as well as to those that do not fully grok perl just yet.

Community is a huge part of any programming environment, possibly even more important than the language itself.

Community is important, and that is the main reason why I tolerate Perl's various annoyances. There are simply a lot of Perl programmers that give me excellent code for free (see http://github.com/languages) and that makes it all worthwhile.

The same does not appear to be true of PHP. PHP's community is more talkative ("How to cut-n-paste code to hash passwords"), where Perl's is more programming-oriented ("Authen::Passphrase"). As a programmer, I prefer to stick with the programming-oriented community.

"The perl community was pretty abrasive when I first looked in to it, the PHP community was the opposite so I ended up programming a large amount of stuff in PHP."

Interesting how the "feel" of a community dictates the choice of language. I thought I'd be immune to this effect after programming for 15 years but I recently chose not to use Clojure on an (eventually to be opensourced) project because of the "dumb fanboi" tone of a part of its community.(eg: http://www.bestinclass.dk/index.php/2009/10/python-vs-clojur... HN reaction: http://news.ycombinator.com/item?id=881642).

I chose to use Haskell instead (I like the "vibe" of its mailing lists and irc and blog posts and so on) and have been feeling a smidgen guilty about dismissing Clojure (which I think is really nice - I admire Rich Hickey's tech skills and design sensibility) for its community's stridency.

Seems I am not alone in my weirdness!

This is exactly right. There's a lot of use cases where what's needed are variables, loops, conditional logic, and easy HTML output. In those cases, the winning language is the one that's easiest to learn and to deploy. Problems with handling invalid characters in octal are just not relevant in those cases.

Of course, those cases aren't interesting to HN, but they're common, and PHP legitimately wins in them.

What should die is not PHP but the use of PHP in circumstances where another language would be a better choice.

That is a very good way of sketching it, but even the last part is sometimes not the easiest to do.

I've written a 'media-player-annex-file-sharing-service' ( http://mxchg.com/ ), the thing has a web based front-end written in PHP and a C based back end for audio fingerprinting (so you don't end up storing 10 copies of each possible audio file).

When the time rolled around to write the scripts that glue everything together in the back-end I chose to do it in PHP instead of python for several reasons:

  - it reduced the number of dependencies

  - it removed the need to rewrite part of the code in yet another language 
    (mostly library stuff)
 
  - it removed the need for yet another skill in people wishing to modify it

Perl may have had a better runtime, but PHP was effectively faster since it had an easy to use apache module and most perl code was being run as cgi scripts, which is hardly performant. I remember trying to configure mod perl and mason circa 2002, and it was an excercise in poor documentation and pain. PHP was dead simple to setup. That said I still stuck with Perl (eventually moving to Ruby), and I loathe PHP.

Installing mod_php:

  apt-get install libapache2-mod-php5
  a2enmod php

Installing mod_perl:

  apt-get install libapache2-mod-perl2
  a2enmod perl

But, in general, running app code in the webserver is a bad idea. This is why everyone uses fastcgi in production, and why every web framework (except PHP) ships a standalone dev server for development work.

PHP is the one that's hard to use now, unless you are developing on an already-configured system.

Go to his home page, this link is from 2004!

Sep 1 2004 PHP Must Die A comparison of how different scripting languages treat their users.

Title is troll, and not even original.

A more interesting discussion would be how more advanced, especially functional, patterns can be used in php. Right now I'm returning in php after many years of java and some time with lisp and clojure, and I'd be very curious to know if any of you managed to apply a more lispish mindset to it.

I chuckled at the subtle unspoken complaint about the required semicolons.

As one of my favourite friends (also a programmer) once said:

"languages are like women; if you dont treat them in ways they like then prepare for unpredictability"

EDIT: replaced "designed" with "like" - much better phrasing

This reminds me of that old joke:

"Doctor, doctor, every time I lift my arm it hurts! What should I do?"

Doctor: "Don't lift your arm."

Instead:

"Every time I get lazy and expect Language <x> to catch my problems, it doesn't respond the way I think it should. What should I do?"

Don't be so lazy. Code it right in the first place.

People make mistakes. Computers don't. So people program computers to catch their mistakes, before those mistakes become problems like "crashing" or "losing money".

If you give the compiler invalid input, a subtly-broken program should not be the output. The output should be an error pointing you to your mistake.

True, but in this case PHP corrected its error (it now returns null for this use case, as it should)... this is why you don't rely on undocumented behaviour as canonical. If it says it should return null, but returns zero instead, check this result always.

"Code it right in the first place."

Isn't this advice better applied to the developers of PHP, in this case?

The developers of PHP created the most popular language on the web. They built a language that is not only preferred by people with no programming background, but also powers some of the most influential and popular websites (eg, Wikipedia, Facebook). They did all this with zero-or-negative hype around them and while competing in a space that some of the richest companies in the world (Microsoft, Sun, IBM) have poured massive resources into.

So, yeah, they did screw up here and there. But very few projects were remotely as successful as theirs.

JavaScript is the most popular language on the "web".

Reply on news.ycombinator.com