The problem with "sufficiently smart compilers" is that they can make reasoning accurately about performance difficult. James Hague has a good post about that, "On Being Sufficiently Smart" (http://prog21.dadgum.com/40.html).

Lua does almost no optimization at compile time* (in part so it can compile data dumps rapidly) but I find it easy to predict the performance trade-offs in various implementation choices. In a roundabout way, it still ends up easy to tune.

Still, usefulness and performance are only indirectly related. I think that was PG's original point.

* Yet oddly it ends up quite a bit faster than Python, and there's also LuaJIT.

That's a great article. Which raises the question, do you want predictable performance, or better expected performance with occasional inexplicably slow outliers? Is it impossible to have both with high level languages? Can it be made configurable?

His blog has a lot of gems. The functional retrogames series, in particular.

Even if it can be made configurable, adding all those knobs and dials may add a lot of complexity.

> From what little I've used Haskell, the strings-as-list paradigm was exceptionally useful.

It's useful from a convenience of programming point of view. The preferred underlying implementation is now something more sophisticated than a linked list of characters. See Data.ByteString. The programmer does not need to care much, though.

IIRC, most of the slowness of Haskell's String type comes from prioritizing Unicode support over performance, not from the speed of lists, per se.