

PHP: Cracks in the foundation - chrismsnz
http://phpadvent.org/2011/cracks-in-the-foundation-by-gwynne-raskind

======
necro
I was at conference recently talking to a group of "developers" and one
finally asked, so what kind of language requirements do you have of the people
you hire. I answered that I don't really have any requirements of the specific
language. They all looked at each other and nodded, oh, so you must not be too
advanced as you are not looking for people with experience in new advanced
languages. I was a little surprised because I was thinking the EXACT opposite.
I work with _developers_. I don't really give a shit what syntax they prefer
of are used to. If you can create your own framework error handling, message
queues, custom db libs, etc then that is useful. A real dev can pick up a new
language and syntax in a week, so just because you can write hello world in 10
languages or use some rails ORM to output some stuff does not make you a
developer.

It's all starting to take me back to my youth watching Robotech and
remembering the Zentradi, an advanced race with awesome technology and tools
that were developed for them generations ago, but none of the understood how
any of it worked or how to fix it, they could only use it. If it broke, they
just start over with a new copy instead of debugging it. I hope that the our
new generation wont end up like that.

I recently interviewed a recent CS grad that had no idea of the correlation of
array of characters and pointers to those characters. You know that it's all
just addresses to memory, right?

Anyway, of course there are those who truly dissect and get all the languages
and their benefits but are few and between.

Give me a dev that "gets it" in one language any day, instead of someone who
thinks remembering the function call or some syntax in 10 languages is of
value.

If I hire someone here is how I rank them... 1\. 5 years experience in C 2\. 5
years experience in PHP 3\. 5 years experience in Rails 4\. 5 years experience
in Rails, Python, erlang, java, php, c, other languages dujour.

Ok, there are people that are just picking up PHP and don't know squat, but at
least they know they are beginners and are teachable.

~~~
masklinn
> A real dev can pick up a new language and syntax in a week

No, that's complete bull. A real dev can pick up syntax in a week (or a day),
but integrating concepts and techniques he's never seen so far and building up
new instincts which correctly fit the new language, that does not happen in a
week unless the guy is in the "genius" category.

What you really have after a week is a guy who writes $previous_language code
in a new syntax. In the way "Real Programmers" can write Fortran in any
language.

~~~
regularfry
It does depend which other languages they've previously been exposed to. I'd
argue that once you've seen Haskell, common lisp, APL and Forth, there aren't
many new concepts that any language is going to throw at you that you can't
relate back to something you've seen before. It doesn't take a genius to get
that much exposure, just curiosity, patience and time.

~~~
mechanical_fish
So far in my limited experience the rule still holds: If you drop a Haskell
programmer into Blub they may well try to write Haskell-flavored Blub for a
while. I've seen it happen.

I think you're misapprehending the problem. It's not that Haskell programmers
can't _understand the structure_ of Blub. Gods, no. It's that it takes time
and tolerance to be able to immerse oneself in the Blub _culture_. Blub has
its way of doing things, much of which is more accidental than logical, and
alas, much of what passes for colloquial Blub is probably stuff that Haskell
was specifically designed to avoid like the plague. There's an initial
tendency to either run around waving one's arms like Jeremiah, trying to
convert the Blub programmers to the side of Light, or to take to drink in
despair at the sheer Rabelaisian sloppiness of the Blub universe. To work
through this takes time, and possibly therapy.

It's like anthropology. It's one thing to be a linguist and work your way
through library books about the syntactic structure of a family of languages
from New Guinea, but it's another thing to be airdropped into New Guinea
itself, insinuate yourself into a local village, pray you don't die of any
tropical diseases, learn which compliments in your native language are
actually mortal insults in your new host culture, try to laugh along with the
natives when they convince you to lean against a tree filled with stinging
ants, and simulate exquisite happiness when your host offers up a delicious
sample of the local insects. It's a cultural problem. Not everyone is up for
that experience. One may have to work through a certain amount of shock.

~~~
_delirium
I agree it's largely culture, but I think there are some technical issues that
go with the culture as well (which are sometimes the reason for some cultural
elements). Even someone who solidly understands OOP, for example, may not know
all the many _specific_ gotchas and possible pain points of C++ if they
haven't written a lot of it, and some of the cultural conventions common in
C++-land were developed because of awareness of those gotchas, and in an
attempt to minimize them. C++ is probably a limit case because it's so large
and has so many interacting features that there's a lot of accidental
complexity, so just knowing the PLs concepts only takes you so far, but I
think many languages have some similar things.

Heck, even ye olde C has a whole litany of detailed spec edge cases you need
to know about if you want to understand the finer points and avoid some nasty
pitfalls (and an even bigger list if you go to C+POSIX).

~~~
mechanical_fish
Oh, I agree, and we're actually talking about the same thing. We're just
defining the word _culture_ with different scopes. My scope was,
approximately, "anything about C++ that you really need to know to write
idiomatic C++ code and interact productively with your C++ coworkers and
community, but which you didn't learn from that _Introduction to C++ for Lisp
Nerds_ book that you skimmed last weekend."

Clearly not a hard-and-fast definition. The more "proper" scope of the word
_culture_ is, of course, ultimately a giant philosophical issue which I intend
to blithely handwave away. ;)

(I suppose one could try to argue that _all_ of C++ is a cultural artifact,
and C and assembly for that matter, but sooner or later you'll reach the
Turing machine, which if you chip away at it you'll soon discover is just the
tip of an iceberg which consists of _all of mathematics_ , and then folks like
_Plato_ will turn up on the battlefield looking for a fight and holy cow, look
at the time, gotta run.)

------
zzzeek
> PHP, being a language intended for beginners,

I've never heard this before. PHP is certainly very easily picked up by
beginners, and in my own opinion makes it easy for said beginners to spend
years and years not moving very far beyond beginner-level architectural
patterns (just look at the source of Wordpress for an example), but do the
creators of PHP really consider it to be "a language for beginners" ?

I have an entirely selfish agenda here. The next time some know-nothing
manager promises his client "we have the top programmers with years of
experience who will write the highest quality code you can get", then demands
that we do everything in PHP because that's all he knows, we can say, "really?
You're going to charge the client all that money, then give the client an app
written in a "beginner" programming language ?"

~~~
einhverfr
Personally I think there are better languages for beginners than PHP. I think
Javascript, Perl, Python, and more are fundamentally better in this regard.
There are some fundamental, lexical problems with PHP in this regard. I think
by a "language intended for beginners" I think it is meant as "a language
intended to allow HTML/SGML authors to cross over into programming."

PHP is in essence a fairly narrow tool, much like a chasing hammer (which
really isn't that good for driving nails but is extremely important in some
kinds of metal work). It is a preprocessor for SGML files (and this is why all
programming logic is typically put in SGML PI tags). I call it a "templating
system turned on its head" because whatever you do with PHP, every file is
lexically part of the template even those which have no other SGML tags other
than the PI tag which is indicating programming logic.

But what this means is it works very well in its own specific domain (namely
preprocessing HTML, XML, and other SGML files), but degrades quite a bit as
one gets out of this area. This limits code reuse basically to web apps (yes,
I know you can write GTK apps in PHP, but really? why on earth would you want
to?) and thus locks one into essentially one set of technologies. So there are
drawbacks as well as advantages.

~~~
mechanical_fish
PHP is _indeed_ a "templating system turned on its head" (according to second-
hand reports from a talk by Rasmus Lerdorf, PHP was originally designed as a
bare-bones templating system for C programmers, but then more and more stuff
migrated into the templating system...). And it is, indeed (or was, anyway)
tied strongly to a single domain, and a limited set of architectural patterns.

But every design choice cuts both ways. These features are not merely
drawbacks. These are PHP's _strengths_ , the things that make it so delicious
for "HTML authors who need to cross over into programming".

You can learn PHP with Google. My understanding is that most people do. [1]
Just Google all your problems and up will pop some code that you can mimic.
This works because, to first order, _all PHP code is solving the same problem
in the same way_. You will probably not accidentally Google up some PHP-based
physics simulation. You will probably not Google up some PHP code used by
sysadmins to parse the output of pipes on the command line. You will certainly
not Google up any PHP-based graphics algorithms or device drivers or client-
side DOM manipulations or Android system functions. No, when you Google "how
to do X in PHP" you'll get some code that you can paste into a template with a
.php extension and then execute on your cheap shared host. Until fairly
recently there wasn't even any danger of encountering object-oriented PHP.

You can argue that programmers trained in this way are useless for anything
but cobbling together Web pages, and you're right, but 90% of them don't care.
Web pages are a killer app. People build whole businesses out of cheesy web
pages.

My suspicion is that many PHP tinkerers don't want more "architectural
flexibility"; that translates into "decisions that we have to make but don't
know how to make", "knobs that we have to set carefully but which we don't
even know how to turn", and "oodles of online documentation for use cases that
we don't have, which chaffs up the search results for the use cases that we do
have."

The irony, of course, is that PHP's maintainers have been hard at work bolting
features from other languages onto PHP, which as a side effect threatens to
destroy the narrow domain-specificity that was its most unique feature. [2]
Objects, namespaces, closures have all been welded onto the superstructure.
One wonders what happens next. Maybe the folks who embrace all these things
will drag the entire PHP community closer to Java, Python, Ruby, or some
oddball superposition of these things. But I think it more likely that the
community will continue to balkanize, with the bulk of users rejecting all
these transplants but certain segments embracing one or another of them.

\---

[1] I learned PHP via reading and hacking on Drupal modules, which is a much
better plan, but also definitely not the beginner-friendly choice. Drupal has
a steep learning curve.

[2] Though don't blame the maintainers too much: These features are in fact in
demand, from the people who took up PHP without realizing that it was a narrow
domain-specific language and pushed it right up to the limits of the available
hacks.

~~~
einhverfr
Completely agreed. Hence the chasing hammer metaphor. You wouldn't use a
chasing hammer to drive nails, but you wouldn't use a carpenter's hammer for
chasing either. These are strengths, but they ensure that PHP is a relatively
specialized tool.

------
MrEnigma
This list seems a bit tired.

There are a couple of things in here that are actual issues, but they seem
small in scope, and easy to work around.

As for the is_a changes, I think it's probably for the better, as they say,
you have to break some eggs to make an omlette. Also, the article first
complains about not having Unit Tests to catch this, and then later complains
about it being ignored on release. Ultimately unit tests are great for
refactoring, but when code is actually being changed, some sort of process
needs to be followed for that (dictatorship, consensus building, anarchy?)

I program in PHP, and we don't depend on too many outside libraries. And for
cases where we do, we will simply fix these issues.

It used to be that upgrading PHP was much 'easier' to do, meaning you'd just
go out and do it, and would hardly breaking anything (at least in my
experience). However lately it seems that the risk is higher. However I
welcome this, because it means the language is progressing and we're getting a
lot of additional things. For all the projects I've worked on, we make sure
the code works with that version of PHP.
Unit/integration/regression/selenium/using it on development for
awhile/whatever are all valid things to do, if you have issues you fix them
and move on.

5.3 was great, excited for 5.4 with traits as well. It's a great time to be
writing PHP.

~~~
MrEnigma
The array/sorting things are sometimes just things developers will have to
deal with until someone makes new methods and deprecates the old ones.

I used to think that the code base needed to be perfect, no extra cruft, only
code that's necessary, switch parameter order just to make things match.
However in doing so it adds a tremendous amount of pain and risk. My OCD
does't want to handle it, and it's always good to strive to get to that point,
but ultimately nothing is perfect, so might as well deal.

------
paulhauggis
PHP has already proven itself time and time again. There are lots of high-
traffic websites running PHP successfully. Yes, it's easy to make a simple
script and get it running fast, but you can also engineer complex OO
applications.

One of the reasons I've stayed away from things like rails is because it puts
too many layers on top of things like the database.

I've known a few developers that use Django or Rails and have no idea how
things work underneath. This is a disadvantage. Especially if you need to do
something like optimize a database query and to do so, you have to actually
change the framework that maps SQL to an object.

~~~
flomo
The problem with your statement is the equivalent developer is extremely
common in the PHP world. There's tons of people who hack on WordPress or
Drupal and 'have no idea how things work underneath'. It's probably the
majority of people with "PHP" on their resume.

~~~
knieveltech
I call bullshit on your Drupal FUD. You can't code effectively for Drupal
without a robust grasp on basic PHP, SQL and the Drupal suite of hooks. You
better have some serious OO chops too or integration with stuff like Views is
going to eat your face.

~~~
flomo
Yeah, but mainly because Drupal is a pile. CCK & custom forms seems about four
times more complicated than just doing it in raw PHP. So that is not
necessarily taking anything away from the intelligence of the developers, only
pointing out they are coding against the abstraction, not the plumbing.

Still I'd bet the majority of 'Drupal developers' are just folks who know what
the right modules are & some customization tricks.

~~~
knieveltech
"Still I'd bet the majority of 'Drupal developers' are just folks who know
what the right modules are & some customization tricks."

My anecdotal evidence based on five years of working with the CMS indicates
you'd lose that bet, but whatever.

------
cobychapple
Learning PHP is how I got into web programming, and for that I'll be eternally
grateful. Since starting to explore languages like Ruby and Python however,
I've been reluctant to use PHP in situations where others are an option, so
I'm really glad to hear things are picking up in PHP's development—it can only
mean good things for the development community.

------
grandinj
But it can be fixed. Rather than specify a grammer in BISON and generating C
code, write your parser as a recursive descent parser. Then add some
annotations and auto-generate grammar files from the C code.

This is the same principle as generating document using DOXYGEN, the closer
the annotation is to the code, the more chance there is of the annotation
being correct.

Also, its something you can incrementally.

------
seanchambers
I havent developed in php in years, but here is my tale on it from my current
point of view.

Of this whole article the one thing that jumped out at me was "broken and
ignored tests". Being an open source developer myself, I greatly value the
tests in every open source project. Nevermind the fact that this is PHP which
warrants the use of tests even further because of the various points the
author makes.

I hope that going forward the maintainers of the PHP core ensure that every
bug fix has a passing unit test along with it. That would at least keep the
dam holding back the flood intact.

~~~
justincormack
Adding tests for bug fixes doesnt necessarily help when your code is in that
state. I think you are better off looking for coverage on tests, and trying to
write specs eg formalize the parser as mentioned. Probably a lot of tests now
are from previous bugs, but the code has drifted and they have not been
maintained.

