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
      }
    }

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

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)

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

    add(x: 2)(y: 3)

    let addTwo = add(2)
    addTwo(3)

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.

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

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

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

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

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

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 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()

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"

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.

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.

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.

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...

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