Currying in Kotlin | Hacker News Reader

Currying in Kotlin

towardsdev.com

76 pointsunripe_syntax55 comments

I enjoy reading and writing "Functional" code in a language where the ergonomics lend themselves to functional semantics. That swift code is painful to read. I'll give some examples (from worst to best.)

Java: (awful, to read and write)

    import java.util.function.Function;

    public class Main {
      public static void main(String[] args) {
        Function<Integer, Function<Integer, Integer>> add = x -> y -> x + y;
        Function<Integer, Integer> addFive = add.apply(5);
        int result = addFive.apply(3);  // Output will be 8
      }

Ruby a. (still not great, but there's many ways to do it!)

    add = proc { |x, y| x + y }
    curried_add = add.curry

    add_five = curried_add.call(5)
    result = add_five.call(3)
    }

Ruby b. (slightly more concise)

    add = ->(x) { ->(y) { x + y } }
    add_five = add.(5)
    result = add_five.(3)

Elixir (functional programing lang but doesn't lean on currying too much)

    add = fn x -> (fn y -> x + y end) end
    add_five = add.(5)
    result = add_five.(3)

ES6 (say what you want about javascript but they at least did arrow functions right)

    const add = x => y => x + y;
    const addFive = add(5);
    const result = addFive(3);

Standard ML (clearly a lang where currying is a first class concern in its language design)

    fun add x y = x + y;
    val addFive = add 5;
    val result = addFive 3;

and finally Haskell (which, in this case is a joy to read and write.)

    add x y = x + y
    addFive = add 5
    result = addFive 3

Java has (limited) type inference now I think, right? Does this work for the example you gave?

    public class Main {
      public static void main(String[] args) {
        var add = x -> y -> x + y;
        var addFive = add.apply(5);
        int result = addFive.apply(3);  // Output will be 8
      }
    }

Still not great, but a lot better than the original IMO

No, I don’t think that works. Last time I checked, type inference doesn‘t work for lambda expressions.

Part of the reason - I think - is that lambda expressions need to be boiled down to some concrete @FunctionaInterface interface. You can have arbitrarily many of these, all with the same signature and method name, so language doesn‘t know which to choose.

You need an helper method for that

    public class Main {
      private static <T,R> Function<T,R> fun(Function<T,R> function) {
        return function;
      }

      public static void main(String[] args) {
        var add = fun(x -> fun(y -> x + y));
        var addFive = add.apply(5);
        int result = addFive.apply(3);  // Output will be 8
      }
    }

Those helpers should be part of the JDK.

Throw a checked exception in there and it all goes to hell all over again.

> That swift code is painful to read.

I you mean the Swift code in the article, that almost looks like Kotlin :-)

Swift requires type constraints on the original add function, but infers them for addFive.

    func add<T> (x:T, y:T) -> T where T: Numeric {
      x + y
    }
    let addFive = {(y) in add(x: 5, y: y)}
    let result = addFive(3)

Edit: in Swift 3, one could write

    func add<T>(x:T)(y:T) -> T where T: Numeric {
      return x + y
    }

and call that as

    add(x: 2)(y: 3)

or, in two steps, as

    let addTwo = add(2)
    addTwo(3)

That functionality was removed, though. For reasoning behind that, see https://github.com/apple/swift-evolution/blob/main/proposals....

I meant Kotlin, i totally whiffed. (can you tell i don't write Swift or Kotlin?) :)

(Swift for currying, based on your example, isn't terrible actually!)

When we talk about Currying I can grok these, but if I saw that ES6 example in the wild and FP isn’t on my mind I’d be so confused when reasoning about it, especially if it was more complex than adding.

Haskell better be good at Currying since it’s named after https://en.m.wikipedia.org/wiki/Haskell_Curry

I loved Ruby: an OO lang with some FP on top where it makes sense. I found Kotlin to be very similar to Ruby: primary on OO lang with FP on top where it makes sense, but now with compile-time types (slightly but fundamentally better than Java's) built in.

The main thing I miss in Kotlin is proper, first-class sum types. There is a trick with using inheritance to achieve it, but not good enough for me. They've become a fundamental tool for me (same level as record (data class) and collections).

I get how that would make Java-interop much harder, and that that's likely why they've been left out.

C++14 standard:

  auto add = [](auto x) { return [x](auto y) { return x + y; }; };
  auto addFive = add(5);
  auto result = addFive(3);

This isn't currying at all because each call to add builds a completely new (internal) representation of the addition function.

Currying looks surprisingly great in JavaScript

It does!

Clojure is really nice here:

(let [add-five (partial + 5)] (add-five 3))

The add-five function can take any number of arguments, including 0.

The Nix language is similarly nice: (assume the following is inside a let block)

add = x: y: x + y addFive = add 5 result = addFive 3

<3 nix & NixOS

Scala

  def add(x: Int)(y: Int) = x + y
  def addFive = add(5)(_)
  val result = addFive(3)

While I find these topics esoteric and very interesting in normal day to day code during a code review I’d probably say make it less complex, because majority of the time spent is reading code this makes code harder to read

Depends on the example. Going off the blurb:

> it’s a way of breaking down a complex function into smaller, simpler functions that can be composed together to achieve the same result.

And you could almost see it as analogous to the "fluent" pattern like:

    GetObject()
    .add(3)
    .applyGradient()
    .giveFish()

Etc. On the side: I really hate the "make it less complex" PR comments because it's not complex, it's just hard to read, and that's usually because the reader doesn't know about them.

I have one guy in our company who wants to unravel any list comprehension or map/generators functions (python) because he doesn't know anything except "for X in Y"

It _is_ literally increasing complexity. Because now the call stack has added layers of indirection:

[0] abort() [1] curry call site [2] partial closure 1 [3] partial closure 2 [4] partial closure 3 [5] partial closure 4 [6] <actual place of issue> [7] partial closure 5 [8] partial closure 6

Compare this to something isn’t using currying:

[0] abort() [1] call-site 1 [2] call-site 2 <actual place of issue> [3] call-site 3

Dealt with this enough at a previous company I’m glad on my team at FAANG people are reasonable and don’t just shoehorn functional paradigms unnecessarily

The curried example actually could only ever add one to the call stack, no matter how many times you do it.

And another thing, currying is one way of decomposing functions. Either your first example is decomposed too much or your second too little.

But I also am less comfortable working in a functional style.

You're only looking at one dimension of complexity. There are tradeoffs.

Complexity and understandability are very difficult to separate. If a coding style is unknown / bizarre to most coders on a team, but beautifully simple to a few who know the technique, which is it?

There should be a balance between teaching new ideas, and acknowledging the truth of what people are comfortable with.

I guess every language needs a variant of JavaScript: The Good Parts. Believe Go, despite its many shortcomings, gets readability better than most languages: https://go.dev/talks/2012/splash.article#TOC_4.

On the topic of Kotlin, it is really one is the better (perhaps the best?) JVM languages out there.

I always think of Rich Hickey's "Simple Made Easy" [1]

At the time I had a coworker who was militant about "simple code" and anti "complexity". I used to argue that the code they preferred was more of a pain in the butt due to avoiding anything beyond the most basic of constructs. They saw that this was a talk, suggested our team watch it, and then became upset because it turned out they hadn't actually watched it and assumed based on the title that it'd back up their viewpoints.

Lowest common denominator coding isn't the same thing as avoiding complexity.

That's hilarious.

The thing is, complexity & complications come from known-unknowns and unknown-unknowns.

Semantics of language use doesn't fit in there unless it's undefined behaviour. Things can be hard to read, but that's seperate from complexity.

And often the "simple, trivial code" is the slowest performance (which is a big deal in python)

> I have one guy in our company who wants to unravel any list comprehension or map/generators functions (python) because he doesn't know anything except "for X in Y"

I'm that guy at my current place of work. Incidentally, I'm also always the guy called in to work out why something doesn't work when the guy who made it (and loved streams and CompletionStage) has moved on to a different job.

I can read and write generators and maps just fine (I do it all the time when writing little one off scripts), but debugging in that mess is a hell. When I write something that will outlive my tenure at an organization, I reach for what everyone knows. I write in a dialect that even somebody right out of programming 101 can understand, because god knows what sort of clown they're going to hire after me.

That doesn't fly in all production environments though.

Sometimes doing 10,000 function calls is a hell of a lot more expensive than sending a 10,000 sized array to one function call.

I'm all for simplifying code, but not to the point of "start at date 0000-00-00 and increment upwards, so what, computers are fast" level (which is close to the type of person I'm taking about)

There's a certain threshold that I would imagine is different for different domains within different companies and perhaps different teams.

I'm fine with people who come out of programming 101 and want to continue to learn new programming ideas, not someone who's going to say my code is wrong because they didn't cover it in their 101 class.

That's partly a Java issue though, due to how streams are implemented. The same code in Kotlin is easy to debug.

These are great when the methods are simple configuration, but it indeed sux whenever you are debugging something. Or when it gets just a little bit more complicated.

Currying is pretty much just a convenient way to write a one-constructor one-method class. It's a parameterized version of the command pattern.

That said, if you're using a language with classes you may as well stick with those and omit the syntactic sugar from your diet.

I find functional programming useful though because it can shorten code in a way where you can get a better view of the big picture and easily make sweeping changes. But it's also easy to write in a way that's too "perfect" (i.e. resistant to change) and incomprehensible. Though I'm not sure the total incomprehensibility is generally any worse than an enterprise Java codebase -- local readability might only give you the illusion that the whole system is understandable. Still, if you don't enjoy reading code in a certain style it makes for hard reading!

It's also nice for making certain kinds of code more readable and maintainable in a way that isn't perfectly emulated by anything in OOP.

Here's a nice talk on the subject: https://www.youtube.com/watch?v=sfYA0HCWgqQ

and slides: https://fsharpforfunandprofit.com/pipeline/

This "looser" way of doing things tends to be more popular in the F# community, which isn't terribly fond of those rigid crystalline structures that you get in other corners of the FP community. Though I'd also point out that, even in Haskell, ways of programming that lead to incomprehensible and resistant-to-change code are often viewed as a sign of inexperience by more seasoned developers. There's a lot of truth in this joke: http://pages.cpsc.ucalgary.ca/~robin/class/449/Evolution.htm

I use Lean 4 quite a lot these days, and I appreciate how the developers embrace syntax extension and metaprogramming solutions rather than trying to encode complicated control flow using ascii art operators (it's like Lisp meets the ML family). I suppose programming with dependent types is enough of a challenge, so why make it even harder? They've got a sophisticated "do" notation with imperative constructs, mutable variables (that are translated into something StateT-like), and pretty seamless monad lifting. They've also got pipeline operators, including things like `x |>.foo a b c` for `X.foo x a b c` if `x` has type `X` (type-directed field notation is wonderful).

Many times you don't even use currying, since it's not always worth the effort making a particular argument be the last one. Instead you might write `xs.map (f · x)`, where `(f · x)` is short for `fun a => f a x`.

The language also has an interesting GC that lets you write functional algorithms that have good memory performance -- objects with exactly one reference can be mutated (using so-called FBIP, "functional but in-place"). There's an Array type whose theoretical representation is a linked list but whose run-time representation is a dense array with O(1) pushing, popping, and writing. Makes it easy to write performant code without resorting to sophisticated functional data structures.

I don’t think currying is esoteric at all, and if someone told me in a code review that it’s “too complex” I’d start looking for a new job immediately, since it’s a career dead end if the reviewer doesn’t even understand simple functional programming.

That said sadly these days I’m working on smart contracts in Solidity which is object oriented, and the primary functional alternative Vyper has had major problems while Rust has proven to be slower to develop in, at least for cosmwasm chains (I still hold out hope for Rust). So you could have a point lol.

I think this illustrates well an issue I have with the whole clean code thing. Utilizing slightly obscure language features isn't unclean, some times they're the cleanest solution.

Some people may not know what currying is and be confused by the code, that's okay. They can ask or Google it and then they understand.

The important thing is that the system itself is clean, that code is organized in a way that makes sense so that everything has a natural place to be etc. Loose coupling is a big one.

People talk too much about shot that doesn't really matter like names or whatever. Sure they're important but that's like saying conditional statements are important in programming. Yes they're important but it's week 1 stuff. Learning to do good work takes years, we're way past naming and stuff.

I'm questioning this advantage:

> Improved type safety: Currying can help improve type safety by ensuring that each curried function takes exactly one argument of the correct type. This can help catch errors at compile time and make your code more robust.

Why would non-curried functions have worse type safety?

I _think_ what they're saying is a specialized/curried function that takes a single argument is better than the method it's replacing that takes three strings or whatever. That is, `foo.a("a").b("b").c("c")` is better than `foo.a("a", "b", "c")`. Which...sure, but 1. if you're really passing 2-3 parameters in with identical types, maybe use inline value classes instead? Or at least type aliases?, and 2. if you can't or don't want to do that, named arguments help.

Type safe builders/factories work and should be used where appropriate (e.g. to catch invalid state at compile time) but I don't see how this has anything to do with the currying shown in the post. The compiler checks the param types whether the function has a single param or not.

Passing around functions that have already been partially applied means that downstream users can't incorrectly call or accidentally modify the arguments which have already been applied. Whether this actually results in more safety is unclear, as there are other language features or API design that accomplishes the same thing.

Yeah I would think that downstream users would just expect a function that only takes in the params that they specify - leave it up to the API user to just make a closure on the spot.

If we're using the more formal/traditional definition of "type safe" of "won't crash or go into an undefined state due to runtime type errors", then I think that it doesn't actually change the type safety situation at all.

Assuming we're actually using the more common colloquial meaning of "helps prevent logical errors due to a failure of the program's types to properly convey semantic distinctions" rather than the more I actually think it's kind of the opposite. When you curry a function that takes multiple arguments of the same type but treats them differently (so, not something like +), it gets easier to lose track of which is which in code that makes heavy use of partial application. Without partial application, someone reading the code is more likely to see that it's being called with two arguments of the same type and think to double-check the documentation if they're unsure which is which.

Not sure if Kotlin is conductive to currying. I find it harder to read with currying, not easier.

I tend to agree. I'm using this in a personal project and when I go back to debug issues with the curried functions I find I am not as smart as I thought I was.

I'm always wondered why some people prefer to use a lambda in a variable instead of just a function.

I'm referring to using

    var f = (a) -> code;

Instead of

    function f(a){ code }

Which are exactly the same.

JavaScript (and typescript) prefers them. Is it because of a convention or it really has advantages?

Haskell (and other functional languages) also use them a lot, but I guess in these cases the language is designed around it.

Kotlin, Java and other languages with lambdas doesn't really benefit from them in my opinion. If it's a global variable, a function is just enough and 99% of the times preferred. If it is something local, either inline it or also use a function (Kotlin allows for inlined functions, Java doesn't; and maybe, if you need to capture variables, a local Function variable is the only instance where this is useful, but otherwise please just use a function. * )

Python and other languages with limited or not available lambdas do use functions, and there are rare cases where a lambda would help.

In general, if you are using language X try to use language X's features and best practices. Don't try to program as if you were using language Y, it will only make it more confusing. You can easily see when someone is used to a language and tries to use another without understanding the differences. Going from java to python is a very clear example (classes everywhere! Loops just because!)

* In java, an initialized private Function<> field is 99% of the time useless and worse than just a function. And 99.99% if it is final.

I think In JavaScript, it often comes down to the fact that you want to use arrow functions if you need to reference this, for instance when creating callbacks for events in a component class context. Since there are some use cases where it’s necessary, some people just use it all the time so as not to have to think about it. The only thing you lose is function hoisting.

> JavaScript (and typescript) prefers them. Is it because of a convention or it really has advantages?

There are some slight differences: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I believe the reason arrow functions are prefered in his is because of the way `this` is handled: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

you would be correct. :)

Ah! Thanks. I always forget the special "this" differences. I still prefer to use function when "this" is not involved though (I find strange to have a function as a variable, if you are not using it as a variable that is.)

You can't define the scope/reassignmentability with latter use.

In Kotlin the syntactic overhead of `fun` is annoying. You have to do a lot more ceremony (e.g. writing return) than if you use the lambda syntax.

(I don't know why they made return mandatory in Kotlin, as a language can function just fine without explicitly writing return everywhere.)

Are you sure? Kotlin allows for one-line functions. This is valid Kotlin:

    fun sum(a:Int, b:Int) = a+b

In fact, it is even shorter than the lambda equivalent:

    val sum = {a:Int, b:Int -> a+b }

Even so, if you still need a block body but dislike the mandatory return, you can use a run body (where the last value will automatically be returned).

    fun sum(a:Int, b:Int) = run { 
      doThings()
      a+b 
    }

And even in that case you can use let, apply, and all the other syntactic sugar to allow beautiful flows and one-liners

> if you still need a block body but dislike the mandatory return

You know, in Groovy, the return is always optional... Kotlin copied the lambda syntax from Groovy but didn't copy that for some reason (notice how this makes the language inconsistent, as "some" blocks require a mandatory return, others don't... Rust for example, like Groovy, does not require return in either situation).

But I remember some of my colleagues were shocked by Groovy not requiring a return :D OMG that makes the code so hard to read!!!!! People just tend to not like anything that goes against what they do in their main language even when that doesn't really make any sense.

I've used currying in the past but these articles don't really make you tick at all as they introduce the concept first, which doesn't mean anything until you realize you actually need it to solve a problem you may encounter but examples also doesn't really feel like it's usable in day to day code.

I've used it to keep specific variable assigned on a function for later use such as for asynchronous functions which you'll lose the current state without saving it somehow such as by currying.

For more hilarity, a blog post I wrote in 2006 on currying in Java using CGLib tricks:

http://cromwellian.blogspot.com/2006/07/fun-with-generics-an...

There are some design patterns which look good on paper but hard to find actual applications and currying is one of them... Maybe it would ring more bells for people who use functional programming on daily basis.

Sounds good.. doesn't work

Reply on news.ycombinator.com