Tight code

Almost more as an exercise than anything else, I've occasionally tried to make a computer program as short as possible (see OAI-PMH and OpenURL 1.0 for example).  The interesting thing is, in general the program was much better for the effort.  Not that the OAI-PMH code is particularly readable, but that was just to get it on a T-shirt.  Taking out the tricks would still result in a very short OAI harvester (maybe two pages instead of one) which would be both readable and relatively short.

Looking at some programs, I'm struck by the idea that when you see regularity and repetition in the code, everyone would be better off if it could be squeezed out.  Usually this results in a shorter, easier to understand, and often faster program.  I think this is one reason I like Python -- it doesn't require as much boiler-plate as languages like Java.

The master of this is Chuck Moore who invented (and seemingly spent his life in) Forth.  Screen shots of his Forth code look almost like noise, but he's able to do things like sit down at a bare machine and bring up an operating system on it in a few hours.  The operating system (along with editors, assemblers, and all your applications) would fit comfortably on a floppy disk (a few hundred kilobytes for those who've never used them).  Or a VLSI design tool in 500 lines!

One thing to keep in mind is that it isn't how hard it is to understand each page of code that's important, but how hard it is to understand the whole program.  I claim that one page of dense code that does what ten pages of looser code would do is easier to read, understand, and maintain.

I once wrote an incremental Forth compiler to run on OCLC's Sigma 9 machines (in assembler, of course).  Can't say I'd recommend the language to anyone to program in now, but it certainly was both fast and compact, characteristics we really needed 25 years ago.  I've always regretted not attending one of the Forth conferences they used to have back then and not getting to meet Mr. Moore.

--Th

Comments

[Eby]

You might like the lesscode.org blog. I've found the posts to be interesting. Simplification seems to be making a comeback right now.

http://lesscode.org/

[Ed Summers]

"I claim that one page of dense code that does what ten pages of looser code would do is easier to read, understand, and maintain."

I would like to agree with you...but in general I find the things that get sacrificed in the name of brevity are, nice whitespace between lines, documentation, comments and abstractions (classes,etc)...all of which are near and dear to me. At least python will encourage pleasant indentation right? If you were using Perl would you do away with the newlines? I'm guessing not. Your claim taken to it's logical extreme in another language would lead to a good entry for an obfuscated code contest.

That said, your openurl code is *much* easier for me to read than the oai client. I guess this one isn't going on a t-shirt eh? :-) I totally agree with you that python is a lovely language that encourages simplicity of expression, without the baggage of Java's explicitness. But this comes at a cost in the form of unforseen runtime errors--instead of compile time bugfixes. Although Bruce Eckel has some interesting thoughts about this in his Strong Typing vs Strong Testing, which I find very compelling.

Martin Fowler has a good quote that I like to keep near the frontal lobe when programming: "Any fool can write code that a computer can understand. Good programmers write
code that humans can understand." It's a challenge that's for sure.

[Thom]

I do think it's important to write code that humans can read. That's one reason I was never a real Pearl fan.
In terms of runtime bugs, only very occasionally do I run into a bug in Python that static type checking would have prevented. I was surprised, but others report the same thing.
If you do worry about it, I think unit tests, and a decent code coverage tool to help you write them, catch the rest of the runtime errors that Java would at compile time. One thing to remember is that Python is strongly typed, it just does it at runtime.

--Th