I think the idea is that you learn it, and then you reap the benefits. Not much different from e.g. maths. You could figure out how to rotate a point about the origin with some haphazard application of multiplication, addition, sine, and cosine. Or you can learn you some linear algebra and then, tersely, multiply your vector with a matrix. When you learn this, you also learn the vocabulary to talk about it.. and then you have human language that you are fluent in. Maybe someone else isn't, but that's ok, you don't need to hold back and we, for sure, shouldn't hold back the entire industry just because some programmers are unwilling to graduate from goto and for loops. (I think any field would be seriously held back if we couldn't make up new concepts and extend our vocabulary)
And like the symbols in math, symbols in K (and presumably other APLs) have names and a programmer who learned the language can just read a line of code out loud; it sounds quite like natural language, but probably comes closer to describing the entire solution than a corresponding read-out of the 50-line chunk of C that performs all these little steps and manipulations of temporary variables and individual array members to arrive at the same result.
For similar reasons, modern programmers tend to prefer stronger abstractions like folds, maps, or function composition to achieve some terseness (and eliminate unneeded variables and manual iteration). These generally bring the solution closer to what its description in a natural language would be.
After that, it gets a bit more controversial. How much whitespace do you need? How long are your identifiers going to be? How many assignments will you nest in a single expression?
My experience is that it gets easier to work with terse code if you get into it, and once you're into it, it actually does save you time (in reading and writing) while more verbose style becomes irritating to work with. It's like reading an article that gets sidetracked and says a lot but doesn't ever seem to get to the point, and once it's finally over, you realize you didn't get the point because it was buried in fluff.
(Fwiw, my personal style isn't quite Whitney level, but it's way more terse than what we have at work, and honestly the verbosity of work-code feels counter-productive to me.)
And so, aside from my opinion about how it is to work with terse code, there's another point: making the trees smaller makes it easier to see the forest for the trees. And if you really need to study the trees (because one of them is wrong and you have a bug?), well, you can still do it (because you learned how to work with terse code).
In other words, the point is actually to improve readability! It's the exact opposite of deliberate obfuscation, even if the end result might seem similar to the untrained eye.
Down this thread ben509 writes that > what you see with most languages is extensive commentary to help future authors understand what's going on, and that's partly because terse languages tend to be cryptic.
I'm not sure I agree. What I see with modern language developments is that they're trying to empower the programmer to make the forest smaller by eliminating the trees or making them smaller where it's feasible. We're making things higher level and more terse (but the APL family is way ahead of any mainstream language). It's the low level languages that make code seem cryptic, because you get lost in the low level details.
I still work with C day to day and the actual comments in the code bases I'm involved in tend to reflect this: C forces you to deal with lots of details (trees), and it is painfully easy to see them but not see what's actually going on at a higher level (the forest). So people write comments to explain what's going on.
And like the symbols in math, symbols in K (and presumably other APLs) have names and a programmer who learned the language can just read a line of code out loud; it sounds quite like natural language, but probably comes closer to describing the entire solution than a corresponding read-out of the 50-line chunk of C that performs all these little steps and manipulations of temporary variables and individual array members to arrive at the same result.
For similar reasons, modern programmers tend to prefer stronger abstractions like folds, maps, or function composition to achieve some terseness (and eliminate unneeded variables and manual iteration). These generally bring the solution closer to what its description in a natural language would be.
After that, it gets a bit more controversial. How much whitespace do you need? How long are your identifiers going to be? How many assignments will you nest in a single expression?
My experience is that it gets easier to work with terse code if you get into it, and once you're into it, it actually does save you time (in reading and writing) while more verbose style becomes irritating to work with. It's like reading an article that gets sidetracked and says a lot but doesn't ever seem to get to the point, and once it's finally over, you realize you didn't get the point because it was buried in fluff.
(Fwiw, my personal style isn't quite Whitney level, but it's way more terse than what we have at work, and honestly the verbosity of work-code feels counter-productive to me.)
And so, aside from my opinion about how it is to work with terse code, there's another point: making the trees smaller makes it easier to see the forest for the trees. And if you really need to study the trees (because one of them is wrong and you have a bug?), well, you can still do it (because you learned how to work with terse code).
In other words, the point is actually to improve readability! It's the exact opposite of deliberate obfuscation, even if the end result might seem similar to the untrained eye.
Down this thread ben509 writes that > what you see with most languages is extensive commentary to help future authors understand what's going on, and that's partly because terse languages tend to be cryptic.
I'm not sure I agree. What I see with modern language developments is that they're trying to empower the programmer to make the forest smaller by eliminating the trees or making them smaller where it's feasible. We're making things higher level and more terse (but the APL family is way ahead of any mainstream language). It's the low level languages that make code seem cryptic, because you get lost in the low level details.
I still work with C day to day and the actual comments in the code bases I'm involved in tend to reflect this: C forces you to deal with lots of details (trees), and it is painfully easy to see them but not see what's actually going on at a higher level (the forest). So people write comments to explain what's going on.