PHP Programming (was JOB: LAMP Artisan)

Levi Pearson levipearson at
Thu Mar 6 16:40:26 MST 2014

On Thu, Mar 6, 2014 at 3:27 PM, Joshua Marsh <joshua at> wrote:

> I guess I'm just not ready to totally discount PHP yet. I still think there
> are perfectly suitable reasons to use PHP from a business, practical, and
> language stand point. I work for a large company and while most of the
> engineers are Java or .NET, PHP is relatively common. There wouldn't be an
> issue getting a new PHP project approved. If I said Erlang, they'd probably
> presume I had tourettes.

The decisions of business executives are necessarily made via some
sort of proxy for actual understanding of the technical details;  this
is very understandable, as they have to make a lot of decisions and
can't be experts on all of them.  This does, however, bias their
decisions towards whatever everyone else (at least among their
successful-looking peers) seems to be doing.  This has a powerful
reinforcement effect for the status-quo; unfortunately, the status-quo
in the field of software engineering is full of large-scale failures.
When even the software engineers themselves just accept this as "the
way it is" and make no serious attempts to find real solutions, you
know there's something wrong.

> One could argue ad nauseam about the faults of PHP. I bet I could do that
> for just about any language though, even the ones I don't know. A couple
> Google searches would probably bring up rants similar to the one about PHP.

A sufficiently motivated person could fill up as much textual real
estate as you'd like on the flaws of the most perfect thing you can
imagine.  The question is, what criteria should we use to judge
software tools, and furthermore how do the tools that are in use stack
up to the criteria?

I've no doubt that the flaws of PHP could all be ferreted out and
fixed, and Facebook seems intent on doing so.  The end product will be
a reasonable language, but how long will it take to gradually
deprecate all the misfeatures and irregularities and broken-by-design
"features"?  The gradual process lets legacy code come along for the
ride, but at great expense.  The end product will still bear the name
PHP, but it will not be particularly different from other languages
that are already at the maturity point that PHP will arrive at in,
say, 10 years.

> You may not like PHP, and that's OK (I don't generally like to use it
> either). It may ruffle some feathers if you touted it at a SIGPLAN
> conference. The fact of the matter is that these people are in the
> minority. PHP has a following for a reason. There are dozens of languages
> that failed because of its faults and PHP isn't one of them. In my
> experience with it, I'm guessing it's because its faults aren't any more
> abundant or worse than that of other languages that share the limelight
> today.

It's entirely possible for majorities of people to be dead wrong about
things, especially when it comes to technical merits.  I mean, Windows
is a lot further along the path to reform than PHP is right now, but
10 years ago would any of you have believed an argument that Windows
was superior to all alternatives simply because a lot of people were
using it?  That its faults were no more abundant or worse than those
of any other OS that people had heard of?  In fact, success or failure
of programming languages has a lot less to do with technical merit and
a lot more to do with social forces.  It's driven by a pop culture,
not a scientific/engineering culture.  Now, I don't think the social
forces work the way they do for random or arbitrary reasons; there are
other things of value besides technical merit.  But people are often
confused about the real reasons for technology adoption, and jump to
false conclusions about the suitability of things for various

Anyway, it's a difficult problem, but we don't do anyone any favors by
shrugging and accepting the status quo, or by failing to really
analyze the problems we have and how they should really be solved,
rather than just accepting that "what everyone is doing" is really the
way things should be done.


More information about the PLUG mailing list