functionaljava VS libsum

Kotlin is JVM compatible and has ADTs.

Java has https://github.com/functionaljava/functionaljava

which is unsupported but stable.

A few side-notes about this code: - you need some sort of "wrapper" or "container" in order to use functional methods like map/flatMap/filter/etc on some object - here I used Optionalfor testing because it's available in standard Java: Optional describes an object that may or may not be available. - A more suitable "wrapper" for this use-case could have been Try which describes the result of an execution that may succeed or fail, see vavr has a Try for example, functionaljava has Either - map transforms A -> B (would make sense for your mapToUser) whereas flatMap transforms A -> Optional (or whichever "wrapper", would make sense for your userService.save if suppose the saving operation can fail) - Here is a working example for you :) - practise exercises: 1- replace the "wrapper" Optional with List, there is almost no change of code, this now gives you the ability to process lists of users 2- import vavr and replace the "wrapper" Optional with Try, there is almost no change of code, this now gives you the ability to process operations that may fail - Enjoy functional programming, you'll find java is rather verbose and quickly gets clunky for FP, consider switching to another language

? Sometimes passing a lambda (or other function) as an argument is a simpler approach to specialization than defining a subclass. That I think is mainstream and accepted in Java today.

There is a lot more to "functional programming" than that, such as the use of persistent collections. In some cases (such as managing the symbol table in a compiler) those methods lead to good efficiency and great simplification, in other cases they are ways to make easy problems punishingly hard.

pidove builds on top of ordinary Java Collections and doesn't push more exotic approaches as does

http://www.functionaljava.org/

We can simulate using type components in modules in Java by using parametrized classes, the type parameters correspond to type declarations in a ML signature. I found an example monoid definition in Java if you want to see how that looks. You can see that the "functors" are kept inside the class definition, though I don't know if it's necessary, I don't really know Java. You probably get weaker abstraction, because you can't have some monoid with an unknown carrier type, you always know the carrier type - it's just the type parameter A in Monoid.

Definitely looks nicer and probably works better than my older attempt [1], but uses 9x more code and depends on the awesome buy scary Meta99 macro toolkit. I think libsum is a good intro if you want to see how algebraic data types work underneath.

[1] https://github.com/naasking/libsum

I created [something similar](https://github.com/naasking/libsum) awhile back:

    SUM(foo) {