Hi,
I would like to know if exist any plans to add Optics support in the same way than other Java libraries:
https://github.com/functionaljava/functionaljava/tree/series/5.x/core/src/main/java/fj/data/optic
https://github.com/functionaljava/functionaljava/tree/series/5.x/core/src/test/java/fj/data/optic
What do you think about the feature?
Juan Antonio
Hi Juan,
I discussed that years ago with Jean-Baptiste Giraudeau, who implemented the feature for functional Java.
Vavr will not support optics. It is not the right direction. Our strategy is to align to native Scala (which does not have optics) while supporting as much standard Java as possible.
Mutating objects using such an abstraction as optics goes in direction of purely functional programming. I have a strong opinion that Java is not the right language for purely functional programming. Not only the type system is very limited but also key features are missing like lazy evaluation etc.
I hope this helps.
- Daniel
And if you really want to wet your feet at functional programming in Java, fj is the best library out there. But from what I've heard it is more of a gateway drug to Scala ;-)
Hi @danieldietrich,
I understand your point of view. I found the topic about Optics in the following roadmap:
http://lambdaconf.us/downloads/documents/lambdaconf_slfp.pdf
The roadmap was generated from opinions from Developers with different levels in FP domain from the following conference: http://lambdaconf.us/
https://www.surveymonkey.com/r/fp_ladder
Yesterday, I found that the library Derive4j provide support for Optics with compatibility for VAVR
https://github.com/derive4j/derive4j/blob/master/README.md
https://github.com/derive4j/derive4j/blob/master/README.md#flavours
I will review in the next weeks how to use the concept. I hope that the compatibility will be nice.
Juan Antonio
I've seen the FP ladder some years ago, when it was first published. To that time, it was controversially discussed by experts on Twitter.
IMO, it isn't necessarily the goal for an expert to climb the ladder to the top. Applying these concepts may also obfuscate your code and therefore business logic (BL) may be hidden. What we really want is to focus on our BL. This is the reason why Vavr did not create an algebraic domain language consisting of words like monoid, monad, applicative, traverse, optics, Kleisli etc. It would take us away from our business logic and pull us into a technical domain. Only experts in functional programming would be able to maintain such programs.
My goal is to target every Java programmer. Sure, we introduced Try, Option and Either. But they are so common concepts that even the Java standard library introduced Optional. And everyone should understand the purpose of Try. It is a functional try/catch. Scala did a good selection of helpful concepts for the standard library. To me, it is a source of joy :)
Yes, totally agree with you Daniel, it is not necessary to reach the level 5 in FP in the same way that not every Engineers with OOP background are experts with The Gang of Four but... at least they are able to know and use if they consider.
But I respect that if the philosophy of VAVR doesn't include Optics/Prism is fine.
I will review if at least it is possible to be used from Deriver4j. Fortunately the library doesn't have a heavy weight (197kb):
https://mvnrepository.com/artifact/org.derive4j/derive4j/1.1.1
FJ for example, the weight is near to 1.9Mb and it is huge if you compare with VAVR with only 876kb
https://mvnrepository.com/artifact/org.functionaljava/functionaljava/4.8.1
https://mvnrepository.com/artifact/io.vavr/vavr/0.10.2
Optics are only supported for the FJ flavour. Went basically the same route and looked into the different functional offerings for Java but settled on Vavr as we need our code to be readable by “normal” Java devs. You can kind of write functional programs in Java, but the type system really lacks expressiveness. Vavr just works with Java, not despite it ...
Related issue in Derive4j:
https://github.com/derive4j/derive4j/issues/96
Most helpful comment
I've seen the FP ladder some years ago, when it was first published. To that time, it was controversially discussed by experts on Twitter.
IMO, it isn't necessarily the goal for an expert to climb the ladder to the top. Applying these concepts may also obfuscate your code and therefore business logic (BL) may be hidden. What we really want is to focus on our BL. This is the reason why Vavr did not create an algebraic domain language consisting of words like monoid, monad, applicative, traverse, optics, Kleisli etc. It would take us away from our business logic and pull us into a technical domain. Only experts in functional programming would be able to maintain such programs.
My goal is to target every Java programmer. Sure, we introduced Try, Option and Either. But they are so common concepts that even the Java standard library introduced Optional. And everyone should understand the purpose of Try. It is a functional try/catch. Scala did a good selection of helpful concepts for the standard library. To me, it is a source of joy :)