4 ms·

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

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
> I'd be interested to hear what else you think is lost as a result of automatic currying. How about I use one of your examples. > 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. All abstractions leak. The fact that Haskell is always curried means that you always have to be aware of currying. There are many kinds of problem solving. One is "how do I solve {x} using {y} in some clever way." Haskell is great for those folk. Another is "How do I solve {x}." Here's one way to distinguish these two groups. The first sends "look at my cute solution to {x}" to their friends while the latter say they send "look at what I built". To put it another way, when a user community is dominated by folks who write papers/essays about the tools, you've got a tool for folks who want to play with tools. Haskell is wonderful for a subset of those folks who care a lot about tools, specifically those folks who think that mathematical purity is important. There are other goals.
- tmhedberg 15y ago
  The fact that Haskell is always curried means that you always have to be aware of currying. No, you don't. That was my point. By pretending that functions aren't curried, you're limiting yourself to a subset of the language's full expressiveness, but it is a completely consistent subset; it behaves precisely as you would expect it to in the absence of currying. And that subset is equivalent to the expressiveness of Python (or any other language) without currying. It sounds like you're implying that Haskell is just an odd assortment of academic "cute tricks" for impressing people who have nothing more important to spend their time on, and that any practical programmer would steer clear of it in order to "get things done". Frankly, this is the opinion of someone who has little experience with the language, or with functional programming in general. There are many ideas in Haskell which are unusual, or of seemingly little value to someone with a strictly imperative background. But as anyone who has used the language to build something practical can tell you, these "tricks" are much more than clever mathematical toys; they enable you to express your intent more succintly and with greater precision than with the tools provided by most other languages, with strong compile-time guarantees of correctness to boot. You tend to miss them quite a bit when using languages which lack these features. Not everyone who uses Haskell falls in love with it, and there are plenty of arguments to be made both for and against the language, but your dismissive characterization is just naive.

anamax 15y ago

> I'd be interested to hear what else you think is lost as a result of automatic currying. How about I use one of your examples. > 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. All abstractions leak. The fact that Haskell is always curried means that you always have to be aware of currying. There are many kinds of problem solving. One is "how do I solve {x} using {y} in some clever way." Haskell is great for those folk. Another is "How do I solve {x}." Here's one way to distinguish these two groups. The first sends "look at my cute solution to {x}" to their friends while the latter say they send "look at what I built". To put it another way, when a user community is dominated by folks who write papers/essays about the tools, you've got a tool for folks who want to play with tools. Haskell is wonderful for a subset of those folks who care a lot about tools, specifically those folks who think that mathematical purity is important. There are other goals.

tmhedberg 15y ago
The fact that Haskell is always curried means that you always have to be aware of currying. No, you don't. That was my point. By pretending that functions aren't curried, you're limiting yourself to a subset of the language's full expressiveness, but it is a completely consistent subset; it behaves precisely as you would expect it to in the absence of currying. And that subset is equivalent to the expressiveness of Python (or any other language) without currying. It sounds like you're implying that Haskell is just an odd assortment of academic "cute tricks" for impressing people who have nothing more important to spend their time on, and that any practical programmer would steer clear of it in order to "get things done". Frankly, this is the opinion of someone who has little experience with the language, or with functional programming in general. There are many ideas in Haskell which are unusual, or of seemingly little value to someone with a strictly imperative background. But as anyone who has used the language to build something practical can tell you, these "tricks" are much more than clever mathematical toys; they enable you to express your intent more succintly and with greater precision than with the tools provided by most other languages, with strong compile-time guarantees of correctness to boot. You tend to miss them quite a bit when using languages which lack these features. Not everyone who uses Haskell falls in love with it, and there are plenty of arguments to be made both for and against the language, but your dismissive characterization is just naive.