Chad Perrin: SOB

6 September 2006

the One Important Factor of programming languages

Filed under: Cognition,Geek,Popular — apotheon @ 02:03

Perl is a favorite flogging target, both of me and others, both of detractors and fans. So is Java. Both tend to become favorite flogging targets due primarily to two factors, I believe:

  1. each has a strong, widespread, zealous body of detractors who find it unutterably bad

  2. each has a strong, tightly-knit, zealous body of fans who find it unutterably divine

As such, both end up being example languages for all sorts of points (half-baked or otherwise). Favorite characteristics for maligning them are, in Java’s case, the immense scaffolding requirements of the language and, in Perl’s case, a harsh-looking syntax. Java’s noun-oriented philosophy is its excuse for the scaffolding. The design of Perl is often justified by explanations such as Paul Graham’s comment that “Real ugliness is not harsh-looking syntax, but having to build programs out of the wrong concepts.”

One of Java’s design philosophy principles is protection for the programmer from himself. It is considered a Good Thing that Java incorporates features intended to make it difficult to shoot yourself in the foot. One of Perl’s design philosophy principles, meanwhile, is that of enabling the programmer (TIMTOWTDI and “makes easy things easy, and difficult things possible”). In the process of trying to make dangerous things difficult, Java also makes things that should be easy rather more difficult. In the process of trying to make difficult things possible, Perl (the “Swiss Army Chainsaw”) also makes it easy to saw your own leg off. There’s a distinct trade-off going on, here. On the same subject, C and C++ are compared thusly, by Bjarne Stroustrup:

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows your whole leg off.
For a better idea of how that’s relevant, feel free to substitute “Perl” for “C” and “Java” for “C++”.

Flon’s Law provides an interesting thought on this subject, as well — one quite worthy of consideration:

There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code.

So, we must ask: What is the important guiding factor toward which we should aim our efforts when designing, or simply choosing for a given project, a programming language?

The answer, I believe, is enabling the programmer to write good code. We cannot prevent him writing bad code. We cannot force him to write good code. We cannot get good code by simply making programming easy. What we must do is make writing good code* as rewarding as possible, and to hell with all other concerns.

The definition of “good code” will change from project to project, to be sure, but within general problem domains there will be definite common characteristics that will arise again and again in the language that best rewards writing good code. The definition of “writing” never changes, however, for this metric.

a note about frameworks and other peripheral tools: If you want to get something done Today, the frameworks and other peripheral tools associated with a language are likewise valuable in direct proportion to their facility for enabling your programmers to write good code, but such value cannot be usefully measured in a vacuum. It must be measured as part of the overall results of evaluating the language. In the here-and-now, your familiarity with a langage, enjoyment of working with it, and ability to expand your knowledge of it quickly are additional factors to keep in mind.

If, on the other hand, you instead wish to invest in your future, you must consider not what frameworks, IDEs, libraries, and so on exist for a given language, but what among such things will likely exist when you need them at crunch-time, at some point in the future for which you are planning. This includes measuring your ability to generate tools for that language yourself.

* Writing good code should probably be defined in the following ways:
  1. writing: actually producing, measured not in lines or in syntactic elements or in time spent, but instead measured in useful progress toward the project’s goal — generally, actual functionality
  2. good: maintainable, readable, extensible, and above all well-behaved
  3. code: this includes source code, documentation, and delivery mechanisms, but not anything that ends up getting thrown away
As hinted above, that which does not qualify as “writing good code” should not be measured as a positive result, nor should it be measured as a negative result. It is irrelevant entirely. Only the “writing good code” metric itself is of value. This is, incidentally, also the central goal of hiring a programmer, so when performing employment interviews for programmers you should definitely keep this in mind.

10 Comments

  1. Right on. I’ve often found that the best hires are those who have a creative urge to find the best solution, as opposed to those who carefully prepare for every possible thing that could go wrong.

    Comment by SterlingCamden — 6 September 2006 @ 01:21

  2. . . . especially since there’s no effective way to “carefully prepare for every possible thing that could go wrong,” but one can always write better code.

    Comment by apotheon — 6 September 2006 @ 01:29

  3. Don’t forget the ability to change everything when your client suddenly realizes what they really want is completely different from what they thought they wanted. Yes, that fits under “writing good code” too…

    Comment by sosiouxme — 6 September 2006 @ 07:10

  4. . . . or write code under conditions where you know from the beginning you’re not going to get anything like a useful spec. You’re just supposed to divine project requirements from tea leaves and the shapes of clouds.

    Comment by apotheon — 6 September 2006 @ 07:47

  5. “This includes measuring your ability to generate tools for that language yourself.”

    Bingo.

    I’m surprised so many people overlook this. Languages don’t help those who cannot help themselves.

    And the same for frameworks.

    Comment by assaf — 7 September 2006 @ 02:12

  6. Languages don’t help those who cannot help themselves.

    That sentence conjures all kinds of interesting metaphorical ideas.

    Comment by apotheon — 7 September 2006 @ 08:41

  7. […] Help yourself. SOB on programming languages: “This includes measuring your ability to generate tools for that language yourself.” Languages do not help those who do not help themselves. And I suggest you help yourself and read the rest of that post. […]

    Pingback by Labnotes » Rounded Corners — 7 September 2006 @ 03:28

  8. The subscribe to comments function doesn’t seem to work for me here, apotheon. I’ve been missing out on all these fine comments.

    Comment by SterlingCamden — 7 September 2006 @ 06:00

  9. Was it working for you at some point in the past, or is the failure a new thing?

    Comment by apotheon — 7 September 2006 @ 07:16

  10. […] Finally, the last thing on the first page of the programming reddit when I looked was 10 tips for developing deployment procedures (or: Deployment Is Development). Yes, I wrote it. In fact, it’s the SOB post just before this one. I wasn’t even aware it was on reddit until I saw it there tonight. I’ve also noticed, in the process of following links around, that both OOP and the death of modularity and The One Important Factor of programming languages are still getting some action, through links various sources. Include Elegance (which I’m almost embarrassed to admit has been called a “seminal work”), and I might have the beginning of a “Joel On Programming” style of book in my future. Then again, maybe I’m just feeling too full of myself. […]

    Pingback by Chad Perrin: SOB » the goings-on in coderspace — 2 June 2007 @ 12:44

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License