1. 13

  2. 8

    Currying is partially applying parameters.

    That is actually “partial application”.

    Currying is:

    the technique of translating the evaluation of a function that takes multiple arguments (or a tuple of arguments) into evaluating a sequence of functions, each with a single argument.

    Also, I think we missed a chance to use a much better name than currying.

    The name “currying”, coined by Christopher Strachey in 1967, is a reference to logician Haskell Curry. The alternative name “Schönfinkelisation” has been proposed as a reference to Moses Schönfinkel.

    It’s got a variant of “beauty” in the name and rolls off the tongue.

    1. 3

      Yes I am a bit short cutting… I wanted to have something simple with an example to get started. I have edited the article and the first example.

      Is it not more difficult to pronounce “Schönfinkelisation” than curry? I had not seen that “beauty component” of the name on first read! Thanks

      1. 1

        moseying could have been nice

        1. 1

          Just use the german “schönfinkeln”, which avoids the nasty inter-language-switch in between.

        2. 1

          It’s got a variant of “beauty” in the name and rolls off the tongue.

          A little known fact about me (unless you’ve seen me on a conf) is that I own a shirt with “schönfinkeln?” printed on it.

        3. 2

          I never understood the power of currying either until I started using Clojure heavily for stream processing. Now I use them so much by default I think about how to construct partials for their versatility in use. For example, I can have a single function that creates stream processors based on various rules loaded from configs at startup. That way, the creation of the stream processor only occurs once at startup when the first argument is passed in, improving performance when the returned stream function is called since any config processing has already occurred. A generalized sanitized example:

          (defn process-rules
            [rule-fn & downstreams]
            (fn [event] (apply (rule-fn event) downstreams)))
          (defn apply-rule
            [rule event]
            (...do some stuff with rule to process event...))
          (defn create-stream-processor
            (partial process-rules
                        (fn [event] (map (fn [rule] (apply-rule rule event)) some-rules))))

          I may have sanitized too much for that to make sense or parse correctly. But the point is also, if you’re not used to currying regularly, this might not even make sense regardless, let alone be the first way you’d think of approaching the problem of stream processing.

          1. 1

            That is nice. It is true it takes sometimes to get used too, but when it clicks, it clicks!

            I also have to get started with Clojure. Especially after I saw some benchmarking between go, nodejs, and Lisp like languages!

          2. 2

            Really liked the article - I also have had a hard time really understanding the points where I’d use currying in the real world. This is a great example though, well done!

            1. 1

              Thank you! Happy to help.

            2. 1

              This post has plenty of issues IMO.

              For instance:

              const add = (a, b) => a + b
              The first line creates a function add() that takes one parameter and it returns another function that also takes one parameter.

              Or the two code samples shown: https://gist.github.com/idealley/1066aca705b768e5f869674e489347c3/0540e51d02106a6e7904e762cc002ed1c2c4ccba and https://gist.github.com/idealley/3691634227195f6d26027e93b9485849/3471b723bbfd47af561e99cb03d2a66d7a986374 which are pretty bad:

              • no consistency (x ;, x;, if (a), if (a ), if () {}, if ()\n{})
              • loose equalities (!=)
              • use of indexOf instead of includes
              • a || b hack instead of default parameters

              Overall, I think this blogpost gives a pretty bad example to the reader.

              1. 2

                Thank you. I will improve it.