Laziness helps a lot with composition, when designing an interface you can have functions with arguments that won't be used by every implementation but have no performance overhead.
Although, most of the time laziness is only useful at a single level, and that kind of laziness can be easily done in languages like C++ with a much lower overhead.
It's a bit sad that GHC has so many advanced code optimization methods but performance is still lacking.
Yes, you can write high-performance Haskell but it requires expertise or huge amount of profiling and time.
On the other hand, you can easily write faster (speed-wise) prototypes in C++ and get superior performance almost all the time.
Yes, you can write high-performance Haskell but it requires expertise or huge amount of profiling and time.
Is there a language X that allows you to write high performance X without huge amounts of profiling and time?
On the other hand, you can easily write faster (speed-wise) prototypes in C++ and get superior performance almost all the time.
You can't really compare development time though can you, even with C++x11? Even if so, you should probably specify the version of C++ you are referring to since they can mean very different experiences.
Is there a language X that allows you to write high performance X without huge amounts of profiling and time?
Yeah, if high-performance is something faster than Haskell I'm already there with C++. If I understand copy/move semantics I won't get bitten by anyone, same thing with laziness in Haskell, although sometimes I stumble a bit.
Of course we're all talking about C++14. I guess everyone else is talking about GHC 8.+, at least in this thread.
You can't really compare development time though can you, even with C++x11? Even if so, you should probably specify the version of C++ you are referring to since they can mean very different experiences.
Write a highly performant discrete optimization in Haskell using monad transformers that have overhead, laziness that has overhead, and almost everything has several levels of indirection.
Yes, I can write a prototype that is sufficiently fast, I can then profile and write a version that Haskell might never reach. And yes, it'll probably take me less time to do than to do the same with Haskell, it might be my lack of expertise, who knows, I've tried.
Comments
Laziness helps a lot with composition, when designing an interface you can have functions with arguments that won't be used by every implementation but have no performance overhead.
Although, most of the time laziness is only useful at a single level, and that kind of laziness can be easily done in languages like C++ with a much lower overhead.
It's a bit sad that GHC has so many advanced code optimization methods but performance is still lacking.
Yes, you can write high-performance Haskell but it requires expertise or huge amount of profiling and time.
On the other hand, you can easily write faster (speed-wise) prototypes in C++ and get superior performance almost all the time.
List of ways to write performant Haskell: https://news.ycombinator.com/item?id=10209798
Is there a language X that allows you to write high performance X without huge amounts of profiling and time?
You can't really compare development time though can you, even with C++x11? Even if so, you should probably specify the version of C++ you are referring to since they can mean very different experiences.
Cool!
Yeah, if high-performance is something faster than Haskell I'm already there with C++. If I understand copy/move semantics I won't get bitten by anyone, same thing with laziness in Haskell, although sometimes I stumble a bit.
Of course we're all talking about C++14. I guess everyone else is talking about GHC 8.+, at least in this thread.
Write a highly performant discrete optimization in Haskell using monad transformers that have overhead, laziness that has overhead, and almost everything has several levels of indirection. Yes, I can write a prototype that is sufficiently fast, I can then profile and write a version that Haskell might never reach. And yes, it'll probably take me less time to do than to do the same with Haskell, it might be my lack of expertise, who knows, I've tried.