Advantages of Functional Programming in Java 8

https://bulldogjob.pl/articles/156-the-advantages-of-functional-programming-in-java-8

by Kellanved • 10 years ago

53 60 10 years ago

edejong• 10 years ago

I am really wondering why this is on HN front-page. It does not provide any good, in-depth analysis of FP in Java 8. In the contrary, the writing seems to be incoherent and assuming knowledge of a certain Java stack.

shekhargulati• 10 years ago

Same here this is a very bad blog. I don't see what you can learn from this tutorial. If you want to learn Java I wrote a series https://github.com/shekhargulati/java8-the-missing-tutorial covering new features of Java 8.

b15h0p• 10 years ago

Agreed. A major red flag is the omission of generics usage on their methods. Just using List or Collection without type parameters is just dangerous and very bad advice for a novice programmer seeking enlightenment for Java 8 programming.

hepta3• 10 years ago

I assumed the omission was for brevity, but there are annotations and 'final' in a lot of places.

Similarly, methods for mutation (compulsory, no less!) are red flag in FP.

misja111• 10 years ago

It looks like the generics used to be there but have been removed. Because there is one generic type 'T' left in the implementation of ClassUtils.setIfNotNull.

So about this setIfNotNull: I don't understand why this method is used in updateEntity. To me it seems the accountType property in the dto can be set with whatever is in the entity, null or not null. And of course, Java 8 has introduced the Optional class as a better way of dealing with null values, so why bother writing a workaround at all?

jcadam• 10 years ago

Last month I created a badly-written blog post (it started out as an incoherent email written at my day job which I later fleshed out into an incoherent blog post) discussing Java 8's Optional type: https://jamesadam.me/index.php/2016/08/04/thoughts-on-java-8...

In particular, I both love and hate the new streams API. It's nice to work with but easily leads to code that is hard to read and hard to debug.

No, I wouldn't call Java 8 a functional language either. Its 'functional' features are more of a tease than anything else, as you'll quickly discover their limitations (and they definitely feel tacked-on rather than an integral part of the language).

pmontra2• 10 years ago

Every time I see a class like ClassUtils I remember that OO is only good for half of the programs we have to write (1). Problem is, it's a half of each source file. On the other side, OO is a very convenient abstraction for the other half.

(1) I'm sure there are more gracious ways to do that, but maybe not in a single line. That's why we keep seeing classes whose only purpose is to be bags of random methods.

ajuc3• 10 years ago

Even C++ has the solution to that - separate namespaces and classes. Allow standalone functions.

    namespace Utils {
         void setIfNotNull(const Supplier& getter, const Consumer& setter) {
             ...
         }
    }

    ....

    using namespace Utils;
    setIfNotNull(...);

odabaxok2• 10 years ago

I believe you can achieve the same in Java by static import.

EDIT: Also, I think the parent comment was not complaining about the missing possibility of creating standalone functions, but rather saying that not every functionality can be forced into objects, i.e. there is still need of standalone functions in OOP.

douche• 10 years ago

Languages that were actually designed to be functional-first, but multi-paradigm, like F# also support this.

Though to be honest, not allowing free functions in Java or C# is kind of silly. It seems like the compiler could pretty easily autogenerate a static class per namespace to actually stick them into, so that it would really just be a bit of syntax sugar.

Zardoz84• 10 years ago

D have better solution. Modules & packages, allow stand-alone functions.

pmontra2• 10 years ago

I'm the OP of this thread.

I add the example of Ruby's modules, that can be included in other modules and eventually classes. Combined with dynamic typing they provide a way to import very generic functions, even if they end up being methods (everything is an object in Ruby.)

Erlang and Elixir are a kind of trade off between functional and OO languages. Formally they are fully functional but their processes (a first class construct) are objects by all means. Processes receive messages (equivalent to method calls) and respond by sending other messages (the caller must pass its process id inside the original message.) We could say that OOP objects are castrated processes because they don't multitask.

What I noticed is that an Erlang/Elixir application has many function calls but far fewer processes/objects than objects in OOP programs. Processes usually encapsulate the main data structures. The equivalent of a Java ArrayList would be a process but its elements don't necessarily need to be processes. Pattern matching and some syntactical sugar help (example: http://culttt.com/2016/04/11/working-keyword-lists-maps-elix...).

Maybe those languages are a more equilibrate middle ground between the extremes of pure OO and pure functional, with the advantages of concurrency and all the external but mandatory infrastructure inside the language (deployment, supervisor trees, etc. - a part of devops.)

pwdis_password• 10 years ago

This is why people don't understand OO. They only see O, not OO.

islon• 10 years ago

For me the biggest advantage of FP languages is exactly not have to deal with `GenericConverter`s, `AbstractDTO`s, `BaseEntity`s and other overly-complex constructs that many OO languages inflict upon the programmer, but to create a small and simple sub-language that solves my problem without making it even more complex.

catnaroek7• 10 years ago

When you really think about it, Haskell's mathematically inspired type classes are more or less the equivalent of Java's “`GenericConverter`s, `AbstractDTO`s and `BaseEntity`s”. The main difference is that their meaning is given by algebraic laws, rather than informally specified design patterns or fuzzy human intuitions about how “objects” interact with each other.

acjohnson55• 10 years ago

Sounds basically like the Kingdom of Nouns argument: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

kozikow• 10 years ago

You can horribly engineer things, regardless if you use haskell or Java.

I've seen Java code like you described, but I've also seen big java projects written in clear, no-nonsense style. For example, look at any open source Java projects released by Google.

I've also seen FP projects that require all engineers to learn category theory. Even when armed with programmers proficient in FP, project did not seem significantly more productive or less buggy from the outside. The approach-ability was lower - you couldn't just quickly glance how something works, even if you knew FP.

The most successful approaches I have seen involved adapting good functional concepts - referential transparency, immutability, compos-ability, minimising local state, functions as objects. They rarely went dogmatically all-in on pure-FP/category-theory/DSL-all-the-things. I strive to write code adhering to those rules, even in non-FP languages, but ultimately favouring practicality and I believe that I get the best of both sides.

myst• 10 years ago

FP in Java. HA HA HA OH WOW

bad_user8• 10 years ago

The article isn't about functional programming.

Functional programming is programming with pure (mathematical) functions. As a consequence, functional programming is also programming with (immutable) values (i.e. persistent data-structures, etc).

This isn't pedantry. The whole point of FP is being able to have your code be "referentially transparent", a property that gives you "equational reasoning", making your code more composable, more testable and easier to understand because you can take any function, divorce it from its surrounding context and still make some sense of it. Of course, there's no silver bullet, yada yada, but take those traits away and the definition loses meaning and usefulness almost completely.

And btw I shouldn't need to specify "pure" or "mathematical" if programming wouldn't have overloaded the meaning of the word "function". We could have stuck with "procedure" or "routine" or "sub-routine". As in jumps in code that push and pop the call stack and that have side-effects. And if you want to express the act of programming using side-effectful functions, there's also a perfectly adequate term for it already: "procedural programming".

Yes, it's cool having closures and anonymous functions in your language. It's sort of a prerequisite if you want your FP code to be comfortable. But that's not FP. There's actually nothing resembling FP about the code samples in the article. And the implementation of AccountConverterImpl would make any programmer that likes FP to cringe.

On Java 8: yes, it's becoming possible to do FP, sort of anyway. But it's still painful as hell, with the environment actively working against you. First of all there aren't many libraries that do FP in Java, I only know of functionaljava.org. So you're swimming against the tide, with the standard library itself being actively hostile to FP. And you can start from the fact that Java 8 was released in 2014 and even its new Option type is breaking the Functor laws, because map(x).map(y) != map(x.andThen(y)) and lets not even mention the word monad because it scares people.

But I guess that if you're forced to use Java, well, then you can find some ways to cope with it (especially if you aren't scared of building your own stuff).

jerven• 10 years ago

So Lisp is not a functional language...

catnaroek7• 10 years ago

Most things in Lisp have an object identity that can be directly manipulated by programmers, so it is indeed not a functional language.

baldfat4• 10 years ago

So R isn't a functional language...

To be fair the vast majority of people would say that it isn't BUT hidden inside is a very Scheme inspired system that can make pretty functional programs.

http://link.springer.com/chapter/10.1007%2F978-3-642-40447-4...

bad_user8• 10 years ago

Technically speaking, Common Lisp isn't a functional language, yes. Common Lisp is a multi paradigm language and you can do FP with it if you want. But from my very limited experience with it, it's not the norm.

However Lisp, the original, is based on the lambda calculus and that is very much about functional programming. So surely you can do FP with most Lisps, but whether that's the norm or not is another question.

catnaroek7• 10 years ago

As a consequence, functional programming is also programming with (immutable) values

I'll go even further: Values don't exist in time (when did the number 2 suddenly come into existence?), so it doesn't even make sense to ask whether they're “mutable” or “immutable”, which is intrinsically about how objects evolve in time. Values exist in the semantics of the programming language in question (a timeless mathematical object!), and a structural operational semantics makes this very clear: a value is a term that a variable can be substituted with. Ergo:

(0) In a call-by-value language, a value is the result of a successful computation.

(1) In a call-by-name language, a value is a snapshot of a potentially unfinished computation.

(2) In a call-by-need language, a value is the identity of a potentially unfinished computation.

(3) In an object-oriented language, the only values are object identities, and the few lucky primitives that escaped being treated as objects.

(i.e. persistent data-structures, etc).

You can have ephemeral data structures in a purely functional program too, provided the language has substructural types.

bad_user8• 10 years ago

You're right, which is why I named "immutable" in parens, to go along with "mathematical" for functions. Values are just values, but because they are uncommon in mainstream languages, except for primitives and strings maybe, I personally feel the need to mention immutability in order to be precise and not have people confuse them with objects that have identity.

marktangotango• 10 years ago

My personal experience has been that Java 8 lambda plus deep class hierarchies can lead to some truly impenetrable code (to read that is). In practice mixing oop and the meager functional tools (as you note) in Java can be really, really bad, and makes me weep at the future of Java development. I think teams need to decide what kind of code they're going to write, either 'functional' or oo. And if you are using Java 8 lambda's (and googles immutable collections for example) teams should strive to keep class/interface hierarhies shallow.

I've been doing enterprise java development for 15 years, and the code I'm seeing now is kinda the nail in the coffin for Java for me. I don't want write or maintain that stuff, the next time I switch jobs I'll be looking at a pay cut, and python/django most likely. Or going into management.

bad_user8• 10 years ago

The problem with working with closures is that stack-traces tend to become very hard to read, close to unusable sometime. Add asynchrony/concurrency to the mix and you've got a wonderful cocktail :-)

Partial blame is on Sun/Oracle for not adding mutual tail-recursive calls optimizations to the JVM ;-)

This is one of the challenges of FP. It makes debugging harder. But then FP code tends to be tested by means of laws described with QuickCheck, a superb automated testing tool that has ports to Scala, Ocaml, Clojure (that I know of) and it raises the quality of the code a lot.

l_dopa2• 10 years ago

This is a really annoying meme in "pop" FP. Equational reasoning isn't limited to "pure" languages. Effectful functions, as you probably are aware, are just functions of type A -> T B.

bad_user8• 10 years ago

I haven't claimed that equational reasoning is limited to pure languages, that's more a property of the code, rather than the language. But you can only achieve equational reasoning with referential transparency and that means the code itself needs to be pure. TFA does not show pure code.

Effectful functions, as you probably are aware, are just functions of type A -> T B

Not sure how to parse that. But if T in your example is meant to be some IO type, then it is pure along with any transformations on it, until you do unsafePerformIO or something equivalent and you only need to do that once, at the end of the program.

aikah2• 10 years ago

The article isn't about functional programming.

functional programming =/= functional purity. You're talking about functional purity,not functional programming.

bad_user8• 10 years ago

No, I'm talking functional programming: https://en.wikipedia.org/wiki/Functional_programming

dschiptsov• 10 years ago

Adding a new Converter for another entity-DTO pair (like User, Address, etc.) needs just creating a new UserConverterImpl class, implementing its own UserConverter, which in turn should implement GenericConverter.

This is exactly what is wrong.

Unnecessary complications resulting from not merely over-engineering but piling up completely unintelligible crap, produced in order to... well, use some Java 8 features.

Imagine that in math instead of doing algebraic simplification one would go into the opposite direction.

Same kind of madness, BTW, is going on in the realm of Javascript frameworks.

cromwellian• 10 years ago

There's something about these kinds of threads that seems somewhat snobbish and tribalist. There was a similar rant a few weeks ago over whether your 'FRP' is really 'FRP' (https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-j...)

I think we can all agree that there's a certain beauty and elegance to completely functionally pure programs. CycleJS for example, really pleases me compared to the complexity of React.

However, like everything in life, the real world is messy and hard to squeeze into binary categories. I can't forsee any large scale program that adheres to such constraints without bending over backwards in weird contortions to meet the limitations imposed, to the extent that such code may even be harder to reason about than mutative code.

I think practical languages 'win' by being 'worse', by compromising and allowing the developer to shoot themselves in the foot a little.

willtim2• 10 years ago

Haskell is absolutely capable of mutation, it's just controlled and tracked. IMHO, immutability is simply a saner default for a high-level language. I think languages "win" due to socio-economic reasons, not technical ones.

Advantages of Functional Programming in Java 8

Related Stories