Some people think PHP is obsolete because it has been around for 20 years. Universities are usually teaching Ruby and Rails in their web programming courses (at least in US). Not a lot of kids feel inspired to learn an "old" language that has always had a bad reputation. And yes, the early versions of PHP were quite a mess. The new generations of engineers prefer learning the newest cool technologies. Nothing wrong with that.
However PHP has become a lot better. Starting from PHP 5, it started feeling a legit language. Frameworks like CakePHP, Laravel and Symphony have shown that PHP is capable of competing with Django with Python and Rails with Ruby. Facebook drastically accelerated its runtime speed with the HHVM. And PHP 7 promises to be even faster.
What I like about PHP is how the runtime works:
- If something is messed up in a controller only the requests that hit that code will have problems. The whole application does not crash.
- The other thing I like is that you change a file and the change is immediately available without having to restart anything.
I love Node.js, C++, Go and Python but PHP is still a good tools in these days.
PHP is only obsolete for those that choose not to use it.
> Universities are usually teaching Ruby and Rails in their web programming courses (at least in US).
I wish this were the case. As an undergraduate in 2013, I took an intro web programming class where we were taught using Java and J2EE...in 2013! My friend went to a school with a top CS program (top 10 or top 20 in the country I think), and his web programming class was also in Java, though I don't remember if they used the horrid J2EE or not.
As a side note, I learned more and made more progress teaching myself Python and Django in a week than I did in that class.
Programming in PHP these days doesn't seem significantly different than programming in ASP.NET MVC or Node or maybe even Ruby. I started playing around with Laravel recently to throw up a quick site on some free hosting I have available and what tools does it require to manage the front-end: npm, bower, and gulp!
PHP may be closer to death now than ever because it's becoming less distinct as a platform.
Exactly. PHP has been "embraced and extended". The essential features of PHP I would say are easy database connectivity, and a built-in templating language.
Both of these features are now present in pretty much every server-side framework and half the client-side ones (both angular and react have it). I would argue that they're both messy, but it's there, and heavily used.
The big feature PHP still has that others are missing is the ease and cheapness of deployment. Any PHP app can be very easily deployed on shared hosting, which isn't true for ruby, asp.net, java, django or any of those. It is "more" true for asp.net and django, but not much more.
This feature is more the result of PHP easily supporting shared hosting, which is something all the others fail at pretty badly (yes, Google and Amazon have implemented it in proprietary form ... that doesn't count. Needs to be open-source, easy to implement for cheap hosters).
And really this boils down to efficiency. As ridiculous as it sounds, PHP is currently by far the most power/money efficient language. Why ? Because of thousands of cheap hosters easily implementing shared PHP hosting which usually works well, certainly well enough for the vast majority of small businesses. Ruby/Python/Go/C++/... none of them have anything like it.
Right now efficient hosting is having a "root" dns entry pointing to Google app engine, and having an ec2/other cloud app that simply checks availability of 2-3 cheap hosters and 403's to one of them. That means you effectively have very cheap bandwidth (WAY cheaper than EC2 or any other cloud hoster), yet retain the reliability/availability you need. Biggest problem is keeping database in sync.
I can't believe companies like Microsoft/Amazon are letting this opportunity slide, but they are (but of course that people use very power/cpu/money inefficient hosting kind of works to their advantage).
I think some things are connected. PHP does not have shared memory like static members. This makes it very easy to run in on clusters. No one cares if one server goes down and is replaced by another. This also makes it hard to write large systems that are supposed to run in a controlled cluster and cache things. Java and .NET are very good for those things. So PHP is good for the web hotels and Java and .NET are better for company IT/devs or any project where you can manage your servers for yourself (even if it is a cluster in Amazons or MS centers).
I'm not sure what Microsoft i letting slide, they have PHP support in Azure and .NET support (and Node etc). More expensive that the lowest cost PHP web hotels but not expensive.
Wordpress also keeps php very relevant. Very, very relevant. You can make so much money focusing on WP that it's not even funny. Even with the endless marketing agencies and low cost options available.
TL;DR PHP does not have concurrency so the author has taken the viewpoint of PHP becoming obsolete.
Concurrency is nice and while PHP out-of-the-box does not support it, I do not think it is a deal breaker (at least not for me). As long as CMS's like Wordpress are around and PHP remains easy to deploy and is installed on nearly all web servers, we are not going to see PHP becoming obsolete any-time soon.
In particular, PHP should be obsolete now that we have many more ways of integrating pieces of code rather than linking together subroutines in one BIG BALL OF MUD. It is no longer necessary for an application to be written in one language or run on one platform. Existing PHP applications could be evolved using another language platform by taking advantage of the HTTP request to integrate other language code. Or using a message queuing library like AMQP or ZeroMQ.
Python and Ruby will be with us for a long time, but PERL and PHP will die an ugly death. Facebook has already abandoned PHP in favor of a PHP subset that runs on a modern VM platform (HHVM). We can't all do that, but we can adopt tools that run on the JVM or take on a well-designed language like Python or Ruby or Javascript.
On the JVM we have things like Grails on Groovy, Clojure and Scala which have strong development teams and visions for the future.
PHP, like PERL, just doesn't fit in any more. We have moved beyond hacks and incorporated computer science into our development platforms in order to save time and money and fossil fuels.
It's more than a bit disingenuous to call Facebook's work on Hack and the HHVM an abandonment of PHP. A big part of the HHVM project was writing a formal PHP spec, and features from Hack have been making their way into mainstream PHP (generators in 5.5; static types in 7).
It would be much more accurate to say that Facebook has invested heavily in PHP by financing an alternative runtime.
"take on a well-designed language like Python or Ruby or Javascript"
I like Javascript and Node.js BUT please do not call it a well-designed language. Strict mode makes it a lot better and ECMAcript 6 is great. Even the people that invented it recognized that it had more than a few design flaw.
As time passes and better engineers that understand computer languages get involved in the core development, things have been drastically improved. This is true for Javascript, Python, and, yes, also for PHP.
JavaScript is well designed? Of course, 'well' is not very precise. But considering how fast it was created, how many translate-to-JS languages there are, at best I'd call it 'best possible design in 10 days' (http://www.quora.com/In-which-10-days-of-May-did-Brendan-Eic...)
I'd call it well designed AND most-misunderstood for this very reason.
And this 10-day argument really makes me smile every time I see it. You're barely using anything that was designed in 10 days, ES6 is already here and it changed thing a lot.
I would call the ability not to be misunderstood a very important design requirement. I'm using ES6, it didn't change almost anything for me. Even the official docs say it is minimalistic improvement, just syntactic sugar. I like the string interpolation, but the class keyword doesn't really do much more than prototype.method =. There isn't really inheritance, super doesn't do what anyone expects, 'this' is not improved. At least 'let' helps with scoping problems.
Well its really not a problem of the language if people keep trying to shove their type systems (typescript) or functional syntactic sugar (coffee - some of it made into standards at least) while those understanding it continue to be successful with it.
> Python and Ruby will be with us for a long time, but PERL and PHP will die an ugly death
> On the JVM we have things like Grails on Groovy, Clojure and Scala which have strong development teams and visions for the future.
> PHP, like PERL, just doesn't fit in any more.
It's because you don't understand PHP's users perspective that you say these things. PHP isn't going away anytime soon. The most popular CMSs are written in PHP, not in Ruby,Python or Clojure. In the small business space, PHP is king, not Scala nor Groovy. Of course it's your opinion, but it's not based on any facts.
> On the JVM we have things like Grails on Groovy, Clojure and Scala
Grails is related to Groovy, but not to Clojure or to Scala. I'm sure you just typed it wrong, but I'm correcting you because some readers might get confused.
To be more precise, Groovy runs on Grails, not vice versa. And almost all of Grails, even Grails 3.0 just released, is written in Java, not Groovy. Groovy is merely provided for use by website builders using Grails. This is different to frameworks using Clojure and Scala, which not only provide the respective language for website builders, but are generally also written in the language rather than Java.
I am pretty sure it is mostly just a few big companies whose critical code bases are in PHP that are collectively keeping PHP alive.
Without the efforts of these few big companies, PHP would be much deader at this point than it currently is.
BTW: When I say dead I mean for new projects. I haven't heard of anyone creating a new product that chooses PHP unless it is the only thing they know or it needs to interface with existing PHP. But my sample isn't scientific so I could be very wrong.
And millions of installations of Wordpress and other PHP based systems. Wordpress is highly active and widely used because it's easy to work with. The ease of use is a SELLING point, that "S" word that engineers aren't always strong with.
Given all this activity on forward progress (we aren't dealing with a Y2K bug where we are prepping for death) I don't see how you could say PHP is a dying language.
All software sucks. All ecosystems have their doomsday scenarios. Business as usual.
Switch to the percentage view of the languages, you'll notice that PHP's percentage is decreasing: 7.7% -> 6.3%.
It isn't decreasing as fast as Ruby is (although that may be an artifact of the Ruby community being a first adopter of Github), but it is still decreasing.
C++, C#, Go, JavaScript, Java, Shell and CSS are not decreasing.
On the other hand Facebook is doing so much with PHP that it may save it. If they get Hack to be more known and supported it might count as a good language which more organizations could use. Not sure if they ever add concurrency and shared memory though (can't remember their plans right now).
I used to do a lot of PHP, and I love Clojure (all my work for the past year has been Clojure only), so I totally get where the author is coming from. Comparing Clojure and PHP is not even fair, whether we're talking performance, concurrency, or elegance.
In the process of learning Clojure, I have discovered a "better" way to write PHP:
1. Use PHP namespaces (5.3+)
2. Use functions in those namespaces that take mostly PHP arrays and sometimes other params, modify them, and return new/modified arrays and params (again, that's similar to how data flows in Clojure, albeit not "pure")
3. Minimize or eliminate use of classes, objects, public, private, protected, getters, setters, and other OOP goofiness; classes with static properties/methods are OK
I tend to have quite a lot of objects that are basically what I'd use complex closures for in a lispy language - i.e. a bunch of read only attributes, then some methods that use those as configuration/etc.
That's basically a 'bigger hammer' version of (2) though - mutable state is, as ever, the enemy.
"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don’t care about this crap at all."
I'm a PHP developer by choice and I like that quote. I like throwing things together - I don't use frameworks, I use libraries. By combining an ORM, a template engine, and my own router... those things form an MVC framework that I actually understand. The frameworks like RoR, people don't understand what's going on when something goes wrong because they put on so much abstraction... PHP remains simple, and I like it.
To be honest I like javascript better, but PHP has more reusable code on the web so most things are still way easier to do in PHP than Node.js. Also I think composer is a great package manager, it's not like PHP doesn't have a good one.
I enjoy hacking things together and agree with Ramus that abstract classes and protected properties are worthless. Wordpress was hacked together and it's still doing fine... all that code and not one abstract class. That's the PHP developer philosophy the author was looking for... we do what we want.
PHP will never be obsolete in the sense of, Wordpress and Facebook will never be obsolete. It's good enough for Facebook to not start from scratch. But it's probably obsolete in terms of starting a new website. I started web dev in PHP but switched to Django as first choice many years ago. Isomorphic React now feels like a one step backwards, two steps forward.
Meanwhile, there are hundreds (thousands?) of new Wordpress installs going up every day. People building their businesses and making money without much thought as to which tooling is behind their administrative control panels other than the name, Wordpress.
You did say, "website." Perhaps you didn't mean to use such a general term. A green field web application may not choose a stack which includes PHP.
Yeah, I meant 'original web app'. Funny, my company also uses Wordpress because thats what the design studio supplied, and we keep it on a completely isolated server for security reasons.
HHVM is one of the things that is making PHP obsolete. You simply cannot run a top-level Internet business on PHP anymore. It does not work!! PERIOD!
Facebook realized this and solved the problem by building a proper platform to run a subset of PHP which allowed them an easy migration to the new platform. Massive companies can afford to do this, but the rest of use need to choose safer tools with a long future ahead of them.
You're confusing the Hack language (the "subset" of PHP Facebook uses -- actually a superset, as all PHP is valid Hack) with HHVM, which is a PHP runtime engine.
Wikipedia recently transitioned their PHP website from running on the Zend engine to running on HHVM. It's still regular PHP code, though.
"You simply cannot run a top-level Internet business on PHP anymore" - I guess you mean ONLY on PHP.
Maybe Facebook is not using just PHP...
Twitter and Slideshare demonstrated that you cannot run their businesses exclusively with Ruby on Rail.
Pinterest and Quora have done the same with Python.
At a certain scale, it is more economical and efficient to optimize part of your architecture with services written in other languages.
This has always be true. People has massively relay on caches that are usually written C/C++ Ex: memcache is a very tiny piece of C has been used with PHP, Python, Ruby forever.
However you would be surprised to know how many million dollar businesses are running almost exclusively on PHP. I am not saying that is the best choice, but it is the reality.
PHP is not obsolete in the sense that it's still in very active use, and will be for quite some time. There are reams of important code already written, and some being written in PHP.
I still hope that PHP is becoming a legacy technology, and fewer new projects will be built with PHP over time, due to increased availability of better tools.
PHP is not going to completely die any time soon, much like Cobol is still alive and kicking in some narrow niches, to say nothing about Fortran.
This reminds me of the arguments people used to start with me (far too) many years ago about mainframes and COBOL. "Mainframes are obsolete. They're on there way out." "Sell your stock in any company who is still using a mainframe."
My retort was always the same: there are many business-critical applications mainframes run well at very large companies, and they are everywhere. It will take many decades for that to change, if they choose to change at all. And the cost to change over those apps will be far too large for many given the limited benefits and IT as a cost center. Also, IBM has too much to lose if they let the mainframe business die. They won't. They will keep improving and encouraging the mainframe ecosystem.
(At the time, I acknowledge I didn't see Y2K as being a future issue that would provide a burning platform that changed the industry dramatically.)
So many people walked away from those conversations shaking their heads and saying I was crazy under their breath. 20 years later, the memory still brings a smile to my face.
I think PHP is good for web development, but the syntax of the language is really bad for people who might potentially go on to learn more languages. One prime example of the really bad sides of PHP is the ambiguity of collections contained within the PHP array(). Gone is the distinction of sets, linked lists, and maps -- they're all contained in this single, uniform data type.
One frustration I encountered at a job this month was attempting to port some code from Java to PHP, but it was a performance hit because some of the Java code being dependent on these primitive data types that were unavailable in PHP's core infrastructure. I heard they've planned to release these primitive data types to resolve the ambiguity, but I have yet to see it released.
My first real programming project was a ticket system for IBM in 2000 using PHP 3. I have to say that I knew C, java and perl. However, for generating HTML at the time PHP took far less time to create the pages I needed than any other language. In fact I went from learning PHP to writing my first full blown ticket system in a matter of two weeks. I'm terrible at programming. Now I use Ruby and Python plus have to do C and Java for Android. I still feel PHP was far easier to go from complete Novice to writing apps than any other language. Maybe I just haven't become well enough versed in this web 2.0 to know what it is I'm missing.
It's a religious argument at best. Laravel is keeping php at the cutting edge in terms of frameworks. Php 7 in terms of core features and optimization.
Essentially, the same php naysayer article crops up a few times a year for the past 10 years.
Laravel is a pleasure to work with and excellent for any new company product you might be building no matter how big or small.
If the task is to create content-oriented sites by non-technical people, who just want to put the darn thing online and maybe generate some income, nothing comes even remotely close to PHP, after all these years.
> The reasons to choose it in 2000 were compelling, but there is no reason to choose it today — the world has changed, and there are dozens of better choices now.
I'm not convinced that he has the reasons for choosing PHP quite right -- either circa 2000 or now.
If you're writing your own web application, really, you've always had complete freedom in choosing the language. Saying your alternatives in 2000 were C, Java, Perl and ASP captures the zeitgeist rather than the actual choices. For example, Python was already a solid option (and Zope was a thing), and a few people/companies you might have heard of even built a successful startup or two off of weird choices like Lisp or TCL. That's one of the great things about the web: you speak HTTP/HTML, it doesn't matter what your back end is written in.
What PHP always had going for it over other options were these things:
1) It was really easy to add to Apache-based commodity shared hosting. So people running hosting companies did. So it was widely available on very affordable hosting.
2) The document-as-program model. Yes, it's terrible from a "separation of concerns" standpoint. Yes, you hate it for the right reasons. That's probably part of what keeps you seeing its strengths:
(a) It's an easy model to grasp, and a particularly gentle step for someone who's only written markup documents. It doesn't even have to end in spaghetti madness (though that's a popular path).
(b) The deployment story is dead easy.
3) Arguably one of the better online reference/tutorial sets for a long time (much less true today, but circa 2000? yeah).
As far as I can tell, it still has most of these advantages which made it the de facto runtime of the back-end web. And it's stayed more or less competitive as a more serious option as various developers and high-profile users have improved the language itself and shaped the practices of the community.
There are two things I see that may be potential sea changes, though:
1) The rise of JS on the back end presents another easy path for people who might start as document authors and then move into front-end scripting. Maybe. Node still has deployment issues and some other complexity I don't think PHP presents. I'm keeping an eye on nginx+js, though... that story sounds enough like Apache+PHP to me that I think there's potential.
2) Or maybe traditional shared commodity hosting doesn't matter as much anymore. The VPS is essentially price competitive with generic hosting now. On the other hand, that's just cost in currency, managing your own virtual server often means more of a sysadmin/ops time investment (not always a gentle step). But then there's containers, and I wonder if managed standardized package configurations for them might finally mean the deployment story for other stacks is going to get as easy as PHP (or even easier).
However PHP has become a lot better. Starting from PHP 5, it started feeling a legit language. Frameworks like CakePHP, Laravel and Symphony have shown that PHP is capable of competing with Django with Python and Rails with Ruby. Facebook drastically accelerated its runtime speed with the HHVM. And PHP 7 promises to be even faster.
What I like about PHP is how the runtime works: - If something is messed up in a controller only the requests that hit that code will have problems. The whole application does not crash. - The other thing I like is that you change a file and the change is immediately available without having to restart anything.
I love Node.js, C++, Go and Python but PHP is still a good tools in these days.
PHP is only obsolete for those that choose not to use it.