Ted Neward is the Principal at Neward & Associates, a developer services company. He consults, mentors, writes and speaks worldwide on a variety of subjects, including Java, .NET, XML services, programming languages, and virtual machine/execution engine environments. He resides in the Pacific Northwest. Ted is a DZone MVB and is not an employee of DZone and has posted 50 posts at DZone. You can read more from them at their website. View Full User Profile

On Functional Programming in Java – It's Coming...

01.22.2013
| 14249 views |
  • submit to reddit
Elliott Rusty Harold is blogging that functional programming in Java is dangerous. He's wrong, and he's way late to the party on this one--it's coming to Java whether he likes it or not.

Go read his post first, while I try to sum up the reasons he cites for saying it's dangerous:

  1. Java is not a lazy-evaluated language. Programmers in Java will screw up and create heap and stack errors as a result.

  2. See? Here's a naive implementation of Clojure code taken directly over to Java and look how it blows up.

  3. Programmers can do bad things with this idea, so therefore we should avoid it.

  4. Oh, and by the way, it's "dangerously inefficient" in Java/JVM, even though I offer no perf benchmarks or comparisons to back this statement, and I'm somehow ignoring that Clojure and Scala run on the JVM as well, apparently without problem.

That kind of about sums it up, I think.

Look, as Elliott points out, Java is not Haskell. Neither is it Lisp. It's its own language, rooted in imperative and object-oriented history, but no less able to incorporate functional features into its development than Lisp could incorporate object-oriented features. However, if you do stupid things, like trying to re-create an infinite (implicitly lazily-evaluated) list in Clojure by creating an actualized list that stretches to infinity... you're going to blow the JVM up. Duh. Not even the supercomputer on the USS Enterprise five hundred years from now will be able to construct that list.

Porting code from one language to another is not a trivial exercise. If you attempt to port line-for-line and expression-for-expression, you can expect that your ported code will not be idiomatically correct. (I know this already, having done the exercise myself.) The root of the problem in his ported code is twofold. One, he (rather foolishly and in elegant strawman fashion) badly simulates what an infinite list would look like in Java--a commenter does the better job by showing how an Iterator can be made to perform the same thing that Haskell actually does under the hood by producing the next value on demand, rather than trying to create a list of Integers stretching to infinity. For someone who professes to have some Haskell experience and love, it surprises me that Elliott makes this kind of mistake, which leads me to conclude that he's trying to create the strawman. Two, he assumes that anyone who programs in Java functionally will have to create all of their functional tools by hand, and frankly, using Guava or FJ here would make this code sample a LOT easier to swallow. The fact that he ignores both of these in his stawman again sort of reinforces the idea that he's deliberately crippling his strawman to make his point.

His underlying point, though, seems to be simple: "I work with bad programmers, who don't seem to understand how to write code functionally in Java without screwing it up." Dude. Sucks to be you. "Bad programmers will move heaven and earth to do the wrong thing." --Glenn Vanderburg.

What really sucks for him is that these features are coming in Java 8, including lambda expressions and library support including a Stream interface that will allow for exactly this kind of code to be written without pain. Those programmers Elliott is working with are going to be even more on fire to use their functional approaches (and all the associated goodness of doing so, including composability and what-not) in their Java code. What might make Elliott more happy is that at least they won't have written it; it'll all be written by guys much smarter than any of them.

Published at DZone with permission of Ted Neward, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mario Fusco replied on Wed, 2013/01/23 - 2:49am

Jilles Van Gurp replied on Wed, 2013/01/23 - 9:19am

I would use the word 'different' rather than the more provocative 'dangerous'. I've been switching between Java, Ruby, Python, and Javascript for the past year or so. I've been a Java developer since the late nineties but before that I actually learned programming using a Haskell predecessor called Gofer in university. There are a lot of different languages and paradigms that one can use to solve the same problems. I think people tend to treat them as proverbial hammers that are suitable for smashing any nail in sight. I think Java people got a little too carried away using object orientation by creating all these really elaborate frameworks for solving simple problems. Swing is a good example and I think JEE pretty much sets the standard of how to make something very simple and straightforward very hard.

Functional programming is great. Having closures in a language is also great. They are not the same thing (though they are related). Java is basically just adding closures to the language. Closures are common in many other languages and generally liked by the people that use those languages. Closures are useful for supporting a lot of popular idioms that are somewhat tedious to do in Java today. Making that problem go away is a good thing. I mean idioms like being able to map a function to elements of a list; being able to reduce a list; being able to do callbacks (without inner classes), etc. Most of these idioms are good things to have and are things that are quite easy to explain to people.

Java has actually had something resembling a closure for some time: anonymous inner classes You can sort of fake a lot of the before mentioned idioms using them. It's not great but quite common. Closures are going to be very helpful in getting rid of a lot of that tediousness.

Functional programming takes things to the next level. Pure functional programming can be very alien to most developers who haven't seen this before. Not having assignments and loops for example is a bit of a mind fuck for example; especially once you start realising you don't need them.

Pierre-yves Saumont replied on Wed, 2013/01/30 - 9:09am

Saying that "Functional Programming in Java is Dangerous" is an error. The truth is that programming is dangerous, although the only danger is writing bad programs that do not work as intended (or do not work at all, which is somewhat better).

Every time a new feature is added to Java, there are some programmers finding that this feature is dangerous and should not be added.

When one finds himself thinking this, he should know that it's time to retire.

When generics were introduced, we heard exactly the same complaint.

The real point is that some programmers want new features because it would make there life easier. Others do not want the formers to have these new features because they fear they will not understand them an it will lower their value as programmers. That's life. If you can't keep up with new features, you are out of the game.

What programmers like Elliotte need is a switch that make the compiler ignoring the new feature they do not want. This way, they can continue to believe the world around them is not changing. The good news is it already possible: just stick to Java 7.

(Note that I agree that functional features should not be added to Java 7!)

Peter Eddy replied on Wed, 2013/01/30 - 10:03am

The dangerous example on the linked blog post seems ridiculous to me. Only an extremely naive developer would write code like that. I don't believe MIT/CMU graduates would make that mistake. 

Functional programming in Java may be coming but I'm afraid I'll be nearing retirement age when it finally arrives. We're still on JDK 6 where I work and there's no indication we'll move to JDK 7 in the near future.

I'd rather use Clojure anyway, it's functional from the ground up rather than having it bolted on.

Misja Alma replied on Wed, 2013/01/30 - 10:23am

You're missing the point. What Elliott was trying to say is that FP in Java is dangerous, - when the programming is done by the wrong person -. 

Sure, someone with good understanding of FP, who somehow ended up programming in Java,  will benefit greatly from Guava and Java 8. But Java is not a functional language to begin with. So the reality is, that most Java programmers do not understand the principles of FP well enough. Which means that in reality, when working in a real world project with real world colleagues, you'll sooner or later end up debugging some hard to debug issue which is caused by someone mixing up FP with mutable state, or by someone who thinks that FP just means that you should put as many statements as possible into one line.


Peter Eddy replied on Wed, 2013/01/30 - 10:47am in response to: Misja Alma

Well, programming done by the wrong person is going to be wrong regardless. I don't believe any reasonably competent developer would write the code in the bad example even if they've never had any functional programming experience. It's just too obviously inefficient. Worst case the developer will conclude that functional programming is too inefficient and use the imperative style instead.

Alex Kashko replied on Wed, 2013/01/30 - 11:35am in response to: Jilles Van Gurp

I recall having to debug  Java code that used recursion and an anonymous inner class in the heart of the recursion.  Occasionally it would loop for ever.   That was not a pleasant experience.   

As a result I regard anonymous classes/functions the way I regarded school dinners.  Occasionally an anonymous function is the way to go but I think it loses in clarity what it gains in convenience. 

Fortunately I do not have to eat school dinners any more. 



Alex Kashko replied on Wed, 2013/01/30 - 11:41am in response to: Pierre-yves Saumont

I agree with your point, however seeing the dangers in a feature is not a reason to think you are past your sell by date, it can mean you are seeing risks others miss: the early versions of enums had problems and dangers that got fixed.  Some will see dangers before opportunities others  will see opportunities first, and some will see neither or both. After a while all groups will agree on how to use the new feature safely. 


Petission Devid replied on Tue, 2013/03/19 - 6:09am

MiEssence  You actually make it appear so easy with your performance but I find this affair to be actually something which I think I would never comprehend. It seems too complex and extremely broad for me.

Stephen Allen replied on Wed, 2014/08/13 - 4:20am

 Java is a program used when you want to have some business in the internet world. However, only programmers understands the way it will be used.

Momo Singh replied on Thu, 2013/06/06 - 2:56am

This is best site to spent time on .I just stumbled upon your chatty blog and desired to say that I have really enjoyed reading your very well written blog posts. I will be your frequent visitor, that's for sure. delivery flowers

David Cameron replied on Fri, 2013/06/21 - 11:22am

A lot of new features will be added in Java 8 and I am eager to check the new lambda expressions of Java 8. I tried to create a booking calendar but without success so the only option was to embedded a booking calendar from AvailabilityCalendar.com, which in my opinion is the best option available on market.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.