4 ms·

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

by 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"
- psykotic 15y ago
  When I see someone towards the middle of their career who is still in the thrall of C++ metaprogramming, it excites in me a mixture of genuine sympathy and condescending pity (and if they're a coworker of mine, righteous wrath). I am glad I went through that phase in my late teens and had the nonsense shook out of me by my first professional experience as a programmer. It's fine to pursue this as fun for its own sake if you are under no pretense as to its practical utility. But the danger of having your fun it in a bread-and-butter language like C++ is that you will be tempted to let it infect your workaday coding style. That's one of the perpetual dangers of hiring bright, overeager C++ programmers at the junior level. Boost is a minefield. Its less booby-trapped libraries have made it into the next C++ standard library, but the more hardcore indulgences in metaprogramming like Spirit deserve all the scorn that is customarily heaped on them, if not more.
  - wolfgangK 15y ago
    Your post is very condescending but also very light on facts. To someone successfully using C++ metaprogramming you just sound like you failed to find how and when to use it. (I do agree that it can get ugly wrt error messages and syntax as neither the compilers nor the language were designed with metaprogramming in mind.)
    - psykotic 15y ago
      The condescension was very much intended. Look, I'm not going to convince anyone of this point of view with a few hastily typed-out paragraphs on Hacker News. No-one can do that. It's something that rings true or false depending on your experience. My experience is that most uses of C++'s features beyond the rudimentary lead to software that takes forever to build, forever to run and forever to maintain, all of which are unacceptable and inexcucable. I started out in my pre-career as an enthusiastic C++ supporter who knew most of the tricks and dark corners of the language; template metaprogramming was (and still is) easy as pie for me. But every experience I've had since then has pushed me in the opposite direction, away from immature self-indulgent cleverness. Nowadays I mostly use C or a very C-like subset of C++.
  - roel_v 15y ago
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..." :)

by palish 15y ago

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"
psykotic 15y ago
When I see someone towards the middle of their career who is still in the thrall of C++ metaprogramming, it excites in me a mixture of genuine sympathy and condescending pity (and if they're a coworker of mine, righteous wrath). I am glad I went through that phase in my late teens and had the nonsense shook out of me by my first professional experience as a programmer. It's fine to pursue this as fun for its own sake if you are under no pretense as to its practical utility. But the danger of having your fun it in a bread-and-butter language like C++ is that you will be tempted to let it infect your workaday coding style. That's one of the perpetual dangers of hiring bright, overeager C++ programmers at the junior level. Boost is a minefield. Its less booby-trapped libraries have made it into the next C++ standard library, but the more hardcore indulgences in metaprogramming like Spirit deserve all the scorn that is customarily heaped on them, if not more.
- wolfgangK 15y ago
  Your post is very condescending but also very light on facts. To someone successfully using C++ metaprogramming you just sound like you failed to find how and when to use it. (I do agree that it can get ugly wrt error messages and syntax as neither the compilers nor the language were designed with metaprogramming in mind.)
  - psykotic 15y ago
    The condescension was very much intended. Look, I'm not going to convince anyone of this point of view with a few hastily typed-out paragraphs on Hacker News. No-one can do that. It's something that rings true or false depending on your experience. My experience is that most uses of C++'s features beyond the rudimentary lead to software that takes forever to build, forever to run and forever to maintain, all of which are unacceptable and inexcucable. I started out in my pre-career as an enthusiastic C++ supporter who knew most of the tricks and dark corners of the language; template metaprogramming was (and still is) easy as pie for me. But every experience I've had since then has pushed me in the opposite direction, away from immature self-indulgent cleverness. Nowadays I mostly use C or a very C-like subset of C++.
- roel_v 15y ago

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..." :)