Re:Moving Java Forward Faster
by callinyouin on Wednesday September 06, 2017 @03:25PM
(#15186408)
I can't tell if you're being sarcastic, but I'm guessing you aren't. Anyway, from a full time Java developer's perspective, lambdas and the FP stuff added to Java 8 have sort of been a holy grail. Filtering with streams have single-handedly made my life as a developer measurably easier, but then again I'm a back-end web dev so it comes up a lot. If you're a Java developer, I'd strongly recommend going back and trying some of these features because they really are quite nice once you get the hang of them.
[ Parent
| on HN ]
You seem to have jumped to the conclusion that I haven't tried the FP features. If I hadn't tried them, I wouldn't be criticizing them. If I wanted to work in FP style, I would choose an FP language; not encourage a traditional, solid language to be perverted to do something that is completely against the nature and design of that language.
FP and OOP are compatible styles. In fact, I would argue that FP is more object orientated than procedural code such as loops.
Re:Moving Java Forward Faster
by dragonwriter on Wednesday September 06, 2017 @07:35PM
(#15188004)
Not really; FP and OOP are dissimilar in their approach to mutable state and it's management, for instance. You can come up with a synthesis (or probably many different syntheses) of ideas from the two styles to make a style blending inspiration from each, but they aren't directly compatible, and most direct combinations mhave tension between the two styles, or directly subordinate one to the other, for that reason.
In support of FP and OOP being compatible:
The venerable master Qc Na was walking with his student, Anton.
Hoping to prompt the master into a discussion, Anton said
"Master, I have heard that objects are a very good thing - is this true?"
Qc Na looked pityingly at his student and replied, "Foolish pupil -
objects are merely a poor man's closures."
Chastised, Anton took his leave from his master and returned to his
cell, intent on studying closures. He carefully read the entire
"Lambda: The Ultimate..." series of papers and its cousins, and
implemented a small Scheme interpreter with a closure-based object
system. He learned much, and looked forward to informing his master of
his progress.
On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures." Qc Na responded by
hitting Anton with his stick, saying "When will you learn? Closures are a
poor man's object." At that moment, Anton became enlightened.
Re:Moving Java Forward Faster
by stickfigure on Thursday September 07, 2017 @01:47AM
(#15189392)
Nothing in OOP requires mutable state.
Thing changedThing = oldThing.change();
It's only very special circumstances where my POD types do not consist entirely of `final` fields. Though I usually skip defensive copying within PODs... One should know better than to trust values from random places. So I defensively copy at use time instead if I want to modify it.
Kotlin, Java's superior offspring, is even better, as the use of data classes provides an automatic implementation of a `copy` command. (Scala does too, but Scala also explodes when I look at it, so, enh.)
Since lambdas and streams are optional, what is your critique of them?
I'm guessing they work on a team, and other members of the team are using them.
Please explain how "I don't have to init an ArrayList and add to it manually" is such a heaven-forfend perversion of that traditional, solid language.
To be fair, the implementation of Streams within Java is certainly filled with ugly boilerplate compared to LINQ in C#. But that's no reason to criticize their mere existence.