4 ms·

From what little I've used Haskell, the strings-as-list paradigm was exceptionally useful. A lot of people also complain about the performance of strings in Ha

by drblast 16y ago

From what little I've used Haskell, the strings-as-list paradigm was exceptionally useful. A lot of people also complain about the performance of strings in Haskell, so this is right where the tradeoff is today. Tomorrow it won't likely be an issue. A really smart compiler should be able to optimize most of the inefficiency away; I'd bank on compilers improving fast enough to make seemingly inefficient things cost much less. If I'm designing a language today for the future, I'd err on the side of usefulness.

silentbicycle 16y ago
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 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.
- jimbokun 16y ago
  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?
  - silentbicycle 16y ago
    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.
eru 16y ago
> 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.
chc 16y ago
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.

by drblast 16y ago

silentbicycle 16y ago

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 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.

jimbokun 16y ago
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?
- silentbicycle 16y ago
  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.

eru 16y ago

> 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.

chc 16y ago

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.