4 ms·

>Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in. +1 On

>Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in. +1 One approach that occurred to me was to use Haskell and Hackage for prototyping a design and then a Rust implementation for production. It also reminds me of this from several years ago: GHC honcho Simon-Peyton Jones saying the next Haskell will be strict, but still pure with effects only via monads. [1], [2]. Following on and presumably related to that PureScript is strict. [3] [1] https://news.ycombinator.com/item?id=1924094 https://news.ycombinator.com/item?id=1924094 [2] http://www.cs.nott.ac.uk/%7Egmh/appsem-slides/peytonjones.ppt http://www.cs.nott.ac.uk/%7Egmh/appsem-slides/peytonjones.pp... (PowerPoint) Slide 40 [3] https://github.com/purescript/purescript/wiki/Differences-from-Haskell https://github.com/purescript/purescript/wiki/Differences-fr...

mrkgnao 9y ago
I'm under the impression that SPJ made that comment thinking of adoption (for a future "regrettably popular" Haskell), since the difficulty of reasoning about laziness does put people off. I might be wrong though: maybe he was arguing that laziness doesn't warrant the user and compiler-author cost it brings. I don't remember where I picked this up from. Idris is strict too, but optional laziness is built into the compiler with the use of a special-cased Lazy wrapper of the form data Lazy a = Delay a This is kind of the opposite of strictness annotations (bang-patterns) from Haskell, except one doesn't need to pattern-match on Delay or use it to wrap arguments to functions expecting Lazy values. The Idris compiler can do something like "laziness analysis" (admittedly trivial in comparison to GHC's strictness analyser) to introduce and eliminate Delay constructors automatically. The laziness information is carried around in the types: force : Lazy a -> a force a = a https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ#can-i-have-lazy-evaluation-if-i-want-it https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ#... (purescript-lazy is also a thing, but I think it's not as seamless because of the "no compiler magic" position.) In any case, what about -XStrict? I've never used it (or -XStrictData either), but isn't it a solution to the laziness problem, albeit a nuke-ish one at that? And while we're thinking ahead, let's talk about the project to get linear types (something similar to Rust lifetimes, but weaker) into GHC :) https://ghc.haskell.org/trac/ghc/wiki/LinearTypes https://ghc.haskell.org/trac/ghc/wiki/LinearTypes
- logicchains 9y ago
  >something similar to Rust lifetimes, but weaker Why weaker? My understanding is that linear types provide a stronger guarantee than Rust's affine types: linear types guarantee that a value is used once, while affine types only guarantee that a value is used no more than once.
  - Jweb_Guru 9y ago
    Lifetimes are not the same as linear (or affine) types... they're related to "fractional permissions" in the upcoming formalism (and also related to region types found in many other systems, which can be partially emulated with monads).
arianvanp 9y ago
SPJ also noted that the original success of haskell was due to their pursuit of laziness. Because laziness has no place in a system with side effects, their pursuit of laziness and functional programming is what led them to discover the usefulness of monads for describing it in the first place. If they were pursuing a strict language instead, then they were allowed to take shortcuts, because sneaking in side effects is a lot easier. YEs maybe the next haskell will be strict, but getting to the point to make that decision required laziness. SPJ made a great lecture about this. It is very easy to follow and a fun insight into the academic history of modern functional languages https://www.youtube.com/watch?v=re96UgMk6GQ https://www.youtube.com/watch?v=re96UgMk6GQ
vmchale 9y ago
>GHC honcho Simon-Peyton Jones saying the next Haskell will be strict, I think all he meant that strictness was an interesting paradigm that would differentiate a language enough to justify its existence alongside Haskell. >Following on and presumably related to that PureScript is strict Partly also to distinguish from GHCJS. Laziness in a strict language is really hard and PureScript generates semi-readable JavaScript.

mrkgnao 9y ago

I'm under the impression that SPJ made that comment thinking of adoption (for a future "regrettably popular" Haskell), since the difficulty of reasoning about laziness does put people off. I might be wrong though: maybe he was arguing that laziness doesn't warrant the user and compiler-author cost it brings. I don't remember where I picked this up from. Idris is strict too, but optional laziness is built into the compiler with the use of a special-cased Lazy wrapper of the form data Lazy a = Delay a This is kind of the opposite of strictness annotations (bang-patterns) from Haskell, except one doesn't need to pattern-match on Delay or use it to wrap arguments to functions expecting Lazy values. The Idris compiler can do something like "laziness analysis" (admittedly trivial in comparison to GHC's strictness analyser) to introduce and eliminate Delay constructors automatically. The laziness information is carried around in the types: force : Lazy a -> a force a = a https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ#can-i-have-lazy-evaluation-if-i-want-it https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ#... (purescript-lazy is also a thing, but I think it's not as seamless because of the "no compiler magic" position.) In any case, what about -XStrict? I've never used it (or -XStrictData either), but isn't it a solution to the laziness problem, albeit a nuke-ish one at that? And while we're thinking ahead, let's talk about the project to get linear types (something similar to Rust lifetimes, but weaker) into GHC :) https://ghc.haskell.org/trac/ghc/wiki/LinearTypes https://ghc.haskell.org/trac/ghc/wiki/LinearTypes

logicchains 9y ago
>something similar to Rust lifetimes, but weaker Why weaker? My understanding is that linear types provide a stronger guarantee than Rust's affine types: linear types guarantee that a value is used once, while affine types only guarantee that a value is used no more than once.
- Jweb_Guru 9y ago
  Lifetimes are not the same as linear (or affine) types... they're related to "fractional permissions" in the upcoming formalism (and also related to region types found in many other systems, which can be partially emulated with monads).

arianvanp 9y ago

SPJ also noted that the original success of haskell was due to their pursuit of laziness. Because laziness has no place in a system with side effects, their pursuit of laziness and functional programming is what led them to discover the usefulness of monads for describing it in the first place. If they were pursuing a strict language instead, then they were allowed to take shortcuts, because sneaking in side effects is a lot easier. YEs maybe the next haskell will be strict, but getting to the point to make that decision required laziness. SPJ made a great lecture about this. It is very easy to follow and a fun insight into the academic history of modern functional languages https://www.youtube.com/watch?v=re96UgMk6GQ https://www.youtube.com/watch?v=re96UgMk6GQ

vmchale 9y ago

>GHC honcho Simon-Peyton Jones saying the next Haskell will be strict, I think all he meant that strictness was an interesting paradigm that would differentiate a language enough to justify its existence alongside Haskell. >Following on and presumably related to that PureScript is strict Partly also to distinguish from GHCJS. Laziness in a strict language is really hard and PureScript generates semi-readable JavaScript.