4 ms·
I don't know what I'm supposed to take away from this. (beyond the well-established Haskell-esque effects bad)
by refulgentis 3y ago
I don't know what I'm supposed to take away from this. (beyond the well-established Haskell-esque effects bad)
- curryhoward 3y agoCitation needed on "well-established". I find myself often benefiting from Haskell's disciplined approach to effects.
- refulgentis 3y ago" (beyond the well-established Haskell-esque effects bad)" read that as: "beyond the well-established idea, from Haskell, that side effects are troublesome and need to be explicitly modelled and thought about."
- curryhoward 3y agoAh, I think your clarification makes a lot more sense than your original phrasing, because Haskell's position is indeed that side effects are bad, not that effects are bad. The bad thing is "side", not "effects".
- mrkeen 3y agoAnother possible takeaway is to start from something 'principled' (for whatever definition of principled you like) and then add functionality, rather than starting on shaky ground and trying to patch it up later. From memory the example in the video was 'pure functions first - then figure out IO'. But it could just as easily apply to memory safety, or nulls. Why build a new language with state-of-the-art static analysis for detecting nulls, when you could just refrain from putting nulls into your new language?