4 ms·

Can't it be both?

dunefox 6y ago
Sure, but I believe that Haskell is great just because it tries stuff that isn't in other languages, like laziness by default. If it's really a pain point you can always switch to Ocaml or others.
- logicchains 6y ago
  Seems like an overreaction to suggest someone move to another language when there's a very simple solution to laziness in Haskell: the -XStrict language pragma.
- Vosporos 6y ago
  >If it's really a pain point you can always switch -XStrict on FTFY
  - hopia 6y ago
    Is that flag really ever smart to switch on? I've heard StrictData makes a lot more sense but turning Strict on prevents the compiler from making some quite crucial optimizations, resulting in degraded performance.
    - logicchains 6y ago
      Which optimisations does it prevent? I've heard laziness prevents a lot of optimisations, because it makes bottom an instance of every type, and the compiler has to account for that.
      - Tarean 6y ago
        There are two main parts to this: - GHC can do less unpacking (moving heap allocations to registers)because of laziness - laziness as an implementation detail is slow To implement laziness, GHC puts a closure with it's environment on the heap. When the value is used for the first time, the closure is called. Then the result is put on the heap, the closure is replaced with an indirection to the result, and the program continues. But this also has some advantages: - For values that might be used zeor or multiple times, this often actually saves time on average over both strict or call-by-name evaluation - This is faster than any equivalent code you can write by hand because compiler and runtime system heavily optimize around it - This gives you mutation through the backdoor which allows asymptotic improvements over strict pure languages in some cases But the main thing is that laziness allows runtime dead code elimination - if you have an unpacked vector of pairs and only use the left element of each pair, only those values will be allocated - still in a dense bytearray.

Can't it be both?

Sure, but I believe that Haskell is great just because it tries stuff that isn't in other languages, like laziness by default. If it's really a pain point you can always switch to Ocaml or others.

logicchains 6y ago
Seems like an overreaction to suggest someone move to another language when there's a very simple solution to laziness in Haskell: the -XStrict language pragma.
Vosporos 6y ago
>If it's really a pain point you can always switch -XStrict on FTFY
- hopia 6y ago
  Is that flag really ever smart to switch on? I've heard StrictData makes a lot more sense but turning Strict on prevents the compiler from making some quite crucial optimizations, resulting in degraded performance.
  - logicchains 6y ago
    Which optimisations does it prevent? I've heard laziness prevents a lot of optimisations, because it makes bottom an instance of every type, and the compiler has to account for that.
    - Tarean 6y ago
      There are two main parts to this: - GHC can do less unpacking (moving heap allocations to registers)because of laziness - laziness as an implementation detail is slow To implement laziness, GHC puts a closure with it's environment on the heap. When the value is used for the first time, the closure is called. Then the result is put on the heap, the closure is replaced with an indirection to the result, and the program continues. But this also has some advantages: - For values that might be used zeor or multiple times, this often actually saves time on average over both strict or call-by-name evaluation - This is faster than any equivalent code you can write by hand because compiler and runtime system heavily optimize around it - This gives you mutation through the backdoor which allows asymptotic improvements over strict pure languages in some cases But the main thing is that laziness allows runtime dead code elimination - if you have an unpacked vector of pairs and only use the left element of each pair, only those values will be allocated - still in a dense bytearray.