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 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).
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.
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).
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).
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.
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...
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.
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).
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.
Rest assured that I would rather hire a good PHP developer than this guy to code in Ruby.
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.
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.
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.
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.)
>> 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.
Let's replace it with "Here's how we can improve."
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.
Well put.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
I know news is slow these days, but this kind of posting needs to stop.
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.
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?
(programming languages and sado-masochistic tendencies would be an interesting avenue to explore...)
if you don't like php, don't use it.
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.
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)
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.
And HipHop is most definitely not the solution, the only reason to use HipHop is if you are Facebook.
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.
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.
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 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.
a demo video also helps create a lot of interest.
Examples aplenty.
Wow, that's a pretty strong statement. I would like to see some sources for it or at least further explanations.
Get a hobby, you won't hate PHP so much ;)
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.
Change that infinitive to "to deploy", and you're spot on.
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).
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 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.
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.
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.
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.
