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.<p>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.<p>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.<p>I love Node.js, C++, Go and Python but PHP is still a good tools in these days.<p>PHP is only obsolete for those that choose not to use it.
TL;DR PHP does not have concurrency so the author has taken the viewpoint of PHP becoming obsolete.<p>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.<p>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.<p>On the JVM we have things like Grails on Groovy, Clojure and Scala which have strong development teams and visions for the future.<p>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.
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.<p>Without the efforts of these few big companies, PHP would be much deader at this point than it currently is.<p>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.
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.<p>In the process of learning Clojure, I have discovered a "better" way to write PHP:<p>1. Use PHP namespaces (5.3+)<p>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")<p>3. Minimize or eliminate use of classes, objects, public, private, protected, getters, setters, and other OOP goofiness; classes with static properties/methods are OK
Article is Jan 2014.<p>Lots has changed since then. PHP7 shows significantly performance gains that make it super fast compared to previous versions [1].<p>[1] <a href="https://www.zend.com/en/resources/php7_infographic" rel="nofollow">https://www.zend.com/en/resources/php7_infographic</a>
"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."<p>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.<p>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.<p>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 is not obsolete. Quite the opposite.<p>HHVM by Facebook has made PHP a bit cooler.<p>An argument from a PHP developer (i'm not one, personally dislike it) could be: "its good enough for facebook"
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.<p>I still hope that PHP is becoming a <i>legacy</i> technology, and fewer new projects will be built with PHP over time, due to increased availability of better tools.<p>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."<p>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.<p>(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.)<p>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.<p>- a proud PHP coder
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.<p>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.
I think it was quite interesting that the thing that originally made him use PHP in 2000 is still something that's true now (integrated everything).
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.<p>Essentially, the same php naysayer article crops up a few times a year for the past 10 years.<p>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 <i>content-oriented</i> sites by <i>non-technical</i> 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.
PHP is a fantastic hackers language.<p>Easy to pick up, easy to code, powerful, lots of quick tips and google answers any problem. I'll be using it till the very end.
> 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.<p>I'm not convinced that he has the reasons for choosing PHP quite right -- either circa 2000 or now.<p>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 <i>weird</i> 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.<p>What PHP always had going for it over other options were these things:<p>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.<p>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:<p>(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 <i>have</i> to end in spaghetti madness (though that's a popular path).<p>(b) The deployment story is <i>dead easy</i>.<p>3) Arguably one of the better online reference/tutorial sets for a long time (much less true today, but circa 2000? yeah).<p>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.<p>There are two things I see that may be potential sea changes, though:<p>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. <i>Maybe</i>. 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.<p>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).