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

PHP needs to die. What will replace it?

seldo.com

98 pointsmuhammadatt148 comments

To replace PHP you need:

1. To be on all shared hosting everywhere. I.e. you need to be really easy to install, and preferably not involve long-running processes that shared hosts might choke on.

2. To be beginner friendly. No requirement of understanding MVC, or running commands in a shell (hi RoR!). Pure instant gratification. Someone's first step into using PHP is likely going to be "I want the current date in the footer of my page", or "I want a random image on my homepage", or something like that. Anything like that you can handle by taking your existing page and dropping a tiny snippet in where you want the change to happen. <?=date('Y')?> is a potent thing to someone who has never programmed before.

(Note: For point 2 many of the things serious programmers hate about PHP are actually advantages. All the functions in one big namespace? That's great! A newbie doesn't have to try to understand `<? import datetime; print datetime.date('Y'); ?>.)

It's easy to replace PHP for serious developers. We like advanced features, and care about a sane default libary. We're willing to use complex tools to get a payoff.

It's hard to replace PHP for non-programmers who just want to tweak their static page in notepad, or install a blogging package on their cheapo shared hosting.

To sum up: if you don't address both of these points then you haven't killed PHP. You're competing with Python or Ruby or whatever. PHP will carry right on ignoring you, because you're not addressing its fundamental use case.

I don't agree that MVC and beginner friendliness are fundamentally incompatible. Nevertheless, if you can't get a "hello world" site set up in a very small number of essentially trivial (and easily memorize-able) steps then that's a big show stopper.

It really depends on the beginner I guess. It seems like what kemayo is saying is that there are beginner programmers and then there are people who don't want to be a programmer at all really, but might like the idea of having a dynamic year string printed in the footer of their page.

Those of us who have been working with computers for a long time - particularly those of us who write code - too easily forget what it's like to be that true beginner and often have a very different idea of what 'trivial' means compared to the beginner. What might barely be a speed bump for us can often be an insurmountable obstacle for them and I really wish I was better at remembering this more often.

From the perspective of the "average" professional programmer with a CS degree the vast majority of all programmers, even those who get paid to do it, are rank and utter beginners. Most programmers cannot solve fizzbuzz. Most programmers don't grok recursion, and have trouble with iteration from time to time. If you were to look at a graph of # of programmers within different skill level bins the "beginner" bin would outweigh all the others by a significant margin.

That's why you can replace PHP with RoR, you need to replace PHP with something that out PHP's PHP, but is based on sounder principles so that in the important cases where a beginner is climbing up the skill ladder or a system originally created in a "beginner language" grows or becomes sufficiently advanced they won't hit a brick wall where they need to migrate to an entirely different technology in order to progress.

Well said. Your second paragraph expands well on what I was thinking when I said we forget that beginners have a different idea of what 'trivial' means. The MVC concept (for example) might be trivial to those who get it, but it's likely seen as undesired friction by the beginner, while simultaneously being a good next step for them to acclimatise to should they be wishing to progress. Something that better facilitates this - or things like it - than what we currently have would be great.

Yeah, exactly. This headline could have been written with the same justification in 1999. Yet PHP refuses to die. Clearly us hackers are missing something important.

The fact it actually solves real world problems would be a first "something important" us so called hackers are missing.

Having not used php for 12 years, I recently accepted a freelance job for a client who had been left in the lurch by his php developer who seemingly abandoned the project because she was out of her depth.

I have to say that I was pleasantly surprised by some of the new language features that php has borrowed from elsewhere... eg: closures, anonymous functions, docstrings.

IMHO php is held back primarily by messy, inconsistent documentation and extremely ugly parts of the core library that are also riddled with inconsistencies that should have been deprecated years ago.

Not that I would consider starting a new project in php - I just love programming too much for that; but I believe php will evolve, benefiting from other languages.

Really, it needs it's own "Python 3" (out with the old, smarten up the new).

Note that python3 still doesn't have widespread adoption, because there are still widely used libraries lacking support for it.

But in the coming future it will. All major libraries and frameworks are going to port over to python 3.

But we are missing the point here. PHP could need a cleanup from the ground up even if they have to break a lot of stuff this could help the language to evolve.

"But in the coming future it will. All major libraries and frameworks are going to port over to python 3."

Don't bet on it. It has been too many a years already, and no dice (or minimal dice)

This was a big topic of discussion at PyconAU this year.

Having listened to several Python core developers as well as core developers of some major web frameworks and libraries, I have no doubt that Python 3 will replace Python 2.

I think the key tipping point will be when the major web frameworks support it.

The big one is Django, and the whole port is a mess. There's some minimal work but it's like it hasn't even been started.

The official party line on the delay was the lack of a WSGI spec for P3, but there has already been one for several months now.

Major PHP versions are the evolutionary jumps for the language. They don't tend to worry as much about backwards-compatibility when going from PHP3 to PHP4 to PHP5. I've read that PHP6 was supposed to take it further and outright remove a lot of deprecated and insecure aspects of the language, but I don't know if or when PHP6 will be released.

I agree that they should take things even further and really clean up the language before releasing the next major version. Fix the needle-haystack vs. haystack-needle inconsistencies, function naming conventions, and so forth.

The adoption rate of a new major version on shared hosting providers is relatively slow, so it'd be a perfect time to really shake things up and clean it up.

I would suggest that minor PHP versions often are, too. Significant internal changes between 5.x versions have caused some code to break (and other code to act very differently than it was originally intended to).

Are you saying that developing an API in PHP is insane?

No, I'm saying that the stuff built into PHP is weird and inconsistent. I should change it to "sane default library" from "sane API".

My current favorite example of this (ignoring the naming scheme for string functions entirely) is that in_array and strpos are functions that perform (almost) the same task, on two different types. They take their arguments in the opposite order. strpos($haystack, $needle) vs in_array($needle, $haystack).

> No, I'm saying that the stuff built into PHP is weird and inconsistent.

You never asked yourself WHY. See, that's the important question, isn't it. WHY.

I'll tell you WHY. Because two different dudes implemented it. At different times. Probably, from different continents. They didn't notice it at the time.

But, eventually, someone noticed it. And then they did something really crazy. They didn't fix it. Because that would break the software already using those functions.

It's impossible to write a perfect language from the start. Hell, it's not possible to write a good language from the start. Things that you didn't see crop up and you have to add functionality. And sometimes, the way you added it isn't right ... at that point, you have two choices.

You can fuck your existing user-base up the ass, refactor your code, change the interface, and do it "right" ... or you can do everything you can to mitigate the damage, while keeping the interface the same.

I can pull up software I wrote 10 years ago and it'll still work. Perfectly. You can only say that about languages that do it right.

And guess what? Those languages, they always have lots of warts. Because someone made the hard choice and kept something that's ugly, instead of fucking over a shitload of people to make it pretty.

I'll take function over form any day.

You're ascribing things to me that aren't present in the text.

I had a pretty good idea why that's how it is. I even completely agree with not changing it now. Backwards compatibility is important, no argument there.

That doesn't change that it's the sort of niggling annoyance that drives people to dislike the language.

But it can (and should be) fixed. It's not that difficult.

Choose a convention (ie: always $haystack before $needle), find the methods that don't conform, and print deprecation messages for them, add their replacements.

Then in the next major release, remove the deprecated methods. Hell, you could even put the deprecations in in a module so that those who can't/won't update their code won't have to be left behind.

It may be impossible to write a good language from the start, but that shouldn't deter from fixing those mistakes.

The problem is not that "two different dudes implemented it. At different times. Probably, from different continents. They didn't notice it at the time". Is is that it was allowed to be added to the core library without it being questioned and fixed before it was too late to fix for compatibility reasons. That is the ultimate problem. I would rather a language or framework or library move slowly and correctly than add things haphazardly.

The thing is, these functions were added a long time ago when the language and the project itself was in it's infancy. It's purpose and audience was different. I doubt anyone developing at the time expected it to last this long and be used by this many people. The goal was to put in as much functionality as possible to be useful. It was web scripting for C programmers.

The problem with a language that moves slowly is that if there's an opportunity, it might just miss it. I was working in PHP in the early days and every release brought features you wanted to use yesterday. Perhaps if PHP didn't have the huge rate of change it did then maybe it would have never caught on. Python is several years older than PHP and yet it didn't come to web until long after.

You're not getting what I'm saying. Even if you are super careful, mistakes will be made. What's important is how you deal will them once they're there.

PHP chooses to be ugly, over shafting its user-base by deprecating shit left and right. I like that. It tells me I can use it in a production setting.

I do understand what you are saying though for the same reason, it makes me not want to use PHP in a production setting. The fact that the core developers are willing to add things without thinking them through forcing the users to deal with problems that can't be fixed so as to not break existing sites concerns me.

If the inconsistencies really bother you, write:

function my_in_array($haystack, $needle) { return in_array($needle, $haystack); }

or whatever, and be done with it...

So now there are some functions you have to prefix with my_, and others you don't?

You're not really helping your cause here.

One word: deployment

To me, the best thing about PHP is that it is so easy to deploy to pretty much any shared hosting on the planet, not to mention really easy to set up on your local machine (with WAMP/MAMP).

I love Rails, but on many occasions have built projects in PHP (using a decent framework like Kohana) just because I was putting this on my client's shared hosting account and didn't want to deal with having them get a new server, or just plain setting up Rails. Yeah yeah, I know there's passenger now, etc. -- still not as stupid easy as dropping a php file into a web directory (and assuming that Apache is set up with mod_php, or FastCGI or whatever -- which it always is).

One of the interesting things about doing Passenger deployments for Rails is that it's very similar to doing PHP deploys, with the added benefit of the server not reloading any application code until you tell it to.

For example: you can update the Rails code on the server, maybe run some data migrations or last-minute production tasks against the new codebase, and THEN tell Passenger to reload the application code.

On an unrelated note, having the Heroku service around for low-traffic side projects or whatever is just plain awesome.

Lots of PHP folks call that a disadvantage... It's nice knowing I can mess with files and after pressing F5 I'll always have the latest version. Yes, ok, caches can get out of sync, but they're easy to clear. There are furthermore no good PHP deployment automations, things Rails and Python have because of the level of complexity.

You do know that reloading is just a configuration option, right?

You claim that deployment automations for Rails and Python exist because of the complexity? Have you ever worked with PHP apps that are larger than 1 single file and use the database? Things like Capistrano do a lot of things that even PHP would benefit from.

Deployments are rarely atomic actions. With Capistrano, apps are stored in versioned release directories. Apache points to a 'current' symlink which points to the latest release directory. Upon deployment, Capistrano creates a new app directory, runs database migrations or updates configurations or creates asset files or whatever is necessary to upgrade the app. Only after it's done will it update the 'current' symlink and instruct the app server to restart.

Consider what happens if you upload your new PHP app with FTP. If someone visits /some_page.php while you're uploading then he could access an old version of it. Suppose some_page.php depends on common_library.php which may have been updated to the latest version in the mean time. Then things blow up because the new common_library.php is not compatible with the old some_page.php. With Capistrano, the deployment is as good as atomic.

Capistrano also supports deploying to multiple servers at the same time, and even to servers that are behind a firewall and can only be accessed through a gateway server. It supports rolling back to a previous version. And much more.

After having battled a PHP (mod_php) deployment system and having to hack the hell out of capistrano to get a usable one... Amen to your comment.

You can (and people do) use Capistrano to deploy php code.

While you can, I've found Capistrano is full of rubyisms and makes inferences. Sure it can all be changed, but needs a power user to really use it.

Couldn't get it to work myself due to various issues related to running DirectAdmin control panel, and protections against symlinks it has built in.

I had never used capistrano before, and still managed to get it working for a node.js project, which also involved Mono, c#, several monit scripts, etc. My config file is pretty big, and the documentation wasn't awesome, but at least it's working. If you want automated deployment, it's definitely worth the effort.

Don't get me wrong -- passenger is great. But it's not set up by default (or even possible to set up often) on most shared hosts. Heroku is cool, but as a freelance developer I've found that it's best for me to not take any responsibility whatsoever for the hosting side of things -- just leads to the most un-fun kind of responsibility down the road.

Also, we're mostly programmers here, but there are a vast number of websites created by designers who have very limited understanding of programming and hosting setups, and all they know is shared hosting, copying files via ftp, and setting up wordpress (and maybe creating a database in phpMyAdmin).

Speaking of wordpress, that reminds me of the #2 reason for PHP's continued popularity despite its arguable sucktitude: applications! See http://www.codinghorror.com/blog/2008/05/php-sucks-but-it-do...

> One of the interesting things about doing Passenger deployments for Rails is that it's very similar to doing PHP deploys, with the added benefit of the server not reloading any application code until you tell it to.

You can get this with PHP's APC opcode caching with file_stat turned off. You deploy and when you're ready you clear the opcode cache.

Or if you want to deploy and clear, then add that to your deploy script. Done.

While I don't agree that it's good. It is definitely a huge reason why beginners love PHP. For learning how to code you can't beat how easy it is to put PHP on a server.

Also things like, file_get_contents() is stupid simple. It's often abused but you can put anything in that and get something back. Even a URL. Who care's if every once in a while you get a 500, or 404. Most of the time it works just fine.

PHP is going to be really hard to replace. I think your better off looking to graduate PHP developers to something else.

I agree completely. It's why I started using PHP and why I continue to use it.

I think the only thing around right now with a realistic shot of replacing PHP is JavaScript with node.js, but it will require widespread deployability. If and when node.js becomes easy to deploy on cheap hosts it has a huge number of wins over PHP (to begin with -- one less language to learn, and then even more importantly node.js understands the web page it's buildings and no other server-side language does this).

Yeah, as http://blog.ianbicking.org/2008/01/12/what-php-deployment-ge... spells out in depth.

It's 2011 and people still compare frameworks vs languages. PHP may suck, but oh boy, the author doesn't have his facts right. No method chaining ? really ?

Rest assured that I would rather hire a good PHP developer than this guy to code in Ruby.

You're right, both things that the author claimed are lacking are in fact very much available.

PHP >5.3 has lambdas: http://ca3.php.net/manual/en/functions.anonymous.php

PHP >5 can support easy method chaining if you return $this from your method.

Lambdas are not yet common, but method chaining is already easy to find in most well-designed PHP libraries and frameworks.

Even though he "can make Rails run just as fast as PHP, but needs between 2 and 4 times as much hardware to do so"?

This entire essay seems to be predicated on the frankly weird assumption that if something is part of the language, it's good, but if it's part of a library, it's not — even if the two are indistinguishable. For example:

Code that writes your boilerplate for you is helpful and all, but if your language requires a pile of boilerplate to get anything done, then something is already wrong.

If the same functionality is implemented, the code is being generated somewhere. Ditto with his dismissal of Ruby on Rails because Rails is not built into Ruby like PHP's web app support is.

I won't argue that PHP is getting long in the tooth, has a somewhat unclear future, and some of the standard lib is hella inconsistent, but these points:

then what PHP is lacking is lambdas and method chaining.

Does the author know anything about PHP at all? As far as I can tell method chaining has been available as long as PHP supported OOP and Anonymous functions have been supported for several years since PHP 5.3 was released.

This makes it really hard to take the author and the article seriously.

>>Does the author know anything about PHP at all?

The author doesn't know about any other languages either, it seems.

I stopped reading when he argued that PHP's assocative arrays was an advantage; hashes/dictionaries are in all the scripting languages. (Afaik, they come from AWK by the way of Perl, anyway -- they were created many years before PHP existed.)

When I read

>> the critical thing Perl was lacking was PHP's wonderfully flexible "associative arrays"

I grabbed my copy of "Learning Perl" from 1997. Chapter 5's topic? Hashes.

Perl hashes don't preserve order. PHP's almost always do. i.e., the order you insert keys is the order in which you will receive them back when you iterate over the array. It's similar to a LinkedHashMap in Java.

CS types might recoil at the mixture of behaviors that are baked into PHP's workhorse data structure, but most of them turn out to be quite useful. (And it makes it easier for the beginner programmer to decide what data structure to use: you have keyed data? a list of data? a set of values? doesn't matter, just use an array!)

There is CPAN for that. (iirc, this is solved with a module in the Perl Cookbook. I don't have that book where I am writing this.)

Edit: For a beginner that wants a Visual Basic for web, sure. By now I have different needs, to enjoy using my tools. (And for the record, if I need to keep order of a hash/dict/etc in some language, I generally use a "traditional" array in addition. That is probably too complex for a beginner? :-) )

Edit 2: I'm not dumping on PHP, it is a useful tool for many people. I just wish the development of the language had been handled a bit more carefully.

Exactly, it's not a native part of the language, which reinforces my point that the beginner doesn't need to think as much about data structures with PHP. The built-in array() usually can handle the task well enough. They never are left muttering "this would be perfect for a linked hashmap but where is my drat PHP cookbook?"

Perl hashes don't preserve order. PHP's almost always do.

This is the point at which serious students of language design point out that, if you look at it from a certain angle, PHP doesn't have arrays built into the language. As it turns out, treating two distinctly different data structures with different semantics and performance characteristics as the same thing multiplies edge cases and bugs.

"Needs to die" needs to die.

Let's replace it with "Here's how we can improve."

Yes.

The article states that php doesn't have lambdas and method chaining, although it does. They aren't well done, as per usual, but it definitely has them.

Honestly, we may be best off doing a CoffeeScript style pre-processor for PHP. Because PHP isn't going anywhere, no mattter how much we may prefer other languages, PHP's popularity is one of pure pragmatism, something the language purists don't seem to understand.

Get me from 0 to "Hello, World" as fast as you can. That's how you build the next PHP.

>> Get me from 0 to "Hello, World" as fast as you can. That's how you build the next PHP.

Well put.

I can't think of any other languages that let you do `echo 'Hello World' > /Library/WebServer/Documents/index.php` and you already see that in the browser because it comes with your OS. It's hard to beat that for normal folks just starting out making web pages.

semi-colon

ASP?

Exactly. To beat PHP, you have to be as easy to write as static HTML. Even though I have done Ruby, Node.js and ASP.NET projects, I still go back to PHP because of how easy it is to go from 0 to hero without all the fuss.

The closest thing I've found is the serve gem, which lets me launch a web server from my current working directory. It lets me quickly mock something up in ERB, Haml and SASS without messing with Rails or Sinatra. As a complete newbie, with no coding experience, PHP is a much easier hill to climb than Rails or Django, which is Mt Everest by comparison.

I agree with you and I think it goes even further than that: get me from hello world to mockup of my final app to my final app. Coding in php isn't pretty, but it's fast, even once you get past that hello world part.

Look at all the questions on stackoverflow from total beginners: they don't understand much of what they are doing yet, but they already have working forms and several pages and, well, results.

Of course, that's also part of what makes people hate php.

Get me from 0 to "Hello, World" as fast as you can. That's how you build the next PHP.

I understand why that is, but I can't help but think that it's optimizing for an edge case instead of the whole operation. I'm willing to invest a little bit longer to get to "Hello World" on day one if it means a lot less pain for every day to follow.

Most of the people using PHP almost certainly disagree with you. (Most of the people who have a clue about PHP, i.e. @fabpot and crew, may not disagree so strenuously, but I would suggest that they are the edge case.)

Of course the people who don't find php to be painful would disagree in my assessment that php is painful, kind of by definition. :)

Would you choose an operating system based on how easy it was to install, or how pleasant it was to use?

Sure, but you said that that was "optimizing for the edge case". Your edge case is PHP's base case, y'know?

A useful criticism, but in this case I don't think it's optimizing for an edge case. There's a power law, or something close to it, when it comes to web developer skill. PHP is so dominant because it requires very little skill to get started, and very little skill to incrementally advance from there.

Other technologies can try to push on the "PHP problem" from above, and they can make a lot of progress, but they won't ever "win" because the inertia of PHP is coming from below. The only way to fully get rid of PHP is to beat it on its home turf, and that's firmly in the "Hello World" realm.

I guess it depends on what the goal is. I personally don't care if anything kills or supplants php. Different people can and should use different tools.

When trying to answer the question of "what tools should I, as a serious professional who is in this for the long-term, choose to work with right now?" it's really short-sighted to balance everything on how easy it is to get to "Hello World".

I really really think this is asking the wrong question. Sure PHP beat perl at its own game, and really was the master of the CGI style web. But the thing is, that really isn't where the world is anymore. Sure, there is a place for building pages from templates, particularly in piecing together custom splash pages and whatnot, or xml feeds, but honestly, the CGI style web is just going away.

Look at what everyone is doing right now: make an app in javascript+html5+css, serve those static files, and feed the app with json. Save bandwidth, scale easier, and just have better control of the display by manipulating the display directly.

tl;dr - Nothing will replace PHP, because no one is making tools for that case (file-oriented-web) anymore.

My thoughts exactly as I was reading the post :-)

I've come to expect hackery from this guys blog.

The truth is that for professional, skilled developers, mastering their Nth language is an increasingly smaller investment compared to their first.

But for people north of HTML coders and south of professionals, they have a lot invested in the scripting skills they've developed and nobody is interested in seeing the value of their investment diminish for a reason like this.

People here always tout PHP's installed-base as a big "plus" for the language. But I think more than that is the mindshare.

Yeah, the first post I read was the ORM one, which I thought was such an egregious piece of misinformation that I debunked it ad nauseam (http://darwinweb.net/articles/in-defense-of-orms).

Now in this article there's a telling clue to why he thinks writing SQL by hand is better than using any ORM:

> I can knock out a good website in an hour in PHP, and an excellent one in a day or two.

This suggests that he's working primarily on tiny projects. Of course if you are working on tiny projects than an ORM doesn't buy you much. Also, there is perhaps no language suited better to tiny web projects than PHP and I don't see that changing. If you want to make something measurably better than PHP for general purpose web programming you start having to make decisions that developers don't want taken away from them. Rails does what it does by being opinionated, but it works because if the opinions are ill-suited to your project you can still use Sinatra or whatever. If you move too high up the abstraction layer while trying to still serve a wide audience you end up with the kind of morass that is Drupal, where the system can do almost anything adequately, but it doesn't do a great job of anything because of the creaking weight of the infrastructure that attempts to be everything to everyone.

Well, it's always hard to respond to a claim about professional, skilled developers, since a programmer will always be looking up at a group that is more skilled (well, most of us anyway).

But I don't think it's a small investment to learn a language and framework. You can learn the basics of ruby, or python, or Java reasonably quickly if you have a reasonably broad background in programming languages, though even that takes a while.

But the frameworks, those really do take an investment. It takes a real investment of time comfortable with Rails or Django. Not to get the initial site or scaffolding up, but to get comfortable enough that you're no longer stymied when you need to do something non-obvious.

And the Java frameworks, oh jeez. To get all that working takes ages. A dependency injection framework, an MVC framework, an ORM, getting it all to work with Maven or some other build too, sheesh that takes a long time, and there are so many dispiriting little errors to chase down.

Well, maybe there really adept coders just don't have a problem with this, but I have this suspicion that it doesn't come down to being smart. This isn't about mastering some difficult algorithm and then implementing it in python or ruby instead of java. There are a lot of idiosyncrasies.

I remember Ellen Ullman (she wrote "Close to the Machine", a reflection on programming before these types of books were so common) described programmers as "serial monogomists", becoming very loyal to their environments for a while, then abandoning them and finding something new. I remember another line, about how you can be a senior developer in one environment but not even know how to turn the machine on in another.

I'm not saying there aren't people who can switch easily, but I do think it comes at a cost, even for people who are reasonably adept programmers.

I get that PHP is not the most elegant language in the World (see kemayo's comment about strpos and in_array for just one example), but I don't understand why people get so worked up over the fact that people use it.

It seems like you can't mention PHP without people inferring that you're a lesser programmer or that you clearly don't know what you're doing.

The funny thing is that the second most visited and profitable website in the world (Facebook) is written in PHP... not bad for a "beginners language" i think.

OMG, Julius Caesar had to die too!

There is no need for any language or framework to "die".

If you do not like PHP (or Perl or Python or COBOL or Ruby or Java) just do not use it. There are plenty of alternatives.

If you and your team can be productive with any of these languages, go for it. PHP with modern OO-frameworks, like Yii, can support rapid development of complex web apps just fine. Facebook runs just fine on PHP even without any 3rd party frameworks. The proof is in the development and deployment. The only way you can "kill" a language with so much support is to offer something 10x better or create some exclusive tie-in. Where is that magic offering?

Vote with your feet and dollars and just take it easy. There is no need to fight the imagined oppression.

He lost me at "The most obvious potential successor to PHP is Ruby on Rails". why compare RoR framework written in ruby vs PHP programming language... go for Ror VS cakephp, RoR vs codeigniter, RoR vs symfony etc

For better or worse, the Ruby web community is so centered around one specific framework that people tend to just say Rails instead of Ruby.

The post isn't comparing PHP with no frameworks versus Rails. Indeed, the author's conclusion is that Rails doesn't sufficiently separate itself from PHP with an MVC framework (and he listed a few).

COBOL is still alive after more than 50 years. PHP will still be being used in 2050 for government web sites. It wont be getting any respect. but the octogenarians who can still program in it will still be making some pretty change.

How do the articles from this site always make it onto the HN front page? They're full of misleading information, are only written for the link/flame bait, and don't provide any good actionable advice.

I know news is slow these days, but this kind of posting needs to stop.

PHP is a nightmare, but only once you learn enough about programming or development to understand what you should really be doing, and only once you've seen how other languages do it.

After that comes PHP's special flavour of OOP. I'd prefer to call it 'Do Whatever The Fuck You Like Orientated Programming' given the abundance of 'magic methods' and other functions that try really hard to make sure you've got a cheeky workaround for something you can't be bothered doing properly (creating countless security issues in the process). And that's before you start using classes as pseudo-namespaces for collections of static functions.

The disappointing side is that someone who learns PHP before anything else will have a heart attack when they realise that very little of what they know applies the same to another language.

It's so loose and care-free that it doesn't care what you do or how you do it. (Not helped by the mountains of useless tutorials and documentation that teach awfully bad practices.)

So I guess the thing I dislike about PHP is that I learnt to use it but it didn't give me good programming skills.

> It's so loose and care-free that it doesn't care what you do or how you do it.

This is precisely why I fell in love with PHP. My first was BASIC, my second was C, my third was Java, but my fourth ... oh god ... like that slutty girl who will let you do absolutely anything. How can you not fall in love with that?

All I can really say is that I'm getting fed up of it. In keeping with your analogy, I'd certainly prefer one that gave me the odd slap and told me to get my shit together if I tried pushing my luck.

(programming languages and sado-masochistic tendencies would be an interesting avenue to explore...)

Perhaps a little appropriate: http://c2.com/cgi/wiki?BondageAndDisciplineLanguage

Amen. PHP is for hippies, Java is for squares.

why does one language have to die for another to become more popular?

if you don't like php, don't use it.

Why is the article comparing PHP (a language) to RoR (a framework). There's plenty of good PHP frameworks which have emerged over the past few years that take care of the boilerplate code needed for a web app. Symfony 2.0 was a released a few months ago; Fabien Potencier's hard work brings a lot of great patterns and conventions from Java to PHP users.

I understand why rails continues its ascent but the LAMP framework is still very popular - you can get to hello world on your home computer or free hosting account extremely quickly, that's pretty powerful when your're starting out. Services like codecademy may change that but we're a ways off imo.

I'm surprised that you didn't mention HipHop, especially if performance is your biggest gripe. It really is the bee's knees and will only get better.

I spent a good chunk of my day looking at PHP code and profiling data. Assocs are terrible for performance but it's not a fatal flaw IMO. What people really want are separate "vector", "dict" and "set" types. It also needs a decent standard library to replace dyslexic crap like explode(). And don't get me started on the string libraries and the abuse of preg_* functions.

Lastly, comparing plain PHP to Ruby+Rails isn't fair. I prefer Python myself but even then I need something like webpy or Google's appengine library to make reasonable app.

If performance is a problem, then PHP is most certainly not the source of it, the vast majority of performance issues people are having in PHP are related to poorly written code, bad understanding of the language, and most of all use of third party software that were never meant to be performant(WordPress, SugarCRM, Symfony, ZendFramework ...).

And HipHop is most definitely not the solution, the only reason to use HipHop is if you are Facebook.

Show me a website where php is the source of the performance problems and I will show you a website php allowed to reach success/a large audience.

Frankly, unless you are very large scale php is never your bottlenecks, I/O is. And if php become your bottlenecks, you have already won.

(of course you could find exemples of math-heavy calculating sites where this isn't true, but that just means you don't know how to pick the right tool for the job)

You are right that I/O is usually the first bottleneck. I assure you that being CPU bound is no picnic, not least because most optimization knowledge and experience out there relates to I/O. :)

Even if you are not CPU bound, HipHop is steadily adding grown-up features to the language that make it quite nice to use, functions like mysql_connect_with_db() which save a database round-trip, and extensions like xhprof which will tell you what is actually slow.

Does anybody actually use hiphop, besides Facebook?

You know, I don't know. IIRC some of the larger sites like Wikipedia and WordPress were looking at it. The dev mailing list is pretty quiet. Ah, well.

Honestly, why does 2 to 4 times slower mean anything? Why can't you cache? or write that really performance intensive part of the app in something else?

There aren't any numbers to back the idea that 2 to 4X performance means something. It's pretty easy to spend $5-10K per month on a single dev, thats a fair bit of hosting.

If the concern is speed of page rendering go with .NET, the JVM, or C++ it's much faster than rails or PHP will ever be. The trick is to use RAD/MVP to get you to that twitter like world of hurt. Then you rewrite in a faster language once you know what your product is like.

This brings up something I feel gets missed in a lot of language/platform discussions: a vast majority of sites on the internet are informational sites for people/companies and plenty of those are created by designers (non-programmers).

When you say it's easy to spend $5-10k per month, you're obviously thinking of a company whose business is the software, but this does not apply to most websites in the world.

Technologies might "need to die" on blogs, but in the real world they get replaced with better alternatives - once these emerge. Want to replace PHP with your favorite solution X? Write a better Wordpress, Drupal, vBulletin or even PhpMySQL alternative in X.

It's incredible to me how the fantastically talented X rockstar ninjas can't produce a better replacement for, say, Wordpress given how much technology and our general understanding of building web apps have improved since 2003. Less blogging, more coding.

This past weekend, for the fun of it, I setup MongoDB and Node.js on Windows. After ~3 hours of downloading, reading MongoDB and Node.js example docs, and looking up some config issues on StackOverflow, I had written a small TODO list app. Last night, in about 45 minutes, I setup CoffeeScript and translated my node.js webserver into CoffeeScript, resulting in about 25% fewer lines of code.

This is by far one of the easiest stack deployments I've ever done. I'm even thinking about writing a push-button windows installer to do all the installation and configuration stuff for me in the future. If there is any interest, I'll share it.

And heck, couple those technologies with jQuery, and I imagine that you could use CoffeeScript to develop for both the server and client side of a web app.

Easy and way cool.

I'd like to see a windows installer with node.js, coffeescript, mondodb and a couple apps with some collected docs behind a web server for example. that approach bootstrapped a lot of Rails coders.

a demo video also helps create a lot of interest.

It is so nice to be addicted to the coolest abstractions of programming languages, considering PHP undeniable lack of elegance and orthogonality just a mess, but I think when there is to get shit done this is not the only quality a programming language should have. PHP has other qualities: trivial to deploy, a set of libraries built-in, dispatch/execution fast enough. So I would love to see PHP improved as a language as replacing it is not so easy at this point. Instead fixing the language should not be so hard, assuming a competent core team.

PHP is not the devil. It has some funky design decisions, but oh well. Mixing HTML, SQL and logic is the devil. The problem is that PHP makes it too easy to do (some would say it encourages it).

PHP is not that bad? What other popular language is worse?

Lua and JS both come to mind. Neither of them are worse than PHP, but they're right around that same level of (un)usability and number of pitfalls.

Lua, really? Could you provide some examples?

No basic string manipulation, only RE-based stuff.

One-based indices instead of zero-based.

> No basic string manipulation, only RE-based stuff

It's trivial to write, there are lots of libraries that do this. I've worked on a lot of string processing code in Lua. It's not as easy as Perl or Ruby but it's not by any means hard.

> One-based indices instead of zero-based.

Other than violating the expectations of people used to other C-like languages, this is not in any way even remotely a problem. I don't know anybody who's spent any significant time with Lua who regards this as more than a minor detail.

These are pitfalls and usability concerns. Languages that make you actively work against the nature of the language are not good; programming languages should be making this stuff easy.

One-based indices stop being a "minor detail" as soon as you realize that out-of-bounds indexing doesn't fail, but returns nil. Time to re-examine all of your code. Combine this with the natural mathematical awkwardness of one-based indices and it can get really frustrating, really fast.

I had to do Lua for some game design stuff a few years ago, and these were the two things which stuck out at me almost immediately and bothered me during the entire ordeal. Maybe I've been spoiled by Python, Perl, Java, C++, C, and other languages, but it's deeply frustrating how wrong Lua is about this.

Lua is not perfect. But saying you shouldn't use it because of 1-based indexes is an overreaction.

> Maybe I've been spoiled by Python, Perl, Java, C++, C, and other languages

Probably. :)

One of Lua's main goals is to provide a language easy for beginners to use for small tasks. This affects its design in some other rather annoying ways (like for example, variables being global by default rather than local) but they were pretty carefully made decisions.

The context of this thread is, "what could be a good replacement for PHP?" I think because Lua aims to be easy for inexperienced programmers, it's a rather good choice, even if some of its characteristics can be surprising or annoying to established developers experienced with other languages.

JS has bad parts, but it has good parts as well. And those parts are pretty great.

PHP is all bad parts. Easily the most inconsistent, poorly designed language in popular use today.

Killing PHP is like trying to kill English. Too many people know it and use it day to day for it to go away. It will just carry on with all its inconsistencies and weirdness.

PHP is totally fine, for startups and for web projects.

Examples aplenty.

I can confirm that I will die first before PHP.

I'm mainly a Python programmer now but used to use PHP fairly extensively. I defended PHP for its ubiquity and how easy it is to get started using it until I saw what was going on with the development of PHP6. That's pretty much when I decided that, personally, it's no longer a language worth investing in.

Django is capable but not really what developers expect from MVC, and other MVC frameworks for Python have much less traction.

Wow, that's a pretty strong statement. I would like to see some sources for it or at least further explanations.

the leap from ORM->code generation->magical thinking!! -> IS BAD , just hysterics. A clear example of the slippery slope logical fallacy. Good ORMs are a huge productivity boost and entirely worth it. Those particular PHP coders who barely know programming (keep in mind, this is just a subset of PHP programmers I'm referring to) should not use relational databases at all, they should stick to simple key/value stores - they don't need joins, they don't need subqueries, they've no concept of transactional isolation, foreign what ? Just use a K/V.

Ha, don't use it. You must have some other hidden problems if you hate PHP so much, that's my take away.

Get a hobby, you won't hate PHP so much ;)

Ada. After all, it replaced COBOL, Fortran, various ALGOLs, and C, right?

I only ask for a language that is readable so that code can be readily understood among a team developers, and PHP is universally understood. It may not be cool, but less time is wasted obsessing over being more clever.

why does he compare PHP to rails ? the latter is a framework, not a language. PHP has excellent frameworks as well, Symfony 2.0 for example is awesome.

Node.JS will replace it. Not a fanatic Node user either.

I have used node and like it, but there is no way it will replace PHP. It is just too easy to drown in callback soup with node.

Roughly a decade ago, PHP killed Perl. Not completely, of course; it still clings on in some environments, it has a sizable legion of die-hard fans, and legacy apps will need to be maintained in it for decades to come. But as a language for newcomers, and especially for web developers, it was already dying in 1999 and was mostly dead by sometime around 2005.

Uh. http://www.indeed.com/jobtrends?q=perl%2C+php%2C+ruby

I think newbies just found easier languages to work with than Perl for web dev, which says nothing about the use or demand for Perl in industry.

I think newbies just found easier languages to work with...

Change that infinitive to "to deploy", and you're spot on.

I'm convinced that PHP is just too big, too popular, and, as the author realizes and points out, too fast and utility-wise too well-equipped to die at this point in time. Whatever may be able to kill it off surely won't be Ruby, Perl nor Python.

Perl used to be "too big, too popular" and writing Perl apps that plugged into mod_perl was what every company was trying to hire for.

PHP will likely be replaced, but not for a long time and it will take time. And there are still a lot of perl hackers out there too, none suffering (aside from having to use perl).

php lowered the bar to web programming to below "moron" level.

so you will need something equally instant-gratificational.

only without the horrible warts

rails was too clever. stupid people are afraid of clever.

I don't see anything to hand.

PHP is great! It's like flypaper, attracting and trapping mediocre devs, keeping them from writing their terrible code in nicer languages

Don't want to be inflamatory, but:

PHP has already been replaced by Ruby/Rails as the good thing that should be used for new projects. Only PHP developers don't see that.

You lost me when you tried to argue that ORMs are not useful. Its easy to see why PHP developers think that, though.

As the author points out, Rails is a framework and PHP is a language. There are countless (great) frameworks for PHP - my current favorite is Symfony 2. And PHP developers do in fact know and value ORMs, hence the existence of Doctrine 2.

You're being inflammatory. Rails has nowhere near the install base that PHP has, and furthermore, it's a framework, not a language, so the comparison is unequal. Further, setting up and installing Rails is nowhere near as frictionless as installing, for instance, CodeIgniter. Until that can be said, Rails is not a viable alternative.

I'm all for a PHP alternative. I use it because it's ubiquitous, but I have no love for the syntax or the internals. But the only way you can compete with it is to have the same kind of momentum mixed with the kind of frictionless use that comes standard.

If installing Rails (or Flask, or whatever) isn't trivial compared to the difficulty of writing the actual code, then either your project is a toy, or your web host needs to get its act together.

Let's be clear, we're talking about popularity here. We're talking about the massive popularity of Wordpress and Joomla, of which no Rails project can match. We're talking about the fact that most websites on the web, by that standard, would be "toys". But that doesn't matter, because those toys are what power the web. Not everybody is Facebook, not everybody is looking to secure VC, not everybody is coding their own site.

In fact, I'll go so far as to say that what you're saying is indicative of the kind of out-of-touch response that keeps any of the proposed alternatives from replacing PHP.

I was not talking about popularity, I was talking about mindshare, two very different things. If you're talking about popularity, Java, C and C++ are more popular than php, but I don't see you pointing them as viable solutions. tiobe.com

but I don't see you pointing them as viable solutions

Java, C and C++ are viable solutions, due to their popularity.

I take it you have never tried to get major changes to core server infrastructure approved at large bureaucratic institutions. Writing your code in php is often orders of magnitudes faster, easier and cheaper than getting a decent RoR setup installed.

major changes to core server infrastructure approved at large bureaucratic institutions

It sounds like you've already lost.

How so? I find out what I have to work with, work within the limitations set, deliver what the client asks for (if I feel it can be done in a reasonable way) and collect my paycheck.

I didn't mean to be so snarky, I was just projecting. I personally don't have the patience to deal with organizations like that anymore. Life is too short and they aren't the only source of paychecks that I can find.

That's your experience, and highly subjective. And yes, I deploy code to dozens of enterprise servers for a global company. And that company is looking into Rails, not PHP.

Looking into rails? What are they using currently?

.NET, like most enterprises, afaik.

My point isn't so much rails vs php, but about the non-technical difficulties in getting major infrastructure changes done (especially if it's for a minor project) . I'm sure it'd be equally hard to get a ASP.NET MVC stack set up at a company with a big RoR setup already in place.

If you have unlimited hardware at your disposal, work on projects where a slightly faster development for certain, specific cases can be obtained, or work on projects of a size that can be managed by the performance of a single machine, sure. If not, R/R isn't replacing PHP.

Rails doesn't really need that much hardware, that's a very common misconception. PHP is not the fastest thing in the world either, unless you go with a compilation cache server. Rails can be easily perform well under single machines. I have VMs with 512Mb of ram handling thousands of users per day with Rails with no problem.

Of course, it's not like a modern first person shooter or anything. My point was that on one and the same machine, PHP gets a whole lot more done per portion of computer power than Ruby does :)

Because all projects are CRUD apps?

You aren't going to convert the masses of php hacks with an opinionated and rapidly changing framework like Rails. These are people who still mix logic with templating and you want them to learn an ORM, Coffeescript, Sass and Moustache?

> You lost me when you tried to argue that ORMs > are not useful. Its easy to see why PHP > developers think that, though.

Really? So the object-relational impedance mismatch problem isn't real? You lost me when you completely ignored the real engineering trade-offs involved in choosing abstraction layers like an ORM. Its easy to see why Ruby developers think that though.

There are problems with ORM, but there are much larger problems with PHP+SQL. Most of the problems created by ORMs are easy to workaround, though (to the point of having to write SQL sometimes), while problems created by SQL only are not (like n+1).

As a Python developer in SF, I can 100% agree with this. Ruby/Rails has replaced PHP for almost the entirety of new projects going forward out here — at least with the developers I know and respect — and Python makes up the rest.

So by looking at a tiny subset of programmers (those that you respect), of a tiny subset of programmers (those that you know), of a tiny subset of programmers (those in SF), you feel you can say something representative about programmers and programming as a whole.

I will argue that ORMs are not useful to the majority of good developers.

The PHP app I am currently saddled with generates anywhere from 100 (absolute minimum) to 40,000 MySQL queries on every single page view thanks to a developer who didn't know what ORMs are for and was clearly behind the curve when it came to architecting scalable applications.

I have never seen a PHP application abuse a database connection so thoroughly in my life. If he had just stuck to a nice, lightweight PDO wrapper and been able to craft some decent SQL statements, we wouldn't be rewriting this thing right now.

Reply on news.ycombinator.com