PHP Programming (was JOB: LAMP Artisan)

Levi Pearson levipearson at gmail.com
Thu Mar 6 21:42:20 MST 2014


On Thu, Mar 6, 2014 at 8:29 PM, Joshua Marsh <joshua at themarshians.com> wrote:
> On Thu, Mar 6, 2014 at 7:38 PM, Levi Pearson <levipearson at gmail.com> 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 believe you, and I've seen the same thing.  The skill sets required
to thrive in academia vs those to thrive in the programming industry
are not the same, though there is at least *some* overlap.  There are,
of course, some academics who are incredibly good at both theory and
practice, but I think that most tend to favor thinking, reading, and
writing over actually coding.

My point is not that we should make all our academic types write our
code.  That would be a mis-use of their talents!  We should help them
study the real issues that arise in practice, and ensure that they can
get funding to study those issues and find novel solutions for them,
or discover how to practically apply known techniques.  If we ignore
them as irrelevant, we will mostly likely find them pursuing various
interests, perhaps uncovering useful techniques only to have them lost
in the stacks of journals.  If we never apply the things they learn,
we're never going to make any progress.

> 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.

There's a certain vicious cycle at work here.  Academia has known a
lot about programming languages for a very long time, but it's popular
to sneer at them and regard their work as useless nonsense while
hacking away in C or PHP, because that's the way it's done in
industry!  Meanwhile, more news of failed software projects, more
security failures, etc.  Industry seems pretty blind to the fact that
they're doing a lousy job; mostly, I think, because of the sheer
volume of crap we put out means you can swap one broken thing for
another often enough that people never really stop to think that their
new shiny computer thing really ought to work better. That's just the
way computers are!

>> 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. :)

Haskell has its own warts; I think a lot of them are due to the fact
that it hasn't had a whole lot of industry usage yet.  It's a
well-designed language, and its flaws are largely fixable, but at the
moment it's not exactly easy to pick up.  It's definitely rubbing off
on languages like Scala and Clojure, though, and I expect that the
"ambient knowledge" of the larger programming community will get to
the point where the barriers to picking up Haskell won't be so large.

I am, however, finding it a fun and surprisingly practical language to
play with, and it's definitely a tool that can be leveraged by the
right sort of people in industry to make better software.

>> 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 think you're making a false equivalence here.  Just because all
software has bugs doesn't mean that the number and severity of the
bugs is the same between languages.  Furthermore, the main selling
point of PHP seems to be that it's *easy*, but in fact that's a huge
lie made more treacherous by the fact that it makes *bad* programs
easy, but only starts to become reasonable when you are taught to
ignore all the tantalizing "easy" bits and follow a discipline that
runs counter to the "path of least resistance" in the language.  By
the time you've been redirected to the more modern bits of PHP and
learned all the things you must avoid and the various gotchas and the
disciplines that provide some semblance of sanity, you might as well
have started with a reasonable language, something like Python
perhaps, to begin with.

I'm not sure what you mean by Erlang people eating crow due to a
Whatsapp hack.  I understand they did some stupid stuff in the past
with their encryption, and that they recently had a bit of downtime
due to "server problems", but I haven't seen any details regarding
what problems there were or whether Erlang had anything to do with
them.  Erlang is another example of an academic putting his research
to good use.  Although it appears to be a fringe language from the
web, its primary home has, for many many years, been in telecom
equipment that has FAR more stringent uptime requirements than most
web tech does.  And it proved useful enough in that area that it's
been able to overcome the immense inertia against "old stuff" and
"weird syntax" and find a foothold in the fickle web service arena.

> 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
> superior.

Static analysis tools are great, as long as they're actually used.
How many PHP programmers on this list use static analysis tools to
check their PHP code?  As nice as it is to have them, and I think they
ought to become more widely used for any language, it's both *easier*
and *more robust* for programs to be "correct by construction" rather
than only correct when stringent extra-language policies and practices
are put into place. Languages such as Ocaml, Haskell, and Scala can
leverage their advanced type systems to rule out many kinds of errors
that have to be manually checked for in PHP.  If you wrote web
software in Racket, you could take advantage of its advanced contract
features and optional type checking to get many of the same benefits,
and also be able to cut out vast swaths of error-prone boilerplate.

What is the point of sticking with a poor language when there are
*nice* ones that are at worst no worse than PHP, and at best provide
all sorts of extra benefits?

        --Levi


More information about the PLUG mailing list