3 ms·

> Like the article explains, laziness is a big part of this. I don't think the article does a good job addressing this. They have a conclusion they want to get

by bmitc 4y ago

> Like the article explains, laziness is a big part of this. I don't think the article does a good job addressing this. They have a conclusion they want to get to, but I don't see how they get there with the arguments provided. Languages that are eager by default but support lazy evaluation are also not really discussed, and it's because they are the best of both worlds. Yes, lazy evaluation has its pluses, but more often than not, you don't need it. So it's better to have optional lazy evaluation and then reach for it when you really need it. F#, OCaml, Racket, Elixir, etc. work this way. And F# and Elixir, especially, heavily use compositional code with pipelines. The article states: > On a strict FP language, you end up writing more explicitly recursive functions (hopefully with tail calls) than using higher order functions that express your intent. That is not my experience at all, and I haven't seen anything that supports that. Lastly, Idris has a short FAQ as to why it's eager by default: https://docs.idris-lang.org/en/v1.3.4/faq/faq.html#why-does-idris-use-eager-evaluation-rather-than-lazy https://docs.idris-lang.org/en/v1.3.4/faq/faq.html#why-does-... And that addresses something else the article doesn't get at. Preciseness and explicitness make code much easier to reason about. Lazy evaluation increases mental burden.

sfvisser 4y ago
> Lazy evaluation increases mental burden. In some situations, definitely! In other situations, definitely not! My experience with writing Haskell application code is that you’re thinking way less about the runtime operational aspect of your code than in any other language. The burden is much lower. The exceptions are possibly when writing low level library code that involves a lot of IO and steaming. Or when storing a lot of data in-memory for longer periods of time.
runeks 4y ago
> Languages that are eager by default but support lazy evaluation are also not really discussed, and it's because they are the best of both worlds. Yes, lazy evaluation has its pluses, but more often than not, you don't need it. What makes you say strictness is the right default? I write Haskell at my day job, and I practically never experience crashes due to space leaks. And given that strictness has its own performance issues (unnecessary evaluation), it’s not clear to me that either is the “right” default.
shirogane86x 4y ago
As someone who worked with F# professionally for multiple years, I think I can quite confidently say that laziness is not ergonomic in F#, at all. I've tried making use of it many times, but because you have to explicitly delay and force values all over the place, it infects and dirties up code whenever you try to use it. Idris(at least idris2) gets a bit closer with the implicit delaying and forcing, but changing a value from lazy to strict and viceversa still modifies the signature, which is kind of annoying in my opinion. Compared to Haskell, where I can just add bangpatterns and sprinkle `!` in a few places, it's still less ergonomic. I feel like there isn't really a good implementation of strict-by-default but lazy-on-demand functional programming that is ergonomic and gets out of the way, quite yet.

by bmitc 4y ago

sfvisser 4y ago

> Lazy evaluation increases mental burden. In some situations, definitely! In other situations, definitely not! My experience with writing Haskell application code is that you’re thinking way less about the runtime operational aspect of your code than in any other language. The burden is much lower. The exceptions are possibly when writing low level library code that involves a lot of IO and steaming. Or when storing a lot of data in-memory for longer periods of time.

runeks 4y ago

> Languages that are eager by default but support lazy evaluation are also not really discussed, and it's because they are the best of both worlds. Yes, lazy evaluation has its pluses, but more often than not, you don't need it. What makes you say strictness is the right default? I write Haskell at my day job, and I practically never experience crashes due to space leaks. And given that strictness has its own performance issues (unnecessary evaluation), it’s not clear to me that either is the “right” default.

shirogane86x 4y ago

As someone who worked with F# professionally for multiple years, I think I can quite confidently say that laziness is not ergonomic in F#, at all. I've tried making use of it many times, but because you have to explicitly delay and force values all over the place, it infects and dirties up code whenever you try to use it. Idris(at least idris2) gets a bit closer with the implicit delaying and forcing, but changing a value from lazy to strict and viceversa still modifies the signature, which is kind of annoying in my opinion. Compared to Haskell, where I can just add bangpatterns and sprinkle `!` in a few places, it's still less ergonomic. I feel like there isn't really a good implementation of strict-by-default but lazy-on-demand functional programming that is ergonomic and gets out of the way, quite yet.