| The article is not about FP. > Languages like Java encourage patterns where you instantiate a half-baked object and then set the fields later. Maybe it did before 2010. For many years everyone prefers immutable objects (so that object and its builder have different types, or in simpler case -- no setters, only constructor initialization). You can see it in pretty much all frameworks. I'm ok with both functional and procedural languages, I just think this article is not about functionality. Come on, FP is all about monads! Moreover, the "imperative" code example would be impossible anyway with immutable objects without side effects. So what I think the article is about is immutable data types. Everyone agrees that immutable are better, we have to do mutables only when we're optimizing for CPU/RAM. And BTW concurrency is typically easily achieved if variables were not plain objects, but Future/Observable/Flow/Stream -- pick your poison. They all have passed the hype hill already, and became "just a tool" I think. |
(sorry, bitter personal experience) And yes, that is explicitly "modern" Java code written by a lead engineer and "java champion" in 2023.