4 ms·
Clearly you have no idea what you're talking about. I suggest first learning the language before spreading FUD about it. Separation of pure and unpure componen
by rastapasta42 12y ago
Clearly you have no idea what you're talking about. I suggest first learning the language before spreading FUD about it.
Separation of pure and unpure components greatly simplifies the reasoning about the problem domain. Traditional imperative programs are often full of subtle bugs because calling a procedure can have arbitrary effect on your system. For example calling function with the same arguments can return different values based on arbitrary hard-to-track reasons (such as your OS's scheduler). It's just too much details to keep in your head.
But in Haskell pure functions are guaranteed to have same result with same input. It enables the programmer to create logically isolated blocks without messy interdependencies.
It's especially helpful for concurrent programming by freeing you from all the non-deterministic spaghetti.
Haskell has a steep learning curve, but it'll make you a better programmer in the long run.
- nbevans 12y ago"But in Haskell pure functions are guaranteed to have same result with same input." I'm pretty sure that same law applies to a pure function in any language, not just Haskell. #shitthatHNsays
- codygman 12y agoCorrect. Though many languages don't encourage and as a result don't have nearly as many pure functions as Haskell code.
- guscost 12y agoIn fairness, I could also say that hammers don't encourage carpentry best practices and as a result they cause many more smashed fingers than wood glue. The fact that a tool doesn't prevent counterproductive usage patterns doesn't automatically make it inappropriate for every job.
- jbooth 12y agoPoint being, I/O doesn't square with that concept. For some reason, every time I point this out, I'm accused of not appreciating the beauty of pure functions. I love pure functions. Maybe they're not appreciating the ugly reality of I/O?
- dragonwriter 12y ago> Point being, I/O doesn't square with that concept. Sure it does, and composes well under it.
- jbooth 12y agoI'm seeing I/O as "side effects with possible random error conditions". I really don't see how that squares with functional purity. It's late on EST but I promise if you put effort into explaining a higher-order take on this I'll put effort into reading and understanding it tomorrow. Have a good night.
- codygman 12y agoThrough monads functional purity with I/O is achieved, ergo you can compose I/O and get other advantages of purity.
- codygman 12y agoHow much experience do you have composing I/O in Haskell to prove that I/O doesn't square with that concept? Others here have experience using Haskell with I/O, but you just seem to have a hypothesis without experience or examples to support it.
- Dewie 12y agoWhat "pure" means varies from language to language.
- nbevans 12y agoIt really does not.