dreadedmonkeygod . net

Okay, kids. Gather 'round, and hear Uncle Chris talk about why you should always use a build script.

Yes, always.

I was a young computer science student, and I was working on a project that happened to be in Java. I'd edit the code, then type:

%> rm *.class
%> javac *.java

(Yes, javac will re-build all .class files that are older than their source code. But javac isn't smart enough to notice an edit in Foo.java that creates a broken call in Bar.java. Removing all the .class files ensures a springtime-fresh build every time.)

Ahem. Anway, so that's what I'd do. And that worked fine for weeks, until late one night I was very tired, and recompiling and testing about every 90 seconds. At this rate, it was just a matter of time before I typed:

%> rm *.java

Whups.

If I'd had any sense, I'd have had a build script. In this case, it was simple enough to make into an alias, so that's what I did:

%> alias build="rm *.java; javac *.java"

I did this before re-typing my source code. Why? Because I don't want to make the same mistake twice. Now I can't type "biuld", and it'll just fail to run. I can't accidentally delete my source code.

And I can already hear you younguns saying, "But I'm smart! I'll be careful to keep backups, or not accidentally delete my source!" That's just youth and inexperience talking. If I'd really been careful, I'd have been fine. But the real lesson here is that the less you have to be careful about, the better. Humans are bad at being careful about repetitive tasks. Computers are really, really good at being careful about repetitive tasks. So staff it out. Building your project is the computer's job, not yours.