4 ms·

> 1 - You don't know what's happening. Even with higher level imperative languages you have a (direct) correspondance between code and machine code (or somethin

by tome 12y ago

> 1 - You don't know what's happening. Even with higher level imperative languages you have a (direct) correspondance between code and machine code (or something similar like bytecode). Not in functional There is a direct correspondance between Haskell code and machine code. GHC translates from Haskell into an imperative language called C--, which is basically a restricted subset of C. Sure, the translation is of a different style than you are used to in the imperative world, but it's still a direct translation. > 2 - Sometimes you want side-effects, in ways you didn't know they were side effects (like writing/reading a file, random numbers, etc). Now Haskell's way of solving this may be mathematically elegant, but it's clunky in real life. Arguably, but after several years with Haskell I now find unrestricted side-effects "clunky" and effect typing much more practical. > 3 - Doing things functionally require a different mindset. You think of a for/if cond() break, and you need to rethink this on functional (and a lot of other things). I agree. It requires a significant change to your way of thinking about programming.

cousin_it 12y ago
Well, all languages translate to machine code eventually, but that doesn't make all languages equally easy to understand. Specifically, some people try to understand code by mentally stepping through it. IMO that's a lot easier in imperative languages than in Haskell. In imperative languages, you step down one line at a time, and loop back in easily specified places. In Haskell, on the other hand, you need to imagine graph reduction in your head. That's already pretty hard for most people, but it gets worse! You can't mentally step through a Haskell function in isolation, because the sequence of graph reduction steps depends on what the caller will do with the answer. That's not just a theoretical difficulty. Take a look at this thread: http://lambda-the-ultimate.org/node/3127 http://lambda-the-ultimate.org/node/3127. A bunch of programming language researchers and long-time functional programmers are looking at a six-line Haskell program implementing the Sieve of Eratosthenes, and cannot figure out its big-O complexity. I can't, either.
- tome 12y ago
  Maybe I am splitting hairs then. I still hold that the translation is fairly simple. On the other hand, the operational steps that the machine code goes through can be mind bending, and I still have trouble figuring it out myself. Perhaps that's what raverbashing meant all along.

by tome 12y ago

cousin_it 12y ago

Well, all languages translate to machine code eventually, but that doesn't make all languages equally easy to understand. Specifically, some people try to understand code by mentally stepping through it. IMO that's a lot easier in imperative languages than in Haskell. In imperative languages, you step down one line at a time, and loop back in easily specified places. In Haskell, on the other hand, you need to imagine graph reduction in your head. That's already pretty hard for most people, but it gets worse! You can't mentally step through a Haskell function in isolation, because the sequence of graph reduction steps depends on what the caller will do with the answer. That's not just a theoretical difficulty. Take a look at this thread: http://lambda-the-ultimate.org/node/3127 http://lambda-the-ultimate.org/node/3127. A bunch of programming language researchers and long-time functional programmers are looking at a six-line Haskell program implementing the Sieve of Eratosthenes, and cannot figure out its big-O complexity. I can't, either.

tome 12y ago
Maybe I am splitting hairs then. I still hold that the translation is fairly simple. On the other hand, the operational steps that the machine code goes through can be mind bending, and I still have trouble figuring it out myself. Perhaps that's what raverbashing meant all along.