These contests, as focused as they are, are indeed vulnerable to attack when that focus is recast as tunnel vision. While it is true that most of the effort in a a software project is figuring out the right question to ask, the performance on a well-structured problem _does_ have value. It seems disingenuous for a misdirection towards less measurable skills, it allows 'I could do that just as well' to be plausible, just not to me. As someone who has proven worthy in these contests, and having been faced with naysayers, I have found that when I try to figure out what other aspects are important, I find that others have no real clue what they want, yet they blame me for not delivering it.

Debugging APL on old DOS machines, without the codepage magic, not that difficult. One quickly got used to 'gamma' being 'iota', 'square root' being 'rho', 'o acute' being 'quad'. Unicode removes all that, and APL got its own place in Unicode as well.

Having a lot of experience with APL, my first encounters with Perl led me to the realization that Perl is truly 'write-only': Type in an expression: var = expression -- sure there's supposed to be some profanity at the start of the name $ or % or @ or something, but bear with me.... try to get the result out var {something that effectively says: I'm not telling, like {aList} or some such.... not impressed. ) at least with APL you can see data values. One good thing about Perl: it is not a pin-head language, one where functions can only return scalar results.

shouldn't this be from the you're-a-mean-one-mr.-KIM dept, since Kim _is_ the surname....

As an APL'er, 2 lines seems excessive to me. What was the problem?