The point he (Josh) makes is that function types enable (he says "encourage") an "exotic" style of programming - functional programming - which should be discouraged, otherwise the entire platform will become infected with unreadable code.
Huh! What exactly is the implication here ?
It could be either ..
- Functional programming leads to unreadable code.
OR
- The mass of today's Java programmers soaked in the trenches of imperative programming are likely to generate unreadable code with powerful tools of functional programming.
I sincerely hope it is not the first one that Josh meant.
What exactly is unreadable code ? To someone not familiar with the idioms of a particular language, perfectly idiomatic code may seem unreadable. To someone not familiar with the functional paradigms, higher order functions, list comprehensions and closures will look illegible.
The question is, do we constrain down a language to the lowest common denominator only to cater to the masses or try to uplift the developers by encouraging them to program to a higher level of abstraction using more powerful idioms of functional programming. Closures in Java definitely introduce more powerful abstractions, and coupled with tail call optimization, will help us write more concise and succinct programs. To someone familiar with functional programming, the resultant code will definitely be more readable and enjoyable.
I am all for having true closures in Java 7 !
10 comments:
Josh has been pretty clear that he does not want Java to have a syntax that might encourage programming with higher order functions or list comprehensions.
reading through Josh's powerpoint, his use of the word 'exotic' has caused quite a stir, and distracted from the central theme of his critique.
some points made were:
* there are dedicated functional languages which can run on the vm and interoperate with java
* java was intended as a searingly simple duplo like language, and adding whole new layers of complexity needs very careful thought
you speak of targeting the lowest common denominator. For working programmers in industry, this is a comforting idea - if large scale software development can be compared to a conversation with diverse participants, then lets keep the shared vocabulary small and simple.
I'm keen to hear how people respond to the concept of an impedence mismatch in adding closure support to Java, and how Java with such support 'bolted on' compares to languages designed from scratch with this in mind.
@Neal: I was not present in Josh's presentation. Did he mention any specific reason for not wanting to have higher order functions in Java ? Does he think that the very fact that the mass of Java programmers today, being not familiar with functional programming idioms, may misuse the features leading to unreadable code ? Or he thinks that incorporating functional programming features into the Java type system will be more of trying to fit a round peg into a square hole ?
@anonymous:
"For working programmers in industry, this is a comforting idea - if large scale software development can be compared to a conversation with diverse participants, then lets keep the shared vocabulary small and simple."
Java has been touted as the "language for the masses", "language for the average programmer" etc. by many people. I am afraid we will continue to carry this stigma if Java continues NOT to implement more powerful abstractions that other paradigms support. I apprehend that such an approach will push more and more good programmers away to other languages. This looks like a straw man argument to me.
Debasish, if you really want these features, why don't you try out Groovy. It's 100% Java and offers the robustness of Java with the malleability and beauty of FP. Scala is another name that comes to mind. Putting closures into Java, I believe, really is hammering in a feature into a language NOT built with this in mind. Hasn't "Generics" done enough damage already? Aren't there enough things on Sun's hands to take care of. Better File API, multimedia support etc. I'm not against adding new features to the language, but do consider the gain/loss to be achieved in the long run.
Just my 2 cents.
@kodeninja: I have used Groovy to some extent, but I have used Scala and Ruby quite extensively. I love all of these languages. But my main point is against the strawman argument that people put forward to resist closures in Java. Is there really any technical reason not to include closures in Java ? As I mentioned in my post, this will continue to make Java a language for the average programmer. And believe it or not there are more lines of Java code and more Java programmers than Ruby, Groovy or Scala. And I do believe that a significant part of them are very good programmers. I think they deserve the power of abstractions that closures will bring to the language. Another point is that some of the features like TCO is essential for the Java platform as well for better implementations of Scala and other languages on the JVM. So, if we have the underlying mechanics in place, why not have the syntactic sugar to make powerful programmers happy ?
Do you think Generics, in its current form, offers you "syntactic sugar"?
And the way Groovy is implemented, moving to it for smart Java programmers, as you say, would be an absolute breeze! The learning curve is almost flat!
I think having something like "named parameters" in Java would be a nice feature which could add a lot of value without making the code illegible.
@kodeninja:
Do you think Generics, in its current form, offers you "syntactic sugar"?
I agree there are problems with the current implementation of generics. It can be improved and votes are already in for improvement. I am sure it will also be improved shortly, but, we need to start somewhere in order to make a language more powerful.
Regarding Groovy as a replacement, I am not sure if it will be a breeze. Groovy is possibly the one closest to Java at this point in time. But there are performance issues with Groovy and you really cannot substitute Groovy for Java when building large scale enterprise applications. The huge amount of investment we have already made with lots of frameworks and libraries, the great concurrency stuff etc. are too good to be switched over to another language.
I don't think Josh dislikes closures. The arguments I have heard him say are the ones the first anonymous repeats, and they have to do with getting from here to there. I think Java should add closures, but Josh tends to think people should migrate towards a different language.
The beauty of option B is that we don't have to wait on Sun to do it. We "just" have to convince our coworkers.
-Lex Spoon
@Lex Spoon: Yeah, we can migrate to languages like Scala (which I like a lot). But I cannot agree with the argument that Java should not add complex features and that Java has been designed to remain a simple language. Do u think generics, the way it has been implemented makes life simpler for the programmers ?
Post a Comment