PHP Programming (was JOB: LAMP Artisan)

Levi Pearson levipearson at gmail.com
Thu Mar 6 11:37:50 MST 2014


On Wed, Mar 5, 2014 at 9:56 PM, Joshua Marsh <joshua at themarshians.com> wrote:
> On Mar 5, 2014 7:26 PM, "Levi Pearson" <levipearson at gmail.com> wrote:
>> Every language has some of these "misfeatures".  PHP has far more than
> its share of them.
>
> It's hard to argue this point but I think people don't give PHP enough
> credit. It's first incantation was just a couple of years after Mosaic was
> released. Many of the web friendly languages today have PHP to thank for
> paving the way (and highlighting the pot holes).
>
> Rasmus said himself while he was here that he was never a language expert,
> he received his baptism by fire. He just had an idea to simplify web
> development and the popularity of PHP at the time suggests that everyone
> agreed despite its shortcomings.
>
> Would I suggest PHP for a new project? Not likely. Trying to compare PHP to
> modern languages is like trying to compare COBOL to Go. They were born in
> different eras to serve different purposes. It's hard for me to bag on
> COBOL because of what it did for its time and the fact that it's still in
> use today for niche purposes. I could have just as easily written a similar
> rant as the blog post on the subject though.

My issue is that we tend to get emotionally attached to technologies
like PHP that we had success with in the past. I used PHP as a
template language for a simple home page back in the day when that's
generally what it was used for.  No databases or e-commerce, just
creating a consistent header/footer and menus for a site.  It was a
wonderful tool for that, and the way it integrated with apache made it
extremely easy to set up and maintain a personal home page.  Go
figure!

Just because a tool makes simple things really easy and accessible
doesn't mean that it's an appropriate tool for more complex jobs.  It
doesn't even mean that you ought to *extend* the simple tool to handle
the more complex jobs. That's hard to do unless you are already an
expert in both the domain *and* in the design of the kind of tool
you're making.  While nobody was really an expert in web programming
in the early days, programming languages were an established field at
that point with a large number of experts, who were clearly not
consulted on the matter.

So, I don't even care that much about PHP.  My pet language to hate is
C.  It was a pretty reasonable language for its day and in the context
in which it was developed, just like PHP in its early days.  It
completely took over systems programming, just like PHP took over web
programming, and for much of the same reasons.  DEC used to have a
very nice language for systems programming called BLISS.  Macs used to
have their low-level code programmed in a systems version of Pascal.
But UNIX swept the universities due to its openness and it was
implemented in C, so C is what everyone learned to do systems
programming in school, and they just assumed it was the best way to do
things because it's what they knew.

People use C not because of its static types (it's got a very poor,
weak type system by today's standards) but because it lets you manage
certain things manually that sometimes have to be managed manually.
This is absolutely essential when you are writing an OS kernel or even
another language run-time support library.  But the weak static types
and machine abstractions of C get in the way here--the size of
registers, the alignment and packing of structures in memory, the
calling conventions for procedures with arguments and return values,
etc. are all important details that must be managed by an OS or
language run-time, but C COMPLETELY IGNORES these things and instead
provides the back doors of macro-based conditional compilation, inline
assembly, and non-standard compiler pragmas if you must manage them
yourself. These are about the worst possible tools I can think of for
managing the problem! And you can't even really deal with different
stack discipline or calling conventions at all! The "portable assembly
language" thing is a total and complete lie, unless you happen to be
running on a PDP-7 with a really old version of C.  The assembly-like
bits are decidedly non-portable, and the high-level language bits are
just BAD and can't be swapped out. It's not really GOOD at anything,
except creating buggy code that runs really fast on some subset of
possible inputs! Yet our core operating system, programming language,
and security libraries are all written in it, and a certain class of
"gurus" practically worship it in the way that only someone who's
either ignorant of the flaws or who is blinded to them by extreme
mastery of them can.

If people were not so damned emotionally attached to tools like PHP,
UNIX and C, they'd realize that even their creators moved on from them
(except for the regrettable case of PHP, which has a creator that is
also unreasonably emotionally attached), and that we actually know how
to do better! There's no shame in recognizing the flaws of your tools
and using the knowledge you gained from them to build *better* tools.
Just because you *could* build nice things with the old tools doesn't
mean you *ought* to continue to do so.  Of course, sometimes you
should, for various reasons, but if everyone just continues building
things with the same old tired and broken tools, we will be left with
a world of garbage piled upon garbage, only held together by the
monumental effort of vast numbers of people who don't realize that
their efforts at patching up the surface and keeping a fresh coat of
paint slapped on the facade are just hiding a rotting infrastructure
within.

To wrap this rant up--I want to emphasize that I am primarily a C
programmer at work, and I'm pretty good at it, primarily because I
view C as a treacherous underling who will follow instructions
precisely but is always looking for ways to trip me up or torpedo my
projects if I leave out or mis-specify some arbitrary detail.
Similarly, it's okay if you're primarily a PHP programmer, provided
that you share a similar view of it as a terrible menace that must be
subdued and bent to your will through extreme discipline.  But it's
not okay to think that C and PHP are modern and adequate tools as they
stand, or that there's any chance in hell they'll *become* modern
adequate tools. They are terrible tools, you should hate them, and you
should be looking for adequate replacements. *They may not exist yet*
for whatever reason for your particular job, but you should be on the
lookout; and in the long run, investment in alternatives will have a
far greater payoff for *everyone* than just dealing with the
brokenness.  The only reason the situation exists today is that we
grow attached to our tools; we get lazy about learning new things; we
look for a quick buck today without adequate thought for future
efforts.  It's our fault, but we don't have to be okay with it.

       --Levi


More information about the PLUG mailing list