Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think Haskell accommodates imperative programming so well that it surpasses many imperative languages and beats them in their own game.

I also think the name "purity" is misleading. In the context of Haskell it means:

* Referential Transparency: references to things are indistinguishable from those things. This helps a lot with equational reasoning about code, optimizations and all sorts of mechanical refactorings. I don't think there are significant disadvantages here.

* Typed effects: Haskell types its effects and requires explicit composition of effects and not just of values. This, in turn, turns "side effects" simply into "effects" because they are so explicit. This has some disadvantages, mainly regarding learning curve. If you get a pure function type, you are guaranteed many of useful things about its behavior. The flip side of this, is that if you want to change a pure function to have effects and break these guarantees, you will have to change its type and somewhat restructure it.

Haskell doesn't "get ugly fast" in any circumstance I've seen. It accomodates an extremely wide array of paradigms as pretty encodings on top of its own functional paradigm.



I completely agree, in fact I've been trying to show people how well Haskell can encode imperative programs.

See https://github.com/DanielWaterworth/Musings/blob/master/why_... and https://github.com/DanielWaterworth/Musings/blob/master/comp...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: