I just saw a guy trying to argue that writing functional-style Java is the "new" way to write Java, and that not using functional interfaces means you're writing "old" style code.
> I just saw a guy trying to argue that writing functional-style Java is the "new" way to write Java, and that not using functional interfaces means you're writing "old" style code.
Sounds right to me. (Of course not having first-class functions was just as bad 20 years ago, but fewer people had realised it back then).
I don’t know about Java, but we’re seeing a shift to functional in the mobile space, where non functional code is definitely “old” code. In Swift with Combine and in Kotlin with their thing.
> "Old" in what sense though? In the style/fashion sense?
If you take the time to look into it, you'll discover that the functional style is only a change in the "fashion sense" to those who are totally oblivious to their advantages.
I get how the pedantic take on monads turns people away from the functional side of programming, but you'd be hard pressed to find anything to criticize how returning either/result monads from promises is not a huge improvement over the boilerplate-rich/pure OO approach to Java.
Me too. Mostly because it’s a smell to me that I’m mutating some internal state. I try to avoid that as much as possible because it quickly becomes soup.
The contortions I see used day-to-day to write code in the latest/greatest pardigm du-jour is criminal... I routinely have to revisit "functional masterpieces" of "easy to grok" code, and completely re-write to minimize CPU and/or memory consumption.
Yes Java is uqititous and it's not going away for 30 years at least. See Cobol. Java also has had significant improvements in the language so that there is less incentive to use other JVM languages like kotlin and it's fully interoperable with heartland code bases as far as I know
The number of flaws that make Java inferior to other JVM languages is surprisingly small. By far the worst parts are excessively verbose "Beans", nullpointer by default, the JEE ecosystem (there are good alternatives) and the high RAM consumption (a JVM flaw). Honestly 80% of the value I derive from using a different JVM language come from avoiding NPEs, getters and setters. The remaining 20% can be very useful but they are certainly not essential nor can they be considered mandatory.
Yes, pretty much the whole world is using Java. Some FAANGs use it as basically their default software stack, and at most have introduced some Kotlin along the way.
The world doesn't revolve around flavor of the month tech stacks.
That seems like an unnecessarily confrontational way to put it.
What I would say is that, from a 10km perspective, functional interfaces are just where the Interface Segregation Principle takes you when you really lean into it, and that dependency injection can be thought of as just a convenient way to do partial application in bulk, and that CQRS encourages you to create an ever-wider separation between your commands and your queries, and that, in general, once you get far along where clean object-oriented design wants to lead you, the whole functional vs OO debate often starts to feel like it's quibbling about syntax as much as anything else.
Sounds right to me. (Of course not having first-class functions was just as bad 20 years ago, but fewer people had realised it back then).