Re^3: Code Readability. Break Rule Number 5?

I remember writing APL for a part-time job in college, quite some time ago. The language was powerful, and compact. However, when I went back to a piece of code that I hadn't looked at in two weeks, the compact and powerful nature of the language made it hard to read. It was often denser and harder to read than mathematical proofs. Sometimes it was faster to re-write the code from scratch than to read it, so it was, to some extent, a write-only language.

Comment on Re^3: Code Readability. Break Rule Number 5?

Replies are listed 'Best First'.
Re^4: Code Readability. Break Rule Number 5? by holli (Abbot) on Apr 21, 2007 at 14:11 UTC
I remember writing Perl for a part-time job in college, quite some time ago. The language was powerful, and compact. However, when I went back to a piece of code that I hadn't looked at in two weeks, the compact and powerful nature of the language made it hard to read. [...] Sometimes it was faster to re-write the code from scratch than to read it, so it was, to some extent, a write-only language. Sorry, couldn't resist holli, /regexed monk/	[reply]
Re^4: Code Readability. Break Rule Number 5? by rodion (Chaplain) on Apr 22, 2007 at 03:05 UTC
Beyond the humor, you end up making my point well, perhaps better than I did. I've sometimes found "map" leading me into stacking functions 'till they look like a Schwartzian Transform gone wrong, but I never have found Perl leading me towards writing at the density of a mathematical proof. Regular expressions certainly get dense and obtuse without the "/x" modifier, but they stay in their own restircted string context. Nothing's ever come close to the APL experience for leading me down the path of unintentional obscurity.	[reply]