Wednesday, April 11, 2007

Fight the next battle

Tim O'Reilly posted some book sales data that indicates PHP is going mainstream:
We've noticed that one of the signs that a language is becoming mainstream (and perhaps being abandoned by the cutting edge developers) is that the For Dummies book becomes the top seller. [...]

In Q1 of 2005, the Dummies book was #7; in Q1 2006, #5; in Q1 2007 it's #1. Not only is the Dummies book now #1, four of the top five titles are now introductory.
Tim raises an important point: PHP is going mainstream, and cutting edge developers are looking elsewhere.

Many of the want ads I've seen for PHP recently read like we're looking for someone young and cheap to work like mad and crank out web pages. This is a little depressing, but not entirely surprising. The web has been the dominant development platform for over a decade; no one needs to pay top dollar to just build web apps (or worse, maintain and configure them).

Why would a professional developer want to use PHP and work on a project where someone who picked up PHP For Dummies last month is nearly as qualified? The whole point behind being a professional developer is accepting progressively more challenging tasks, not switching from one entry level skill to the next.

None of this reflects on PHP itself, just PHP's status as a mainstream tool suitable for beginners. Sure, there's interesting work for PHP experts, but the bulk of PHP work doesn't need an expert of any stripe.

Tim's point is an expression of Paul Graham's Python Paradox, but in reverse:
if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job.
Because PHP skews to beginners and is becoming mainstream, professional programmers are moving away from it.

The problem with the Python Paradox is that it's both vague and fuzzy. By Paul's logic, if I'm starting a company, I should be using Factor or Io, because those languages are extremely esoteric.

Somehow, I don't think esoteric-ness is the important quality.

People who program professionally and truly care about their craft want to solve increasingly hard problems. They want to walk away from the old drugery and focus on what matters: solving the problem. Using the same tools over and over again means each project starts by fighting the last battle over again. Only then can the real work start: fighting the next battle, and solving the new problem.

The "fight the last battle" syndrome helps explain why languages like Python and Ruby are on the rise with professional programmers, while languages like Java and PHP are on the decline. Java uses a heavyweight, cumbersome, static object model, while Python and Ruby use a lightweight, dynamic object model, supplemented with powerful core types like lists and dictionaries. PHP makes it possible to build web applications, while Ruby and Python offer a variety of frameworks to that make web applications easier to build with much less effort.

Thus, Java and PHP are on the decline because they use old ideas and enforce older, more cumbersome styles of programming to solve problems than those offered by Python and Ruby.

As Ruby and Python make dynamic languages respectable, the whole "static vs. dynamic" language debate sounds like fighting last battle to me. It's tired. It's boring. It's a solved problem, they both work, and it's time to move onto something new.

What's the next battle? I'm not sure, but I've got a few ideas:
  • Functional programming over OOP and Imperative programming
  • Strong typing over weak static typing or dynamic typing
  • Mathematical foundations for concurrency over ad hoc models (i.e. threads)
  • Parsing over regex hackery
  • Implicit parallelism
I guess this is why I'm more and more comfortable spending time with Haskell these days. Haskell may not be the next thing, but whatever the next big thing is, it's probably going to have Haskelly fingerprints all over it.


The 27th Comrade said...

Um ... you can have the OOP ideas (which I kinda can't live without) in a Haskell-ish mood. Like Ocaml. Of course, OOP as we know it, now, involves gross impurity (so Haskell can't do it).

I really wish I could figure out how to have the best of both worlds. I'm supposed to learn Ocaml one of these months. I do ML, so it shouldn't hurt. I hope.

I like these posts, even though we may not completely agree on some things. Me, I am just sick of the other languages. I hate regexes - I don't even understand my own! I love Haskell, and I don't know what can push me back to ... what was that torture I endured? Java?

Dan Weston said...

As Ruby and Python make dynamic languages respectable, the whole "static vs. dynamic" language debate sounds like fighting last battle to me. It's tired. It's boring. It's a solved problem, they both work, and it's time to move onto something new.

This statement is both too bold and too meek.

Static typing is superior to dynamic typing not because it makes a language respectable, but because it allows programmers to program more respectably. Some apocryphal story has it that a reporter once asked Carl Sagan if he feared for our planet if humans keep destroying it. His surprising answer was: "Of course not. The planet will always be here. It is humans I fear for if we destroy our only home." Because we are all bad programmers, we need (ironically) less powerful tools so we don't hurt ourselves. Static typing is one (admittedly powerful) such self-imposed limitation. Of course static and dynamic typing "both work" if they are used correctly. Experience shows that they aren't.

There is no "next" battle. The fight to realize in software ever more complex algorithms while fending off the (potentially factorial) explosion of potentially buggy interrelationships in unrestricted coding practices is the battle that has been fought since the invention of the computer.

The use of static typing and monads in Haskell, invariant proofs in Eiffel, encapsulation in the module system of ML, limited interfaces and data encapsulation in OO languages, automatic memory management (garbage collection, reference counting), built-in testing, UML diagrams, documentation, and on and on have proved to be useful precisely because they provide the discipline we need to save ourselves from the instinct to make greater progress today even at the cost of forever slowing progress in the future with "maintenance" difficulties.

It is tired. It is boring. It is time to move onto something new if that will help.

But it is not a solved problem, so long as programming is a human activity. It is a war of attrition that can never be fully won, but can be catastrophically lost.

Disdaining the benefits of static typing is the hallmark of a very self-confident programmer. I am, for better or worse, not so assured of my own programming skills to reject any help that comes my way.

Adam said...

"[The next big thing is] probably going to have Haskelly fingerprints all over it."

I hate to "Paul-Graham-ify" this quote (because it's so beautiful), but think about language progression: we went from the (Lisp . Fortran) pair of (super-high-level . just-above-assembly) to languages like Java, Perl, Python, and Haskell.

If the next big thing's going to have "Haskelly fingerprints all over it," what about the big thing after that?