13 ms·

Translating Haskell to C++ metaprogramming

59 points by oever 11y ago

jlarocco 11y ago
I don't know why people don't just use Haskell. C++'s template system has become the ugliest part of the language, both the syntax and the perverse ways people twist the language with it. I understand most of the metaprogramming tricks are in the same vein as "Look what I made in Brainfuck!", and are more about showing off than for serious consideration, but for getting real work done it's a huge headache to work with, and the effort would be better spent doing more interesting things in languages that weren't so hard to use. And it's not every day that I suggest Haskell is easier than something else :-)
- cies 11y ago
  Haskell community is growing quite fast it seems.
- chongli 11y ago
  I don't know why people don't just use Haskell. Because perception is everything in this business. Haskell is perceived to be an impractical, academic language. Therefore, people refuse to use it and instead try to translate lessons they learned from it to "more practical" languages such as C++. If everyone was working solo and didn't need to justify their decisions to others, maybe Haskell would catch on faster. As it is, people seem to find it harder to convince others in their groups/teams/companies to use Haskell than to simply go with what everybody else is using.
  - SamReidHughes 11y ago
    Haskell's perceived as an impractical language because it is one †. There aren't many projects where you'd get any plausible benefit from using Haskell instead of some other reasonable garbage collected language. Lazy evaluation is a big risk, if you aren't writing programs that start and finish. It sure is one that I've suffered from. At the line-by-line level, purely functional code also takes more effort to edit, once written, than imperative code. †Edit: Well, it's practical for some stuff, but it's not particularly more practical than other languages, and there's a big spooky bit of danger that comes with it.
    - codygman 11y ago
      > Haskell's perceived as an impractical language because it is one †. Theoretically maybe ;) The real world disagrees with you however: https://www.fpcomplete.com/business/haskell-industry/ https://www.fpcomplete.com/business/haskell-industry/ https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry > At the line-by-line level, purely functional code also takes more effort to edit, once written, than imperative code. How? You can locally reason about purely functional code which makes it much easier to edit then it's imperative counterpart which likely depends on global mutable state. > Lazy evaluation is a big risk, if you aren't writing programs that start and finish. Have you written much lazy evaluated code? Have you written much Haskell code? > and there's a big spooky bit of danger that comes with it. Can you elaborate on this? It sounds like "Haskell is bad because reasons that are spooky".
      - deeviant 11y ago
        You link two cherry picked pro-Haskell links as proof that "the world believes that Haskell's is totally practical language"? Good grief.
        codygman 11y ago
        I was never trying to prove "the world believes that Haskell's is totally practical language". My response was purely a rebuttal to: "Haskell's perceived as an impractical language because it is one" The "cherry picked pro-Haskell links" were picked because they link to examples of Haskell's practical uses in industry. Should I have created a faulty rebuttal that didn't list real world counter-examples of "Haskell's perceived as an impractical language because it is one"? I don't think I could find a link to practical uses of any language in industry that wasn't "cherry picked".
      - SamReidHughes 11y ago
        The spooky danger comes from lazy evaluation. The "line-by-line" level has nothing to do with global mutable state. It has to do with locally mutable state. It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever. In any reasonably architected software, you can see how a function depends on global state by looking at its argument list. Those that use database connections take the database connection. Those that create database connections receive a parameter that tells them what to connect to. Pretty much everything writes log messages. If you're in a position to choose Haskell, then you're also in a position to make your software this way.
- oever 11y ago
  Haskell is a great language. But there are large codebases out there in C++. Porting those is often not feasible. Yet, Haskell can serve as a great inspiration of how to write clean code. C++ does not have the limitations/strictness of Haskell, but that does not mean that a programmer cannot apply the rigor of Haskell to C++ code. Blasien is meant as a way to improve software that works with XML. Big packages like LibreOffice and Calligra could benefit from it without switching to Haskell. In fact, I've not figured out yet how to bring the features of Blasien (literal XML and compile time schema validation) to Haskell.
  - banachtarski 11y ago
    Agreed. While I would never use Haskell to, say, right a next gen graphics engine, I can confidently say that learning to write idiomatic Haskell code has improved my C++ code.
    - pjmlp 11y ago
      Specially with C++14, algorithms and functional libraries.
    - banachtarski 11y ago
      /s/right/write
- deleted 11y ago
  [deleted]
- banachtarski 11y ago
  I'll explain it to you, as a person who was a Haskell enthusiast and uses C++ professionally. The problem with Haskell is that while it is very effective at expressing ideas and logic, it is just as ineffective at expressing runtime behavior. In world where everything is lazily evaluated by default and garbage collected, it is very difficult to reason about how the code will actually execute. Are you trashing the cache? Fragmenting your heap? Are you misusing the instruction cache? For performance reasons, Haskell programmers often need to forcibly make operations strict and turn off the thunk essentially. This is a layer of complexity you don't often see in blogposts and Haskell tutorials. In contrast, I can look at C or C++ code and tell you more or less exactly how it will map to assembly (with some exceptions like when compilers decide to inline). So in short, that Haskell you know is not the full story. I've written some Haskell programs and tried very, very hard to make them fast (they were parallelized too). At the end of the day, it's hard for a language to completely outclass another one because there are tradeoffs and life isn't so simple.
  - raphaelss 11y ago
    Thank you. Haskell is no bed of roses and C++ is not all that bad. Some of us write real time signal processing code and C++ is a viable choice in this context.
    - notthemessiah 11y ago
      "Bed of roses" seems like a weird idiom because roses have thorns.
      - raphaelss 11y ago
        True. I did not think about it this way and just went with a common expression. Feel free to read it as "Haskell isn't all sunshine and rainbows." To be clear (before you say that "sunshine and rainbows" seems like a weird idiom because sunshine causes cancer), I meant that I think Haskell also has disadvantages.
        11y ago
- halayli 11y ago
  You're comparing apples and oranges.
- pjmlp 11y ago
  > I don't know why people don't just use Haskell. Because sadly it isn't a first class language in OS vendor's SDKs. Even Swift and F# have more possibilities to succeed in the industry, exactly because of that.
cies 11y ago
Please correct me if I'm wrong, but I think the word metaprogramming (MP) is used a bit too liberal in this article. When I think of MP I think of programs-writing-programs, which might very well be a too narrow definition. TemplateHaskell --DSLs that are transformed to (mostly rather repetitive) Haskell at compile time-- are MP in my idea, also: macros in LISP and open classes modified my the program at runtime in Ruby. Non the less a very interesting article! Compared to C++ Haskell's syntax is soo clean!
- oever 11y ago
  I use the term 'metaprogramming' because that's the title of the relevant chapter in Stroustrups 'The C++ programming language'. I do think that 'C++ metaprogamming' is a bit clunky, but 'C++ template programming' sounds too limited. 'compile time programming' also sounds strange. Wikipedia says: "Metaprogramming is the writing of computer programs with the ability to treat programs as their data." Writing C++ templates to treat Relax NG specifications and literal XML in C++ as input for schema validation would fit that definition.
  - igravious 11y ago
    I think 'C++ template programming' might be better also :/ The following syntax in Haskell causes a parse error in my brain: contains :: NameClass -> QName -> Bool I really want it to be contains :: (NameClass, QName) -> Bool Or even just contains :: NameClass, QName -> Bool Is it just my problem to get over or do other people have it, or is there syntactic sugar coming to my rescue?
    - gaze 11y ago
      You should get over it. It's just syntax... and it's there for a reason (Makes more sense for curried functions, and it's a holdover from logic where you say that if you have a nameclass, you have an object that sense a qname to a bool, and if you have a nameclass and a qname then you have a bool.)
      - 11y ago
gergoerdi 11y ago
I did a barebones Haskell to C++ template compiler as a fun diversion once, see http://gergo.erdi.hu/projects/metafun/ http://gergo.erdi.hu/projects/metafun/ If I understand right, this guy is doing this by hand -- why not just extend MetaFun for whatever language constructs he needs to use that are not yet supported by MetaFun?
harry8 11y ago
Why is there no usable haskell SSL library? It would seem this is an area where the claims about haskell eliminating whole classes of bugs and so on would really be worthwhile and an amazing advert for haskell advocates. The claims about being able to formally prove the code implements the spec would be pretty damn compelling in that space too. Once upon a time I asked on HN if there are any useful and usable haskell programs you can just install and run for a purpose that isn't writing haskell code. Shellcheck & pandoc seemed to be the suggested examples. Is that still the case or are there now a few more?
- rtpg 11y ago
  There's xmonad, the tiling window manager. Apart from that I can't think of anything that is actively worked on and has any major traction.
- hobo_mark 11y ago
  Pandoc (document format converter) comes to mind.
  - tome 11y ago
    It seems to have come to harry8's mind too.
    - hobo_mark 11y ago
      Sorry, clearly the caffeine hadn't kicked in yet.
- tome 11y ago
  Firstly, the entire classes of bugs that Haskell eliminates are not classes that are especially relevant to cryptography. Secondly, if you know where someone has claimed that Haskell lets you "formally prove the code implements the spec" then please point it out to me so I can challenge them for being misleading at best.
  - harry8 11y ago

59 points by oever 11y ago

I don't know why people don't just use Haskell. C++'s template system has become the ugliest part of the language, both the syntax and the perverse ways people twist the language with it. I understand most of the metaprogramming tricks are in the same vein as "Look what I made in Brainfuck!", and are more about showing off than for serious consideration, but for getting real work done it's a huge headache to work with, and the effort would be better spent doing more interesting things in languages that weren't so hard to use. And it's not every day that I suggest Haskell is easier than something else :-)

cies 11y ago
Haskell community is growing quite fast it seems.
chongli 11y ago
I don't know why people don't just use Haskell. Because perception is everything in this business. Haskell is perceived to be an impractical, academic language. Therefore, people refuse to use it and instead try to translate lessons they learned from it to "more practical" languages such as C++. If everyone was working solo and didn't need to justify their decisions to others, maybe Haskell would catch on faster. As it is, people seem to find it harder to convince others in their groups/teams/companies to use Haskell than to simply go with what everybody else is using.
- SamReidHughes 11y ago
  Haskell's perceived as an impractical language because it is one †. There aren't many projects where you'd get any plausible benefit from using Haskell instead of some other reasonable garbage collected language. Lazy evaluation is a big risk, if you aren't writing programs that start and finish. It sure is one that I've suffered from. At the line-by-line level, purely functional code also takes more effort to edit, once written, than imperative code. †Edit: Well, it's practical for some stuff, but it's not particularly more practical than other languages, and there's a big spooky bit of danger that comes with it.
  - codygman 11y ago
    > Haskell's perceived as an impractical language because it is one †. Theoretically maybe ;) The real world disagrees with you however: https://www.fpcomplete.com/business/haskell-industry/ https://www.fpcomplete.com/business/haskell-industry/ https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry > At the line-by-line level, purely functional code also takes more effort to edit, once written, than imperative code. How? You can locally reason about purely functional code which makes it much easier to edit then it's imperative counterpart which likely depends on global mutable state. > Lazy evaluation is a big risk, if you aren't writing programs that start and finish. Have you written much lazy evaluated code? Have you written much Haskell code? > and there's a big spooky bit of danger that comes with it. Can you elaborate on this? It sounds like "Haskell is bad because reasons that are spooky".
    - deeviant 11y ago
      You link two cherry picked pro-Haskell links as proof that "the world believes that Haskell's is totally practical language"? Good grief.
      - codygman 11y ago
        I was never trying to prove "the world believes that Haskell's is totally practical language". My response was purely a rebuttal to: "Haskell's perceived as an impractical language because it is one" The "cherry picked pro-Haskell links" were picked because they link to examples of Haskell's practical uses in industry. Should I have created a faulty rebuttal that didn't list real world counter-examples of "Haskell's perceived as an impractical language because it is one"? I don't think I could find a link to practical uses of any language in industry that wasn't "cherry picked".
    - SamReidHughes 11y ago
      The spooky danger comes from lazy evaluation. The "line-by-line" level has nothing to do with global mutable state. It has to do with locally mutable state. It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever. In any reasonably architected software, you can see how a function depends on global state by looking at its argument list. Those that use database connections take the database connection. Those that create database connections receive a parameter that tells them what to connect to. Pretty much everything writes log messages. If you're in a position to choose Haskell, then you're also in a position to make your software this way.
oever 11y ago
Haskell is a great language. But there are large codebases out there in C++. Porting those is often not feasible. Yet, Haskell can serve as a great inspiration of how to write clean code. C++ does not have the limitations/strictness of Haskell, but that does not mean that a programmer cannot apply the rigor of Haskell to C++ code. Blasien is meant as a way to improve software that works with XML. Big packages like LibreOffice and Calligra could benefit from it without switching to Haskell. In fact, I've not figured out yet how to bring the features of Blasien (literal XML and compile time schema validation) to Haskell.
- banachtarski 11y ago
  Agreed. While I would never use Haskell to, say, right a next gen graphics engine, I can confidently say that learning to write idiomatic Haskell code has improved my C++ code.
  - pjmlp 11y ago
    Specially with C++14, algorithms and functional libraries.
  - banachtarski 11y ago
    /s/right/write
deleted 11y ago
[deleted]
banachtarski 11y ago
I'll explain it to you, as a person who was a Haskell enthusiast and uses C++ professionally. The problem with Haskell is that while it is very effective at expressing ideas and logic, it is just as ineffective at expressing runtime behavior. In world where everything is lazily evaluated by default and garbage collected, it is very difficult to reason about how the code will actually execute. Are you trashing the cache? Fragmenting your heap? Are you misusing the instruction cache? For performance reasons, Haskell programmers often need to forcibly make operations strict and turn off the thunk essentially. This is a layer of complexity you don't often see in blogposts and Haskell tutorials. In contrast, I can look at C or C++ code and tell you more or less exactly how it will map to assembly (with some exceptions like when compilers decide to inline). So in short, that Haskell you know is not the full story. I've written some Haskell programs and tried very, very hard to make them fast (they were parallelized too). At the end of the day, it's hard for a language to completely outclass another one because there are tradeoffs and life isn't so simple.
- raphaelss 11y ago
  Thank you. Haskell is no bed of roses and C++ is not all that bad. Some of us write real time signal processing code and C++ is a viable choice in this context.
  - notthemessiah 11y ago
    "Bed of roses" seems like a weird idiom because roses have thorns.
    - raphaelss 11y ago
      True. I did not think about it this way and just went with a common expression. Feel free to read it as "Haskell isn't all sunshine and rainbows." To be clear (before you say that "sunshine and rainbows" seems like a weird idiom because sunshine causes cancer), I meant that I think Haskell also has disadvantages.
      - 11y ago
halayli 11y ago
You're comparing apples and oranges.
pjmlp 11y ago
> I don't know why people don't just use Haskell. Because sadly it isn't a first class language in OS vendor's SDKs. Even Swift and F# have more possibilities to succeed in the industry, exactly because of that.

cies 11y ago

Please correct me if I'm wrong, but I think the word metaprogramming (MP) is used a bit too liberal in this article. When I think of MP I think of programs-writing-programs, which might very well be a too narrow definition. TemplateHaskell --DSLs that are transformed to (mostly rather repetitive) Haskell at compile time-- are MP in my idea, also: macros in LISP and open classes modified my the program at runtime in Ruby. Non the less a very interesting article! Compared to C++ Haskell's syntax is soo clean!

oever 11y ago
I use the term 'metaprogramming' because that's the title of the relevant chapter in Stroustrups 'The C++ programming language'. I do think that 'C++ metaprogamming' is a bit clunky, but 'C++ template programming' sounds too limited. 'compile time programming' also sounds strange. Wikipedia says: "Metaprogramming is the writing of computer programs with the ability to treat programs as their data." Writing C++ templates to treat Relax NG specifications and literal XML in C++ as input for schema validation would fit that definition.
- igravious 11y ago
  I think 'C++ template programming' might be better also :/ The following syntax in Haskell causes a parse error in my brain: contains :: NameClass -> QName -> Bool I really want it to be contains :: (NameClass, QName) -> Bool Or even just contains :: NameClass, QName -> Bool Is it just my problem to get over or do other people have it, or is there syntactic sugar coming to my rescue?
  - gaze 11y ago
    You should get over it. It's just syntax... and it's there for a reason (Makes more sense for curried functions, and it's a holdover from logic where you say that if you have a nameclass, you have an object that sense a qname to a bool, and if you have a nameclass and a qname then you have a bool.)
    - 11y ago

gergoerdi 11y ago

I did a barebones Haskell to C++ template compiler as a fun diversion once, see http://gergo.erdi.hu/projects/metafun/ http://gergo.erdi.hu/projects/metafun/ If I understand right, this guy is doing this by hand -- why not just extend MetaFun for whatever language constructs he needs to use that are not yet supported by MetaFun?

harry8 11y ago

Why is there no usable haskell SSL library? It would seem this is an area where the claims about haskell eliminating whole classes of bugs and so on would really be worthwhile and an amazing advert for haskell advocates. The claims about being able to formally prove the code implements the spec would be pretty damn compelling in that space too. Once upon a time I asked on HN if there are any useful and usable haskell programs you can just install and run for a purpose that isn't writing haskell code. Shellcheck & pandoc seemed to be the suggested examples. Is that still the case or are there now a few more?

rtpg 11y ago
There's xmonad, the tiling window manager. Apart from that I can't think of anything that is actively worked on and has any major traction.
hobo_mark 11y ago
Pandoc (document format converter) comes to mind.
- tome 11y ago
  It seems to have come to harry8's mind too.
  - hobo_mark 11y ago
    Sorry, clearly the caffeine hadn't kicked in yet.
tome 11y ago
Firstly, the entire classes of bugs that Haskell eliminates are not classes that are especially relevant to cryptography. Secondly, if you know where someone has claimed that Haskell lets you "formally prove the code implements the spec" then please point it out to me so I can challenge them for being misleading at best.
- harry8 11y ago