4 ms·

That's my point. You're talking about jumping around from language to language, but Functional Programming techniques tend to be applicable across all of them.

That's my point. You're talking about jumping around from language to language, but Functional Programming techniques tend to be applicable across all of them. My personal angle is that Haskell puts up less bullshit in your path while you're learning stuff about type based reasoning at the cost of being much less like things you may have seen before. Regardless of that, going from Haskell to Scala to ML to Clojure ad naseum isn't going to get you any deeper understanding of techniques. At most you'll understand how some very basic concepts work in different languages.

pohl 14y ago
I wouldn't call opening myself to multiple languages "jumping", and it seems a bit of a leap that you assume so. (Note that I said nothing of the proportions invested in each.) The only point of my post was that one does not need to wall oneself off from one language in order to open oneself to another. Regardless of that, going from Haskell to Scala to ML to Clojure ad naseum isn't going to get you any deeper understanding of techniques. I suppose that's a fair view if one starts from the assumption that techniques are all that is worthy of pursuit. But there is also comparison of priorities implicit in different design choices. There is also an appreciation of history (ML is a good example of that) and an appreciation for industrial frontiers (Rust is a great example there: if you're not following Graydon Hoare you're missing out). Each language also has its own unique traits that don't readily map to others. Haskell's lazy evaluation and monadic IO are a great example there. Want to wield the sword of homoiconicity? Better learn a LISP. Moreover, learning Haskell prepares you to read a lot of literature. ML prepares one to read Chris Okasaki's book on purely functional data structures. (Yes, there is a Haskell appendix in the back of the book, but knowing both means you can compare them!). Scala is worth study as a case study in the tradeoffs of making on object/functional hybrid. The human brain is an associative machine, you know. Sometimes the act of broadening has the consequence of strengthening (or even deepening), because you're giving your melon more things to interrelate.
- DannoHung 14y ago
  Learning any one of these, if they have a strong type system and an emphasis on immutable data are going to prepare you for the literature. Comparative language evaluations are fine, but don't tell me that you made that clear that that was what you were after in your original comment.
  - pohl 14y ago
    You're a strange chap. If you agree that languages are small – so much that you insist it was your point when, in fact, it was mine – then why do you think there's such a large cost to picking up another one? I also don't understand why I needed to make it clear that language comparisons are beneficial. Was someone trying to assert that they're not?
    - DannoHung 14y ago
      You said, 'My own approach to learning FP has been "Hello Haskell", "Hello Scala", "Hello ML", "Hello Clojure", "Hello Rust",...' and I thought to myself, "Well, that's not going to really help you learn Functional Programming techniques and design strategies". You really have to use a language for a while to understand how to make a good software design inside of it. It's not the cost of learning the language, it's the cost of not spending enough time working with the language. Now on the other hand, if you just like looking at a lot of languages and seeing the design tradeoffs, you can spend a lot less time using each one to get that perception. But you only mentioned learning FP in the first place. I didn't divine that comparing the language design was your reason for not picking one and sticking with it.
      - pohl 14y ago
        ...and I thought to myself, "Well, that's not going to really help you learn Functional Programming techniques and design strategies" That's where you went wrong, then, because it doesn't in any way rule out the possibility of learning it either. In your initial response, you said "Maybe you should actually learn something about FP...". Let's make this clear: you don't know me. Pro tip: if you have to make assumptions about other people, then it's possible to make a wrong assumption. In these cases, it's often better to ask a question than to launch into criticism based on assumptions.

pohl 14y ago

I wouldn't call opening myself to multiple languages "jumping", and it seems a bit of a leap that you assume so. (Note that I said nothing of the proportions invested in each.) The only point of my post was that one does not need to wall oneself off from one language in order to open oneself to another. Regardless of that, going from Haskell to Scala to ML to Clojure ad naseum isn't going to get you any deeper understanding of techniques. I suppose that's a fair view if one starts from the assumption that techniques are all that is worthy of pursuit. But there is also comparison of priorities implicit in different design choices. There is also an appreciation of history (ML is a good example of that) and an appreciation for industrial frontiers (Rust is a great example there: if you're not following Graydon Hoare you're missing out). Each language also has its own unique traits that don't readily map to others. Haskell's lazy evaluation and monadic IO are a great example there. Want to wield the sword of homoiconicity? Better learn a LISP. Moreover, learning Haskell prepares you to read a lot of literature. ML prepares one to read Chris Okasaki's book on purely functional data structures. (Yes, there is a Haskell appendix in the back of the book, but knowing both means you can compare them!). Scala is worth study as a case study in the tradeoffs of making on object/functional hybrid. The human brain is an associative machine, you know. Sometimes the act of broadening has the consequence of strengthening (or even deepening), because you're giving your melon more things to interrelate.

DannoHung 14y ago
Learning any one of these, if they have a strong type system and an emphasis on immutable data are going to prepare you for the literature. Comparative language evaluations are fine, but don't tell me that you made that clear that that was what you were after in your original comment.
- pohl 14y ago
  You're a strange chap. If you agree that languages are small – so much that you insist it was your point when, in fact, it was mine – then why do you think there's such a large cost to picking up another one? I also don't understand why I needed to make it clear that language comparisons are beneficial. Was someone trying to assert that they're not?
  - DannoHung 14y ago
    You said, 'My own approach to learning FP has been "Hello Haskell", "Hello Scala", "Hello ML", "Hello Clojure", "Hello Rust",...' and I thought to myself, "Well, that's not going to really help you learn Functional Programming techniques and design strategies". You really have to use a language for a while to understand how to make a good software design inside of it. It's not the cost of learning the language, it's the cost of not spending enough time working with the language. Now on the other hand, if you just like looking at a lot of languages and seeing the design tradeoffs, you can spend a lot less time using each one to get that perception. But you only mentioned learning FP in the first place. I didn't divine that comparing the language design was your reason for not picking one and sticking with it.
    - pohl 14y ago
      ...and I thought to myself, "Well, that's not going to really help you learn Functional Programming techniques and design strategies" That's where you went wrong, then, because it doesn't in any way rule out the possibility of learning it either. In your initial response, you said "Maybe you should actually learn something about FP...". Let's make this clear: you don't know me. Pro tip: if you have to make assumptions about other people, then it's possible to make a wrong assumption. In these cases, it's often better to ask a question than to launch into criticism based on assumptions.