Rubbish. I've worked with a dozen languages, and its unquestionable that certain ones attact a high ratio of terse complicated code.
Clojure is specifically renouned (and celebrated) for its low LOC counts; people go as far as saying (literally on /r/clojure) given a choice of library, pick the one with a lower LOC.
That's not because people write simple pointless libs like lpad; its because the community actively encourages terse complicated code.
I've seen this logic about choosing a library but I think you are attributing a different rationale to it. I've seen it said if you find more than one library doing what you need, go through a hierarchy of criteria to choose and choose the first one that wins; in the event of a tie, evaluate the next point
1. pick the one with the most readable, understandable architecture
2. choose the one that focuses more on what you are looking for and not a slew of different things
3. choose the one with fewer lines of code
This third point is not "choose the more clever library" but more along the lines of choose the more straight forward and simple library. It's not code density you are evaluating but focus.
But honest question: Does where you work in the stack, meaning the level of abstraction, matter for language choice? Or vice versa?
I've written a few parsers in Java. Not terrific but not terrible either.
My (future) interest in Clojure is CSP. Mostly because I'm tired of wrestling with concurrency. But I'm not sure I'd want to be doing data processing with it.
Clojure is specifically renouned (and celebrated) for its low LOC counts; people go as far as saying (literally on /r/clojure) given a choice of library, pick the one with a lower LOC.
That's not because people write simple pointless libs like lpad; its because the community actively encourages terse complicated code.