To replace PHP you need:<p>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.<p>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 <i>tiny</i> snippet in where you want the change to happen. <?=date('Y')?> is a potent thing to someone who has never programmed before.<p>(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'); ?>.)<p>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.<p>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.<p>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.
One word: deployment<p>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).<p>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).
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 ?<p>Rest assured that I would rather hire a good PHP developer than this guy to code in Ruby.
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:<p><i>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.</i><p>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:<p><i>then what PHP is lacking is lambdas and method chaining.</i><p>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.<p>This makes it really hard to take the author and the article seriously.
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.<p>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.<p>Get me from 0 to "Hello, World" as fast as you can. That's how you build the next PHP.
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.<p>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.<p>tl;dr - Nothing will replace PHP, because no one is making tools for that case (file-oriented-web) anymore.
I've come to expect hackery from this guys blog.<p>The truth is that for professional, skilled developers, mastering their Nth language is an increasingly smaller investment compared to their first.<p>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.<p>People here always tout PHP's installed-base as a big "plus" for the language. But I think more than that is the mindshare.
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.<p>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.
OMG, Julius Caesar had to die too!<p>There is no need for any language or framework to "die".<p>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.<p>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?<p>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
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.<p>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 <i>really</i> be doing, and only once you've seen how other languages do it.<p>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.<p>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.<p>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.)<p>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.
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.<p>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.<p>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.
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?<p>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.<p>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.
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.<p>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.<p>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.<p>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.<p>Easy and way cool.
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).
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.
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.
<i>Django is capable but not really what developers expect from MVC, and other MVC frameworks for Python have much less traction.</i><p>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.
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.
<i>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.</i><p>Uh. <a href="http://www.indeed.com/jobtrends?q=perl%2C+php%2C+ruby" rel="nofollow">http://www.indeed.com/jobtrends?q=perl%2C+php%2C+ruby</a><p>I think newbies just found easier languages to work with than Perl for <i>web dev</i>, which says nothing about the use or demand for Perl in industry.
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.
php lowered the bar to web programming to below "moron" level.<p>so you will need something equally instant-gratificational.<p>only without the horrible warts<p>rails was too clever. stupid people are afraid of clever.<p>I don't see anything to hand.
Don't want to be inflamatory, but:<p>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.<p>You lost me when you tried to argue that ORMs are not useful. Its easy to see why PHP developers think that, though.