Translating Haskell to C++ metaprogramming
vandenoever.info
Translating Haskell to C++ metaprogramming
1–10 of 63 posts
Re: Translating Haskell to C++ metaprogramming
#2I 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 :-)
Re: Translating Haskell to C++ metaprogramming
#3Please 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!
Re: Translating Haskell to C++ metaprogramming
#4I 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 wit…
Haskell community is growing quite fast it seems.
Re: Translating Haskell to C++ metaprogramming
#5I 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 wit…
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.
Re: Translating Haskell to C++ metaprogramming
#6Please 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 R…
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.
Re: Translating Haskell to C++ metaprogramming
#7I 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 wit…
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.
Re: Translating Haskell to C++ metaprogramming
#8I 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 wit…
[deleted]
Re: Translating Haskell to C++ metaprogramming
#9I 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 wit…
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.
Re: Translating Haskell to C++ metaprogramming
#10I 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 wit…
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…
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.