Thanks for the link. I've tried and tried to understand monads, with little success. It's lead me to the conclusion that monads won't easily become one of the dominating approaches to program organization. This is because, as the document says, without an understanding of category theory, "it's like talking about electricity without using calculus. Good enough to replace a fuse, not good enough to design an amplifier." Yet the "easy introduction" to category theory in this document (and every other I've read) is anything but easy for software engineers otherwise unconcerned with advanced or abstract mathematics.
For monads to gain widespread support, someone will have to do a few things. First encode monadic operations into the OOP features of Java or C#. Then use them to solve a bunch of problems familiar in those cultures in a way that the gains are substantial and obvious, without incurring the overhead of a complete code reorganization. Essentially, monads will have to find a bunch of back doors into the engineering toolbox, a little like LINQ in C# (the IQueryable API, not the special query syntax). Monads tutorials are simply not going to get the job done. On Aug 31, 12:45 pm, Raoul Duke <rao...@gmail.com> wrote: > http://patryshev.com/monad/crashcourse.pdf > (via SVP) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
