4 ms·

This argument seems silly to me. Currying is the name of the technique. Why is that scary? Should he call it something different just to avoid "scaring" feeble

This argument seems silly to me. Currying is the name of the technique. Why is that scary? Should he call it something different just to avoid "scaring" feeble programmers who are afraid of new words?

joejohnson 15y ago
No, but he could introduce a new topic (Currying), and then instead of showing how it's "just like Haskell" (something his target audience might not care about), he could instead show how it's another way of thinking about something that most programmers probably already do.
anamax 15y ago
You're missing the point. Currying isn't a big deal for python programmers. The article fails precisely because it makes currying into a big deal. This is yet another example of how haskell got it wrong. Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. (And that's true even if we ignore the complications that it adds to polymorphism.)
- tkahn6 15y ago
  > Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. Can you elaborate on what you mean by this? As it stands I don't understand what this means. > (And that's true even if we ignore the complications that it adds to polymorphism.) Please elaborate on this as well.
- dustingetz 15y ago
  > [basing haskell on opaque ideas like currying is dumb] (paraphrase) Simon Peyton-Jones (haskell creator) often says in videos that haskell is a sandbox for playing with CS ideas that haven't yet mainstreamed. Monads are a great example - haskell's purity helped distill the idea into something less opaque and now these ideas are starting to pop up in mainstream languages - "jquery is a monad"[1]. its not haskell that is dumb, dumb is when people try to use haskell for things it wasn't designed for. Scala and Clojure are both chock full of functional opinions yet designed to be practical. [1] http://importantshock.wordpress.com/2009/01/18/jquery-is-a-monad/ http://importantshock.wordpress.com/2009/01/18/jquery-is-a-m...
- tmhedberg 15y ago
  Currying isn't a big deal for python programmers. The article fails precisely because it makes currying into a big deal. I wasn't trying to imply that currying is a big deal for most Python programmers, nor do I agree that the article was. But I think it's probably safe to say that many Python programmers aren't familiar with it or how it can be effectively put to use, since in Python, it's a neat, occasionally useful technique, but isn't exactly "central" to the language. For whatever reason, Python also tends to attract a lot of beginner programmers, who probably haven't had enough experience to be exposed to functional techniques. I interpreted the article as targeting that kind of audience. This is yet another example of how haskell got it wrong. Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. (And that's true even if we ignore the complications that it adds to polymorphism.) Disclaimer: I like Haskell a lot, so you should probably take my opinion with a grain of salt. I'm not trying to start an argument, just expressing a counter-opinion. From my point of view, Haskell's "currying by default" approach gives you what is essentially a superset of the functionality available in most other languages, while taking away very little. It's fine to think of `f a b c` in Haskell as being equivalent to `f(a, b, c)` in Python, even though we know that, under the hood, f isn't really a function of 3 arguments. It has the same behavior as the Python version if you always fully apply it to all 3 arguments, though (ignoring strictness). But of course, Haskell conveniently allows you to partially apply f without requiring any extra effort on your part. At least Python gives you the functools library module to make that sort of thing easier; most languages don't even do that. What does automatic currying take away? Well, as you alluded, function polymorphism based on the length of the argument list isn't as straightforward as it is in, say, Java, since Haskell functions really only have a single argument, period. But if you really want the ability to do this kind of overloading, it can be accomplished using type classes. And Python's optional/keyword arguments can be emulated using record syntax. It's just not particularly common to use these techniques, because most of the time there are much more idiomatic ways of accomplishing the things you might use function overloading for in a different language. I'd be interested to hear what else you think is lost as a result of automatic currying. It's difficult for me to come up with anything other than benefits, but maybe I am being blinded by my enthusiasm for the language.
  - anamax 15y ago

joejohnson 15y ago

No, but he could introduce a new topic (Currying), and then instead of showing how it's "just like Haskell" (something his target audience might not care about), he could instead show how it's another way of thinking about something that most programmers probably already do.

anamax 15y ago

You're missing the point. Currying isn't a big deal for python programmers. The article fails precisely because it makes currying into a big deal. This is yet another example of how haskell got it wrong. Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. (And that's true even if we ignore the complications that it adds to polymorphism.)

tkahn6 15y ago
> Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. Can you elaborate on what you mean by this? As it stands I don't understand what this means. > (And that's true even if we ignore the complications that it adds to polymorphism.) Please elaborate on this as well.
dustingetz 15y ago
> [basing haskell on opaque ideas like currying is dumb] (paraphrase) Simon Peyton-Jones (haskell creator) often says in videos that haskell is a sandbox for playing with CS ideas that haven't yet mainstreamed. Monads are a great example - haskell's purity helped distill the idea into something less opaque and now these ideas are starting to pop up in mainstream languages - "jquery is a monad"[1]. its not haskell that is dumb, dumb is when people try to use haskell for things it wasn't designed for. Scala and Clojure are both chock full of functional opinions yet designed to be practical. [1] http://importantshock.wordpress.com/2009/01/18/jquery-is-a-monad/ http://importantshock.wordpress.com/2009/01/18/jquery-is-a-m...
tmhedberg 15y ago
Currying isn't a big deal for python programmers. The article fails precisely because it makes currying into a big deal. I wasn't trying to imply that currying is a big deal for most Python programmers, nor do I agree that the article was. But I think it's probably safe to say that many Python programmers aren't familiar with it or how it can be effectively put to use, since in Python, it's a neat, occasionally useful technique, but isn't exactly "central" to the language. For whatever reason, Python also tends to attract a lot of beginner programmers, who probably haven't had enough experience to be exposed to functional techniques. I interpreted the article as targeting that kind of audience. This is yet another example of how haskell got it wrong. Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. (And that's true even if we ignore the complications that it adds to polymorphism.) Disclaimer: I like Haskell a lot, so you should probably take my opinion with a grain of salt. I'm not trying to start an argument, just expressing a counter-opinion. From my point of view, Haskell's "currying by default" approach gives you what is essentially a superset of the functionality available in most other languages, while taking away very little. It's fine to think of `f a b c` in Haskell as being equivalent to `f(a, b, c)` in Python, even though we know that, under the hood, f isn't really a function of 3 arguments. It has the same behavior as the Python version if you always fully apply it to all 3 arguments, though (ignoring strictness). But of course, Haskell conveniently allows you to partially apply f without requiring any extra effort on your part. At least Python gives you the functools library module to make that sort of thing easier; most languages don't even do that. What does automatic currying take away? Well, as you alluded, function polymorphism based on the length of the argument list isn't as straightforward as it is in, say, Java, since Haskell functions really only have a single argument, period. But if you really want the ability to do this kind of overloading, it can be accomplished using type classes. And Python's optional/keyword arguments can be emulated using record syntax. It's just not particularly common to use these techniques, because most of the time there are much more idiomatic ways of accomplishing the things you might use function overloading for in a different language. I'd be interested to hear what else you think is lost as a result of automatic currying. It's difficult for me to come up with anything other than benefits, but maybe I am being blinded by my enthusiasm for the language.
- anamax 15y ago