[SGVLUG] PHP question

[Dustin Laurence]

On 02/23/2016 10:48 AM, Henry B (Hank) Hotz, CISSP wrote:

> I did use PHP 1-2 a bit a long time ago. So, please, it’s just a
> language. Why is everyone so down on PHP?

That's a lengthy rant I have no interest in writing up anytime soon.
Also, my therapist says I'm coming along nicely suppressing the memories
of the details of PHP, and I'd hate to undo all that hard-wone progress. :-)

In this vein, there is an interesting essay by Dijkstra:

http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html

which is good food for thought even though I don't agree with every
single point in it.  PHP didn't exist at the time, or it would
undoubtedly have attracted some pithy abuse from Dijkstra.  But one
facet of the point of the essay is that criticizing the language that
someone first learned programming in is like criticizing their mother,
and receives similar responses.  So to reduce the howls of anger from
those with lingering PHP affection, I'll use an analogy that takes aim
at myself.  The essay contains the quote

"It is practically impossible to teach good programming to students that
have had a prior exposure to BASIC: as potential programmers they are
mentally mutilated beyond hope of regeneration."

That bothered me once, because 8-bit basic brought me to programming
(along with 6502 assembly).  But I'm a grown up programmer now and I can
distinguish between feelings and truth, and the truth is that Dijkstra
was correct.  For example, basic didn't have any abstraction facilities
to speak of, and so it taught one to program without using arguably the
single most important programming concept.  That's objectively bad for
baby programmers.  It's not so different from growing up and learning
the difference between lingering affection for your old girlfriend and
the memories of good times and the realization that she was downright
crazy and about the worst thing in the world for your emotional development.

PHP has similar problems, but as Dijkstra says, feelings get hurt when
you say so.

> From my viewpoint, the more extensive the functionality of a language
> the longer the learning curve.

Makes perfect sense, but it just turns out that the world doesn't
actually work that way.  In practice there is enormous variation because
there are so many ways to provide similar functionality.  Some syntactic
choices and some semantic choices are much, much harder to learn to use
correctly for the same payoff than others.  It's important to know that
when choosing languages to learn, particularly if you're not grown up as
a programmer yet.  A few examples.

Python, for example, seems to be particularly efficient in programmer's
learning time; I found I could program in it fairly well before I even
learned anything about it explicitly.  Guido isn't an awesome C hacker
(GIL, I'm looking at you), but in the words of a friend he IS awesome at
standing on the principle of consistency.  It seems to be a good place
to grow because you waste less time learning syntactic oddities and it
has relatively few horrors and bad habits, even though it is not a
minimalist language and has a lot of functionality.  I would prefer
people get comfortable in at least one statically typed language first,
but for better or worst that's not how people are learning programming
right now.

C++, by contrast, is probably the hardest widely deployed current
language to use well.  For example, it provides exceptions just like
python does, so your reasoning would suggest that it will take similar
amounts of time to learn to use exceptions in either language.  Nothing
could be farther from the truth.  Python exceptions just work, with no
subtle gotchas (that I remember) in their straightforward, consistent
semantics.  C++ exceptions, by contrast, have some of the worst
semantics you'll ever find as a consequence of forcing them to coexist
with manual memory allocation, two things which are barely possible to
do simultaneously.  An expert can use them, but the price is that you
have to learn some skills that are unnecessary almost anywhere else,
such as writing code (particularly constructors) that mutates state
transactionally because it calls something that could throw even though
your own code can't (and so exception handling invades your entire
codebase, even where you aren't explicitly using them).  It's telling
how many companies I've talked to that simply don't use exceptions in
C++ at all, and I can't blame them.

So no, feature count isn't a good measure of learning curve, even though
I agree that logically you'd think it would be.  The devil is in the
details (particularly in C++).

Dustin