4 ms·
> Monads can help solve certain classes of problems in a uniform way. You solve 3 completely different problems using the exactly same code and have the gall t
by vesak 9y ago
> Monads can help solve certain classes of problems in a uniform way.
You solve 3 completely different problems using the exactly same code and have the gall to call this less complicated? I'm forced to sometimes wonder whether functional programmers have any idea how to create software.
If this was a joke I didn't understand, I apologise for my thickness.
- greydius 9y agoIt's called abstracting. The problems fit the Monad interface. Details are in the implementations.
- deleted 9y ago[deleted]
- eklavya 9y agoI hope you are joking or else a lot of people like me who don’t have any idea about software are just somehow fooling everyone quite successfully :)
- deleted 9y ago[deleted]
- naiveai 9y agoPersonally, I feel the reason we think of these as completely different problems is that it isn't necessarily natural to see the abstraction between all of them. I don't understand monads fully myself, but it's still kind of missing the point to say this.
- deleted 9y ago[deleted]
- empath75 9y agochaining together the outputs of these very different problems is the same problem, and should be solved the same way. The implementation details are within the monads themselves, not the do block.
- Davidbrcz 9y agoThat's pretty much the point. I'll detail the first example (the Maybe monad). The idea is that you have a maybe object that is either an just an object (denoted Just(a)) or nothing at all (denoted Nothing). If you want to manually apply a function f on object m, the code would look like this if(m is Just(a)){ f(a) } else{ // there is nothing to do } You can take f as a parameter to create a generic function apply. You want to your new function to be total (to return a value in all cases). Since you may (or may not) have a value within the maybe monad, the return type is also a Maybe value. If there was no value, then return Nothing, else apply `f` on `a` and wrap it back within the JUst part of the monad. The code looks like this. apply(m,f){ if(m is Just(a)){ return Just(f(a)) } else{ return Nothing. } } From an initial maybe value m, you can chain calls: apply(apply(apply(m,f),g),h) With a bit of syntactic sugar, the code looks like this. do m <- getData b <- f a c <- g b d <- h c print d And the code is similar for the others cases. In all solutions, <- denotes an apply function on some monad. There is a function for each type of monad and it is responsible for doing all repetitive plumbing according to the given type of the monad. I hope it helps =)
- vesak 9y agoYou (and the other repliers) seem to be confused. It's not that I don't understand monads, it's that I don't value them. It seems obvious to me that they serve mostly to harm code quality.
- IncRnd 9y ago> You solve 3 completely different problems using the exactly same code and have the gall to call this less complicated? That's the point, though. If the code is identical, then the problems are identical. There is less complexity through abstraction.
- HelloNurse 9y agoThe problems are indeed similar, but using the same syntax and obscuring what monad is being used is itself a worse programming language hell than the original bad examples.
- IncRnd 9y agoWhy is recognizing the fundamental sameness of the problems, and solving them once, a "worse programming language hell"?
- vesak 9y agoBecause that sameness is irrelevant, and building something on it decreases clarity. Just because you can show something in mathematical terms doesn't make it useful.