I'll give you an example. I wrote the following code in perl because it would be prettier, although I could have easily done it in the shell (yes, I am a shell warrior).

#!/usr/bin/perl -w

use strict;
use Carp;

foreach my $file (@ARGV) {
  next unless $file =~ m/ctl$/;
  print "archiving $file\n";
  system "archivedvd $file\n";
  sleep 60;
  system "verifydvd $file\n";
}
[download]

Now, this can be done in the shell, as well:

#!/bin/ksh

for file in $*; do
  echo "archiving $file";
  archivedvd $file;
  sleep 60;
  verifydvd $file;
done
[download]

Perhaps this is a bad example because it is too simple to demonstrate why I chose perl. I will elaborate. I chose perl not because it was necessarily the best tool for the job. I did not choose it because there was any particular advantage to it at all. I chose perl because the method is important to me. I chose perl because I think perl is more elegant than using echo, and I like the syntax. Should I ever need to modify the script, perl is far more flexible than the shell. So the script is less efficient than using the shell (ksh uses less ram and processor than a perl interpreter).

Dan, of course, would scoff at this approach. Dep, he'd say, "why the hell would you use perl there? youre just writing a shell script in perl. simplicity is important." Today, he even gave me a document from the Lisp folks (Dan is an MIT alum, and thinks Lisp is cool). I present it here, with my comments below.

http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html

Let me say this article has given me horrible indigestion, and I have not been able to get any work done knowing that people like this are out there.

Yeah, I am that irritated.

Call me obsessive compulsive, anal retentive, whatever, but I just cannot get past the idea that there are people who think that it is ever okay to cut a methodological or ritual corner. ever!

I have always found the concept of hacking together something (Larry calls this "Whipuptitude") repulsive. I like a shell or perl oneliner as much as the next guy. But if I use it more than once, I write it out properly, and make an application of it. The above article has this to say:

Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Excuse me? Consistency of interface is worthless??? Argh! He goes on:

First, the right thing needs to be designed. Then its implementation needs to be designed. Finally it is implemented. Because it is the right thing, it has nearly 100% of desired functionality, and implementation simplicity was never a concern so it takes a long time to implement. It is large and complex. It requires complex tools to use properly. The last 20% takes 80% of the effort, and so the right thing takes a long time to get out, and it only runs satisfactorily on the most sophisticated hardware.

Maybe I should give some background here, but I think most of you know this stuff. I, right now, am auditing a large perl site installation. It has various components, including Javascript, Oracle/plSQL, and Bourne Shell, and it stretches over roughly 6 public webservers and 2 database servers. I come across some really ugly code. It gets the job done. It's even simple. But it is not elegant. It is extraordinarily fragile. Its author is no longer employed here. We dont know why it works because the interface and code is inconsistent. We dont know if when or how it will break.

And it's my job to fix these problems or re-engineer them so that in the future we can just "plug in" the code I have written. Its time/money capital now to save us another prolonged site audit in the future.

I feel like I am fighting a war against lazy programmers who believe that "worse is sometimes better."

Dont get me wrong, laziness is cool. My above example (the shell script vs. perl script example) is a good one. It only runs two commands, and leaves 60 seconds inbetween for the robotics to return. The reason for the script is that I am lazy: I don't want to type that sequence of commands in for each of the 700 dvd's Im going to burn in the next 6 months.

Laziness in code, however, is criminal.

I really want to hear what the rest of you have to say about this. We are here at the Monastery because we share a common ideology. What is that? Do you have pride in your code? Do you think that short, concise, and simple (but hackish, ugly, and inconsistent) code is better than going the extra mile? Spending 80% time on 20% of the code?

We live in a time of gigahertz processors and terabyte raids. Efficiency is important, but not at the expense of an elegant and useful API. And not at the expense of man-hours de-engineering your work. <!- chipmunk, if this offends you like my last rant did, perhaps you should consider changing your ways. -!>

brother dep

--
Laziness, Impatience, Hubris, and Generosity.