Ian Bicking: the old part of his blog


It makes me laugh when a Perl programmer badmouths Lisp:
"But I suppose I could go back to lisp if I wanted lots of madly nested insanity."

Learn Lisp before trying to badmouth it. Lisp programmers use the "loop" macro, which is much more powerful and succinct than Python list comprehension, much easier to read and maintain than Perl code, and doesn't require excessive parenthesis.

Lots of parenthesis don't make code hard to read or maintain: just the opposite. Good Lisp programmers use lots of white space and indentation to make the meaning of their programs quite clear.
Since Lisp syntax is so regular, it's easy for text editors to intelligently edit Lisp code, auto indent, balance parens, move over logical units of code, etc.

What makes code hard to maintain is lots of context sensative jibber jabber punctuation like Perl uses, that text editors and humans have an extremely hard time parsing and understanding.

It amazes me that Perl programmers complain about Lisp's parenthesis, then they go write programs that look like line noise, on purpose. Some actually savor Perl syntax, thinking it makes them more manly. It's like voting for Bush because he puts on a macho act, even though you know that his policies are horrible and he's a liar.

I don't think that it's a question of taste or style or manlyness. Programs that look like random line noise are much harder to write and maintain than programs with a regular syntax that you can validate and maintain without actually executing the program in a debugger and looking up syntax quirks, precedence rules contextual nuances in a huge manual.

With regard to list comprehensions versus writing out loops: It's not wise to take false shortcuts that you'll have to end up backtracking later and rewriting your code. Because list comprehensions have limited functionality compared to Python loops (or Lisp loop macros), sometimes you have to rewrite them later as normal loops if you need to add features the syntax does not support, or that it does support but would strain the syntax. If you write it out as a loop in the first place, it's much easier to maintain later, because you don't have to decode and recode it into a longhand loop when it needs to grow later.

For the same reasons, I take the same approach to putting statements on separate lines so they're easy to edit and maintain later. When I'm programming in C-like language, I always use braces, even if there's only one statement, because later on I might want to add another statement, an assert, or a debugging printf. It's just good engineering practice. You wouldn't want a bridge builder to leave out bolts because it made the bridge lighter and let him take his lunch break earlier.

Taking short-sighted shortcuts to reduce the number of characters you have to type and lines of code in your program, like leaving out braces in C programs or overusing list comprehensions, is only a shortcut to writing code riddled with bugs that's hard to maintain.

Comment on Code Pickiness
by Don Hopkins