5 ms·

So basically he'd be against currying? I find currying useful in certain situations - threading/piping being a common scenario.

chc 9y ago
Currying and composition, I think. I actually think he has a point on those two in the context of Clojure specifically. The process of explicitly currying or composing functions (again, in Clojure specifically) is usually more verbose and IMO harder to read than just writing an anonymous function that expresses the same thing.
- daxfohl 9y ago
  I frankly don't like these features even in Haskell. There are a few specific places where it makes things more elegant, but in general I dislike having to think about "how do I arrange params to allow for the greatest possible use of partial application in the rest of my code?", and then the inevitable "oh I can fix that with (flip (flip flip))" or some nonsense. It's tangential to the requirements of getting my app done, and generally time / brain cells wasted. I'd rather it simply not be part of the language in the first place. Granted most of my Haskell work is in boring line of business apps, so maybe partial application is more important in other fields.
  - Silhouette 9y ago
    It's one of those things where you can take a simple tool and probably make something hideously complicated with it if you go too far, but in simple cases it's useful all over the place. For example, I very often write functions that take an initial parameter representing some sort of customisable context and then further parameters that are the right types to use with some standard higher order function like a map, filter or fold. Partial application then supplies the context and gives back something ready to pass into that HOF.
  - michaelmrose 9y ago
    I would rather chunks of functionality not be removed from tools to suit other peoples aesthetic sensibilities.
    - allengeorge 9y ago
      Not all features have equivalent upside (I.e. Some features have very limited upside and significant cost, in terms of maintainability etc.) When creating a codebase we should be conservative with the features we use - and this is all the article is arguing for.
      - mercer 9y ago
        I feel this way about the destructuring assignment and spread syntax in javascript, or at least a little bit. It's incredibly convenient to use, but sometimes when I look at 'idiomatic' React code, in particular in the context of Redux, I can't help but feel it's a bit too much, especially when I look at the code through 'teacher' eyes, and especially when it's combined with JSX. And that's not even mentioning the arrow function variants, default parameters, and other ESNext goodies. And yet I find it difficult to keep my hands off it, because it's just so damn convenient.
    - daxfohl 9y ago
      I believe I've heard it said: the most difficult thing when building a language is not deciding which features to add, but which features to leave out.
      - allengeorge 9y ago
        This is a pretty common maxim, and applies to any design exercise :) "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. " -- Antoine de Saint-Exupery
  - a-saleh 9y ago
    If you were to get rid of curried functions everywhere, how would change the applicative pattern. I just find the "plain_fn <$> weird_type <*> weird_type ..." e.t.c really convenient.
- fnordsensei 9y ago
  Sometimes they have different characteristics even though they produce the same result. Such as when composing transducers, which has performance implications.
rhinoceraptor 9y ago
I use it a lot when writing functions with side-effects in JavaScript, as a sort of informal dependency injection. If I have a function that needs to do an HTTP request, I will curry it so that the outermost function of the service takes the HTTP service as its argument.

chc 9y ago

Currying and composition, I think. I actually think he has a point on those two in the context of Clojure specifically. The process of explicitly currying or composing functions (again, in Clojure specifically) is usually more verbose and IMO harder to read than just writing an anonymous function that expresses the same thing.

daxfohl 9y ago
I frankly don't like these features even in Haskell. There are a few specific places where it makes things more elegant, but in general I dislike having to think about "how do I arrange params to allow for the greatest possible use of partial application in the rest of my code?", and then the inevitable "oh I can fix that with (flip (flip flip))" or some nonsense. It's tangential to the requirements of getting my app done, and generally time / brain cells wasted. I'd rather it simply not be part of the language in the first place. Granted most of my Haskell work is in boring line of business apps, so maybe partial application is more important in other fields.
- Silhouette 9y ago
  It's one of those things where you can take a simple tool and probably make something hideously complicated with it if you go too far, but in simple cases it's useful all over the place. For example, I very often write functions that take an initial parameter representing some sort of customisable context and then further parameters that are the right types to use with some standard higher order function like a map, filter or fold. Partial application then supplies the context and gives back something ready to pass into that HOF.
- michaelmrose 9y ago
  I would rather chunks of functionality not be removed from tools to suit other peoples aesthetic sensibilities.
  - allengeorge 9y ago
    Not all features have equivalent upside (I.e. Some features have very limited upside and significant cost, in terms of maintainability etc.) When creating a codebase we should be conservative with the features we use - and this is all the article is arguing for.
    - mercer 9y ago
      I feel this way about the destructuring assignment and spread syntax in javascript, or at least a little bit. It's incredibly convenient to use, but sometimes when I look at 'idiomatic' React code, in particular in the context of Redux, I can't help but feel it's a bit too much, especially when I look at the code through 'teacher' eyes, and especially when it's combined with JSX. And that's not even mentioning the arrow function variants, default parameters, and other ESNext goodies. And yet I find it difficult to keep my hands off it, because it's just so damn convenient.
  - daxfohl 9y ago
    I believe I've heard it said: the most difficult thing when building a language is not deciding which features to add, but which features to leave out.
    - allengeorge 9y ago
      This is a pretty common maxim, and applies to any design exercise :) "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. " -- Antoine de Saint-Exupery
- a-saleh 9y ago
  If you were to get rid of curried functions everywhere, how would change the applicative pattern. I just find the "plain_fn <$> weird_type <*> weird_type ..." e.t.c really convenient.
fnordsensei 9y ago
Sometimes they have different characteristics even though they produce the same result. Such as when composing transducers, which has performance implications.

rhinoceraptor 9y ago

I use it a lot when writing functions with side-effects in JavaScript, as a sort of informal dependency injection. If I have a function that needs to do an HTTP request, I will curry it so that the outermost function of the service takes the HTTP service as its argument.