PHP is dead. | Hacker News Reader

PHP is dead.

blargh.tommymontgomery.com

20 pointspavel_lishin17 comments

It's really annoying whenever anyone declares a widely used platform as dead.

PHP, like most things, has a lifecycle. If we know anything about scripting languages, they're incredibly resilient. PERL, for instance -- a language nearly 25 years old -- seems to be updated with less frequency than PHP, but continues to be used and developed. Not just to maintain legacy infrastructure, but to build new products.

Even if we're witnessing the sunset of PHP's development -- which I doubt is the case -- it'll be a very long time before it dies.

  > PERL, for instance -- a language nearly 25 years old --
  > seems to be updated with less frequency than PHP,

While there was a discernible lull in the mid-2000s, development of Perl 5 is in surprisingly good shape right now. Also, it's not an acronym.

PHP's biggest problem is the people who demand OO features out of a procedural language.

If you want classes, namespaces, anonymous functions, etc. use a different fucking language. Don't bitch when the feature you want is a shoehorned in piece of crap.

Stop polluting an otherwise useful language.

How do classes, anonymous functions and functions in PHP differ from those in _insert_your_language_of_choice?

I love those features in PHP, especially OO and anonymous functions as a way to organize my code, make it more readable and maintainable. However, I'm not using them strictly in a conceptually pure way. OO was meant to lead to massive inheritance schemes, and PHP is just not a suitable environment for that paradigm.

The reason why most PHP devs don't go off on massive Java-like inheritance sprees is PHP's execution model. It's strictly request-based. For every request, PHP code creates an environment to service it, and then everything gets discarded. This is one of the strengths of PHP, actually, it makes PHP apps stateless in many respects. However, this also means that it is unwise to build computationally wasteful structures like extensive OO schemes - at least for performance-conscious production environments. Contrast this to Java or ASP.NET apps, for example, where the cost of initializing massive OO frameworks is offset by the fact that they stay intact across requests.

So I believe OO features are very good and important for PHP, as long as developers keep the computational cost in mind. Also, closures are awesome.

I certainly agree with the sentiment that forces are pulling PHP where it isn't comfortable being.

"You don't hammer in nails with the handle of a screwdriver." was something my Dad used to say and I thought it was pretty stupid, until I thought of it as a metaphor for all the times my 'pain' was that I had the wrong tool in my hand and was too blind to see that.

People are trying to PHP in ways it can't easily go, and yet that is the requirement the user's have, thus PHP is by definition the wrong tool. Tools which do not serve a purpose as well as other tools don't get used. A language, system, or tool which nobody uses is 'dead'. QED.

Can you give a simple example for this PHP is by definition the wrong tool ? Maybe a common problem being solved in php which should be done in another language.

The first part was the context,

"People are trying to [take] PHP in ways it can't easily go ..."

Tools make hard jobs doable, the right tool for the job can make a difficult job trivially easy. The definition of the 'right' tool can then be expressed as 'doesn't cause you pain' and the inverse works as well, if your tool is causing you pain then it is not the right tool for what you're trying to accomplish.

Probably an example of tm;du (too meta; didn't understand) :-)

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." Bjarne troustrup

Hurray! :)

Ok, no, no that's not fair, but it'd be nice to see people move over to other languages, if only because many of them strongly encourage the use of web frameworks which inspire (or force) better coding practices.

It'll be refreshing to see that my data isn't being compromised by every website I visit because their PHP/MySQLi code is vulnerable to SQL injection...

I'm sorry to bring the bad news, but SQL injection vulnerabilities are not a problem of the combination of PHP and MySQL. You can have the same problems with most other combinations of a scripting language and a backend database, for example ASP and Microsoft SQL Server.

The true lesson is: Don't assume user's input is ok for SQL queries. All input is evil!

Is there an alternative to PHP that is as easy to setup? It seems that most languages require another server process running in the background (Tomcat, Ruby, etc.) and a web server to proxy requests. Is it old-fashioned to like the way Apache and PHP work together (and even nginx with PHP-FPM)?

In some languages (Racket, Common Lisp, Haskell), it's easy to make the webserver part of your application. Then it's just a "server process running in the background".

You should check out the most recent versions of Passenger (a Ruby app server). You install Passenger using a simple call to `gem install passenger`, then run a single command to install the Apache module and copy/paste two lines in to your Apache config. Outside of having the module delivered by your OS distribution (like PHP + Apache), it's the easiest, most integrated app server install I've ever performed.

Passenger configuration is done through your Apache vhost configs. You tell Passenger how many app server processes to spawn, restart Apache, and you're done. Passenger even plays nice with user-specific deployment strategies, meaning your Ruby apps will automatically run as the user who owns the Ruby app files. I'm not even sure mod_php does that. Passenger architecture includes process monitoring that keeps track of your Ruby processes, so you no longer have to implement "watcher" apps like Monit of God.

Did anyone even notice the date on that? July 2010. Why would you even dig this up?

July 2010? Apparently, PHP dies a horrible, slow death.

As there are lots of people apparently still happily using PHP 4, it will presumably take a long time for PHP to die out in the wild, even if the PHP core team decides tomorrow to call it a day.

Reply on news.ycombinator.com