This essay was based upon the talk he gave at OSCON and I was sitting there listening to it (yesterday, as a matter of fact) and I really appreciated much of what he had to say. I do think that he overgeneralizes in some places, but the core of much of what he was saying was interesting, if you could distill it down. What I heard him say, ultimately, was that great hackers enjoy scratching their personal itches more than they enjoy searching for a back scratcher. As a result, they tend to be less inclined to look for tools that don't allow them to immediately dive into the problem.

To a certain extent, I think this is due to his love of the Lisp programming language and other dynamically typed languages that let programmers focus on the problem rather than the fiddly bits (bad stretch of a pun intended.) If I'm trying to track down that memory leak, I'm wasting time. If I really have to care about "hard drives, buffers and other things" then I'm not solving my actual problem. I'm solving problems that the language imposes.

Take Java for example. Consider one way of opening a file:

try {
  FileInputStream stream = new FileInputStream(myFile);               
+                                                                 
  DataInputStream input  = new DataInputStream(stream);               
+                                                                 

  while (input.available() != 0) {
    System.out.println (input.readLine());
  }                                                                   
+             
  input.close();
}
catch (Exception e) {
    System.err.println("Could not read from file");
}
[download]

Now really, what hacker is going to want to jump through those hoops to print the lines of a file?

open INPUT, "<", $input or die "Cannot open ($input) for reading: $!";
print <INPUT>;
close INPUT or die "Could not close $input: $!";
[download]

If you're in a corporate culture, the first example might seem more appropriate because you can't forget to see if the open was successful and everything is this really cool OO stuff. The second example, though, lets you focus on the task at hand and clears away a lot of cruft. If I have an itch to scratch, I don't reach for a diesel-powered backscratcher. That, I think, is what Paul Graham was trying to say.

And no, Perl's not comparable to Prolog. The latter is a wonderful language, but it has such a limited problem domain that comparing it to Perl is comparing cheese and Wednesday. Different tools solve different problems and comparing them without a problem to contrast them against is an exercise in navel gazing :)

Side note: does anyone else see the weird newlines in the Java example? I've been seeing that a lot recently, but I don't know if it's a quirk of Firefox, my using FC2, or something else entirely.

Update: It's been pointed out that the "weird newlines" are from a bunch of whitespace at the end of some lines of code. Curiously, they don't show up in the editing textarea and they didn't come from me. Weird.