I personally question the utility of such terseness, and much prefer the verbosity of the Lisp family of languages, where cultural norms make for function names like "number-to-string" and "expand-file-name", rather than the norms I've seen in languages like APL, K, J, Q, OCaml, and Haskell, which seem to love more mathematically-inspired single-letter names like "n" or "k", and various operators in a similar vein.
The Lisp-like way of programming is more appealing to me because it makes the programs very easy to read. You can mostly get a sense of what they're doing just by reading them like ordinary English. I've found this especially useful when I'm trying to understand code I'm not already familiar with, or when looking at my own code months or years from when I wrote it, and it's especially important these days when polyglot programming is commonplace -- I don't need to remember nearly as much of how to do something in Lisp because it's so easy and straightforward and doesn't have the overhead of remembering a whole bunch of specialized syntax.
Contrast this with the terser, more mathematically-inclined languages, where specialized syntax and single-character names are widely used. These tend to be more write-only languages for me, where I have to be constantly steeped in the language in order to make understanding it relatively natural, and if I go away from them for a while, it takes quite a bit of effort to get back in to them enough to make sense of what was written, and reading other people's code is much more of a chore than it is for me in Lisp.
In the old days, or perhaps on embedded systems these days, when one had to closely watch the byte count of one's program lest it not fit in to memory, perhaps such terseness was useful. But these days, I'm not yet convinced of its utility outside of a mathematical context, where the mapping of such terse names and operations is more natural.
For me clarity trumps terseness.