I completely agree with the points in this article and have come to the same conclusion after using languages that default to unary curried functions.

> I'd also love to hear if you know any (dis)advantages of curried functions other than the ones mentioned.

I think it fundamentally boils down to the curried style being _implicit_ partial application, whereas a syntax for partial application is _explicit_. And as if often the case, being explicit is clearer. If you see something like

    let f = foobinade a b

in a curried language then you don't immediately know if `f` is the result of foobinading `a` and `b` or if `f` is `foobinade` partially applied to some of its arguments. Without currying you'd either write

    let f = foobinade(a, b)

or

    let f = foobinade(a, b, $) // (using the syntax in the blog post)

and now it's immediately explicitly clear which of the two cases we're in.

This clarity not only helps humans, it also help compilers give better error messages. In a curried languages, if a function is mistakenly applied to too few arguments then the compiler can't always immediately detect the error. For instance, if `foobinate` takes 3 arguments, then `let f = foobinade a b` doesn't give rise to any errors, whereas a compiler can immediately detect the error in `let f = foobinade(a, b)`.

A syntax for partial application offers the same practical benefits of currying without the downsides (albeit loosing some of the theoretical simplicity).

  f = foobinade a b
  g = foobinadd c d

    let f :: Int = foobinade a b

    let result =
        input
            |> foobinade a b
            |> barbalyze c d

    let f = foobinade a b >> barbalyze c d
    let result = f input

    let f = barbalyze(c, d, foobinade(a, b, $))
    let result = f(input)

    let result = barbalyze(c, d, foobinade(a, b, input))

  let result = (barbalyze(c, d, $) . foobinade(a, b, $)) input

  let result = input
    |> foobinade(a, b, $)
    |> barbalyze(c, d, $)

  let result = input
    |> add_prefix_and_suffix("They said '", $, "'!")

  let foos = foobinate(a, b, input)
  let bars = barbakize(c, d, foos)

Currying was recently removed from Coalton: https://coalton-lang.github.io/20260312-coalton0p2/#fixed-ar...

One "feature of currying" in Haskell that isn't mentioned in the fine article is that parts of the function may not be dependent on the last argument(s) and only needs to be evaluated once over many application of the last argument(s) which can be very useful when partially applied functions are passed to higher-order functions.

Functions can be done explicitly written to do this or it can be achieved through compiler optimisation.

  where

    go [] = z

    go (x : xs) = f x (go xs)

    [] -> 0

    (x : xs) = x + go xs

  getClosest(points, p) = findInTree(buildTree(points), p)

  myPoints = [...]
  map (getClosest(myPoints, $)) myPoints

  map (\p -> findInTree(buildTree(myPoints), p)) myPoints

  let tree = buildTree(myPoints) in map (\p -> findInTree(tree, p)) myPoints

I couldn't agree more. Having spent a lot of time with a language with currying like this recently, it seems very obviously a misfeature.

1. Looking at a function call, you can't tell if it's returning data, or a function from some unknown number of arguments to data, without carefully examining both its declaration and its call site

2. Writing a function call, you can accidentally get a function rather than data if you leave off an argument; coupled with pervasive type inference, this can lead to some really tiresome compiler errors

3. Functions which return functions look just like functions which take more arguments and return data (card-carrying functional programmers might argue these are really the same thing, but semantically, they aren't at all - in what sense is make_string_comparator_for_locale "really" a function which takes a locale and a string and returns a function from string to ordering?)

3a. Because of point 3, our codebase has a trivial wrapper to put round functions when your function actually returns a function (so make_string_comparator_for_locale has type like Locale -> Function<string -> string -> order>), so now if you actually want to return a function, there's boilerplate at the return and call sites that wouldn't be there in a less 'concise' language!

I think programming languages have a tendency to pick up cute features that give you a little dopamine kick when you use them, but that aren't actually good for the health of a substantial codebase. I think academic and hobby languages, and so functional languages, are particularly prone to this. I think implicit currying is one of these features.

I'm biased here since the easy currying is by far my favourite feature in Haskell (it always bothers me that I have to explicitly create a lamba in Lisps) but the arguments in the article don't convince me, what with the synctactic overhead for the "tuple style".

Okay, but if you combine the curried and tuple styles, and add a dash of runtime function pointers, you can solve the expression problem. [1]

[1]: https://gavinhoward.com/2025/04/how-i-solved-the-expression-...

I'd got a step further and say that in business software, named parameters are preferable for all but the smallest functions.

Using curried OR tuple arg lists requires remembering the name of an argument by its position. This saves room on the screen but is mental overhead.

The fact is that arguments do always have names anyway and you always have to know what they are.

  let warn_user ~message = ... (* the ~ makes this a named parameter *)

  let error = "fatal error!!" in
  warn_user ~message:error; (* different names, have to specify both *)

  let message = "fatal error!!" in
  warn_user ~message; (* same names, elided *)

A benefit to using the currying style is that you can do work in the intermediate steps and use that later. It is not simply a 'cool' way to define functions. Imagine a logging framework:

  (log configuration identifier level format-string arg0 arg1 ... argN)
  

After each partial application step you can do more and more work narrowing the scope of what you return from subsequent functions.

  ;; Preprocessing the configuration is possible
  ;; Imagine all logging is turned off, now you can return a noop
  (partial log conf)
  ;; You can look up the identifier in the configuration to determine what the logger function should look like
  (partial log conf id)
  ;; You could return a noop function if the level is not enabled for the particular id
  (partial log config id level)
  ;; Pre-parsing the format string is now possible
  (partial log conf id level "%time - %id")
  

In many codebases I've seen a large amount of code is literally just to emulate this process with multiple classes, where you're performing work and then caching it somewhere. In simpler cases you can consolidate all of that in a function call and use partial application. Without some heroic work by the compiler you simply cannot do that in an imperative style.

One language that uses the tuple argument convention described in the article is Standard ML. In Standard ML, like OCaml and Haskell, all functions take exactly one argument. However, while OCaml and Haskell prefer to curry the arguments, Standard ML does not.

There is one situation, however, where Standard ML prefers currying: higher-order functions. To take one example, the type signature of `map` (for mapping over lists) is `val map : ('a -> 'b) -> 'a list -> 'b list`. Because the signature is given in this way, one can "stage" the higher-order function argument and represent the function "increment all elements in the list" as `map (fn n => n + 1)`.

That being said, because of the value restriction [0], currying is less powerful because variables defined using partial application cannot be used polymorphically.

[0] http://mlton.org/ValueRestriction

I agree with this article. Tuples nicely unified multiple return values and multiple parameters. FWIW Scala and Virgil both support the _ syntax for the placeholder in a partial application.

    def add(x: int, y: int) -> int { return x + y; }
    def add3 = add(_, 3);

Or more simply, reusing some built-in functions:

    def add3 = int.+(_, 3);

    { add(it, 3) } // Kotiln
    add(_, 3) // Scala

    { add(subtract(it, 2), 3) } // Kotlin
    // add(subtract(_, 2), 3) // no, this means adding 3 to the function `add(subtract(_, 2)`
    x => { add(subtract(x, 2), 3) } // Scala

    fun x => add(subtract(x, 2), 3) // Virgil