3 ms·
All high-level languages with optimising compilers have "non-compositional performance" as you say. The big issue with laziness is reasoning about space usage.
by willtim 6y ago
All high-level languages with optimising compilers have "non-compositional performance" as you say. The big issue with laziness is reasoning about space usage. A strict language is not immune to this however. If one builds lazy abstractions (e.g. Streams, collection views) in Scala, then one has the same problems.
- lmm 6y ago> If one builds lazy abstractions (e.g. Streams, collection views) in Scala, then one has the same problems. Sure. There's nothing to stop you using lazy values in a strict language if you want to; it's just that you get the option of using strict values as well. Whereas in Haskell you have no way of building strict constructions other than some ad-hoc annotations.
- jose_zap 6y agoThere is the -XStrict language pragma that makes everything strict.
- lmm 6y agoHmm, interesting. Is it actually a viable language for working in? (Lack of an IDE would still be an issue, as would the limitations of the record system, but I'd certainly be more interested in Haskell if strict was a first-class way of working there).
- jose_zap 6y agoYou can check the Ghcide and the (early work in progress but very usable) haskell-language-server projects. They implement the language server protocol and add ide-like functionality for Haskell to any editor that support the protocol like vscode. I totally agree that the records system is annoying.