I completely agree with @benwilson512 on this. Elixir has made the choice of taking the first parameter as ‘most important’ parameter for its functions. The BEAM does not have built-in support for currying. The library I made here is indeed slower than not using currying, as anonymous functions are being built in intermediate steps.

Elixir is Elixir because of the design choices that were made (Both in itself, and also partially the things that the BEAM or Erlang decided for it). Elixir is awesome because of its ability to build on top of what’s already built in the past on the BEAM.

Elixir is a dynamically typed language with awesome ideas on macro-creation, improving documentation and testing, and promoting explicitness in general (basically, the dynamic types are the only things that aren’t explicit in Elixir).

I really like Elixir because of these things. There are other languages which I like for different reasons. I like Haskell because of its built-in currying capabilities, and its purity which allows for clearer pattern-matching/guards than in Elixir. I dislike Haskell for the ease at which one can write intelligible programs, and for its high learning curve because of some other design decisions (many of which exist for historical reasons).

I like Ruby because it lets you quickly prototype things. I dislike Ruby for its implicitness and approach to monkey-patching.

I like Prolog because it uses the concept of unification and logic programming. I dislike Prolog because it is very hard to wrap your mind around this difference, and because it is very hard to write non-trivial programs with it.

I like Idris because it is a dependently-typed functional language that lets you reason about your code, instead of testing it. I dislike Idris because it still is very new and badly documented and also has a very high learning curve for newcomers.

I like Inform 7 because it lets you write programs in the English language, like they are books. I dislike Inform 7 because you can only use it to write Interactive Fiction with it.

These are just some languages I’ve experienced over the years. There are many more. I would love a language that would perfectly fit my own needs, but the only way to get such a language is to create it myself. Also, these needs will change over time.

And finally, there is no single language that is best for all tasks. It is easier to formulate some tasks in some languages, but there is no one-language-beats-all.

I’m not entirely sure how I ended up here, but anyway, that was my rant for the day, or something

Currying plus partial application is just awesome, and after having used some haskell you do miss it really hard everywhere else.

Since I haven’t take a look into @Qqwy’s currying package so far, I will give the examples in haskell.

Given the funtion foldr defined as this:

foldr f z []     = z 
foldr f z (x:xs) = f x (foldr f z xs) 

now your job is to implement map on top of this:

You can use either the very naïv approach to just write it down as this:

map f xs = foldr (\y ys -> f x : ys) [] xs

This is a fully applied function but can be further reduced (eta-reduced to be specific) to the following:

map f = foldr (\x xs -> f x : xs) []

After one gets used to it, it is just cool, but maybe, if you do not know it already, you will probably never miss it

Something in Elixir we could do with currying might look like this (untested):

use Currying

def const(a, _b), do: a

curried_const = curry(&const/2)
Enum.map([1,2,3,4,5,6,7,8,9,10], curried_const.(5))

# without curried:
Enum.map([1,2,3,4,5,6,7,8,9,10], &const(5, &1))

I have to admit, in elixir it looks quite a lot more clear and readable, even more idiomatic to simply use a capture

I think it is nice to play with currying and partial application in elixir, but I might probably stick with pipes and captures, since they are a native language thing, while the curried stuff feels foreign.

For the ignorant, what’s the point of currying functions? What’s a use case that it solves for?