4 ms·
It is made explicit and verbose in that contrived example because it specifically an example of those things. I am having a really hard time believing that you
by asdasf 13y ago
It is made explicit and verbose in that contrived example because it specifically an example of those things. I am having a really hard time believing that you genuinely don't understand this obvious fact.
- Chris_Newton 13y agoOf course I understand that this is a contrived example. What I don’t accept — without evidence to the contrary — is that it is unrepresentative. Would more “serious” examples of implementing stateful algorithms using monads and similar tools not be similarly verbose, given the explicit nature of such details in Haskell? Maybe that really is true for experts, in which case I would be happy to learn about it and update my views. Examples are welcome. For now, I have never personally seen it, and it’s not immediately obvious to me how Haskell code would beat a dedicated imperative language at its own game in terms of conciseness. Correctness guarantees, sure. Performance, maybe, if we reach the point where powerful optimisations are possible in Haskell because of the extra information available. And for conciseness, I’m not suggesting it’s orders of magnitude worse or anything silly like that. But when, by design, your effects and sequencing have to be singled out and specified explicitly every time, you’re starting at a disadvantage compared to systems that incorporate that behaviour implicitly. Please also see my comments on quicksort elsewhere in this thread.