PHP Programming (was JOB: LAMP Artisan)

Joshua Marsh joshua at
Thu Mar 6 20:29:52 MST 2014

On Thu, Mar 6, 2014 at 7:38 PM, Levi Pearson <levipearson at> wrote:

> I think that by grouping "zealots" and "academics" together, you show
> that you don't appreciate the connection between the reality of
> programming and its foundations in academia.  It's a really bizarre
> phenomenon, and I see it much more in my programming-trained
> colleagues than in my EE-trained colleagues.
Academics was a generalization, but they tend to be the only other people
with critical analyses of progamming languages other than "I HATE IT!" I
actually consider myself an academic; I'm substantially more studied than
most of my peers and have the stockpile of journals and articles to prove
it. The problem that I've seen firsthand from multiple other academics is
that they forget to balance what they learned with getting the job done. I
know this will sound anecdotal, but I promise it's not the only experience
like this. After 3 months on a relatively simple project, one of my
academic peers produced a 300+ page document on his design for the
architecture of the program. I was able to design, program and document the
program in just 2 months. My program didn't have the level of abstraction
or orthogonality that his might have, but it turns out that those things
weren't needed because the program hasn't changed since.

I'm not saying that academics can't be hard workers and do wonderful
things. I do see their role in this world of technology that I love. I've
just seen enough of them in the real world that I tend to generalize.
Perhaps you've seen fewer of these people, or I just have a bad sample set.
Being critical of PHP's syntax or approach to a standard library often
isn't a substantial motivator to using a language in the real world. It's
important in academia because it progresses our understanding of languages
and computers. Their critical eye will produce better languages in the long
run, but won't do much to win over people who need a language now that has
been vetted and the tools are available to mitigate the risk factors
associated with it.

> I am not talking about "new and sparkly".  The "new and sparkly" stuff
> is often just rehashed "old and broken" stuff without a lot of real
> benefit, and it pays to look deeply into things before adopting them.
> Trendiness is no better than clinging to old, broken ways.  But there
> are plenty of old, good and proven ideas that we are completely
> failing to take advantage of.  And there are all sorts of old ideas
> that were simply impractical before now.  They mostly *aren't* new and
> sparkly, which is why the trend-hoppers never quite seem to get them,
> and continue flitting about on the whims of fancy.
I'm surprised you didn't put in a plug for Haskell here. :)

> What astounds me is that people say stuff like, "we know all the
> risks, we don't make make mistakes and do stupid things like those
> other people" and continue to use their old broken tools that they
> know are put together by sub-standard engineering.  Witness the
> unceasing security flaws that are uncovered in critical packages on a
> regular basis.  Clearly, the remedies are not well-defined enough!  Or
> all these macho programmers are not actually following the disciplines
> required to use thier unsafe tools safely.

You seem to have some language up your sleeve that none of us have? What
all-mighty web framework are you using that is without flaw and has no
security patches? This is common in all languages. This is common to all
new-comers in the field. These mistakes can even be caused by the smartest
of us. All the Erlang people are eating crow right now with the Whatsapp
hack. To suggest that one language is inherently more secure seems a bit
short-sighted. There will always be dumb programs or smart hacker or in
very unfortunate circumstances both.

> I hate to break it to you, but programming is *hard*, and human beings
> are *really bad* at it.  You are too, and so am I.  We need all the
> help we can get from good tools, because we suck at gettign all the
> details right all the time.  We get lazy or tired or just plain
> unlucky, and errors skip past our notice.  Now, I have no idea what
> you do, or what sort of risk analysis you do at your job.  Maybe it's
> perfectly sound analysis, and your PHP code is always flawless (aside
> from the flaws baked into the PHP interpreter itself, of course) and
> you're really deriving some benefit from PHP that you wouldn't get
> from some better tool. There are definitely reasons to use poor tools,
> regrettable though it is.  But there are no good reasons to call poor
> tools anything other than poor tools, or to be apologetic about their
> flaws.  You don't have to like your tools to use them well; in fact,
> you will probably use them better if you don't convince yourself you
> like them. :P
You say poor tool, I say tomato. That works better spoken than written. :)
I think the tools are there for PHP and they are good ones. Where the
language suffers, additional tools and frameworks have been made to
compensate. The same can't be said for other more obscure languages and web
technologies. Again, I don't really use PHP nowadays, but it's one of the
few that major source code analyzers support besides Java and .Net. These
do a great job of finding issues (especially junior level issues) that
front-end penetration tests or black box tool can't. Since we are so bad at
programming, it's nice to have tools that tell you where you were bad and
PHP has those tools. I can't say that our PHP applications are 100% secure.
I am confident though that they are at least as secure as the other
applications I've written in languages that you would probably consider

More information about the PLUG mailing list