Hacker News Reader

Comment by AndreasFrom | Hacker News Reader

As you acknowledge yourself, whether Haskell makes you think or not relies on what you're trained to read.

Yes, you're right that Haskell is probably easier to read for someone with the mathematical background. But I'm referring to the cognitive overload incurred when you try to optimize it, thinking about list creation costs, then stream fusion to avoid it: most physicists or mathematicians will cringe at the thought of having to think about these "computer sciency optimization stuff". As opposed to this, a crude tool such as Cython or C or even Fortran allows one to just "skip thinking" about these and still have fast enough code.

Haskell is great if you want to expand your CS knowledge, but not if your math/physics/engineering problem is already so complicated that it uses up all your available brain cycles and working memory and you just can't squeeze thinking about language-specific optimizations too. I guess this is why it's only used by companies like Galois and such that are already neck deep in advanced CS problems and used to thinking about them all the time.

There is a saying: first make it work, then make it work fast. The problem with doing the second in imperative languages is that you need to pull all your working code apart and rewrite it. Haskell separates the "make it work" from the "make it work fast".

Except that no one actually thinks about that stuff when writing actual vector code. Trust me, I have written several real time 3D reconstruction algorithms (such as SLAM) in Haskell and was not thinking about stream fusion at all.

> Yes, you're right that Haskell is probably easier to read for someone with the mathematical background.

I am quite taken by Haskell, and I have the whopping mathematical background of two introductory courses from my institute of mathematics.

> But I'm referring to the cognitive overload incurred when you try to optimize it, thinking about list creation costs, then stream fusion to avoid i

The author didn't need to know what stream fusion was; all they did was import a library... it might as well have been called import MagicallyOptimizingPrelude and it would have the same effect.

But I'm referring to the cognitive overload incurred when you try to optimize it, thinking about list creation costs, then stream fusion to avoid it

That's not true. This article is about a library that works as a drop-in replacement of the default list processing functions in the Prelude. Eventually, it may be possible that these functions will be put into the Prelude itself. This would allow naive users to get all the performance gains from stream fusion without ever knowing it's happening. All of the "cognitive overload" is taken care of by the researchers who developed this technique and the library authors who implement it.

Reply on news.ycombinator.com