Lambda the Ultimate

At the time I was very skeptical, but now I think I could do it too. It could make a fun contest :-)

The poet seeks compression: Doing as much as possible with as little verbage as possible. The poet accepts surface ambiguities. The reader works harder.

The essayist seeks clear exposition: Every line of code has its place. Assume the reader understands the domain, but make the code as clear as possible with little room for misinterpretation.

The novelist seeks to describe everything in detail: Don't use fancy constructs; keep it simple. Where code isn't crystal clear, re-factor into simpler terms and provide copious commentary.

Although most general purpose languages support all 3 types, I find that there are language features that attract a fair share of each type:

Poet: Perl, Lisp, Tcl, FP languages, C++ template (meta)programming

Essayist: Java, general C++, Python

Novelist: Don Knuth's Literate Programming, C, Java

This system was written in ASM/370 (that's mainframe assembly). This guy was so paranoid he would check the a register is zero, after every subtract instruction used to clear a register! So you had these sequences SR R1,R1 (zero R1) and then three instructions to check that R1 is indeed zero. He didn't trust the CPU!

He didn't believe in macros, either. So huge blocks of code were repeated in each file.

Last but not least, he was so afraid of memory overlays, he cleared each reigster after using it. So the most freuqent line was "SR R4,R4 clear register to avoid overlay". A 5000 line assmebly module could contain up to a thousand of these.

Incidentally, there seem to be a lot of "poets" among C programmers; at any rate there are a lot of obfuscators (in the terminology of the article) who seem to think that whitespace is unbearably ugly and code is only good if it's totally incomprehensible. Hopefully I'll never again have to work with one of those people.

I think Paul Graham would definitely be in the "poet" ranks you speak of. Personally, I don't think commenting or clear explanations detract from the poetry of the program. Ideally, though, a beautiful program wouldn't need much explanation because it would have a sense of compelling rightness to it, and the reader would be able to see that right away.

We can compare this approach to two other common ways to handle execution errors. The basic apporach sees thaem as outside the scope of the program, and they simply result in the program bombing giving a "run time error" message. This is essentaily what Pascal does.

The second approach quite similar, but uses standard langugae mechanisms to help routines to report on errors. The may return an error code (e.g., malloc), set a global error flag (ioerror), asnd may even use exotic control mechanisms to influence error handling (e.g, longjump and friends).

By adding exceptions to the language, you make it harder for the programmer to neglect error handling. The exception mechanism establishes the fact that errors change the flow of control through the program.

"The step beyond Realism is to add a dose of Cynicism. We like to tag all our data structures, so we can recognise them when they are passed in again. The overhead is low, and it makes your modules almost bullet-proof."

What about programmers that try to be like chameleons, and blend their coding style with the style of the system they are working on? A conformist? considerate? Or do they even have a personality?

I wonder what language Antonin Artaud the mad poet of all mad poets have chosen?

An engineer?

The quote is from the paper that's the subject of the posting: "How to tell your personality type from your code."

The links before the quote were to the sections in SICP with type tagging.

I should follow more a easily understandable way of citeing the source of links and text pulled from links.