Translating Haskell to C++ metaprogramming • Hacker News Board

Re: Translating Haskell to C++ metaprogramming

#11

Post by raphaelss » Sun, Jul 12, 2015, 11:52 PM UTC

banachtarski wrote: post #9

jlarocco wrote: post #2

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 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 c…

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.

Re: Translating Haskell to C++ metaprogramming

#12

Post by codygman » Mon, Jul 13, 2015, 12:35 AM UTC

SamReidHughes wrote: post #10

chongli wrote: post #5

Earlier quoted context omitted.

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,…

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

Re: Translating Haskell to C++ metaprogramming

#13

Post by ebiester » Mon, Jul 13, 2015, 12:35 AM UTC

banachtarski wrote: post #9

jlarocco wrote: post #2

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 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 c…

Would you mind writing this blog post? I think some examples would be valuable to many people.

Re: Translating Haskell to C++ metaprogramming

#14

Post by codygman » Mon, Jul 13, 2015, 12:40 AM UTC

banachtarski wrote: post #9

jlarocco wrote: post #2

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 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 c…

Well, you can avoid most problems by remembering the following quote:

"you usually want your data structures to be as strict as possible, but your control flow to be as lazy as possible"

Here's something else that might be of interest to you:

http://johantibell.com/files/haskell-performance-patterns.ht...

> I've written some Haskell programs and tried very, very hard to make them fast (they were parallelized too).

Can you share these? I'm very interested in a Haskell which is both effective at expressing ideas and logic and is very performant (I also think it's farther along at doing so than you give it credit for).

Re: Translating Haskell to C++ metaprogramming

#15

Post by pmelendez » Mon, Jul 13, 2015, 12:58 AM UTC

cies wrote: post #3

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 R…

>"DSLs that are transformed to (mostly rather repetitive) Haskell at compile time-- are MP in my idea"

In it kinda the case in C++ too. C++ template system is a turing-complete machine at compiling time.

Re: Translating Haskell to C++ metaprogramming

#16

Post by gergoerdi » Mon, Jul 13, 2015, 1:05 AM UTC

I did a barebones Haskell to C++ template compiler as a fun diversion once, see 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?

Re: Translating Haskell to C++ metaprogramming

#17

Post by halayli » Mon, Jul 13, 2015, 1:19 AM UTC

jlarocco wrote: post #2

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 wit…

You're comparing apples and oranges.

Re: Translating Haskell to C++ metaprogramming

#18

Post by deeviant » Mon, Jul 13, 2015, 1:27 AM UTC

codygman wrote: post #12

SamReidHughes wrote: post #10

Earlier quoted context omitted.

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,…

> 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://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 ma…

You link two cherry picked pro-Haskell links as proof that "the world believes that Haskell's is totally practical language"?

Good grief.

Re: Translating Haskell to C++ metaprogramming

#19

Post by notthemessiah » Mon, Jul 13, 2015, 1:35 AM UTC

raphaelss wrote: post #11

banachtarski wrote: post #9

Earlier quoted context omitted.

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 c…

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.

"Bed of roses" seems like a weird idiom because roses have thorns.

Re: Translating Haskell to C++ metaprogramming

#20

Post by banachtarski » Mon, Jul 13, 2015, 1:36 AM UTC

codygman wrote: post #14

banachtarski wrote: post #9

Earlier quoted context omitted.

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 c…

Well, you can avoid most problems by remembering the following quote: "you usually want your data structures to be as strict as possible, but your control flow to be as lazy as possible" Here's something else that might be of interest to you: http://johantibell.com/files/haskell-performance-patterns.ht... > I've written some Haskell programs and tried very, very hard to make them fast (they were parallelized too). Ca…

One important thing about performance is that guaranteeing good throughput and latency are two separate things.

I read all the books, all the blogposts and papers; trust me, I did the obvious things. Even if you make your data structures tight, the problem isn't so much that the program runs slow on average. The problem is that it is hard to predict the runtime performance characteristics, let alone guarantee them.