7 ms·

Monads in C++

80 points by VeXocide 15y ago

swah 15y ago
How long did it take you guys to read this post?
- hsmyers 15y ago
  Don't know---haven't finished and I won't until I understand the damn thing ;)
- palish 15y ago
  About fifteen seconds. Skimmed it, realized it was "another instance of someone attempting to do yet-another-bad-thing-in-C++", then closed it. I went through the same phase in my C++ career. (Mine was attempting to add FOREACH to my projects without depending on Boost.) I think at some point every C++ dev gets tired of writing boilerplate code, and then spends the next few days implementing something that would've otherwise taken them a few hours. Once you accept that C++ is not Lisp, and doesn't need to be, then you become much more productive. Additionally, your resulting C++ code is much more likely to actually be used by other C++ engineers. Lastly, these sorts of libraries tend to be very difficult to debug unless you were the one who wrote it.
  - pvarangot 15y ago
    It's in fact an attempt to explain how the author got to understand the inner workings of Boost's Proto library, which is already available for C++ and pretty much a successful project as far as it goes. For people also into Haskell, it's a very concise and insightful attempt indeed. I understand your rant, but I'm not sure this is the place to go and spew it... Actually some people enjoy studying programming languages themselves and sometimes come up with useful stuff for engineers that like building more concrete stuff.
    - Rusky 15y ago
      You can study programming languages themselves without misusing C++ features in horrible ways. Monads are already overused and misunderstood- using them in C++ templates just makes things worse.
      - Peaker 15y ago
        > Monads are already overused and misunderstood- using them in C++ templates just makes things worse. Where are they overused?
        Hemospectrum 15y ago
        In Haskell, mostly. This is probably because most Haskell programmers learned about monads without understanding applicative functors, which are more general and a much better fit for a lot of tasks.
        Rusky 15y ago
        They are an overly-specific interface to what can usually be done with applicative functors or even just functors. This trend originated with Haskell and then when people who learned monads without understanding the other (often better) abstractions spread them everywhere else, we got things like this article. Using monads, especially in a language like C++ templates or Scala, but also in Haskell, can overcomplicate things and make things longer than if you just solved the problem the direct way. -- As an example of where monads are overused, look at the Maybe/Option type. I've read several articles that advocate using bind and/or Haskell's do-notation to move a string of null checks out of the main program. This is great, but it's much more easily and expressively done with applicative functors. Instead of assigning all the intermediate results to names, you can just do someFunction <$> Just 3 <*> Just "Something" and it looks like regular function application. Because Applicative is a more general interface that Monad, it also has the plus of working with more types.
        Peaker 15y ago
        I agree that Applicative should be used when possible. I think the Maybe example may be wrong, though. You may need the power of Monads sometimes. If you have a function that requires the result of a different function which was wrapped in Maybe, Applicative will not be enough. Example: xmlChild :: String -> Element -> Maybe Element Now you might want to do something like: myPath = xmlChild "a" >=> xmlChild "b" >=> xmlChild "c"
  - pnathan 15y ago
    Frankly, I think that the big problem with C++ (and other larger languages) is the engineers who keep trying to use some minimal subset of it, pointing at the Blub+1 capabilities and screaming about how they can't understand it.
    - palish2 15y ago
      I understand the concepts just fine, thanks. My argument was against the mentality "C++ could be made to do... anything". Sure, it could. But it's a Really Bad Idea. If I had to write a C++ program to do this: data Exp = Const Integer | Plus Exp Exp | Times Exp Exp | Arg1 | Arg2 ... then I would embed Lua + LPeg ( http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html#ex http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html#ex ) and write the parser in that. A simple, readable, and maintainable solution. http://en.wikipedia.org/wiki/Parsing_expression_grammar http://en.wikipedia.org/wiki/Parsing_expression_grammar
  - fnl 15y ago
    Lambda-calculus and monads are not necessarily Lisp-specific, neither would I call his syntax that (if only because he uses Haskell ->s instead of Lisp ()s :). See http://www.lfcs.inf.ed.ac.uk/reports/88/ECS-LFCS-88-66/index.html http://www.lfcs.inf.ed.ac.uk/reports/88/ECS-LFCS-88-66/index.... I liked the article, maybe it will be something to think about in some distant cpp. Although I tend to agree to your last argument about "using somebody else's DSL..." :)
- pnathan 15y ago
  Five minutes or so. Likening Haskell to C++ TMP makes a good deal of sense to me.
  - thesz 15y ago
    There was an attempt to use Haskell DSeL to simplify C++ template metaprogramming. http://boostcon.boost.org/program/schedule#schedule.milewski-haskell-the-pseudocode-language-for-c-template-metaprogramming http://boostcon.boost.org/program/schedule#schedule.milewski... Unfortunatelly, slides are gone.
bandushrew 15y ago
This is fantastic. The idea that C++ meta programming is most easily understood as an (unnecessary complicated) functional language actually makes a huge amount of sense to me, and I particularly enjoy the lovely sense of balance it invokes.
Miky 15y ago
This is the worst example of cargo cult programming I've seen in a good while.
- Miky 15y ago
  OK, downvotes. Why, exactly? I'm not trying to troll. Monads as commonly explained on blog posts are cargo cult mathematics, and monads used in languages like C++ where they make code longer and more complicated instead of simpler, are cargo cult programming. I thought comments were for discussion, not silencing anything negative.
  - younata 15y ago
    > Monads as commonly explained on blog posts are cargo cult mathematics, and monads used in languages like C++ where they make code longer and more complicated instead of simpler, are cargo cult programming. I upvoted both of your comments because of that statement. Explaining your position (although, it is a fairly weak argument) is enough. My trigger for cargo-cultism was him stating that you want to lay out your templates in Haskell first.
  - sunir 15y ago
    Your comment didn't add anything that taught anybody else.
    - Rusky 15y ago
      Neither did most of the other comments at the time of posting- "How long did it take you to guys to read this post?" and "This is fantastic" add about as much or less. At least this one was a little thought-provoking, even if it looked dismissive.
  - nandemo 15y ago
    Dismissing a well-written and elaborate post in a one-liner with no convincing arguments is usually considered bad form. Cargo cult programming itself seems to be an overused term. According to wikipedia it means "a style of computer programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug he or she was attempting to solve or the apparent solution". I've seen this done. I knew programmers who would call the same (side-effecting) function twice in a row, "just in case, since it might fail the first time", instead of actually checking the function's return code etc. Do you really think the post's author has no idea of what is talking about? That he copy-pasted some code and ended up with an EDSL in C++? The particular code he shows might not be practical, but that doesn't mean it's "cargo cult". For instance, perl-golf, obfuscated C contests and implementing X in Javascript aren't practical-minded activities either, but you can't call it "cargo cult": programmers engaging in them aren't exactly clueless. Again, monads may be perceived as "hyped" but that doesn't mean they're "cargo cult mathematics" any more than the Y combinator is.
VeXocide 15y ago
His three-hour BoostCon presentation can be found at http://blip.tv/boostcon/haskell-the-pseudocode-language-for-c-template-metaprogramming-5258033 http://blip.tv/boostcon/haskell-the-pseudocode-language-for-... (mirrored at http://wipkip.nikhef.nl/events/BoostCon/2011/Boostcon-HaskellThePseudocodeLanguageForCTemplateMetaprogramming927.mp4 http://wipkip.nikhef.nl/events/BoostCon/2011/Boostcon-Haskel...)
- BartoszMilewski 15y ago
  Here's a better link with three videos and slides: http://www.corensic.com/Community/Resources/BoostconVideo.aspx http://www.corensic.com/Community/Resources/BoostconVideo.as...
Peaker 15y ago
People confuse special-cases (Monad instances) with Monads (the abstraction). "Monads in C++" would be an encoding of the return/bind interface, which is possible (surprisingly, at least to me), and then writing a library of combinators that work with this interface and any instance of them. What this article (and countless others) are about is a particular encoding of bind/return for a single type, and not the Monad abstraction in general.

Monads in C++

80 points by VeXocide 15y ago

swah 15y ago

How long did it take you guys to read this post?

hsmyers 15y ago
Don't know---haven't finished and I won't until I understand the damn thing ;)
palish 15y ago
About fifteen seconds. Skimmed it, realized it was "another instance of someone attempting to do yet-another-bad-thing-in-C++", then closed it. I went through the same phase in my C++ career. (Mine was attempting to add FOREACH to my projects without depending on Boost.) I think at some point every C++ dev gets tired of writing boilerplate code, and then spends the next few days implementing something that would've otherwise taken them a few hours. Once you accept that C++ is not Lisp, and doesn't need to be, then you become much more productive. Additionally, your resulting C++ code is much more likely to actually be used by other C++ engineers. Lastly, these sorts of libraries tend to be very difficult to debug unless you were the one who wrote it.
- pvarangot 15y ago
  It's in fact an attempt to explain how the author got to understand the inner workings of Boost's Proto library, which is already available for C++ and pretty much a successful project as far as it goes. For people also into Haskell, it's a very concise and insightful attempt indeed. I understand your rant, but I'm not sure this is the place to go and spew it... Actually some people enjoy studying programming languages themselves and sometimes come up with useful stuff for engineers that like building more concrete stuff.
  - Rusky 15y ago
    You can study programming languages themselves without misusing C++ features in horrible ways. Monads are already overused and misunderstood- using them in C++ templates just makes things worse.
    - Peaker 15y ago
      > Monads are already overused and misunderstood- using them in C++ templates just makes things worse. Where are they overused?
      - Hemospectrum 15y ago
        In Haskell, mostly. This is probably because most Haskell programmers learned about monads without understanding applicative functors, which are more general and a much better fit for a lot of tasks.
      - Rusky 15y ago
        They are an overly-specific interface to what can usually be done with applicative functors or even just functors. This trend originated with Haskell and then when people who learned monads without understanding the other (often better) abstractions spread them everywhere else, we got things like this article. Using monads, especially in a language like C++ templates or Scala, but also in Haskell, can overcomplicate things and make things longer than if you just solved the problem the direct way. -- As an example of where monads are overused, look at the Maybe/Option type. I've read several articles that advocate using bind and/or Haskell's do-notation to move a string of null checks out of the main program. This is great, but it's much more easily and expressively done with applicative functors. Instead of assigning all the intermediate results to names, you can just do someFunction <$> Just 3 <*> Just "Something" and it looks like regular function application. Because Applicative is a more general interface that Monad, it also has the plus of working with more types.
        Peaker 15y ago
        I agree that Applicative should be used when possible. I think the Maybe example may be wrong, though. You may need the power of Monads sometimes. If you have a function that requires the result of a different function which was wrapped in Maybe, Applicative will not be enough. Example: xmlChild :: String -> Element -> Maybe Element Now you might want to do something like: myPath = xmlChild "a" >=> xmlChild "b" >=> xmlChild "c"
- pnathan 15y ago
  Frankly, I think that the big problem with C++ (and other larger languages) is the engineers who keep trying to use some minimal subset of it, pointing at the Blub+1 capabilities and screaming about how they can't understand it.
  - palish2 15y ago
    I understand the concepts just fine, thanks. My argument was against the mentality "C++ could be made to do... anything". Sure, it could. But it's a Really Bad Idea. If I had to write a C++ program to do this: data Exp = Const Integer | Plus Exp Exp | Times Exp Exp | Arg1 | Arg2 ... then I would embed Lua + LPeg ( http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html#ex http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html#ex ) and write the parser in that. A simple, readable, and maintainable solution. http://en.wikipedia.org/wiki/Parsing_expression_grammar http://en.wikipedia.org/wiki/Parsing_expression_grammar
- fnl 15y ago
  Lambda-calculus and monads are not necessarily Lisp-specific, neither would I call his syntax that (if only because he uses Haskell ->s instead of Lisp ()s :). See http://www.lfcs.inf.ed.ac.uk/reports/88/ECS-LFCS-88-66/index.html http://www.lfcs.inf.ed.ac.uk/reports/88/ECS-LFCS-88-66/index.... I liked the article, maybe it will be something to think about in some distant cpp. Although I tend to agree to your last argument about "using somebody else's DSL..." :)
pnathan 15y ago
Five minutes or so. Likening Haskell to C++ TMP makes a good deal of sense to me.
- thesz 15y ago
  There was an attempt to use Haskell DSeL to simplify C++ template metaprogramming. http://boostcon.boost.org/program/schedule#schedule.milewski-haskell-the-pseudocode-language-for-c-template-metaprogramming http://boostcon.boost.org/program/schedule#schedule.milewski... Unfortunatelly, slides are gone.

bandushrew 15y ago

This is fantastic. The idea that C++ meta programming is most easily understood as an (unnecessary complicated) functional language actually makes a huge amount of sense to me, and I particularly enjoy the lovely sense of balance it invokes.

Miky 15y ago

This is the worst example of cargo cult programming I've seen in a good while.

Miky 15y ago
OK, downvotes. Why, exactly? I'm not trying to troll. Monads as commonly explained on blog posts are cargo cult mathematics, and monads used in languages like C++ where they make code longer and more complicated instead of simpler, are cargo cult programming. I thought comments were for discussion, not silencing anything negative.
- younata 15y ago
  > Monads as commonly explained on blog posts are cargo cult mathematics, and monads used in languages like C++ where they make code longer and more complicated instead of simpler, are cargo cult programming. I upvoted both of your comments because of that statement. Explaining your position (although, it is a fairly weak argument) is enough. My trigger for cargo-cultism was him stating that you want to lay out your templates in Haskell first.
- sunir 15y ago
  Your comment didn't add anything that taught anybody else.
  - Rusky 15y ago
    Neither did most of the other comments at the time of posting- "How long did it take you to guys to read this post?" and "This is fantastic" add about as much or less. At least this one was a little thought-provoking, even if it looked dismissive.
- nandemo 15y ago
  Dismissing a well-written and elaborate post in a one-liner with no convincing arguments is usually considered bad form. Cargo cult programming itself seems to be an overused term. According to wikipedia it means "a style of computer programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug he or she was attempting to solve or the apparent solution". I've seen this done. I knew programmers who would call the same (side-effecting) function twice in a row, "just in case, since it might fail the first time", instead of actually checking the function's return code etc. Do you really think the post's author has no idea of what is talking about? That he copy-pasted some code and ended up with an EDSL in C++? The particular code he shows might not be practical, but that doesn't mean it's "cargo cult". For instance, perl-golf, obfuscated C contests and implementing X in Javascript aren't practical-minded activities either, but you can't call it "cargo cult": programmers engaging in them aren't exactly clueless. Again, monads may be perceived as "hyped" but that doesn't mean they're "cargo cult mathematics" any more than the Y combinator is.

VeXocide 15y ago

His three-hour BoostCon presentation can be found at http://blip.tv/boostcon/haskell-the-pseudocode-language-for-c-template-metaprogramming-5258033 http://blip.tv/boostcon/haskell-the-pseudocode-language-for-... (mirrored at http://wipkip.nikhef.nl/events/BoostCon/2011/Boostcon-HaskellThePseudocodeLanguageForCTemplateMetaprogramming927.mp4 http://wipkip.nikhef.nl/events/BoostCon/2011/Boostcon-Haskel...)

BartoszMilewski 15y ago
Here's a better link with three videos and slides: http://www.corensic.com/Community/Resources/BoostconVideo.aspx http://www.corensic.com/Community/Resources/BoostconVideo.as...

Peaker 15y ago

People confuse special-cases (Monad instances) with Monads (the abstraction). "Monads in C++" would be an encoding of the return/bind interface, which is possible (surprisingly, at least to me), and then writing a library of combinators that work with this interface and any instance of them. What this article (and countless others) are about is a particular encoding of bind/return for a single type, and not the Monad abstraction in general.