3 ms·

I know a bit about Haskell and have played with it. I guess it just seems like functional languages are for those who want to solve super complicated mental ex

by balloot 13y ago

I know a bit about Haskell and have played with it. I guess it just seems like functional languages are for those who want to solve super complicated mental exercises when doing tasks that would otherwise be easy using a traditional language. There are very few things in the world of CS/programming where I can't follow along and grok what's going on, especially when laid out in a tutorial form like this. The fact that I was totally lost when reading this is not a good sign when you're trying to get people to adopt your school of thought.

egonschiele 13y ago
Post author here. I'd love to know where you stumbled!
tel 13y ago
This is a pretty common idea, but it's because pure functional programming is, at first, all about getting you to significantly change your programming POV. It's a shift for anyone---in fact, the better you are at understanding C/Ruby/Python/Perl/Java/ObjC/Lua the harder a shift it is. At the end of the day, you adopt a new way of thinking that is incredibly clarifying for all programming. One simple thing is that it allows you to "see" where state, re-entry, evaluation, IO, and failure are happening in a program---things that you are blind to when you're used to languages where the answer is "always". This article isn't even meant to explain why you ought to learn Haskell. It's more like a signpost on your path to mastery, should you begin walking it.
chongli 13y ago
>There are very few things in the world of CS/programming where I can't follow along and grok what's going on, especially when laid out in a tutorial form like this. That's probably because most of the tutorials you've followed have adopted an imperative style of programming. It is easy for you to follow along because it really isn't all that different from what you are accustomed to. Functional programming really is a different beast entirely. It's often said (though I remain skeptical) that it's actually easier to learn functional programming as a non-programmer than to un-learn your imperative programming tendencies. >The fact that I was totally lost when reading this is not a good sign when you're trying to get people to adopt your school of thought. I don't think that's a fair assessment. You could say the same thing about starting from functional programming and switching to imperative; some people actually do this! They find the idea of mutating a variable to be completely counter-intuitive!
- cynwoody 13y ago
  > They find the idea of mutating a variable to be completely counter-intuitive! The notion of mutation is implicit in the definition of "variable."
  - chousuke 13y ago
    Except it isn't. Unless you learn imperative programming before you learn basic algebra, the first definition of a variable you encounter is that of an immutable one.
    - Shorel 13y ago
      Actually an algebraic variable is named that way because you can change it every time you do the exercise. So you don't change it during one exercise, but you can and certainly will change it when you change the exercise to another one with the same principle.
      - chongli 13y ago
        Right, but you're not mutating it in the middle of your calculation.
        Gravityloss 13y ago
        If you have a sum for example sum_{x=1}^{10}x^2, x definitely changes quite many times during your calculation.
        chongli 13y ago
        No, that's an example of recursion. With recursion you aren't mutating the variable, you're shadowing its definition. This is a subtle, but important, distinction.
        Gravityloss 13y ago
ww520 13y ago
To the other people saying that pure functional programming is the reason that it's difficult to explain Haskell to other programmers and blaming them for doing too much imperative style coding, it's the wrong assumption. Pure functional programming has nothing to do with the difficulty in explaining Haskell. Pure functional programming is in Lisp/Schema/C#/Clojure/and other languages and people have no trouble learning it. Haskell is difficult to explain because it has many terms, vocabulary, and syntax that are not familiar to people. It's ML-style syntax doesn't help. Most tutorials targeting Haskell beginners implicitly assume the readers already know the Haskell syntax, terms, definition, etc, and go right ahead to explain the advance concepts like functor, applicative, or monad. It's like teaching them how to fly before they know how to walk, in the Haskell land. No wonder Haskell beginners are frustrated with any of the monad tutorial. The thing is. Stop. Stop telling beginners what monad is. Just show them the basics in Haskell and get something useful going. Get them to write and use Haskell programs. When the need arise, they will look into what monad is. Programmers have used STL plenty without knowing the internals of C++ templates. Same thing can be done with monad.
- egonschiele 13y ago
  Just to follow up on your other comment: > When the need arise, they will look into what monad is. I couldn't have said it any better. This is the exact scenario that this post is aimed at.

by balloot 13y ago

egonschiele 13y ago

Post author here. I'd love to know where you stumbled!

tel 13y ago

This is a pretty common idea, but it's because pure functional programming is, at first, all about getting you to significantly change your programming POV. It's a shift for anyone---in fact, the better you are at understanding C/Ruby/Python/Perl/Java/ObjC/Lua the harder a shift it is. At the end of the day, you adopt a new way of thinking that is incredibly clarifying for all programming. One simple thing is that it allows you to "see" where state, re-entry, evaluation, IO, and failure are happening in a program---things that you are blind to when you're used to languages where the answer is "always". This article isn't even meant to explain why you ought to learn Haskell. It's more like a signpost on your path to mastery, should you begin walking it.

chongli 13y ago

>There are very few things in the world of CS/programming where I can't follow along and grok what's going on, especially when laid out in a tutorial form like this. That's probably because most of the tutorials you've followed have adopted an imperative style of programming. It is easy for you to follow along because it really isn't all that different from what you are accustomed to. Functional programming really is a different beast entirely. It's often said (though I remain skeptical) that it's actually easier to learn functional programming as a non-programmer than to un-learn your imperative programming tendencies. >The fact that I was totally lost when reading this is not a good sign when you're trying to get people to adopt your school of thought. I don't think that's a fair assessment. You could say the same thing about starting from functional programming and switching to imperative; some people actually do this! They find the idea of mutating a variable to be completely counter-intuitive!

cynwoody 13y ago
> They find the idea of mutating a variable to be completely counter-intuitive! The notion of mutation is implicit in the definition of "variable."
- chousuke 13y ago
  Except it isn't. Unless you learn imperative programming before you learn basic algebra, the first definition of a variable you encounter is that of an immutable one.
  - Shorel 13y ago
    Actually an algebraic variable is named that way because you can change it every time you do the exercise. So you don't change it during one exercise, but you can and certainly will change it when you change the exercise to another one with the same principle.
    - chongli 13y ago
      Right, but you're not mutating it in the middle of your calculation.
      - Gravityloss 13y ago
        If you have a sum for example sum_{x=1}^{10}x^2, x definitely changes quite many times during your calculation.
        chongli 13y ago
        No, that's an example of recursion. With recursion you aren't mutating the variable, you're shadowing its definition. This is a subtle, but important, distinction.
        Gravityloss 13y ago

ww520 13y ago

To the other people saying that pure functional programming is the reason that it's difficult to explain Haskell to other programmers and blaming them for doing too much imperative style coding, it's the wrong assumption. Pure functional programming has nothing to do with the difficulty in explaining Haskell. Pure functional programming is in Lisp/Schema/C#/Clojure/and other languages and people have no trouble learning it. Haskell is difficult to explain because it has many terms, vocabulary, and syntax that are not familiar to people. It's ML-style syntax doesn't help. Most tutorials targeting Haskell beginners implicitly assume the readers already know the Haskell syntax, terms, definition, etc, and go right ahead to explain the advance concepts like functor, applicative, or monad. It's like teaching them how to fly before they know how to walk, in the Haskell land. No wonder Haskell beginners are frustrated with any of the monad tutorial. The thing is. Stop. Stop telling beginners what monad is. Just show them the basics in Haskell and get something useful going. Get them to write and use Haskell programs. When the need arise, they will look into what monad is. Programmers have used STL plenty without knowing the internals of C++ templates. Same thing can be done with monad.

egonschiele 13y ago
Just to follow up on your other comment: > When the need arise, they will look into what monad is. I couldn't have said it any better. This is the exact scenario that this post is aimed at.