C++17: I See a Monad in Your Future

Re:C++17: I See a Monad in Your Future by barrkel on Thursday February 27, 2014 @06:02PM (#7315900)

They are simple concepts, just more abstract than you're used to. They actually turn up all over the place - they're a bit like classes were before object orientation was popular, and everybody was building structs filled with function pointers in C in order to emulate polymorphism. The things these concepts address are things you're doing in your code today, by hand, and don't realize how they can be compressed, mostly because C++ has historically lacked a concise notation for type-inferred lambdas.

They're able to turn a lot of algorithms inside out; make the kernel a simple function of values where they used to be threaded through the code flow, and use things like bind to mix them back in. This makes algorithms testable and more composable, and raise the level of abstraction in the rest of your code so that you're operating more at the DSL level for your domain, whatever it is.

It's worth learning the concepts. Once you do, you'll be surprised that there's so little "there" there.

And their commonality and generality are exactly the reasons why they should have short yet precisely general names.

[ Parent | on HN ]

Re:C++17: I See a Monad in Your Future by dclinton on Saturday March 01, 2014 @01:27PM (#7325431)

Most of the comments on here seem to be talking about whether the name is good or not. For me, the question isn't what a 'monoid' is called, or whether it can be defined in a few lines of English, but rather what it is that they are useful for.

I've been using Scala full time for a couple of years now, but it took me ten months to really understand not just what monads are, but how they are useful in expressing a program from a different perspective to other approaches, and the benefits that come from that. Now I use them all the time and see how they add huge benefits to my code.

In all the time that I've been working with Scala, and building my knowledge and experience of how to apply functional principles usefully, I have yet to (knowingly) use a Monoid, or encounter a situation where it was clear that they would have a benefit. I'm not saying that there are no such situations, and it may be that there have been situations where they would have been useful, but I didn't know it, and I would love to be able to add them to my toolbox. However, I do see that a lot of the time these concepts are introduced in a very abstract way and what it missing is not the simple definition, but rather some clear idea of when, how and why to use them.

[ Parent | on HN ]