
Taking PHP Seriously - josephscott
https://slack.engineering/taking-php-seriously-cf7a60065329#.v643zvbw3
======
swalsh
I work on PHP at my day job (in a public company), before this, I came from
Ruby, and .NET before that.

I'm convinced the reason so many successful projects use PHP, is not because
of any inherent nature of the language. I think it's the people who use it.
They just don't care. A successful project needs to be started by someone that
cares just enough, but not too much.

If you're programming in PHP, you're not running around talking about
"convention over configuration" giving talks, or trying to make your code
beautiful. It's a garbage language, and you know it. But it allows you to get
something up and running, so dang quick. You're failing while the other guy is
still updating his gem file. You're advertising while the other guy is trying
out some fancy new deploy script. You're incorporating feedback while the
other guy is just starting to get to work. When he finally fails, he's used up
half his runway, whereas you, the guy who didn't give a fuck about your code
has gotten past that first failure, and are finally getting some traction.

Hopefully, the next guy to join the company will clean up your shit. The other
guys code may not look like shit, but it doesn't solve any useful problems...
so they never got the chance to hire that next guy.

~~~
brian-armstrong
I'll offer an alternate hypothesis.

Some companies are succeeding in spite of php. There are many, many users of
php, and we'd expect that there would be considerable variance, with some
users doing awful (no traction, buggy sites, etc) and some hitting home runs
(facebook). Because it's such a popular language, it will have users across
this entire spectrum.

It's easy to cherry-pick the winners and miss all of the tremendous losers who
picked php and got nothing for it.

~~~
increment_i
It would be an outlier company indeed who held an 'all hands on deck' meeting
and said, "We're succeeding in spite of PHP everyone!"

Only engineers care about programming languages. Seriously. That's it. No one
else cares about them. I work in a large public university alongside a
revolving door of student interns who are always 19. In 10+ years of work,
I've still yet to meet the person who talked about their favourite website or
app, but lamented that it was written in Php or JavaScript or Go or Java. It's
only us (the HN'ers) who fret about this.

Don't believe me? Imagine the look on everyone's faces at the tech publishing
houses around 2009 when books about Objective-C sold a few hundred copies a
year to doing tens of thousands per month when the iPhone rocked the world.
This happened without a proper language hot stove on Hacker News, no?

People care about outcomes. People care about products. People care about
being dazzled. People care about showing their friends this incredible thing
they saw on the web/this new app.

~~~
ddw
But program managers and CTOs and other non-engineers at a company care about
scalability, performance, technical debt and quality, right? Let's not pretend
that these don't matter once you've gone past the "users actually care about
our app" phase, because they do and they affect the bottom line of a company.
And IMHO PHP falters in these regards.

~~~
ransom1538
Performance? You need to update your act. PHP7 is 3x faster than python and
now faster than Java 8 . The only people that can call php slow are
masochistic c++ web hacks.

[https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-
vs-...](https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-php-
performance-benchmark-2016/)

~~~
jbergens
Funny that people complain about js performance. In this benchmark it was 3
times as fast as php7 and about 7 times as fast as java 8. Have not checked
the details of the benchmark yet.

~~~
juliangoldsmith
It's worth noting that it's compiled JavaScript vs. interpreted PHP. With
something like HHVM the PHP version would likely be a lot faster.

~~~
secoif
Compiled JavaScript?

~~~
niutech
I think he meant JIT compilation.

------
Klathmon
The article points out that arguably the best part of PHP is the "shared
nothing lifecycle". That each request starts new, and the process dies at the
end of the request. It's by far my favorite part, and I completely agree that
it makes "reasoning about" (boy do I hate that phrase...) your program much
easier.

Why are there no other "competitors" in this space? Why do most other
languages go with the alternative route of using an event loop or daemonizing
your "server" to serve up requests? I can understand why Node.js does it
(otherwise the async nature would just be an annoyance for no gain), but why
haven't there been any other server-side languages that not only work well
like this, but actively target it?

It seems like it would be easier for everyone involved. You wouldn't need much
of a GC when the process is killed every time, you don't need to worry about
async IO or multi-threading or catching errors or any of the other annoyances
that come with most of the traditional "event loop" way of doing things.

So what's the catch?

~~~
mikey_p
The downside is literally exactly the same as the upside: you have to
bootstrap from _literally nothing_ for every single request. Think about how
ActiveRecord in Rails reads from the DB schema to generate it's magic methods,
etc. This is usually done on startup or at least cached in memory once it's
loaded. This is something that you have to manage more carefully with a PHP
app since you can't have anything initialized before a request starts. Code
paths, auto-loaders, database connections, config files, etc. All that has to
happen over and over for each request. You can cache that stuff, but it's
still overhead that isn't central to handling a request.

There's actually work being done to build PHP frameworks that get around this
with ReactPHP, ZeroMQ, Photon, etc. Essentially this is what HHVM does as
well, by at least keeping your compiled bytecodes in memory (similar to
APC/eAccelarator/ZendOptimizer, etc).

See: [http://reactphp.org](http://reactphp.org) [http://www.photon-
project.com](http://www.photon-project.com)
[https://gnugat.github.io/2016/04/13/super-speed-sf-react-
php...](https://gnugat.github.io/2016/04/13/super-speed-sf-react-php.html)

Even the idea of an alternative runtime for PHP (ala HHVM) is nothing new:
[http://quercus.caucho.com](http://quercus.caucho.com)

~~~
toast0
> Code paths, auto-loaders, database connections, config files, etc. All that
> has to happen over and over for each request.

Do you most of those need to happen at all, ever? In my mind, auto-loader is a
sign that nobody knows what's being loaded (if they did, they would just
require it). Requires should be full pathed (because have you seen what
happens when you search the include path). Mysql_pconnect has been doing
connection pooling for a long time, mysqli supports it too (so yes, you do
need to connect sometimes), anyway, if you're loading a framwork, loading that
probably takes longer than connecting to a mysql server in the same colo.

~~~
dpcx
IMHO, developer time is more expensive than CPU time; I don't want or _need_
to have to write out all of those requires. That's the job of the autoloader.
And if I'm writing my code remotely well enough, each section only uses the
things that it needs. Granted, there may be some things that each request get
that they don't need with the autoloader. But I can optimize later. "Make it
work, make it right, make it fast"

~~~
Twirrim
> IMHO, developer time is more expensive than CPU time; I don't want or need
> to have to write out all of those requires.

Every wasted millisecond on the server side matters. It impacts scalability,
customer experience (and revenue) etc. You should take every easy win you can
get there.

Not doing full includes is just ridiculously lazy. It doesn't take _that_ long
to write them out, and your IDE can help you out there. I bet you spend more
time on social media during office hours than you'd ever save from not having
to type out those import statements.

~~~
bpicolo
Except you still need autoloading configured for most libraries in the
ecosystem to work, unless you want to manually chain absolutely huge
quantities of requires.

------
skippyta
I worked in PHP at Box for about 3 years. This article does a great job of
reflecting my sentiments on the language. In particular, I'm glad to see that
the author recognizes that there are some glaring issues with PHP that aren't
tradeoffs in favor of something else - they're just warts.

That said, PHP is really good at what it does - providing a framework and
environment for serving web requests efficiently and easily. I find developing
in it very fluid once you know how to avoid the warts. A lot of the flak that
PHP receives as a language revolves around the fact that it doesn't actively
discourage developers from doing bad things, and sometimes the language itself
does some crazy stuff (as shown in the article with the divide-by-zero
behavior). I think this is a huge shortcoming of the language, especially as
code bases and teams grow and your organization needs to depend on the
language more and more for safety. That said, I still don't _hate_ working
with it. Sometimes I rather enjoy how quickly I can develop in PHP, and how
reliable it can be if you know how to operate it.

I think in all, it was a bit of a slog to get to the point where I am with PHP
today - to the point where I understand its strengths and flaws, but
ultimately I think it does have a place in modern webapp development. I think
Hack and HHVM are excellent spiritual successors to what PHP tried to (is
trying to?) accomplish, and that they do a great job of hiding or eliminating
some of the warts of their parent language.

Kudos to the Slack team for being pragmatic about their approach to the
technology, and hey again to all of my former colleagues working there!

------
rpeden
I've had to do some PHP work recently, on a fairly old school PHP codebase for
a high traffic website, after spending most oy my career working in Java and
C# (and I still do most of my work in those languages).

I've read a lot of PHP hate over the years, but I've found working with it in
practice to be decidedly...not bad. Perhaps the codebase I inherited is better
than most. But I've had to make some fairly major updates, and they've proven
to be far less painful than I had expected based on the amount of PHP attacks
I'd read online.

Maybe the snobbery toward PHP is a good thing? There are some really big PHP-
based communities out there, Wordpress being probably the largest. And in
these communities, there appears to be a large demand for paid consulting and
plugins. Sure, there's a ton of competition on the low end, but it's an area
where a really great developer could stand out from the crowd and do very well
financially, _especially_ for more complex consulting and dev work since so
many good developers turn their noses up at PHP.

~~~
leeoniya
The language is not beautiful, it is full of signature and func naming
inconsistencies [1] it inherited from C. The devs are ultra-conservative and
stubborn to cause BC even at major version bumps (like the forever-incorrect
ternary associativity [2][3]). But PHP7 is both fast and productive with many
modern first-class features. You _can_ in fact write excellent code without
much effort that will handily outperform Python, Ruby and even Node.

The Wordpress codebase [plugin api included], though, is utter garbage.

[1] [http://www.phpsadness.com/](http://www.phpsadness.com/)

[2]
[http://php.net/manual/en/language.expressions.php](http://php.net/manual/en/language.expressions.php)

[3] [https://www.mail-
archive.com/internals@lists.php.net/msg7196...](https://www.mail-
archive.com/internals@lists.php.net/msg71964.html) (yes, i asked for this in
2014)

~~~
gravypod
> The language is not beautiful, it is full of signature and func naming
> inconsistencies [1] it inherited from C.

It was consistent with the thing it inherited most of it's syntax from so that
makes it inconsistent?

> The devs are ultra-conservative and stubborn to cause BC even at major
> version bumps (like the forever-incorrect ternary associativity [2][3])

You shouldn't be judging the way operators work in one language with the way
they work in others. Is lisp inherently bad since it's operators are prefix
and not infix? No I'd say not, it's just different.

On the other hand, the PHP devs changing the ternary would cause major
problems for anything that uses it. The most the PHP devs have done is
deprecate methods and add features. That's great. I think that changing
something, that has been there since the beginning, to a new behavior is
stupid. Much much much worse then having ternary work backwards.

> The Wordpress codebase [plugin api included], though, is utter garbage.

Yes, yes it is. That's not the language's fault.

~~~
TheDong
> It was consistent with the thing it inherited most of it's syntax from so
> that makes it inconsistent?

It is also internally inconsistent in so many ways.

Half the array functions take arrays as the first arg, the other half the
last.

explode and implode have different argument order requirements (one is strict,
the other works either way).

Functions have a grab-bag of errors from returning null to false to 0 to
strings to requiring error\\_get\\_last to even requiring an object specific
error function (DateTime::getLastErrors).

Functions were named to make them have more randomly distributed hashes
([http://news.php.net/php.internals/70691](http://news.php.net/php.internals/70691)).
Functions randomly do or don't have underscores, sane order, etc.

Some apis are in terms of objects (DateTime), some are not (getdate).

The whole thing is far less consistent than C. Some inconsistencies are from
C. Most are PHP shit layered on top.

> You shouldn't be judging the way operators work in one language with the way
> they work in others. Is lisp inherently bad since it's operators are prefix
> and not infix? No I'd say not, it's just different.

It's a C-like language. Every c-like language does it the other way. I will
totally judge a language that makes a decision that makes programmer's lives
terrible with no justification. In this case, it's different in a way that
often leaves to bugs and surprises.

~~~
gravypod
C++ is a C-like language but C++ muddies up the difference between some
operators due to operator overloading. This is an inconsistency.

Do you support that? No one will ever be able to convince me that "<<" and
">>" make sense to be read and write.

~~~
TheDong
It doesn't matter, we're talking about php not C++. But yeah, "<<" and ">>"
are at fairly _internally consistent_ within C++ and don't generally confuse
programmers or cause significant bugs in my experience, so _I_ don't find them
problematic. They did seem a bit weird at first, but they didn't cause
significant problems.

Perhaps they do for you, and I accept your complaint about those operators as
valid actually, but it's on a whole different level of badness than php, and
again, we're talking about php. Just because "other languages suck" doesn't
mean php doesn't, so that's not a valid argument against anything I said.

~~~
gravypod
I'm saying neither of them suck. They both have small things "Wrong" with them
that are only "Wrong" because I don't like them.

>they didn't cause significant problems

That's not a valid criticism of any feature. I'd say that the worst feature of
any programming language yet has been pre and post -- and ++. Some of the
nastiest bugs I've seen have come from there.

In both cases I avoid them. I only really use -- and ++ if I need to, just
like ternary operators.

> Just because "other languages suck" doesn't mean php doesn't,

Ok what about other languages that are good? Python's ternary operator isn't
the same as C-style languages but I still think of Python as being good.

------
calsy
Come on, PHP is the 'Justin Bieber' of languages, everyone knows it. Its the
most successful and widely used web server language in use and with anything
so popular it has a large group of haters.

If anyone wants to come off like a 'serious' programmer, all they need to do
is denounce PHP as a horrible aberration, a frankenstein of a language. Most
don't even know about the changes in the language over the last decade, they
just hate it to stay inline with their peers.

However, those opinions dont line up with the facts. PHP goes beyond semantics
of language, it's a complete service for delivering dynamic HTML from the
server. Why is it so successful? It is one of the most robust, well supported,
battle tested languages to appear in the last 15 years. Its support is
guaranteed on any hosting platform or cloud solution available. It has a large
array of libraries capable of integrating with most any service whether that
be databases, web apis etc. It has the ability to scale for high demand, as
demonstrated by the many large corps that use it.

If you want to rip on PHP because it's cool, I think you're simply shooting
yourself in the foot and ignoring a tool capable of performing almost any task
you would require of it on the server side.

------
agentgt
It is not entirely clear if the author aka Slack chose PHP with these reasons
in mind apriori or did they choose PHP first and are now justifying why their
choice of PHP is not bad.

I'm going to guess they picked PHP because they knew PHP and not because of
the nice reasons mentioned in the article. That is the article should be "why
slack is sticking with PHP".

Almost all the major languages are actually (despite lots of HN debate and
arguments) fairly good choice for developing not because the major languages
are expressive/powerful but because they have very very mature tools (e.g.
Java sucks but the JVM and its tools are very mature) and lots of people who
know it.

Basically you could write a plethora of articles with _" Taking
MAJOR_BORING_LANGUAGE Seriously"_.

For example I'm responsible for choosing Java for my companies startup. Java
historically is not a very productive language to pump something out but in
recent years it has vastly improved... regardless I chose Java because thats
what I knew at the time and I would pick it (or some other JVM language)
again. And I could rattle off whole bunch of reasons why the JVM still kicks
butt but the reality is I am biased because of my familiarity.

~~~
stevesun21
Agreed, and only thing I want to mention is that 'Productive' which people
normally think about how fast to develop rather than measure it within the
whole system development life cycle – code easy to read and maintain, tools
for test/profiling, logging, deploying etc.

------
throw2016
I think there is a needless air of elitism especially here that can only come
when people take themselves too seriously, seek validation for their choices,
and are always on 'display'. This is also now fuelling a full scale culture of
complexity as nobody wants to do things simply lest they be judged as
'unsophisticated' and lose career and other opportunities.

This cannot lead to real conversations or good software. There are far too
many naysayers always eager to jump in with their 2 bits of negativity with
the same cliched talk points and links most of whom I am sure would never be
seen near php and may not even have used it.

The criticism goes silent when HN favourites like Slack show up on discussion.
Ignoring the sheer number of high traffic websites and successful startups
using PHP is just another way to deny it its due.

Most PHP apps are a breeze to install and use compared to just about any Ruby
or Node app. Try installing Discourse to understand just how user hostile it
has become. The respect for users and simplicity comes through in PHP. NPM and
Ruby with their dependency hell expect a full dev environment even on user
machines and nobody thinks this is ridiculous. There is no denying PHP warts
but Node, Ruby and Python I think have their fair share of issues.

I really do like Python but for a web project that needs to scale and not get
mired in other issues I would choose PHP every single time. For a library or
SAAS app maybe, but for an installable app I would never expose users to the
Ruby or Node ecosystem.

------
andreygrehov
Hack is awesome, but we decided to go with PHP 7 and this choice was primarily
made because of lack of tooling on the Hack side. Things like New Relic are
not available and these type of things do matter a lot when it comes down to
choosing the programming language.

I must say that PHP 7 is a great language nowadays. Most of the modern
concepts are baked into a language or are about to be developed.

At some point, I wish Hack and PHP merge into a single language in the future,
somewhat similar to what happened to Node and iojs. I'm not sure if Hack is
going to be around in 5 years, but I'm pretty confident about PHP.

I'd definitely love to see more articles about Hack and people's experience
with using it in production.

~~~
tomschlick
With the changes in PHP 7.0/7.1 & the powerful frameworks (Laravel & Symfony),
PHP has made a dramatic turn for the better in the past ~3 years. I work with
Laravel daily and it is actually an enjoyable experience using PHP.

Most of the hate for PHP comes from the PHP 4 days, but we are well past that
and charging ahead with featureful yearly releases.

------
callesgg
That example of "Surprise type conversions" is crazy. Did not know that.

While i do not think PHP is a perfect programing language. There is one think
i LOVE about PHP, it is that the PHP "community's" default way of documenting
code behavior is to make a small example.

When i read most other languages documentation i read it. Then i need to make
a small test to verify that i understood it.

All those tests takes a long time to make and i have to make them over and
over again, every time i forget the way a function behaves.

~~~
bitwalker
In my experience code examples as documentation are far more common than
actual documentation (e.g. guides, user manuals), but perhaps I just haven't
worked in a language where the opposite is true.

~~~
tracker1
You can take a look at the node api docs... there are some areas (particularly
in crypto), where it's really hard to understand what you need to do, as there
are pretty much no examples of actually exercising said code. So you go
searching via google, find a similar example, look at the docs again, and hope
that you got it right.

It's harder still when you're trying to en/decrypt data from multiple
programming languages... Java is particularly painful as well, since a lot of
the things that are "standard" are abstracted behind class structures with
naming that differs from the standards.

------
Tehnix
I find the virtues quite uncompelling, take for example

>First, state. Every web request starts from a completely blank slate.

Except for, you know, when you don't want to reinitialize everything everytime
someone makes a new request. There are tons of things that you only need to
run once.

>I claim that PHP’s simpler “think; edit; reload the page” cycle makes
developers more productive. Over the course of a long and complex software
project’s life cycle, these productivity gains compound.

I cannot disagree enough with the conclusion he draws from the quick feedback
loop in PHP. I do PHP in my day job, because that's what our codebase is in,
but recently I finally got the opportunity to use Haskell for a side project.
The feedback-loop might be slower (honestly not by much, automatic reloading
is a thing in almost any framework), but I'm a zillion times more confident in
my code, because you are able to encode so much logic in the type system,
meaning the compiler will catch whatever. Contrast this with PHP, where I'd
almost have to visit every branch of code when I alter something because of
it's many weird behaviours. _Particularly_ when refactoring code, which you
often end up doing while hasing something out.

Also, PHP works at a quite coarse granularity of concurrency. A thread per web
request only? As soon as you want to do something more advanced, you are
forced out into the many patchwork solutions (wanna do async? queue that
shit).

Sure, a lot of people have done a lot of quite cool projects in PHP, but I
would much more benefit that to the lower barrier to entry - heck PHP was my
first language and I made a CMS from scratch without even knowing much of what
I was doing.

That said, it has come a long way, and something like HHVM/Hack definitely
helps a bunch! I just think the pros in this blog post are quite weird and
IMHO incorrect.

</rant>

~~~
bkanber
> Except for, you know, when you don't want to reinitialize everything
> everytime someone makes a new request. There are tons of things that you
> only need to run once.

I mean, _you 're_ not reinitializing it, and it's not exactly slow. And when
your application starts scaling across many instances, many zones, many
servers, you can have more faith that each request runs independently and
there are no runaway processes to worry about on a single one of your random
servers somewhere.

> where I'd almost have to visit every branch of code when I alter something
> because of it's many weird behaviours

I'm not really sure what you mean by that. Write a method, write tests for
that method. Just because PHP has weird type coercion issues doesn't mean you
can't be diligent about the types that you use. And of course tools like
PhpStorm understand docblocks, annotations and PHP types and classes and
basically does the same thing that a compiler does, it'll show you big honking
type errors if you ask it to, it'll even stop you from committing broken code
if you use that option.

> Sure, a lot of people have done a lot of quite cool projects in PHP, but I
> would much more benefit that to the lower barrier to entry

I don't know about that. Low barrier to entry gets you a lot of crummy
projects. In my experience PHP is a lot easier to manage and maintain in
production, and that's a huge advantage to companies and products with small
teams.

~~~
Tehnix
>when your application starts scaling across many instances, many zones, many
servers, you can have more faith that each request runs independently and
there are no runaway processes to worry about on a single one of your random
servers somewhere

It's just as easy to scale with other languages, you would keep the data that
needs to be persisted in a DB. The benefit comes from things that does not
need to be persisted, like resource pooling, memoization, config loading etc.

> > where I'd almost have to visit every branch of code when I alter something
> because of it's many weird behaviours

>Write a method, write tests for that method

Exactly, I need to write tests for things that are trivially verifiable by a
compiler. And I'm not just talking about type coercion (which is a bad thing),
but also missing function parameters, wrong parameters, missing initialization
of variables etc etc. These are runtime errors and you either have to write
tests to catch them (hence visit very code block) or manually try and reach
them.

Some IDEs, like PHPStorm, can you get pretty far though.

>Low barrier to entry gets you a lot of crummy projects

As someone else mentioned in another comment, 1% of PHP projects succeeding is
still a lot more than 20% of Haskell projects.

>PHP is a lot easier to manage and maintain in production

Except for when you need to scale. Varnish, memcache, php-fpm, redis, what-
have-you are basically mandatory for a PHP site to really run performant,
adding quite an overhead to any production setup you'll get into.

~~~
combatentropy
Look, if you want to use something other than PHP, don't let me get in your
way. However, if PHP is one thing, it is fast and always has been.

    
    
      > Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory
    

We don't use any of that. We don't even use database connection pooling. Every
request has to reopen the database. Every request has to reopen an LDAP
connection to Active Directory for authentication. We are still on PHP 5.3 and
we aren't using an opcache. We are using the memory-hungrier mod_php instead
PHP-FPM, and we are using the slower, memory-hungrier Apache prefork instead
of its newer event MPM. We are also running PostgreSQL on the same server. And
yet PHP is connecting to the database over the slower network instead of UNIX
domain sockets.

Every request takes just a split second. The server's processor is running at
1-2%, with about half a gigabyte of RAM in use, a lot of which is probably the
database.

All those inefficient design decisions are artifacts of history that I hope
eventually to revise out --- except for connection pooling, which I've read
has its own problems. On my personal website I've been able to choose the
newer and better things, but none of them were really more work to set up:
Apache event MPM, Unix domain-socket connections, PHP-FPM, and PHP's OPcache.

------
combatentropy
PHP is wonderful as a thin layer of glue between your database and the web
browser. It's when you write a thick middle layer that PHP gets unwieldy.

Business logic: Don't write it in PHP. Write it in PostgreSQL.

Authentication: Don't write it in PHP. Use Apache 2.4's mod_auth_form. Replace
hundreds of lines of PHP code with a few lines of Apache config. When it gets
to your PHP script, all that's left to do is read $_SERVER['REMOTE_USER'].

Authorization: Don't write it in PHP. Use one of Apache's modules (LDAP, DB,
or even file) or if possible make your users all very restricted database
users and use database permissions more.

Don't need a database? Then why not handle it all on client-side JavaScript?

I'll admit that my advice fits well with CRUD web apps. If you're doing
something else, PHP may be gross.

But really, my goal in programming (don't always reach it) is for PHP to just
make a simple database call and wrap the result in HTML. If you're doing 123
== '123foo', can you move that up into the database or down into the browser?
If you're writing elaborate class hierarchies in PHP, I think you're doing too
much in PHP. I write a few functions, if needed, but mostly move all data
processing to the database or browser.

~~~
cutler
I always wanted to do PHP this way as I have a Perl background but since PHP5
appeared in 2005 the psuedo-Java posse took over and it was PHP Design
Patterns everywhere and suddenly procedural/functional PHP was un-idiomatic. I
find this odd as Java's verbosity can be forgiven as it gets compiled away.
Not so PHP5's verbose OOP which has to be fed to the interpreter.

~~~
pmlnr
I wonder if procedural/functional PHP will make a comeback, since functional
programming is kind of the shiny right now.

~~~
cutler
Don't hold your breath. PHP suffers too much from Java envy. PHP5 was game set
and match for the PHP Design Patterns crowd and now we have PSRs advocating a
coding style in which blank lines and comment-based annotations outnumber
lines of real code by a factor of about 10 to 1.

------
staticelf
I was kind of surprised to read this and started to think this was just a copy
of a previous speech I've heard before.

I was right it was: [https://www.infoq.com/presentations/php-
history](https://www.infoq.com/presentations/php-history) but the author is
the same person.

It is a good speech and I've been developing in php for years, written a blog
post ([http://sucky.ninja/leaving-php-is-too-
expensive/](http://sucky.ninja/leaving-php-is-too-expensive/)) about it but I
do no longer use php for my backends.

I've whole-heartedly switched to ASP.NET since my productivity is increased
with it and I can actually use the language (C#) for other things. I would've
agreed with the author a couple of years ago but with Azure, AWS and other
cloud services it is simply no longer true that php gives developers a quicker
feedback loop. I can setup a node server with gulp and start working in 10
minutes or I can start a new ASP.NET project and deploy to production right
after the project creation has completed. With php I still have to setup a
virtual machine etc etc.

I would not go back, even if it is cheaper.

~~~
kogir
You can deploy PHP to Azure App Services as easily as you can deploy a ASP.Net
app.

~~~
wtetzner
I don't think the point is that PHP isn't as easy to deploy. The point is that
PHP doesn't have easy deployment as an advantage over other languages.

So if other languages are just as easy to deploy, what does PHP bring to the
table?

------
jv22222
Love the memes:

"PHP is garbage language!", "PHP is a shitty language!"

That is the antiquated view of course. The old days.

Now with Laravel and PHP7 it is a pleasure to use.

I'd go further.

Working in Laravel is BETTER than ROR IMHO.

~~~
cutler
Have you used Rails in production? Just curious.

~~~
captn3m0
I've used both Rails and Laravel in production, and while I equally love both,
the amount of hassles you face with rails in prod is an order of magnitude
more.

rails + unicorn/passenger v/s apache + mod_php.

~~~
mtberatwork
> rails + unicorn/passenger v/s apache + mod_php.

That's not a fair comparison though. For any non-trivial app, most people
deploy PHP using a CGI, PHP-FPM being the standard. Even the cheap, shared
hosts provide FastCGI these days.

That being said, getting RoR or Django up and running is really no more
difficult than getting Laravel setup and running via PHP-FPM.

------
paulddraper
> Virtues of PHP

> First, state. Every web request starts from a completely blank slate.

> Second, concurrency. An individual web request runs in a single PHP thread.

> Finally, the fact that PHP programs operate at a request level

Isn't this just "virtues of Apache modules"?

There's mod_python, mod_perl, and mod_ruby. Are state, concurrency, and global
requests virtues of these languages too?

\---

Even if you _do_ somehow convince me that these virtues are specific to PHP,
you can't convince me it does it well. Hence, MaxRequestsPerChild.

To quote Radmus Lerdorf,

> The real programmers will say "Yeah it works but you're leaking memory
> everywhere. Perhaps we should fix that." I’ll just restart Apache every 10
> requests.

Clean slate, my eye.

~~~
junker101
> The real programmers will say "Yeah it works but you're leaking memory
> everywhere. Perhaps we should fix that." I’ll just restart Apache every 10
> requests.

They're cattle not pets. (/semi-sarcastic)

------
rahul286
We are mostly (95%) a PHP company but going by trends; we did some projects in
Python, NodeJS and Rails a few years ago.

Now I look back; I see the projects which have technical debt were flawed in
design and did not get maintenance they needed. Most of them did not get
traction to the point where scalability issue came into the picture.

So this year, we started moving that 5 % non-PHP projects to PHP counterparts.
Again, we are miles away from any real-world scalability issue, but at least
we are now able to maintain projects as we have a large PHP team.

At a small to mid-size organization level, it is more important to use one
language for all projects.

I believe technical debt is not related to the choice of language but
anticipating direction a project might take and picking up right design
patterns to support that.

Which programming language is better is a highly overrated question!

I wish I had learned this few year ago.

------
20years
There have been huge improvements made with PHP over the past few years. PHP 7
is great and I would choose it over Hack. Modern PHP using autoloading
(Packagist & Composer) and an MVC structure allows for rapid development. With
frameworks such as Laravel, you can get something up quickly or just pull in
Packagist libraries you need if you don't want the bloat of a framework.

I recently finished up a fairly complex web app that uses PHP 7 for the back-
end. Took me under 2 weeks to develop partly because I was able to leverage a
lot of stable and well supported libraries through Packagist. It brought in
over $4k its first month. Not bad for 2 weeks worth of work. It would have
been hard to accomplish the same thing that quickly leveraging Node or Python
(I use both) at lease for this app.

~~~
chj
It's hard to believe that a REAL "fairly complex web app" can be finished in
two weeks. What kinds of libraries do you use?

------
tonyarkles
I've been doing consulting for several years now, as well as a MSc thesis that
involved me looking at a number of open source codebases. I am generally in
the "PHP is garbage" camp, but I keep hearing people say that nice codebases
in PHP are possible. I've never seen one, but I am perpetually open to the
idea that they exist.

Does anyone have a good example of an open-source PHP project that will
enlighten me?

~~~
bkanber
Symfony, Aura, Laravel, Guzzle, Composer, Zend Framework, Lithium, SwiftMailer

~~~
tonyarkles
Those are all frameworks and libraries, aren't they?

~~~
bkanber
Sure, but most of the OSS for Python and Ruby is frameworks and libraries
too... If you want an application check out phabricator, though I'm not a fan
of their DB schema design.

------
oridecon
Sorry to sound so dramatic but I don't know how to put this in better words:

After reading this thread, is there even a proper way to measure how good a
language is (trade-offs, benefits down the road)? Having done web stuff in PHP
and Python I think both are terrible. So, how would a programmer trying to
avoid his own biases and anecdotes find what tools are right for each job?
Maybe I didn't "liked" PHP and Python because I'm a terrible programmer. Or
maybe I only worked with awful teams.

Is there any science involved or should I make my decisions based in what blog
post I read that week? How can I actually trust the opinion of
companies/engineers if they are so invested in that tech? Who would admit that
after investing millions on it they didn't actually think it was worth it?
There's no way that I'll be able to have deep knowledge about all the
languages that are out there.

The sad thing is that I end it up choosing whatever is popular and half sane
because not finding (updated/well-maintained) libs or tools you need is worse
than picking a niche language that might do the job better.

~~~
pre
> is there even a proper way to measure how good a language is?

Nope.

I mean.

They're all Turning Complete (except for the ones that deliberately aren't),
and they're often good at expressing different types of problems.

So depends what you're trying to do.

Trouble is, it so often turns out you didn't really know what you were trying
to do till you were nearly done doing it and then you're stuck with what you
picked.

PHP is pretty good for building website prototypes, and can now handle the
scale as they grow too really.

But "Good" depends on what you're trying to do, and what tools you already are
running anyway.

Is there a way to measure how good a spanner is compared to a hammer?

------
bradleyjames
My assumption is they already knew PHP before setting out on this (if not I'd
be interested in hearing about that). What you know is a huge part of these
decisions. I doubt many of the sites noted truly picked PHP after sitting down
and doing a comparison of all the popular languages across the board. Their
systems grew out of what they knew and there was no time to rewrite or maybe
there wasn't a need either. If you like PHP and can support it good for you.

Regardless of their findings I wouldn't recommend anyone learn PHP if starting
out.

~~~
sbarre
> Regardless of their findings I wouldn't recommend anyone learn PHP if
> starting out.

This is bad advice.

If you are a new programmer starting out, first of all you should learn a few
languages, not just one, but also, why would you not want to learn one of the
most popular and prolific languages in the industry you are trying to enter?

If you want to work in the web world, not knowing PHP will close lots of
potential doors. They may not be the coolest of the cool but not everyone has
the luxury of being that picky when looking for work.

Of course if you are an exceptional developer and/or you live in one of the
insular startup hubs (SF, NYC, etc), then you can get away with being picky
and sticking to the bleeding edge or the du-jour tech stacks and you'll
probably get hired, but for the majority of people entering the web
development world, that may not be the case, and they should be more
pragmatic.

Even if you don't specialize or focus on PHP, knowing how to code in it will
help you land jobs and advance your career.

~~~
bradleyjames
> If you want to work in the web world, not knowing PHP will close lots of
> potential doors.

Not knowing language X will obviously close doors but by learning language Y
instead will open others. Insert whatever language you like.

I wouldn't recommend it to someone starting out because it's use is in a
limited context. You could do scripting outside of a webserver in PHP but it's
not done often. Since there are mature ecosystems for other languages that are
also used inside and outside the webserver I'd recommend something along those
lines. In my experience developers who develop systems and can learn and
understand the varying pieces have more options than someone who is a PHP or
Java or whatever context limited developer. Because of that I'd recommend a
more versatile language and ecosystem when starting out.

But of course do what you like. I'm not trying to bad mouth PHP. I just don't
think it's the best option for someone new to the field as it would limit them
to a specific context.

~~~
sbarre
The "field" in this conversation is defined as "web development" since we're
talking about PHP..

If you were speaking generally about programming then obviously don't learn
PHP.

But that's not the context of this thread.

------
eloisant
Wordpress succeeded because they were using PHP, because during the 2000's it
was very easy to find a cheap shared hosting solution in PHP+MySQL. There was
no cheap way to host Rails applications.

And their target was people who would install Wordpress themselves on a cheap
shared host.

Facebook and Wikipedia probably used PHP because many developers knew it, and
the reason was... That there was many cheap shared hosting solution for their
pet projects.

Not only this is no longer true (it's just as easy and cheap to host Rails,
Java, Scala, or anything with cloud hosting), but the availability of cheap
shared hosting is not relevant for most problems.

tl;dr:

* Wordpress couldn't have succeeded without PHP, because of a context that is no longer true today * Facebook succeeded despite using PHP, because they had the manpower to fork the language and write their own VM

~~~
davidgerard
The reason Wikipedia - or, rather, MediaWiki - uses PHP is because Magnus
Manske was going to write something to replace UseMod, and thought he'd try
this "PHP" thing he'd heard of.

It was his first PHP project.

(And why didn't Wikipedia have a visual editor until 2013, rather than 2005?
Because wikitext syntax was literally defined as "whatever this series of PHP
regexps does". Of small acorns, mighty oaks of technical debt can grow ...)

Anyone who claims anything even vaguely in the direction of "PHP is good 'cos
Wikipedia uses it" is talking rubbish.

------
pcwalton
> Almost all languages these days let programmers compare, e.g., integers and
> floats with the >= operator; heck, even C allows this.

The implication that C is an especially strict language for type conversions
is strange. C is actually one of the loosest languages for type conversions.
It's even legal to do things like compare pointers to integers (though most
compilers warn you)!

------
menelaus35
Write an API for my client app which returns user's data as JSON (or render
HTML page for profile);

You:

<!-- api.php -->

{

<?php

mysql_connect("host", "pass"); mysql_select_db("users");

$uid = $_GET[ "uid" ];

$res = mysql_query( "select * from users where uid = $uid" );

$ar = mysql_fetch_assoc( $res );

echo "name: " . $ar["name"] . ","; echo "location: " . $ar["location"];

?>

}

<!-- end of api.php -->

Just call it
[http://domain.com/api.php?uid=USER_ID](http://domain.com/api.php?uid=USER_ID)

( Yeah I know you want to scream and say all the things about this code, but
this is kind of code you would encounter with PHP, most of the time it's more
horrifying than this one. )

People use it PHP for this reason, If you want to make same functionality in
another language you need to setup an app and all the necessary things that
protect you from garbage, some obvious security issues and bugs, not a single
file like this. It's so easy and so wrong, it should be illegal to do this.
Create a file and put it into directory and call it from your browser. You
don't have to know anything about web or web servers and stuff. You just make
shit by copying and pasting from internet, that's why Facebook made by PHP and
now there are whole teams who are trying to protect company from PHP horrors.
(They made a PHP VM, bunch of software to analyze PHP and optimize it etc. )

Just don't try to justify PHP, do not defend it. It's shit and you know it,
accept it and move on.

(Note: do you remember Facebook's profile.php pages, they are still exists you
can call it just like old times profile.php?id=YOUR_ID, yeah it's a shit once
you get infected you're not gonna get out of it completely. Even if you can,
it leaves traces on you just like profile.php URL's

~~~
EJTH
The way you write code I wouldn't trust you with any language really. You give
6 lines of code and it has display of all the worst practices that I haven't
seen since I read a 13year olds tutorial on the language back in 2003.

~~~
BaconJuice
Hi, can you list all the worst practices you see in this code? Just curious of
the full list

~~~
oridecon
I'm no expert but since he didn't reply:

\- Use of mysql_ functions (This extension was deprecated in PHP 5.5.0, and it
was removed in PHP 7.0.0. Instead, the MySQLi or PDO_MySQL extension should be
used)

\- Using the user input directly in the query instead of binding, using
prepared statements, or at the very least casting to an integer (don't do
this)

\- (besides mixing multiple layers) Possible whitespace problems in the output
validation (if you're using JSON), you want most php code to be "validated"
(like using json functions), to have proper headers, to output types correctly
(like booleans). This is also why you should never use PHP's closing tag,
except for things like pure PHP templating, it's even in the PSR-2:

> The closing ?> tag MUST be omitted from files containing only PHP.

Not really the case here but you get the idea. It's like you're using a "html
view" to output JSON API stuff.

\- Possible "Undefined index", or worse, at $ar["name"], $ar["location"]

\- Having to write some ugly conditionals if you have more than a single
result and need to end the sequence without a comma or do any kind of
transformation

\- Trying to save vertical space by using expressions in the same line,
sacrificing readability

\- No error handling. What if the DB connection fails?

\- Output is not valid JSON

[http://www.php-fig.org/psr/psr-2/](http://www.php-fig.org/psr/psr-2/)

[http://phptherightway.com/](http://phptherightway.com/)

[http://jsonlint.com/](http://jsonlint.com/)

~~~
floatboth
> The closing ?> tag MUST be omitted from files containing only PHP.

It doesn't contain only PHP. There's the closing JSON } after ?> :D

------
merb
> a typical Python application server, e.g., the debugging > cycle will look
> something like “think; edit; restart the > server; send some test requests.”

the "most typical" Python stack (wouldn't call it a application server) is
probably built with Django where you don't reason about the Server restart,
it's as fast as changing something in PHP.

P.S.: I don't use Python that much anymore. Other people would say that the
thing I'm using now takes endlessly long to compile and has some wierd
operators.

~~~
dom0
The typical Python Web app debug cycle is "think; write regression test; fix
test[; confirm fix manually as well]".

And the subcycles are literally "Change -> [run test | send test request]".

------
wojcikstefan
Thank you for writing this - very eye-opening. One sentence doesn't seem right
to me though:

> Hack provides an option that no other popular member of the MPDPL family
> has: the ability to introduce a type system after initial development, and
> only in the parts of the system where the value exceeds the cost.

Python 3 allows you to do that, too:
[https://docs.python.org/3/library/typing.html](https://docs.python.org/3/library/typing.html)

~~~
Etheryte
That sentence stood out to me as well.

Javascript has Typescript and Flow, both of which are very popular and allow
you to gradually transition.

------
wnevets
>I claim that PHP’s simpler “think; edit; reload the page” cycle makes
developers more productive. Over the course of a long and complex software
project’s life cycle, these productivity gains compound

this is certainly what got me started with PHP and what makes its so easy for
beginners

------
labrador
> Inconsistency around reference, value semantics.

I ran into this problem today with some code by a programmer who should have
known better. The problem is not with PHP, it's with programmers who learn one
version and then don't keep up and change as the language evolves and improves
(ain't nobody got time for that.) One guy I work with is still programming PHP
like it's year 2000. It's maddening. PHP7 is a very nice language. People
decided JavaScript was cool after "The Good Parts" came out. The same is true
for PHP. If you learned PHP3 in high school and are still banging out code
like you did then, you're the problem, not the language.

------
Kluny
I'm a PHP programmer and it's great to see this because a lot of times I feel
like PHP is limiting my ability to move forward in my career. I've been
looking for jobs and it seems like having pretty much only PHP, jQuery and
mySql on my resume isn't enough to get hired. I've been trying to figure out
what I have to do to get noticed - is it worth cranking out a bunch of
projects in PHP that won't impress anyone because it's just PHP, or or is it
better to learn a language like Ruby and make a bunch of (shittier, because
I'm not experienced with it) projects?

------
qaq
For greenfield project main question would be why? It's not horrible but what
do you exactly gain? With so many options around it's actually hard to make a
case for PHP (and I have being using it since 2000).

~~~
kowdermeister
I'm currently hesitating between PHP and Node.js for a new side project and
I'm leaning towards PHP simple because I could do it 50% faster due to my
experience with it.

~~~
qaq
Node is actually one case where depending on the project it could be very easy
to make a case for PHP :) if you need a simple API backend you can use PHP and
not deal with whole async thing.

~~~
kowdermeister
Actually for that project Node would have an advantage over PHP with job
handling and realtime functionality.

But currently I only care about a fast MVP.

~~~
alessioalex
Use whatever you are most confortable with then, be it Node, PHP, Perl or
others. For an MVP what matters is creating it as fast as possible.

~~~
qaq
Very true and with enough pain you can make anything work at any scale booking
is doing fine running pretty much a monopoly built on perl.

------
JED3
TLDR; Because Cal Henderson made the initial commit.

He's obviously a big fan of the language, and surely had a big hand in
influencing what technology would be chosen very early on.

PHP can be like playing with dynamite. If you have an explosives expert on
site (or Cal Henderson), you can get a helluva lot done with PHP in a very
short amount of time.

------
nnq
I find it odd that nobody sees the elephant in the room: _productivity is
determined by the "fit" between a developer's or team's mindset and the
language!_

None of them matter in isolation. If you have a team of people who likes to
think _dynamic, functionally and meta-linguistically_ , just pick the best
Lisp-family language for your needs. For another team who prefers to think
_dynamic, functionally, with actors and pattern-matching_ , pick Erlang or
Elixir. Someone who likes to think _pragmatically, likes obviousness and
simple static typing_ should probably pick Go if he's also "minimalistic" or
Java otherwise. For a _" move fast and break things + fuck this functional
programming bullshit"_ thinking team, pick the best version of PHP (Hack &
HHVM) etc. Want "move fast and break things + ok with event-driven + some
sprinkle of functional programming goodness", then use Nodejs.

For example, for "move fast and break shit" prototype development I pick
Nodejs over PHP because my mind "works functionally" and every attempt at
writing functional code in PHP is _pure pain_.

There is a reason why there are so many languages: _people think very very
very differently from one another, but at the same time they think similarly
enough that they can gather in "tribes" around certain technologies and idea!_

------
tamalsaha001
It is interesting that author does not mention the performance improvements of
PHP 7. I have read with PHP 7, HHVM does not have the performances any more. I
wonder author cared to test that in their codebase.

~~~
tomschlick
Yup, and it's pretty much a drop in upgrade from 5.6. I have seen/heard of
many companies reducing their cpu load by ~40% just by switching to 7.

------
iamleppert
The shared nothing request model leads to laziness. And once you get to any
kind of scale you'll want to run PHP in something like php-fpm with lighttpd
or nginx, which actually does aggressive caching. It's painfully slow to re-
evaluate for every single request. This introduces subtle problems because
your code was probably shit to start with.

Of course, this is not a post about how good or bad PHP is/was. It's just a
matter of personal preference at the end of the day. Your favorite language is
the one you feel you're the most productive in and says a lot more about you
and your experience/background than the language itself.

------
mtrn
If people would focus more on usability, comprehensibility, clear algorithms
and project structure and precise requirements we could probably skip debating
over languages altogether, because programs would look beautiful in any
language.

~~~
astrodust
No program will _ever_ look beautiful in M4 or sed.

------
jacobsenscott
My experience is that programming is fun no matter what language you use. I've
used C, C++, Python, VB6, C#, Java, Ruby, elisp, PHP and a little clojure and
some others. I don't get all the language hate.

------
thom
A while back I found myself doing a Laravel project and found it totally
adequate and not at all painful, so I don't have the same old flinch reflex
whenever someone asks about PHP these days.

That said, nobody will ever convince my that the style of structureless,
start-at-the-top, run-to-the-bottom monolithic PHP pages has any merit at all
for real apps. I have seen many projects fail, or slowly mire themselves, by
creating these monstrosities, with the opening <html> tag 1200 lines down the
file. But I assume these days that's not common.

------
mastazi
Of the four disadvantages of PHP mentioned in the article, in my opinion, the
worst by far is the first, i.e. confusing comparison rules. The article
however fails to explain that clearly: the worst thing is not that comparison
rules are just confusing (heck, many things are confusing at first, but
eventually you work them out); the worst thing is that those rules are
intransitive (!!!), as explained very well here:
[http://phpsadness.com/sad/52](http://phpsadness.com/sad/52)

The second disadvantage, passing by reference vs. by value, honestly can or
cannot be confusing, depending on which other languages you are accustomed to.
So I would say it is a debatable point.

The third point, the language being failure-adverse, is a choice made by
design, this is also a debatable point, but it's in line with the fact that
PHP was created as a utilitarian language as Lerdorf explained numerous times,
e.g. here
[https://www.youtube.com/watch?v=anr7DQnMMs0](https://www.youtube.com/watch?v=anr7DQnMMs0)

The last point, inconsistencies in the standard library, is obviously true but
I would say it is very common in languages that have been around long enough
to have subsequent approaches layered in the standard library. Some languages
resolve this by making breaking changes and keeping consistency (think Python
2 vs Python 3), some others just show their age by having libraries that were
developed at different point in time (Perl, R and Java come to mind), this is
also explained by Lerdorf in the video linked above.

------
leovonl
The biggest issues I see with the language didn't made into this list: for
instance, I can think about more serious issues like accessing the wrong
variable name does not returning an error, assignment and initialization being
the same (thus also suffering the same issues related to wrong names), various
surprising type conversions, defaults, and so on. I guess it all boils down to
the mindset of the language itself, as the article says.

However, I disagree that "other languages do not work like that thus are not
as easy to test". You can implement this in any way you like in any other
language. You can implement your webserver by forking a new process at every
call. You can even use a worker that communicates to a different hot-swappable
process. It can efficient as you want - copying the whole data around, sending
file descriptors, etc. The alternatives are endless.

PHP may be "interpreted and hot-swappable" by default, but that's an accident
from it's design and it _only_ works like that - if you try to use it as a
long-running process, you'll run into a lot of issues. It's also terribly
inefficient - have you ever developed a web interface for an embedded
platform? A really embedded one, like 32MB of memory, shared with the
application itself?

I guess in the end it boils down to the duct tape analogy: it's terribly fast
to prototype something with duct tape and scraps and you can join a multitude
of materials in a very simple way - just put everything in place and cover
with enough tape to hold it together.

Surely, it works.. but that's about it.

------
dendory
I don't consider myself a programmer, just someone working in IT that writes a
lot of code, and to this day when I want to write any type of web page or web
based "app" PHP is my goto tool. I can write my HTML and add PHP logic
directly inline whenever I need it, and get the job done in no time. Sure I
could spin up a node.js framework, use routing, create classes and objects,
etc.. But to 99% of my needs it's just not worth the extra time.

------
bpicolo
Really, the worst part of PHP in my experience has been the debugging
facilities. Print-line debugging just doesn't cut it anymore, and things like
xdebug and phpdbg just aren't elegant, are hard to configure properly, and
don't work for all the relevant scenarios (trying to debug PHP running in a
docker container is not a fun task).

The quality of open-source libraries in the ecosystem is also pretty below
what I've come to expect from other languages, and then half of them are
c-lang PHP hybrids that are more difficult to manage, update, and install.

I think the author failed to mention the downsides of no long-running
processes either. Shelling out to e.g. memcached for configuration setup
(especially when memcached might not live locally) isn't particularly fun. Not
to mention this has made it difficult to integrate into some useful things,
like GRPC[[http://www.grpc.io/](http://www.grpc.io/)] which can't use PHP as a
server as of yet.

Then there are all sorts of random deployment gotchas, like proper opcache
configuration.

PHP is a pretty wart-filled language. It's usable, but I wouldn't make it my
first choice in any situation, given a choice.

~~~
skippyta
PHP has xdebug. You can debug interactively using an IDE like IntelliJ /
PHPStorm or whatever floats your boat. Is that not enough?

Edit: I commented on this post before the OP edited the original with a longer
form explanation. Originally it just said he didn't like the debugging and
left it at that.

~~~
bpicolo
I mentioned that in my post. Needing a full-fledged IDE for some baseline
debugging isn't what I look for. And, like I said, doesn't "just work" in all
scenarios.

Plus, you can't do inline code execution (the interactive part) if you are
using xdebug for PHPUnit tests (even in PHPstorm). It's a really flawed
experience, where getting it to half-work is a frequently frustrating
experience.

Even the baseline REPL is flawed. PHP went again and forgot the P, so you have
to figure out the correct-of-many-variant print statements and remember to put
it before the code you want to run when using the 'REPL'

~~~
securingsincity
You should definitely try vscode. I've found it to be the easiest to set up
step debugger for PHP and it's not a heavy ide like intellij

~~~
bpicolo
Step by step with the ability to execute arbitrary expressions in the middle
of it? That's the important bit. What VSCode extensions are useful here?

~~~
kowdermeister
Official docs are a good starting point:

[https://code.visualstudio.com/Docs/languages/php#customizati...](https://code.visualstudio.com/Docs/languages/php#customization-
articles)

------
boulos
I also liked Keith's previous version of this, given at Strangeloop a few
years ago [0] and discussed here [1]

[0] [https://www.infoq.com/presentations/php-
history](https://www.infoq.com/presentations/php-history) [1]
[https://news.ycombinator.com/item?id=7054294](https://news.ycombinator.com/item?id=7054294)

------
sigi45
Wrote Java code for few years and was writing php code the last 2,8 years.

While it doesn't matter that much at the end of the day, php is slow compared
to java. A language which has so much hidden potential performance (from 5.6
to 7) can't be that good.

Also a lot of stuff i was used to in java is now also how php developer write
code but with a language which doesn't support it properly. Annotations for
example.

The worst thing was the type annotations in comments. Why do you write type
annotations in your php comments? Because otherwise your ide can't protect you
from those errors. and it doesn't provide you with proper code completion.

When you use tomcat and basic servlets or spring, you can write code quick and
easy without any problems. Not sure why you wanna would use php.

Tooling is much better (IDE support, Profiler support) and Debugging is much
better (simple to connect, can drop frames) and yes java has hot code
replacement.

I can change the code while i'm debugging it and than drop the frame and test
it again without reloading anything.

And at the end of the day you do know a language which you can use for
android, server, games, desktop clients and it is cross platform out of the
box.

------
otto_ortega
What I find interesting about all this debates about programming languages is
that most of the time people fail to remember that they are just that
"languages"... Each one has its strong points and flawns, at the end of the
day what truly matters is how competent you are at expresing on them and
carrying out your goals.

For decades people have been complaining about Php, and how afwul it is, yet
still, for decades successful projects have raised (and still do) having Php
as its core, just today there 2 posts on the front-page about big companies
(Slack, Dailymotion) talking about their Php codebase...

The argument that due the huge volume of programmers using it, it is "bound
to" return a few success cases here and there is BS... if that were true we
would be flooded about news about how X and Y company succeed "thanks to"
using Python, Java or whatever language you deem as "superior", but that
doesn't happen... because companies don't suceed "in spite of" Php, they
suceed "with" Php, in the same way companies don't suceed "thanks to" X or Y
language but "with" them.

When people set to built a piece of sotware they don't have in mind "I wan't
to build the most technically perfect code base" or "I want to build the
fastest piece of software" because nobody writes software for the sake of it,
everyone has a goal... they want to build "a messaging app for teams" or a
"video-sharing website" and the best programming language for that, is
whichever enables them to do so on the way they need it, with the resources
they have, and within the timeframe they set.

And rant as much as you wish, but Php remains king about doing exactly that
"enabling people".

------
ww520
I've looked at some of the new PHP feature and was quite impressed. There are
trait, multi-value return, pattern matching, and destructure.

------
ohthehugemanate
Most of the hate for PHP comes from the PHP4 days, when it really was a wild
west, fast and dirty kind of language. And of course, wordpress has done a lot
of reputational damage as the world's most popular plate of spaghetti code.

But look at the way modern php developers work, in PHP7 with frameworks like
Laravel, Symfony, and even Drupal 8. Modern PHP is a pleasure to work with.

------
LyalinDotCom
Many amazing products have been built with PHP, Python, .NET, Node.js, etc.
etc.

The reality is these (above) and many other good languages/frameworks exist
out there for building web apps today. we live in the time with a ton of
choice, and the rest is in our hands.

I for one love the new .NET Core, but I am a little biased being a long-time
.NET developer and a Microsoft employee as of late.

------
Cymen
A lot of projects do a rewrite from PHP to Ruby on Rails or some equivalent
migration. What the project really needs is a rewrite/refactor/cleanup however
it's much easier to frame that in the context of going to a "better" choice
than it is explaining it just needs a rewrite with better practices/engineers
(ie maybe more and easier tests or using the prior prior/current architectural
lessons to create a better architecture). The reality is one could just
rewrite it in the original language/stack but that is apparently harder to
sell even though it's less risky.

So if the first language/stack is less respected, it makes it easier to sell
that rewrite to non-technical/management. Thus PHP is a great choice for the
first stack.

The one huge trap here is if the second team isn't experienced enough in the
holy grail (next) stack. I've seen that and been relieved to walk away from
those projects/companies.

------
greggman
I didn't understand some of the mentioned benefits of PHP.

Progressively adding types:

This isn't PHP it's hack. How is this different than typescript or flow?

Edit/refresh vs edit/restart server.

It seems like it's been several years that there have been things like meteor
or webpack that make iteration super fast on JavaScript. Is that iteration
slower than PHP?

------
sparrish
The author incorrectly states PHP stands for "Personal Home Page". It changed
in 1997 with the release of 3.0 when the project changed from being called
"PHP/FI" to just "PHP", a recursive acronym - "PHP: Hypertext Preprocessor".

------
jkaptur
> Hack provides an option that no other popular member of the MPDPL family
> has: the ability to introduce a type system after initial development, and
> only in the parts of the system where the value exceeds the cost.

JavaScript and Python both have systems that allow you to do this: JavaScript
has the Google Closure Compiler, and, more recently, TypeScript. Python has a
number of projects that use a common syntax [1], including PyChecker.

I say this not to "well, actually" the post, but just to be a gradual typing
cheerleader. It's great! We should all be using it! All the time! Please!

[1]
[https://www.python.org/dev/peps/pep-0484/](https://www.python.org/dev/peps/pep-0484/).

------
hawkice
The shared-nothing model works great... if either you're just one developer or
you've got a semi-competent Ops/DevOps setup. My first job out of college used
PHP with one of the Rails-a-likes PHP has. During our user onboarding process,
we'd poll the server to see if a data import finished, but since the requests
shared _nothing_ and the Ops guy didn't understand PHP, it would load/run
millions of lines of framework code for every single tiny polling request. On
launch our site crashed because two people used it at the same time. Bananas.

There's a way to make Apache fork after some code has already been run, but
boy howdy if you don't do that and love those mega-frameworks.

~~~
throwanem
That doesn't sound like an ops problem.

------
philippz
We are using PHP7 at stomt. We decided to use PHP for several reasons.

\- First of, it is the language i have the most experience with. It would have
been stupid to start with some new fancy stuff that would postpone our MVP or
getting market/idea/product validation.

Apart from that...

\- PHP allows you to write good code, it just does not force you to do it.
Means if i need to prototype something really fast i can do so. At stomt we
are really focused on writing SOLID code.

\- PHP evolves great and became really fast in the last years.

\- Economically it is cheaper to find PHP developers than developers in most
other languages. And if you have a nice and clean software architecture in
place, it is easy to also get more unexperienced developers to write good
code.

------
icedchai
I do Java and python for my day job, but do quite a bit of PHP on the side
(small consulting projects, etc.)

The main advantages of PHP are ease of deployment (no build required, just
upload your files and go, use a shared web hosting or a cheap VPS) and a fast
dev cycle (edit/refresh the page.) It's also simple to work with for web
designers who don't have a lot of back-end knowledge. They can edit your
templates and see results instantly.

For anything with complex business logic, background processing, etc. it's
absolutely the wrong choice. However, for basic web apps, when combined with a
good framework (such as Laravel), it is fast and productive.

------
OhHeyItsE
Much of this is valid in spirit. But to me, is irrelevant with the advent of
Node. Node does all the good things the author describes. It does some
terrible things too, but generally does them much less terribly than PHP.

~~~
tracker1
I think one of the things that made node great, is standardizing on CommonJS
modules, and error-first callbacks... That alone makes it much easier to build
everything else on top of. JS does have some "bad parts" but they're easy
enough to avoid via linting/testing.

NPM is another great/horrible thing in JS... people get hung up on the size of
some packages, it's worth noting that a lot of that size doesn't go into your
application, mainly because those packaging don't always know enough to
exclude their samples, tests and documentation from the module as packaged in
npm. Which is a mixed blessing.

You do get a lot of file bloat as it's not pre-build/bundled in npm (usually),
and as such there is a lot of file-system access at startup (SSD strongly
encouraged).

Through all its' warts, I'd still take it over almost everything else I've
ever worked with.

------
phreack
Well this is seriously making me rethink my opinion on the PHP workflow, if
Hack is as much of a game changer as the article claims? Could anyone here
comment on their experiences with it, and its pitfalls?

~~~
kmavm
You're asking about Hack, and the only response I see so far is about HHVM.
So!

I've seen Hack used in a multi-tens-of-MLOC codebase to gradually insert
types. It made huge differences in the kinds of changes that were possible;
you can, e.g., rename a class or method, or change the order of its arguments,
with confidence comparable to that in a C++ codebase. Most developers hack-
ified everything they could get their hands on, and did all new work in Hack,
without any external encouragement.

~~~
biesnecker
Yup, this. I work on (the original?) multi-tens-of-MLOC PHP-cum-Hack codebase,
and writing new code is every bit as safe type-wise as C++, with none of the
compile time. It's pretty great.

Dealing with the parts that aren't Hackified, though, is horrific. Complex
codebases with no types are just ridiculous.

------
lol768
Does anyone know how the types in PHP7 compare to what's offered by Hack?

It looks like generics aren't yet in the core language
([https://wiki.php.net/rfc/generics](https://wiki.php.net/rfc/generics)), but
I believe return type hints work. I think we're also still missing
property/field type hints
([https://wiki.php.net/rfc/property_type_hints](https://wiki.php.net/rfc/property_type_hints)).

~~~
TazeTSchnitzel
PHP 7's type declarations are enforced at runtime, rather than Hack's compile-
time types.

This has its pros and cons. This means these declarations are _always_
enforced, even when calling between typed and untyped code. However, there's
no compiler to catch you out, at least not just from using the interpreter.
Your IDE, or an external type checker (e.g. Phan) can check them for you,
though.

PHP 7 also gives you a choice between weak and strict type coercion modes,
whereas Hack lets you choose between enforced type declarations and unenforced
type declarations.

As for the specific things you can type in PHP 7.0, there's parameter and
return type declarations for `int`, `float`, `string`, `bool`, `array`, any
class or method, and `callable` (a function name, method reference or
closure). PHP 7.1 brings nullable types (prefix any type name with `?`),
`iterable` (an array or an object implementing `Traversable`) and the `void`
return type (enforces that a function doesn't use `return` with a value).

Notable omissions are generics (even for arrays), and property types. There
was a proposal for the latter, but it was rejected, for better or worse. As
bkanber mentions, however, IDEs can still check property types if they're
annotated using docblocks. Hack also has a few extra special types that PHP
lacks.

------
jwmoz
Having come from years of PHP development and then into Python the past year
or two, there's no way I'm going back to PHP. This is the same as every other
ex PHP dev I know.

------
gravypod
Every programming language is a tool. As such it isn't good if used for the
wrong job. PHP is amazing for simple services that don't need much aside from
database/filesystem access. I love PDO and wish more languages had such a
first-class database access implementation.

I wish more people gave PHP a chance and didn't just keep bagging on it. There
are problems with the standard libs, but nothing that isn't bearable. Grab an
IDE and it's not an issue.

------
mi100hael
> Hack provides an option that no other popular member of the MPDPL family
> has: the ability to introduce a type system after initial development, and
> only in the parts of the system where the value exceeds the cost.

Python now has type hints that allow a similar migration for existing code.

[https://docs.python.org/3/library/typing.html](https://docs.python.org/3/library/typing.html)

------
Tehnix
>Asynchronously curl’ing to localhost (or even another web server) provides a
shared-nothing, copy-in/copy-out way of exploiting parallelism

Wait, wait, wait, wait. Is he saying that to do async work he'll send a curl
request to somewhere (spawning a thread for that request), not wait on the
output and carry on? Last I used curl in php it was a synchronous action. Hell
of a threading model there.

~~~
Zachery
You can do some decidedly hacky stuff with PHP if you are smart about it. To
get background tasks to run in a popular forum software, the system would send
an ajax request to the cron script. The cron script would return a 1x1 clear
gif and "close" the connection. The script would then be run in "in the
background". It would be easy to do the same thing there. curl another script
and have it instantly return nothing while it continues to process.

------
yahyaheee
This is nonsense. As someone who has had to work in PHP environments that were
a mess, just write Python or Go they are worlds better

~~~
dokeke2
as someone who has been in the industry for over a decade:

when i hear people say stuff like this, I assume they are a rookie dev. Have
passed on many interview candidates for it.

~~~
yahyaheee
As someone who has been in the industry for 6 years, I'm certainly not a
rookie dev. I have simply witnessed the horrors of PHP. I don't know who in
their right mind would pick PHP over Python or Go. For high volume API work
you simply can't beat Go nowadays. It's fast to write, stable as hell, and the
TechEmpower benchmarks make it obvious how performant it is. Python has the
added bonus of all the Data Science/ML libraries with it, which seems to be
the way the world is turning nowadays. Not to mention that Flask with Meinheld
workers also does very well performance wise.

To me you sound like a guy who has spent most of the last decade writing PHP.
I've know a couple devs who used to defend PHP vigorously, mainly because
thats what they knew best. Now they all write Go and haven't looked back. PHP
is a story of right place right time, thats all there is too it.

------
anindha
Doesn't Slack use Java for its messaging system?

That's not mentioned in the blog why they didn't use PHP for this.

~~~
bkanber
PHP is great for HTTP requests. It's not that good for listening on sockets,
running an event loop, etc, which is what you're likely going to do with real
time messaging.

~~~
astrodust
This really depends on your definition of "great".

~~~
bkanber
Who does it better?

~~~
aikah
Unless you are using ReactPHP, PHP doesn't handle Http requests in any serious
production configuration, the server fronting PHP does( Apache ,Nginx). But
PHP wasn't design with Async programming in mind so using ReactPHP is more
than tricky since most operations are blocking.

~~~
bkanber
That wasn't my point. PHP is great at HTTP because it doesn't have to do HTTP,
and with php-fpm and mod_php it has first class support with Apache and Nginx.
Node isn't very good at HTTP, Python doesn't have first class support with
HTTP servers, Java has great HTTP libraries but is stateful, etc.

If you want to handle HTTP requests quickly, reliably, repeatably, with
minimal setup and maintenance, I still argue that PHP is one of the best. And
yes, because of Apache and Nginx, but that doesn't nullify the point.

~~~
astrodust
"Node isn't very good at HTTP" is just blatantly false.

Most languages don't "have to do HTTP" and those that do often do a pretty
terrible job. Somehow Node not only does it, but does it well, where a bare
Node process behind some load balancers is often enough to get the job done.
PHP on the other hand needs all sorts of hand-holding to work properly.

~~~
bkanber
Node is stateful and not threaded, but yes you're right that it serves http
out of the box. Http was a module in the early days but I see now it's core
API and has been for a while. My mistake.

~~~
astrodust
Node isn't a pure functional language, and neither is PHP. I'm not sure what
you mean by "stateful" otherwise.

JavaScript _does_ have threading facilities like WebWorkers, but they're often
largely overlooked since the code complexity that comes with it isn't worth it
and the multi-process model generally works fine. A single Node process can do
a lot of work because of the aggressively asynchronous approach to processing
it takes.

Node + Express is actually a pretty slick package.

~~~
fiedzia
WebWorkers have nothing to do with threading. They will not let you share
memory, and this means that you waste time on seriazlizing/deserializing
anything you pass to them, so from optimization point of view, they are more
like processes. This makes js completely unsuitable for things that are data-
heavy and cpu-bound (just cpu-bound may work, but it still not the best
choice).

~~~
astrodust
They do have a lot to do with concurrency, which is often what threads are
used for. They do have limitations to fit in with the JavaScript model.

JavaScript is generally a lot better at compute intensive tasks than
contemporaries like Ruby, Python, PHP and Perl due to the incredible
performance of the V8 engine and others like it. The language is ugly, but
it's more easily optimized by the JIT compiler.

If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but
few languages are, and none of those are frequently used for general-purpose
web development.

~~~
fiedzia
> If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but
> few languages are, and none of those are frequently used for general-purpose
> web development.

Java and Go work just fine here and both are used for webdevelopment.

My point is that js in not suitable for many cpu-bound operations and neither
webworkers nor multiple processes are enough to help it with that. In the
browser you don't have other option, but on the server you can (and in
practice people do) use other languages like java or go (not to mention
C/C++). This is were things like image processing or full-text search goes.

------
FranOntanaya
One of the things to appreciate about PHP's ecosystem is how much you can be
exposed to warnings, criticisms and cautionary tales. There's so much energy
put into tearing it apart that if you aren't getting an education about coding
pitfalls it's really your own fault.

------
3chelon
Freaky coincidence. Today I just happened to __twice __edit some PHP, for two
separate tasks... but it 's the first time I've touched PHP for about 10
years!

What goes around comes around. I'm editing my LinkedIn and dusting off the old
O'Reillys...

------
shafiul
Language matters too less, What matters is how it is being used. A Java
project may be meanly architected, while PHP code may be architected with good
quality. Its is the quality of architecture and code what makes projects
sustainable(i.e technically).

------
marcosdumay
Sorry, but I'd rather take opinions on web environments from somebody that at
least knows that nearly all web frameworks, on any language that you choose
have those properties of no shared state, independently parallel request based
execution.

------
OOPMan
Ahhhhh, PHP.

Never again.

Life's too short to waste on that junk.

------
scurvy
Opcache still crashes and burns under high concurrency in 5.6 and 7. No
thanks. It's been an issue for 2 years now and still not fixed.

Running a 2 year old framework on the Internet because the new versions
include a non functional opcode cache kinda sucks.

------
bluetwo
I just want to use whatever tools we will be using in 5 years. While the
underlying technologies of css, html, and javascript have gotten cleaner,
powerful, and more cross-compatible, everything that sits on top seems to have
gotten bloated.

------
teilo
I would add one other big negative in the language design: The automatic
import of the entire SPL.

Back when I was a green web programmer, I loved this feature. After working
with Python for a good many years, I now abhor it.

------
bostonvaulter2
I agree with the overall sentiments of the article but I don't know if I agree
with the conclusions. One thing I don't see mentioned is the lack and overall
lower quality of many php libraries.

------
ohstopitu
Taking from the article..

> I claim that PHP’s simpler “think; edit; reload the page” cycle makes
> developers more productive.

Would you not use file watchers to reload the server? (especially in Node?)

------
jonthepirate
PHP engineer of 10 years here - all things being equal, I cannot, in good
faith, recommend a person use PHP for anything. General rule of thumb is, if
you can, use Python. We still see folks actively choosing it though.. mostly
because it's a language we already know and better to create an MVP in
something folks know rather than struggle with something "better" that will
take a person 5x longer to write while they learn it.

I would bet a donut that Slack is off PHP within 2 years.

------
marcusbrown
What I think most people are missing about PHP is the incredible ecosystem
that emerged in the recent years (especially with Laravel) that helped to
speed up the development of web apps by A LOT and removed all the annoying
boilerplate.

I know that nowadays there are a lot of fancier languages to write your next
project, but I challenge anyone to find anyone that has a similar ecosystem
that can do all the following things with just a matter of editing config
files basically.

\- Create a fully working app with authentication, database migrations,
security checks, middlewares, route management, and much more with just one
command line ("laravel new project_name") (Laravel)

\- Logging in a user with an external service with one line of code. (Laravel
Socialite)

\- Sending real time notification with any type of channel. (email, socketio,
sms, ios/android, ...) (Laravel Echo)

\- Create a complete Oauth2 server with all the backend and frontend parts
with just one configuration file. (Laravel Passport)

\- Make text search with Elasticsearch using external services as easy as
making a normal query to the local DB. (Laravel Scout)

\- Super easy tu use payment system integration that handles both one time
payments and subscriptions with Stipe and Braintree. (Laravel Cashier)

\- Optimized and lightweight version of the full framework to get blazing fast
APIs. (Laravel Lumen)

\- Local web server that automatically creates .dev domains for each project
and that works with most PHP projects (not just Laravel) (Laravel Valet)

\- Vagrant box with everything you need for a local development web server.
(Laravel Homestead)

\- Easy frontend assets management (compiling, versioning, ...) built on top
of Gulp and Webpack. (Laravel Elixir)

\- Provision a web server with all the things you need (security, git push-to-
deploy, ssl certificates, queue workers, ...) properly set up with one simple
click. (Laravel Forge^)

\- Zero downtime deployment with history backup and much more. (Laravel
Envoyer^)

\- Fully working SaaS app that handles all the boring stuff (subscriptions,
invoicing, team management, emails, ...) and let you concentrate on the
actually product you want to built. (Laravel Spark^)

\- Tons of video tutorials/screencasts/lessons on how to use every aspect of
Laravel and much more (PHP, Vuejs, Text editors, ...) (Laracasts)

As you can see from the list, almost everything is related to the incredibly
good framework Laravel, that I highly recommend to anyone that is working or
will work with PHP.

I especially recommend to all those people that are about to create their next
SaaS project to take a look at Laravel Spark. It really puts all the pieces of
the puzzle together and it makes your MVP really around the corner instead of
months away.

Coming from old-school PHP where I hacked everything together, after learning
and switching to Laravel my life as a developer completely changed and now I
can't imagine that I'm still using the same language actually. They feel like
two completely different things and in my opinion all those people that are
talking bad about PHP, they are stuck with old memories of how PHP used to be.
Yes, PHP as a language still has a lot of things that needs improving, but PHP
as ecosystem of libraries and frameworks is definitely still the king of the
web!

The King is dead, long live the King! :)

[^]: These are commercial products but their price is definitely accessible
(99$ for Spark and 10$/month for Forge and Envoyer)

~~~
oridecon
You mentioned Laravel 20 times. You might want to slow down on that kool-aid.
And I know you're not affiliated with them because I see this behavior all
around the place, especially with unseasoned developers.

> What I think most people are missing about PHP is the incredible ecosystem
> that emerged in the recent years (especially with Laravel)

I would replace that last bit with: "especially with Symfony and Laravel". And
composer, and all the changes made in 7.x, and lots of libraries that people
build on top of it and made all of this it possible.

This is a good talk (Symfony's "creator") about the PHP ecosystem:

dotScale 2014 - Fabien Potencier - My Take on PHP
[https://www.youtube.com/watch?v=gpNbmEnRLBU](https://www.youtube.com/watch?v=gpNbmEnRLBU)

------
mrmagooey
I'm surprised no one has posted this fairly thorough criticism of PHP from a
few years ago [https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-
design/](https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/)

~~~
labrador
There was a time I thought Toyotas were beautiful cars and American cars were
crap. Then some years later I had two occasions to rent a car. The first time
I got a Toyota. Absolute crap. The transmission couldn't stay in the same gear
with even slight inclines. The next time I rented a Chevy Malibu. An absolute
dream. Loved that car. I learned a lesson to not let my prejudices prevent me
from taking another look.

~~~
tensor
A sample of two very short term rentals is an awful way to judge cars on long
term traits like reliability.

------
EGreg
PHP would have been better if it supported evented programming.

~~~
captn3m0
Would this count: [http://kraken-php.com/](http://kraken-php.com/)

~~~
EGreg
Why is this 404: [http://kraken-php.com/faqs](http://kraken-php.com/faqs)

------
george_ciobanu
Great projects exist in every language from COBOL to Lisp.

------
yegortimoshenko
Totally. PHP is a great technology and a bad language.

------
known
Where does PHP stand in mobile platforms?

------
justinlardinois
PHP was the first programming language I ever used, so it holds a special
place in my heart. And I use it daily at my current job.

I have to disagree with this article. PHP is a heavily flawed language. It's
very easy to get started with PHP, but there are too many pitfalls that are
too easy to fall into.

Most of the "Virtues of PHP" are available in other web languages if you use
the right framework. And if you use those languages you'll benefit from the
consistency and predictability that come from having a clear design philosophy
from the start.

I don't think PHP is a _bad_ language. It's possible to write good software in
PHP, and it's possible to work around the flaws if you really know what you're
doing. If your software is already written in PHP, it's probably not worth it
to throw it out and rebuild it in something else. But I don't think it's worth
the trouble if you have a choice, and I think writing new software in PHP
should be avoided.

I'll admit I'm not familiar with HHVM and Hack. Maybe they alleviate PHP's
problems.

P.S. Most of the points under "The Case Against PHP" are also issues with
Javascript. But the difference is that if you're developing a web application,
you have to use Javascript. _You don 't have to use PHP._

~~~
rrdharan
Zero startup time and a serious JIT aren't actually available in Python or
Ruby even after all these years.

I would be hesitant to dismiss the significance of those - although I'm
admittedly biased, having worked with Keith previously as well as on an
erstwhile "competitor" to HHVM (talariatech.com).

~~~
orf
> Zero startup time

My pretty heavy Django app takes about half a second for Gunicorn to boot 6
workers then it's off to the races. That might as well be zero startup time.

~~~
tracker1
Similarly many of the node apps I've worked with have about a half second or
less of startup (unless pre-warming database connections, that takes more
time).

