[jacquesm]

I think this is all somewhat related to how much you can keep in your head at once. More code -> less expression -> less that you can keep in your head -> you can solve smaller problems.

If a problem requires that you keep all of it in your head then being able to express that problem concisely will aid in solving it.

The poor mans solution is to reduce the scope: chop the problem into sub-problems that you can solve individually.

Divide and conquer is the most powerful tool in a programmers arsenal because it allows you to use the worst languages to solve some of the most complicated problems.

But there may be a subset of problems where that strategy no longer works and for those problems the more compact languages may have a very strong advantage.

[sacado2]

It's a double-edged sword, though : your compact, clever solution is great when your write it but becomes unreadable when you (or worse, someone else) tries to maintain it. And then you have to understand both the hard problem and the way it was solved in the first time.

[lmm]

The main way to make code genuinely shorter is to actually make it simpler; replacing logic with a higher-order function call (e.g. map rather than a loop) makes it more readable and maintainable, not less. Or if we're talking about meaningless syntactic clutter like the extra lines of begin/end, they don't make the code any clearer.