A friend worked on a project in 2005 that had lots of K code in production. They had a contract with Kx Systems and Arthur Whitney in particular because, in my friend's opinion, only Whitney could really understand K code well enough to debug it. Friend's description was it took my friend two days just to comment the code into something grokkable by a normal developer, whereas AW didn't need to do that. Of course, it took Whitney those same two days of staring at the code before he said "Oh, of course, how silly of me." and found the bug and all resolved.
Part of those two days of commenting was that since K is interpreted all of the developers would hand-obfuscate all of the code so that the variables were a, b, c, etc. so that they would be slightly faster to parse than a multi-character string. This sort of thing is done all the time now, with JS to make it load faster, but his team at least didn't have any scripts to automatically turn developer-friendly code into interpreter-friendly code, they worked with the interpreter-friendly code version.
In my experience this practice isn’t obfuscation or for performance. The whole point of array processing languages is to amortize any fixed operation cost over the span of the array.
The notation-as-a-tool-of-thought camp prefers short identifiers on the principle that the more concise the expression, the easier it is to comprehend in total. This is not at all dissimilar from the general practices of mathematics.
Once you get used to it, it's just faster and stop noticing the 'oh line noise' thing. But like learning a natural language, you need to get to the point where you stop translating in your head and you think in the operators. Once you reach that, it is very hard to go back.
Comments
A friend worked on a project in 2005 that had lots of K code in production. They had a contract with Kx Systems and Arthur Whitney in particular because, in my friend's opinion, only Whitney could really understand K code well enough to debug it. Friend's description was it took my friend two days just to comment the code into something grokkable by a normal developer, whereas AW didn't need to do that. Of course, it took Whitney those same two days of staring at the code before he said "Oh, of course, how silly of me." and found the bug and all resolved.
Part of those two days of commenting was that since K is interpreted all of the developers would hand-obfuscate all of the code so that the variables were a, b, c, etc. so that they would be slightly faster to parse than a multi-character string. This sort of thing is done all the time now, with JS to make it load faster, but his team at least didn't have any scripts to automatically turn developer-friendly code into interpreter-friendly code, they worked with the interpreter-friendly code version.
In my experience this practice isn’t obfuscation or for performance. The whole point of array processing languages is to amortize any fixed operation cost over the span of the array.
The notation-as-a-tool-of-thought camp prefers short identifiers on the principle that the more concise the expression, the easier it is to comprehend in total. This is not at all dissimilar from the general practices of mathematics.
Once you get used to it, it's just faster and stop noticing the 'oh line noise' thing. But like learning a natural language, you need to get to the point where you stop translating in your head and you think in the operators. Once you reach that, it is very hard to go back.
And Whitney is into being able to see the whole code at a single glance as far as I know.