PHP needs to die. What will replace it? | Hacker News Reader

PHP needs to die. What will replace it?

seldo.com

46 pointsseldo93 comments

I've been using PHP professionally since it was called PHP/FI, and while it's a terribly designed language, I've longed stopped hating it. I know all of it's quirks, and I know all of it's work arounds, and the density of support it has can't be beat.

I wouldn't complain if a better server-side language came around (not a big fan of Ruby's syntax, but Google's Go looks enticing), but until then, I've built incredibly complex apps in PHP, and rarely do I run into a limitation of the language. My biggest issue in the past was the lack of namespaces, and 5.3 has those.

I think the best thing you could do to get a new language as popular as PHP isn't to evangelize, or even to make the language dead simple, but make it dead simple for administrators to add support to a typical shared hosting environment.

PHP's amenability to shared hosting environments is an advantage I failed to mention.

I'm pretty much in the same place as you with regards to PHP: I know it like the back of my hand and everything and everybody works with it. But the code is ugly compared to other languages and I really want method chaining, dammit. Plus, of course, I don't want to have to write an MVC framework every time I want to do something.

Unless you're being more specific than I think you are, PHP5 has basic support for method chaining, I use it all the time.

I use structures like this in PHP5 all the time:

  $object->doThis()->doThat()->doTheOther();

But maybe he is referring to method chaining using PHP's built-in functions. There isn't a way that I'm aware of to do the following (short of wrapping the built-in functions with your own classes):

  $string->preg_replace("/[^A-Za-z]+/","_")->trim()->upper();

Precisely what I meant, thanks for clarifying.

But this is not method chaining, that's simple function nesting, and can easily be done as:

$string = preg_replace("/[^A-Za-z]+/","_", trim(upper($string)));

Or am I missing your point?

something tells me you don't know what method chaining is

Re: MVC re-writing. I settled on Zend Framework and havn't looked back. http://framework.zend.com/ (link added)

> I really want method chaining, dammit

What? We've been doing code like:

    filter('user')
        ->first_name->like('bob')
        ->age->equals('22')
        ->order_by->created->desc
        ->find();

Since 5.2.x

Method-chaining has been there for a while.

I keep happening upon projects with their own craptacular homebrew MVC framework, and their own abysmal homebrew caching.

Fix is a swap for yii and memcached -- feel free to choose your faves.

5.3 has namespaces? Awesome :)

Yes, but in true PHP fashion they're just slightly ugly. :)

namespace my\name;

$c = new \my\name\MyClass;

Leave it to PHP to look up to MS-DOS for inspiration.

Ug. I thought you were joking. Now I'm sad for humanity.

Ugly but functional, that's good enough for me :)

while it's a terribly designed language, I've longed stopped hating it. I know all of it's quirks, and I know all of it's work arounds, and the density of support it has can't be beat.

Stockholm Syndrome?

Oh yeah, it's totally like being violently threatened and abused by terrorists. That's a perfectly reasonable analogy.

Seriously, when you've been programming long enough, you really stop caring about programming languages. I could build a huge project in VB.Net or ColdFusion if I had to at this point. If there's good reasons for why a language should be used (and PHP has plenty of them that are external to the language itself), then it's immaterial to me.

Yeah, any replacement will need to be _everywhere_. No-one talks about PHP deployment issues, because it's literally everywhere. You have to build your own server if you want one _without_ php. That's it's killer feature.

PHP can die when there's another language that's as dead simple to run as PHP. A new programmer can open up a text file with a php extension on (pretty much) any web server, type "<? echo "Hello World"; ?>", and it works.

You are mixing your requirements really badly here: a language that's "dead simple to run" vs a language that works stupidly simple with the web.

Ruby is very easy to run: puts "Hello World"

As is perl: print "Hello World";

Php? <?php echo "Hello World"; ?> (wtf is all that crap, says the new programmer)

The point the OP is trying to make is the "stupid simple with the web" side of the equation. Of course the PHP side isn't as simple as "the language runs on the web". PHP runs on Apache because of the tons of work put into mod_php to integrated it and make it work as easy as possible.

You can't "just run" php on nginx, lighty, etc. Then you need to setup FastCGI instances, and now you're no different from Rails land with mongrels or thins.

Ruby is very easy to run: puts "Hello World"

You are confusing Ruby for Ruby on Rails.

Ruby is easy to run. Ruby on Rails, not as much(relatively).

Since he never said anything about Ruby on Rails and he was talking about languages rather than web app frameworks, I'm pretty sure he meant Ruby.

Comparing use of Ruby to PHP is like comparing C++ to PHP. It makes little sense. We don't write web pages in C++ or Ruby. We do in PHP and RoR.

Actually, PHP is not a programming language. It's a templating language gone bazooka.

He is referring to an under-appreciated virtue of good software: installability.

apt-get install php5

Usually you don't even need that.

I don't understand how this is distinct from PHP's competition. Python is "apt-get install python" — two extra characters are not going to break even the greenest noob's back.

And if this is the argument, Perl is in Debian's default install anyway. Hell, the APT system is partially written in Perl...

What? PHP is not in the default install of, say, Debian. But Perl is.

Actually, perl is "say 'Hello, world.'". Shorter and more readable.

Here you go, works on heroku. http://github.com/capotej/joke

Ironically, that requires 2 extra steps, your script and heroku.

As opposed to what? Getting a shared host and uploading? Same two steps.

any language with cgi.

I don't see a reason for PHP to "die" (using that term very loose, considering that people think PHP killed Perl, while Perl is still very alive and well).

When people just want something nice and simple, PHP works beautifully. There's nothing wrong with the parts of the language that people who don't know programming are using to glue pieces of their website together. It's really only once you start using it for more than that when you start hating the terrible design choices and language constructs.

Leave PHP as the ubiquitous solution for simple glue, it does it quite well. When people want to do web development beyond the glue they can turn to any other number of great languages/frameworks.

> "<? echo "Hello World"; ?>"

That's actually a good example for why it should die (embedding code in html).

And what exactly is a .html.erb file? The erb stands for embedded Ruby if I'm not mistaken.

It's okay to use it for templates only (and the same is true for php if you use a sane framework). If you use erb files to quickly hack together a dynamic web-page I'd be wary though.

A lot of misinformation in this post. Perl pointers? The Perl hash is the same as the PHP assoc. array (thats where they got it from). PHP has both lambda's and method chaining (method chaining isn't a lang feature).

confusing language and platform/framework - "the language now requires modification by a framework to do what you need." and "I want a language that assumes everything I will be building is an MVC web app, and builds that right into the core language, not just a library.". yikes.

Not sure what else to believe in this article after spotting basic errors (not to mention terrible cliches, assumptions, no background or references etc. and statements like this - "nowadays it doesn't feel like you're doing it properly these days")

Yeah ... after all that I'd stop and think if a complete rewrite is really necessary or if I should maybe bring somebody in who know RoR and fix what I've fucked up.

You're the second person to mention that perl doesn't have pointers; references are not strictly speaking pointers but functionally very similar. I think it's pretty obvious those are what I was referring to, and disputing the naming seems like nit-picking.

Many of PHP's basic functions do not return objects, therefore method chaining frequently doesn't work. It would have been more correct to say that I want "everything is an object" to be a feature of the language.

Lambdas only recently turned up in PHP (though I'm pleased to see them!). My point is that in PHP these features are being shoehorned in late in life, and it seems like a language which was designed with the expectation of these features would be a better choice at this point.

And finally, yes, I want a language that assumes everything I will be building is an MVC web app, and builds the necessary infrastructure at the language level, with the performance and stability gains that implies, rather than having it built as a framework on top of the language. It seems weird, I realize, but no more weird than PHP seemed in 1995, with its assumption that everything you'd be writing was a web page.

I just finished reading past "Forward Ruby on Rails". I started writing down couter-points, and realized my list was longer than your article - so I deleted it to tell you this:

You seriously need to edit this post, or just take it down.

references are not strictly speaking pointers but functionally very similar

I have more than a passing familiarity with C and Perl. References and pointers are very different. For example, you have to know where you allocated the memory pointed to to work with pointers effectively. You can also lie to the compiler about the type of pointer. You can also do math with pointers.

These are very useful things to do in C (or assembly or C++ or whichever languages give you access to raw memory), but you don't have to do any of those things in Perl because you don't have access to raw memory.

Similarly you can get into a circular reference situation with references that you won't normally find in C unless you have a specific type of garbage collector.

disputing the naming seems like nit-picking

Accuracy is important in programming. The difference between lightning and lightning bugs is not merely degree.

Hmm,

I'm starting to think that "confusion" can defined as "repeatedly expecting people will do what you think they should do after seeing they don't"

In this sense, thinking language and platform can be glibly separated is the approach that looks confused given the present era. Languages live or die today based on their default platform, their example code, their default programming style, etc..

Part of this is that large changes in group behavior are actually easier than small changes. Will we improve our Perl/C++/VB style - heck no, we're used to doing it our way. Will we learn a whole language with a whole new style? Maybe, especially if it can be sold as the sexy-secret-source. So talking about the whole package is realist if not literally accurate.

> The Perl hash is the same as the PHP assoc. array...

Perl has real arrays as well as hashes, though. PHP only has one object which acts as both.

> PHP has both lambda's

create_function() isn't really a lambda: the created function isn't bound to the local variable namespace that it was defined in.

no php has native lambdas and closures since 5.3.

Fair enough! (http://php.net/manual/en/functions.anonymous.php) Still, it's taken them a long time to add that.

Perl has pointers? Uh, nope.

Also, how does Perl not have associative arrays? Oh, you mean that vectors and dictionaries are separate types, whereas PHP has one type that does both poorly? Yeah, I'm sure that's why PHP is so popular.

(What is it with people writing about Perl as though they are experts without ever having written a Perl program?)

Looking back at my own experience as a newbie developer in 1995, the convenience of PHP was absolutely the reason I picked PHP over perl, and having arrays that could also be dictionaries if I changed my mind was a big part of that.

What kind of programs are these where you don't have to rewrite a bunch of other code anyway to account for the difference between keyed and indexed lookups?

PHP programs.

In 1995, PHP was a set of Perl scripts that Rasmus had just posted on Usenet.

What is it with people writing about Perl as though they are experts without ever having written a Perl program?

I've long believed that some sort of rigorous comparative linguistics education would only benefit programmers. Certainly it could have squelched some of the howlers in this article.

What he probably meant to say is:

In Perl, you can pass only one kind of argument to a subroutine: a scalar. To pass any other kind of argument, you need to convert it to a scalar. You do that by passing a reference to it. A reference to anything is a scalar. If you're a C programmer you can think of a reference as a pointer (sort of).

That's from

http://www.troubleshooters.com/codecorn/littperl/perlsub.htm

... which I found because I, unlike the OP, happen to remember that the thing-which-is-sort-of-like-a-pointer-only-not-really in Perl is called a reference.

So let me help the original author: What he meant to say is that "Perl has things that remind me of pointers, but have a different name, and that aren't exactly pointers, but are nearly as confusing as real pointers, especially to someone who just wants to put up a simple web page in five minutes."

But PHP is just as confusing. When you say:

    foo("bar", "baz", "quux")

and

    foo(array("bar", "baz", "quux"))

you have the same confusion problem as Perl. Except there's no explanation for it at all.

I guess if you don't know anything about programming and never hope to, "Oh, well, uh..." is good enough.

This makes me sad.

Yet another article that wants a language to be a framework. Ruby on Rails is a framework just like Symphony, Kohana, etc are frameworks for PHP.

Thus you can't compare something like Rails to PHP, but rather would need to compare Rails to the many frameworks out there. There are many frameworks out there that make working with PHP a joy, some like NOLOH (which I'm a co-founder of) feels like it's own thing completely allowing you to work in a single language that shields you from having to deal with the craziness that is client-server interaction, AJAX, Comet, SEO, etc, something which the author alludes to wanting to have.

If you don't want to use a framework, PHP can be very useful by itself to write quick scripts, just like many other languages. Furthermore, the release of PHP 5.3 last year has moved PHP forward considerably and makes the frameworks and libraries available for it even cleaner, and more powerful than before.

Personally, I'm an advocate of using the best tools for the job, but first it's important to understand what in fact that tool is and what it's capable of.

Ultimately, any blanket statement that suggests something that's being used by millions of developers and some of the largest companies out there should die just doesn't sit right with me.

I've noticed that it's in vogue to bash PHP, but frankly, with the current state of the language, along with its frameworks and libraries, there's no better time to work with PHP. It reminds me of a recent exchange I had with an associate of mine, we were talking about writing a script and when the mention of PHP came up, he bashed it without reason. He hadn't used PHP in years, but just had this impression in his mind that it was bad. Several days later I showed him the completed script in PHP and how clean, clear and concise it was. He was amazed.

I would hope that we could move beyond such statements and take pride in what we produce, instead of second guessing yourself when the tool you're using is getting the job done, lets explore some of the amazing tools, frameworks and libraries that are pushing PHP forward.

This is the best comment here. Haters gonna hate. Players gonna play.

I've noticed that it's in vogue to bash PHP, but frankly, with the current state of the language, along with its frameworks and libraries, there's no better time to work with PHP.

I've noticed that, too, I think a lot of people who bash PHP may have used it at one point, switched to something like Rails or Django, and assumed that PHP stood still, which just wasn't the case. In fact, while I may not use rails, I'm very glad it came about, because it was a very necessary kick-in-the-ass to other language communities to address common and necessary development concerns.

The thing about new technologies, is that they rarely replace the old technologies, usually they just provide new ideas to make the old technologies better.

I wouldn't be surprised; that's certainly the pattern that befell (early-ish) linux users that moved away from the platform.

The language that newbies love is never going to be the language that experts love. Andy Hunt writes about this somewhat in his book Pragmatic Thinking and Learning - newbies need a level of structure and support that experts would feel to be braces restricting their movement.

Whatever eventually replaces PHP will have to be easy for beginners to get going with. I assume it will not be a compiled language. I think that rules out most of the languages on the JVM, even the really easy ones, because it is on the JVM, and dealing with compiling is one more hoop that beginners won't necessarily want to jump through. CLASSPATH is not friendly. Likewise, I'd rule out .NET languages.

New languages tend to gain a foothold when people change contexts, so I assume cell phones offer a starting point. A light weight script language that works on cell phones? I am not sure what that will be.

Yes, let's kill PHP. Now we just have to figure out who's gonna rewrite Facebook, Wikipedia, Yahoo, flickr, digg, all drupal sites, all Wordpress blogs...

Facebook has said php is a legacy problem and they wouldn't use it again if they were starting over. The Wikipedia code is horrendous. Wordpress is a security exploit masquerading as a CMS.

I've found PHP very useful as an indicator of what jobs I do not want to apply for.

I have a similar love/hate relationship with PHP. I write PHP because I want my code to be used by as many people as possible. As long as another language gets even a tenth of the deployments PHP has, I will gladly start writing software in that language.

One thing that must surely die, is PHP 4. Please stop making your PHP projects backwards compatible from PHP 4.2 and up. PHP 5 is a lot more palatable and 5.3 even more so.

We have to kill PHP version 4. With fire.

It would be a service to all PHP users, as well as the PHP developers who still have to maintain the 4.2 branch. And it would move PHP 6 one step closer to reality, from the pipe dream it seems like today.

perl is dead?

http://www.indeed.com/jobtrends?q=perl,+php,+rails,+ruby&...

that is also an accurate picture, but lack of growth doesn't imply death.

It doesn't imply it, it forecasts it.

Someone is going to figure out a really nice framework on top of nodejs for making webpages with javascript.

edit:

Which is to say, I think javascript is a great language, has the benefit of being the de-facto language of UI development on the browser (and on a lot of embedded apps now as well). Nodejs alone is much too low-level and evented for normal humans to use for throwing together a web site without callback mindfucks, but its a great base to build something on.

There's some confusion between PHP and Perl, the languages, and PHP and Perl+various things as solutions for creating web sites.

I think most people is missing are missing the point. The issue isn't whether PHP, Python, Ruby or Perl are better as of today, but if we are missing something that is even more aligned to web development. For the past few years PHP has been the language of choice for many many programmers because as its name imply, it "pre processes hypertext" (and words actually matter). Do we need some new kind of language (not framework) that understands caching, REST, CRUD, templating, asynchronous calls the way we need it on the web of today (and the near future)?

I guess nobody here is calling for a new language to rule them all, or for a champion framework. I guess as hackers the least we can do is DO NOT assume that what we have today is what we'll need tomorrow.

I don't know if there's an easy answer to the dilemma (or if your arguments are solid enough) but it makes me think. Thanks for bringing this up.

One major point of contention: the quality of PHP's documentation is a critical part of it's overall value to developers.

A language isn't done until it's documented. Parts of the language available that aren't documented simply don't count.

A competitor has to beat PHP on both the lingual and documentation fronts to win.

If a programming language 'needs to die', it does. If you have something better in mind, go ahead and write it. If it really is the replacement for the language you hate, I'm sure everyone will thank you for it.

True programmers aren't stuck to a language. They switch to whatever's best for what they're doing. Often, that means sticking with the language they know best to minimize issues and speed development. But often, they know multiple anyhow and have more choice available.

True programmers make a point to learn about the new languages and their strengths and weaknesses. If a new language came out and was worth looking at, they would. They may not learn enough to actually use the language yet, but always enough to know when that language might be the best solution.

I imagine that the convenience of PHP is why its still going strong. Simply because you could have a html file with some php tags in there and throw it up in a directory on your webhost and you now have a "dynamic" webpage.

The problem is that most popular PHP applications (and, by extension, most PHP-driven sites) are far more complex than that model allows for. It's telling that HTML appearing before a <? tag is generally considered a mistake. :)

> Ruby is a newer, cleaner language, with modern features and a sparse, elegant syntax...

This isn't entirely true. According to the two languages' Wikipedia pages, development on PHP started a year after Ruby. The first public version of PHP came out six months before Ruby.

http://en.wikipedia.org/wiki/Ruby_language and http://en.wikipedia.org/wiki/Php have more.

Here are the salient dates:

- Ruby conceived of in December 1993

- PHP development started in 1994

- PHP/FI 1.0 released in June 1995

- Ruby 0.95 released in December 1995

- PHP 3.0 released in 1997

Those dates don't say what you're claiming. They say that PHP development started at most a year after Ruby was "conceived of" ("December 1993" could be as little as one day before something that happened in "1994"), and PHP/FI 1.0 was released before Ruby .95.

Also, I'm not sure comparing languages by when somebody started toying with the first prototypes is very meaningful. You could say Clojure is decades old by viewing Lisp as a prototype.

Sure they do.

The implication in the article, as I read it, was 'Ruby is a wizbangy new language that sprouted into being only recently' whereas the truth is that it and PHP are just about the same age.

Maybe I wasn't clear. I was disagreeing with the statement: "development on PHP started a year after Ruby"

The dates you posted show that this is almost certainly not the case, though they do indeed disprove the idea that "Ruby is a wizbangy new language that sprouted into being only recently".

The very latest possible date real development started on Ruby was Aug 19, 1994. http://cvs.ruby-lang.org/pub/ruby/1.0/ChangeLog-pre-alpha

It is likely this code predates that date given that there is no reference to the 0.95 release or anything before that.

update: the earliest release I can find is Ruby 0.49 from http://eigenclass.org/hiki/ruby+0.95 (direct link: ftp://ftp.ruby-lang.org/pub/ruby/1.0/ruby-0.49.tar.gz)

The earliest date mentioned in the CVS entries file is March 17, 1994.

To me, the point of this whole thing is that the author's statement of "Ruby is a newer...language" is inaccurate. You're absolutely correct that I cannot definitely prove that "development on PHP started a year after Ruby."

And language age comparisons are entirely meaningful in this case, given that the OA specifically describes Ruby as a newer language than PHP. Ruby is definitely clearer and cleaner. But it is certainly not newer.

PHP established itself when there was no real contender for a HTML preprocessor that could mix server-side code in with web pages. There are a staggering number of choices for this now, but none of them come anywhere close to being widely supported on every Linux shared host in the world like PHP is.

Hah! Rails? Seriously? Rails is a framework, not a language. And there are far too many really huge project using PHP (larger than any Perl project I know of) to suggest whacking PHP for Ruby in any flavor.

Am I the only one who sometimes wishes I could write PHP-style pages in Ruby? Sometimes a whole framework is overkill. I wish I could make Ruby pages as simply as I can take an HTML file and sprinkle in some PHP.

he cites performance as the main reason why he hates frameworks, but it seems like a compiled php module that implements an mvc framework would gain performance and put the "web development back into the language", so to speak.

creating a new language is not the answer. that will work up until the day you need to do something beyond tying a database to an html form, like process images or encrypt files or talk to a weird database that isn't mysql. php, ruby, and python have a ton of modules and 3rd party libraries that can be tossed in to accomplish a lot of things.

(Insert hackneyed religious battle between Python and Ruby here).

Precisely what I was trying to avoid by being as respectful as I could to both languages. They're great, they just don't do what I want.

Haha nothing against your article - it's well written. But if we're on HN, any post that can invite an argument, will invite an argument.

My day job is mostly php and I have come to hate it. 5.3 is tolerable, but it was released in 2009 so a lot of servers/hosting are stuck with the completely fucked PHP of the past 15 years.

PHP.net's documentation is pretty good, even though half of it is discussion of language limitations. The problem is that PHP is also the first language every new developer so there is an incredible noise background. Searching for a problem in another language I can usually find a could good blog posts with solutions and comments. In php it's mostly blog spam complete with sql injection holes and other bugs.

Maybe I'm a little grouchy today but the article was a bit annoying to me.

- His argument for why PHP needs to die basically comes down to "PHP is lacking is lambdas and method chaining".

- He flirts with a possible replacement to PHP being Ruby on Rails, even though he comes around to note that Rails is not a language (essentially making that whole tangent masturbatory)

- Then he forgets to assess Sinatra http://www.sinatrarb.com/ which really sounds like something that actually fit the mold of what he's actually looking for (allows you basically run Ruby on a webserver)

Actually a thoughtful article.

To each their own. Use something else if you want, but there's millions of people who don't want PHP to die.

Correct. And people in the Perl community didn't stop just because someone else had more market-share in web development. There's many area's of programming and I'm always surprised when people think web development is the only one that matters.

A good point. I focus on web development, and the question is entirely about what will replace PHP in the field of web development (not that PHP is extensively used anywhere else).

I agree. I'm not sure if the "replacement" will be a single technology or merely a standardized interface for hooking up web applications on a host.

Reply on news.ycombinator.com