[lmm]

Consider e.g. traverse, which is a function you simply can't write in a language without higher-kinded types. Several times I've written half a page of code only to realize "that's just traverse" or "that's just foldMap" or so on. In a less expressive language I would've had to leave that half-page as is. Surely that means the expressiveness results in more readable, less complex code?

[enneff]

Sounds more like boilerplate or redundancy to me than complexity. Things I would call "complex" in a software system are god objects, APIs with too many options, invisible interactions between parts that appear unrelated, and so on.

[lmm]

Fair enough. In that case I'd say expressive languages help, but only indirectly, because they make it possible to keep track of effects and interactions without having to write reams of code.

In a language with lenses, you can delimit where your models are mutated. In a language that lets you treat composable effects in a generic way, you can e.g. split up your variables explicitly with ReaderWriterState, making it clearer which serves which purpose.

The kind of things you might be tempted to use "magic" or global variables for in a lesser language - the "cross-cutting concerns" - you can instead handle in normal code as a generic kind of context. E.g. an audit trail can just be Writer. Or actions that need access to a database session can just be another kind of context. I'm working on such a thing right now (see tpolecat's doobie for a public example of the same kind of thing) - whether a function accesses the database or not is visible right in its type, but it's easy to compose functions that do. The types ripple up, and in the end I'm probably going to do session-creation-in-view - but in a principled way, using the ordinary type system, visible in the code - with Spray, my web route definitions are just another ordinary bit of Scala code (whereas in most languages I would define routes in an external config file, or at best a config object a la Django - adding complexity).

Heck, error handling is a perfectly good example of this. In a less expressive language, the only way around the boilerplate of handling errors where they occur is unchecked exceptions (or effectively-unchecked exceptions, as in "throws Exception"). In a language with good generic context support, the possibility of failure is just another kind of context that we compose with the same generic tools as any other, and the control flow becomes something sensible again.