4 ms·
> Monads is taking it too far. Mutation is a reality, the correct approach is disciplined mutation. Shoving mutation into convenient boxes and convincing yourse
by gwn7 8y ago
> Monads is taking it too far. Mutation is a reality, the correct approach is disciplined mutation. Shoving mutation into convenient boxes and convincing yourself to never look inside it does not mean mutation does not exist.
Monads exist exactly because mutation is a reality. Monads do not defy the "mutation reality", nor try to encourage programmers to never look inside them. They are a means of dealing with the "mutation reality" by encouraging to separate pure and impure parts properly and while still making functional composition possible. The image you create for monads is a straw man. Monads ARE a kind of "disciplined mutation" as you put it.
You don't have to like them nor prefer them. But they are clearly a great and established abstraction loved and used by many. You may prefer Clojure, I get it, but I see no reason to talk shit about monads in this way. Have you ever used monads and similar abstractions extensively?
> Monads is taking it too far.
> Mathematical purity of programs is a myth propagated by Type theorists dont buy into it.
Those are big words. Are you some kind of authority? You could have at least prepended "I think" to those phrases.
- pankajdoharey 8y agoYou are repeating what i wrote, by writing this large comment you havent increased anyone knowledge neither mine nor yours. Monads exist because because haskell people want to pretend that there is this ideal mathematical world where things dont change, some go as far as saying Strong types removes the need for writing tests. > Those are big words. Are you some kind of authority? Yrs of writing programs have taught me that programming functions are not equivalent to mathematical functions, there is no equivalence that exist stop pretending that it does.
- neukoelln 8y ago> Monads exist because because haskell people want to pretend that there is this ideal mathematical world where things dont change Monads exist independently from Haskell and are not about "things that change".
- always_good 8y agoOnce again, monads are a form of "disciplined mutation." They didn't repeat what you wrote, they contradicted your entire premise. You didn't respond to anything they said and you doubled down with your nonsense about "Monads exist because because haskell people want to pretend that there is this ideal mathematical world where things dont change." That monads ignore the "mutation reality" isn't a very strong point when monads are a concession for the "mutation reality." Unless you want to repeat yourself a third time, the ball is in your court to bring concrete supporting arguments since you're making the extreme and somewhat self-aggrandizing claim that these other people don't really see the mutation reality of the world like you do, thus they are using inferior tools. I'd say that anyone specifically trying to corral/isolate their I/O code (monads or not) are so "enlightened" about the mutation reality of the world that they use specific abstractions to address it. If you want to see code that tries to paper over I/O, look at a program where you can't even tell when and where the I/O is performed because it just looks like any other function call. Active Record in Ruby on Rails might be a good candidate in its effort to make DB access opaque to the programmer.
- pankajdoharey 8y agoOK This has become a big feud, apologies for choosing the incorrect words and being rude. Let me put it another way by "disciplined mutation" all i meant was localised mutation. A lexically scoped local variable is enough to handle the spread of mutation, i dont see the need for a specific datatype to handle mutations exclusively. Monads make mutations explicit and global. I hope that makes sense.