5 ms·

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 ex

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.
    - notthemessiah 11y ago
      Makes more sense when you look into the etymology. https://en.wiktionary.org/wiki/bed#Etymology https://en.wiktionary.org/wiki/bed#Etymology from Old English bedd (“bed, couch, resting-place; garden-bed, plot”)
ebiester 11y ago
Would you mind writing this blog post? I think some examples would be valuable to many people.
codygman 11y ago
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.html#%281%29 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).
- banachtarski 11y ago
  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.
jlarocco 11y ago
That reply came off a little condescending. I'm not some kind of Haskell zealot, and I haven't even used it in several years. That said, I'm well aware of the downsides of Haskell, and I've pointed out on numerous occasions that "real life" Haskell doesn't match up with the pure, lazy Haskell people often talk about. However, the reality is that people who really care about performance and predictability in C++ aren't doing crazy template metaprogramming because, although not as bad as Haskell, it's also difficult to reason about and understand what's going on under the hood. My guess is that every time somebody has said, "I translated this Haskell code to C++ metaprogramming," they could have just used Haskell with no negative repercussions.
- pjmlp 11y ago
  Just upvoted you. Yes, but C++ enjoys profilers like Instruments, Visual Studio Profiler, Intel Amplifier among many others that allow to check how all that meta-programming is affecting the application, while Haskell tooling is much more limited.
- banachtarski 11y ago
  I think that's probably mostly accurate. That said, I do use templated code in my inner loops even. After all, the benefit of generics is that you do the work at compile time instead of runtime (no casting, data marshalling is tight, etc). Even with code that needed to be significantly templatized (as is the case with many core libraries), I have to give C++ a clear edge as far as runtime debuggability and performance is concerned.

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.
  - notthemessiah 11y ago
    Makes more sense when you look into the etymology. https://en.wiktionary.org/wiki/bed#Etymology https://en.wiktionary.org/wiki/bed#Etymology from Old English bedd (“bed, couch, resting-place; garden-bed, plot”)

ebiester 11y ago

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

codygman 11y ago

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.html#%281%29 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).

banachtarski 11y ago
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.

jlarocco 11y ago

That reply came off a little condescending. I'm not some kind of Haskell zealot, and I haven't even used it in several years. That said, I'm well aware of the downsides of Haskell, and I've pointed out on numerous occasions that "real life" Haskell doesn't match up with the pure, lazy Haskell people often talk about. However, the reality is that people who really care about performance and predictability in C++ aren't doing crazy template metaprogramming because, although not as bad as Haskell, it's also difficult to reason about and understand what's going on under the hood. My guess is that every time somebody has said, "I translated this Haskell code to C++ metaprogramming," they could have just used Haskell with no negative repercussions.

pjmlp 11y ago
Just upvoted you. Yes, but C++ enjoys profilers like Instruments, Visual Studio Profiler, Intel Amplifier among many others that allow to check how all that meta-programming is affecting the application, while Haskell tooling is much more limited.
banachtarski 11y ago
I think that's probably mostly accurate. That said, I do use templated code in my inner loops even. After all, the benefit of generics is that you do the work at compile time instead of runtime (no casting, data marshalling is tight, etc). Even with code that needed to be significantly templatized (as is the case with many core libraries), I have to give C++ a clear edge as far as runtime debuggability and performance is concerned.