> curried functions often don't compose nicely

Same for imperative languages with "parameter list" style. In python, with

def f(a, b): return c, d

def g(k, l): return m, n

you can't do

f(g(1,2))

but have to use

f(*g(1,2))

what is analogical to uncurry, but operate on value rather than function.

TBH I can't name a language where such f(g(1,2)) would work.

  #!/usr/bin/env perl
  use v5.36;
  
  sub f($a, $b) {
    return ($a+1, $b+1);
  }
  
  sub g($k, $l) {
    return ($k+1, $l+1);
  }
  
  say for f(g(1,2));

  3
  4

There are good ideas in functional languages that other languages have borrowed, but there are bad ideas too: currying, function call syntax without parentheses, Hindley-Milner type inference, and laziness by default (Haskell) are experiments that new languages shouldn’t copy.

I like currying because it's fun and cool, but found myself nodding along throughout the whole article. I've taken for granted that declaring and using curried functions with nice associativity (i.e., avoiding lots of parentheses) is as ergonomic as partial application syntax gets, but I'm glad to have that assumption challenged.

The "hole" syntax for partial application with dollar signs is a really creative alternative that seems much nicer. Does anyone know of any languages that actually do it that way? I'd love to try it out and see if it's actually nicer in practice.

I completely agree. Giving the first parameter of a function special treatment only makes sense in a limited subset of cases, while forcing an artificial asymmetry in the general case that I find unergonomic.

With a language like Forth, you know that you can use a stack for data and apply functions on that data. With currying it you put functions on a stack instead. This makes it weird. But you also obscure the dataflow.

With the most successful functional programing language Excel, the dataflow is fully exposed. Which makes it easy.

Certain functional programming languages prefer the passing of just one data-item from one function to the next. One parameter in and one parameter out. And for this to work with more values, it needs to use functions as an output. It is unnecessary cognitive burden. And APL programmers would love it.

Let's make an apple pie as an example. You give the apple and butter and flour to the cook. The cursed curry version would be "use knife for cutting, add cutting board, add apple, stand near table, use hand. Bowl, add table, put, flour, mix, cut, knife butter, mixer, put, press, shape, cut_apple." etc..

Here’s an article I wrote a while ago about a hypothetical language feature I call “folded application”, that makes parameter-list style and folded style equivalent.

https://jonathanwarden.com/implicit-currying-and-folded-appl...

The Roc devs came to a similar conclusion: https://www.roc-lang.org/faq#curried-functions

(Side note: if you're reading this Roc devs, could you add a table of contents?)

I've long been thinking the same thing. In many fields of mathematics the placeholder $ from the OP is often written •, i.e. partial function application is written as f(a, b, •). I've always found it weird that most functional languages, particularly heavily math-inspired ones like Haskell, deviate from that. Yes, there are isomorphisms left and right but at the end of the day you have to settle on one category and one syntax. A function f: A × B -> C is simply not the same thing as a function f: A -> B -> C. Stop treating it like it is.

What's the steelman argument though? Why do languages like Haskell have currying? I feel like that is not set out clearly in the argument.

I feel like not having currying means your language becomes semantically more complicated because where does lambdas come from?