Advantages of Functional Programming in Java 8
bulldogjob.pl
bulldogjob.pl
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).
John McCarthy might disagree with you if he was still with us saying LISP is not a functional language. Here is a great summary of his "Recursive Functions of Symbolic Expressions and Their Computation by Machine" https://swizec.com/blog/the-birth-of-lisp-a-summary-of-john-...
I really think we need a definition of functional programing language. I feel that many just see Haskell and other "pure" functional languages as the only functional programming language when I really don't see that is the point (Also Haskell isn't very pure looking at Monads)
Personal Definition. If you can program in a functional manner and it looks and feel good then it is.
R - More then just this reason but yes JavaScript - Sort of but I would say no if my arm was twisted behind my arm Racket / LISP - Absolutely Python - NO WAY First Class Functions alone don't make a functional language
No, I'm not defining a purely functional language. ML-family languages (Standard ML, OCaml) aren't purely functional, but they have arbitrary compound values, the physical identity of whose in-memory representation is inaccessible - not a part of the abstraction the programmer is shown. And, FWIW, I only call Haskell “almost purely functional”, because divergence is a kind of effect that its type system doesn't track.
In any case, a function is a mapping from values to values, so a decent treatment of a rich collection of values (including compound values) is a prerequisite for a language to be considered “functional”.
> I really think we need a definition of functional programing language.
Here's a very simple definition: A functional language is a value-oriented language with an abstract type of functions, which can only be distinguished from one another up to extensional equality.
> (Also Haskell isn't very pure looking at Monads)
Monads (resp. monad transformers) can be used to embed the abstract syntax of an effectful language into a pure (resp. less effectful) language. That isn't news to anyone.
> Personal Definition. If you can program in a functional manner and it looks and feel good then it is.
I have no idea what you mean by “program in a functional manner”, but, when I do functional programming, I expect to be able to formally reason about my programs without reaching for Hoare logic, which is an insanely complex beast.
I consider FP languages to be those that actively encourage an FP style. We live in a pragmatic world with limits, many times we need to work around those limits and working with totally pure code where side effects are modeled by means of monads is sometimes limiting. However, in FP languages the FP style should be considered the default and breaking out of that style should be done for optimization reasons.
The set of features required is not that big. Of course, for static languages, it would be nice if the language had some form of type classes and higher-kinded types, because that goes well with parametric polymorphism, which blends well with FP. But actually, you can't name a certain feature, other than having first class functions maybe. But the community and the available libraries need to encourage a preponderantly FP style.
I can't say exactly what languages are like this, but I can say that Java does not and it never will.
The closest general purpose language I have been exposed to that fits your description is Racket. Based off of Scheme and has the ability to really make your own language from it, but also has pragmatic pieces to get things done.
Love your definition: However, in FP languages the FP style should be considered the default and breaking out of that style should be done for optimization reasons.
On the other hand, Haskell's type inference algorithm is simply incompatible with abstract types.
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...
---
Sorry, can't reply properly, I'm “submitting too fast”.
<ignore>I understand neither the form nor the content of your objection. Is Scheme a programming language? Yes. What does this have to do with whether it supports functional programming reasonably well?</ignore>
Scheme is a higher-order programming language: procedures are first-class objects whose identities can be bound to variables just like any other value. I'm not sure about calling it “functional”, though: the type of procedures isn't fully abstract, because you can query the physical distinction between two procedures that have the same behavior when called. In other words, in Scheme, procedures are objects, but they are not values.
Sorry but I am an old timer and seeing people blast the paths that led us to where we are is very frustrating to me.
Edit added is a functional
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.
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.
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.
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.
> 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.
Sorry, I may have read that into your comment.
> the code itself needs to be pure
But that's also incorrect. Just because you can't replace an effectful computation with a value doesn't mean you can't reason equationally. You can also have benign effects that are unobservable, for example, memoization.
> Not sure how to parse that
I meant that functions with effects are just functions with computation type at the meta level. I.e. there's nothing more "mathematical" about only allowing nontermination in your language. It's just the simplest case.
functional programming =/= functional purity. You're talking about functional purity,not functional programming.
Similarly, methods for mutation (compulsory, no less!) are red flag in FP.
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?
Yes, it's strange. I'd prefer to map a null in a DTO to an empty optional. I'd like even more to never have nulls in the dto in the first place.
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).
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.
(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.
namespace Utils {
void setIfNotNull(const Supplier& getter, const Consumer& setter) {
...
}
}
....
using namespace Utils;
setIfNotNull(...);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.
> there is still need of standalone functions in OOP
Yes, and that's what I've shown?
Such functional namespaces were part of Java from the very beginning (Math is a good example and with release of Java 8 now there are many more in standard library). I have not seen an enterprise project yet, in which there's no something ending with Utils or Helper, that is just a collection of functions. Such naming is an anti-pattern, of course, but still, almost every developer in Java world uses this and has it part of it's development culture.
This is exactly the cultural problem with too strict adherance to OOP :)
It's like people saying "nails are anti-pattern of course, but people still use them, so we've added hammer-heads to our screwdrivers".
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.
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.)
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.
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.