Is the Java Language Dying?
We tend to think of programming languages in two categories: "living languages" in which we should seriously consider developing new code, and "legacy languages" that we mainly use, if at all, because we have to maintain an existing code base. The act of classifying a language into one or the other category helps us decide what, if anything, we might consider doing to change the language. If a language is primarily a legacy language, changes should be aimed at making it easier to maintain and modify existing bodies of code. A living language, on the other hand, also benefits from changes that make it easier to design, develop, and maintain new code. Living languages evolve to reduce accidental complexity.
"What does a high-level language accomplish? It frees a program from much of its accidental complexity. An abstract program consists of conceptual constructs: operations, datatypes, sequences, and communication. The concrete machine program is concerned with bits, registers, conditions, branches, channels, disks, and such. To the extent that the high-level language embodies the constructs wanted in the abstract program and avoids all lower ones, it eliminates a whole level of complexity that was never inherent in the program at all." -No Silver Bullet - Fred Brooks
Programs written in legacy languages tend to exhibit a high degree of accidental complexity [Code's Worst Enemy, Steve Yegge] [Mr. Yegge meets Mr. Brooks, Brian C Cunningham]. Early in the life of a language, the complexity of programs written in that language may appear to be essential, but as we learn more about software engineering and programming languages, we find patterns of complexity appearing in the code that can be eliminated by improved languages.
A good example of this is garbage collection. In C and C++, memory management is a pervasive concern. Smart pointers and destructors help, but they do not significantly reduce the complexity of memory management. In languages with garbage collection, most of the complexity of memory management is assumed by the implementation of the language. Most languages that have been introduced in the past ten years support garbage collection.
Another example is concurrency. The threads-and-locks-and-semaphores primitives of Java enable parallel programming, but require that programmers express concurrency at a fairly low level. This has been "good enough" for some time, as most programs are not deployed on highly concurrent hardware. But that is changing [The Free Lunch Is Over, Herb Sutter]. Libraries such as java.util.concurrent and Doug Lea's fork-join framework help somewhat, but in many cases they introduce complexities of their own. Other languages that support closures, such as Scala make fork-join-like libraries much easier to use. Scala supports control abstraction [Crowl and LeBlanc], which allows the libraries to manage much of the complexity associated with concurrency [Debasish Ghosh]. Support for the Actors model [Haller and Odersky], for example, can be expressed cleanly as a library in Scala
Besides raising the level of abstraction of concurrent code, control abstraction also raises the level of abstraction for sequential code by eliminating whole categories of boilerplate, which can instead be moved into common library code. This kind of boilerplate cannot be significantly reduced by adding one or two custom statements to the language, because such built-in forms necessarily make assumptions about the use cases that narrow their applicability. For example, ARM blocks don't document how they handle exceptions arising from the close() method. One example in the proposal suggests they are silently swallowed at runtime, which may work for many cases involving I/O streams, but another example given is a transactional API, in which ignoring such exceptions is precisely wrong. Without a specification for the syntax and semantics, the reader is welcome to imagine the most favorable treatment of each use case. But an attempt to reconcile these and other conflicting requirements may show the approach cannot be salvaged. Perhaps that is why no progress has been made since mid 2006.
What about Java? Is it a living language, or a legacy language like Cobol? This question underlies much of the debate about how to move the Java programming language forward, if at all. Carl Quinn asked at the December 14, 2007, JavaPolis Future of Computing Panel (to be published on http://www.parleys.com): "How can we address the issue of evolving the [Java] platform, language, and libraries without breaking things?"
Neal Gafter: "If you don't want to change the meaning of anything ever, you have no choice but to not do anything. The trick is to minimize the effect of the changes while enabling as much as possible. I think there's still a lot of room for adding functionality without breaking existing stuff..."
Josh Bloch: "My view of what really happens is a little bit morbid. I think that languages and platforms age by getting larger and clunkier until they fall over of their own weight and die very very slowly, like over ... well, they're all still alive (though not many are programming Cobol anymore). I think it's a great thing, I really love it. I think it's marvelous. It's the cycle of birth, and growth, and death. I remember James saying to me [...] eight years ago 'It's really great when you get to hit the reset button every once and a while.'"
Josh may well be right. If so, we should place Java on life support and move our development to new languages such as Scala. The fork-join framework itself is an example of higher-order functional programming, which Josh argues is a style that we should neither encourage nor support in Java. Is it really time to move on?
Personally, I believe rumors of Java's demise are greatly exaggerated. We should think of Java as a living language, and strive to eliminate much of the accidental complexity of Java programs. I believe it is worth adding support for closures and control abstraction, to reduce such complexity of both the sequential and concurrent aspects of our programs. At the same time, for completely new code bases, we should also consider (and continue to develop) newer languages such as Scala, which benefit from the lessons of Java.
40 comments:
Your dichotomy and thus the entire underlying assumption if false. C and C++ are not bleeding edge always changing entities (as you refer to 'living languages') - but only a fundamentalist would define them as 'dead' or even 'legacy'.
Languages are tools, and certain tools are better at some things than others. Often, what the tool is better at is baked in when the tool is designed. A hammer will never be a good soldering iron. Even if you bolted a heating coil to the head, it's just not designed for it. Now, when I need a hammer, great, I have one. And, you can even make better hammers. You have sledge hammers and rubber mallets and all sorts of sizes and shapes. But the fundamental 'hammer-ness' never goes away.
Java is a great tool, and we should evolve it to make it better! But, some things cannot be unbaked from the design. That may very well mean that for some upcoming new types of tasks, we will need new languages.
However, in the mean time, I have many many nails here that need hammering.
amalter: Languages are not tool. They are toolboxes. It's not a case of making a better hammer, it's a case of the hammer being missing from the toolbox.
amalter,
If all you have is a hammer, everything looks like a nail.
Programming languages have a habit to stick around for a very long time.
I think you should first define "dying".
For me, what is most important is the level of influx (new people) picking up a language, and then compare this to other languages. In this respect, I do believe Java is dying, simply because python or ruby are a lot faster to pickup than
Java (and lets not forget the needless boilerplate to satisfy a silly parser).
No it has just reached the peak of the bell curve. Now that it is open, strong support from Google, it might just beginning it's second wind, or the stroll into old age and EOL.
It is slow, bloated, but follows the javascript, c, c++ type feel and will always be part of the club. C# has taken many who would have ended up in Java, C# is better than Java now, but it is the syntax and abstraction to object oriented that makes it succeed in business right now.
If they were to really go in and remove bloat (getters/setters, bloated iterations etc) and re-market it with Google support, it would resurge.
If you remember before when C and C++ were king, academia was pushing Java heavily, now it is turning to more dynamic languages as well. It is like once a language goes from underground (the 20% ers) to mainstream both academia and the 20%ers think it sold out like a bunch of rappers. That is when the mediocrity comes in.
Java is Jason Vorhees
Don't waste your time killing it again, it will come back. Maybe try making some lightweight Java kits and help improve it.
Java had the honor of bringing in the 5th generation and virtual machines, it was the first attempt and scored pretty big based on the later vm success of .NET framework, AVM3 (flash), even haXe. It did influence the next layer.
Javascript has continued to mature, ES4 may take Java's place. Or Java could get more minimalist and less boilerplate.
I support you efforts to modernize Java with the introduction of closures, and the control invocation syntax, but it would be important, in my opinion, to reconsider the proposed syntax for the remaining aspects of the specification. Others have expressed this concern, but it appears no one officially involved in the JCP w.r.t., this matter has as of yet addressed those concerns.
{x, y => x + y}
can be expressed in more familiar terms using:
(x, y){x + y}
It may appear as a trivial matter for some, but I believe it would benefit Java in the long term, if the designers make every effort required, to maintain its current intuitive feel despite the introduction of more advanced concepts. To those who enjoy Java despite its flaws -- and having invested heavily in its future -- maintaining familiarity as well as consequent attractiveness to newcomers, should represent the real challenge to designers.
Java is dying. Long live the JVM.
The problem is that it is better to keep Java as is, rather than evolving it by adding new half-baked and broken features to it.
Consider Generics. While I do not consider Generics as a crucial feature, I am also not against having full-featured and rock solid Generics support for Java. I hate to see that Java Generics is half-baked and broken. The same is true about auto-boxing/unboxing.
Another problem within the Java universe is not the language itself, but its built-in libraries and broken JCP standards. java.util.logging is so useless that almost everybody still prefers Log4J. JSF 1.0, 1.1, and 1.2 are all broken. Java Collections lack many useful structures. A big number of open source libraries and frameworks I know all use Apache Commons Collections. Java Portlet Specification is still broken and lacks essential features.
That's it! I preferred Java 1.4 syntax and semantics compared to Java 1.5+, because it did not smell. I hope in Java 1.7 auto-boxing will be fixed (http://adamshibbz.blogspot.com/2007/05/java-5-autoboxing-unboxing-valueof-and.html)
What Sun can do is too keep Java's syntax as is, and invent a new statically typed JVM language with features from functional programming, etc.
Java can't be a dying language until a successor arises. Something needs to replace it before we can start to say it is "dying". For all Java's warts (and there are quite a few), nothing out there offers everything that Java can. Think about it.
* Speed
* JVM
* Frameworks
* Enterprise toolkit
The language itself might need some work, but until something like Groovy can standup and takes Java's place (Groovy can't yet...not fast enough), we'll still be using Java.
Hi Neal
Nice posting. I think saying "Java is a living language" may only mean, in practice, that we can improve the APIs but have to restrict ourselves mostly to the current syntax; or at least, that would be one way to read current opinion. Just because it is a living (and growing) language doesn't imply that we can successfully alter or extend the syntax and maintain the current popularity and developer commitment to the language.
On reading this blog posting, I began thinking of Objective-C, PHP 5, and VB.Net, all of which attempted to "improve" their predecessors while offering the existing user base to continue working (mostly) as before. To my knowledge, all of these have largely been failures on the open market of developer mindshare. Note as well that each of the original languages (C, PHP4, VB 6) had very large developer communities. You could argue in response that the changes these brought in comparison with the languages they "replaced" were much larger than what BGGA would bring to Java, but I would say there is still a cautionary tale lurking within.
As far as Java, I think we already have practical evidence of what might happen if BGGA closures and control abstractions were introduced to Java 7. While, for the most part, annotations and the foreach loop in Java 5 have been accepted, autoboxing and especially generics have met with controvery and generics in particular is, as far as I can tell, not widely appreciated outside of the most mundane use-cases to which they apply. I can only imagine that the BGGA changes would create a real rift in the developer community, and after Java 7 we might see the language begin a pronounced decline in usage.
OTOH, I personally like what you're proposing and welcome the changes, but I'm more willing than some (from what I can read in the discussions) to be open to such changes.
I think an option that has some appeal is to leave Java 5 as the standard language for developing common libraries on the JVM, and to introduce a "new Java" which learns from the mistakes of the original (as well as from other languages developed since 1995) which is what is recommended moving forward. That way you maintain the current, large developer base of Java 5 programmers while offering a newer, cleaner feature set for people ready to move on and up. Scala is one possibility, although I'd like to see a larger group of engineers working on the core language and smoothing out some of the rough spots and complexity that are there in 2.6. OTOH, it would be hard to finesse such a strategic move and it might fail; maybe the best option is for a company like Google to invest some resources in supporting Scala (for example), allowing the new community base to develop in an organic way. That seems to be the approach Sun has taken with JRuby: don't tell people you're abandoning the current approach, but entice them towards a new, well-supported, well-funded language and let them vote with their feet.
Regards
Patrick
Thanks for this great article Neal!
You may get more people to read it if you don't use "dying" in the title. People are voting down the article on social bookmarking sites just because of it's title.
Add my vote for improving Java by adding closures.
I believe that "aliveness" of a language is very much dependant on the tools that are available for it. Looking at how good Java IDEs are in comparison, Java is by far the most alive language today. I have posted a couple of more criteria on selecting a programming language on my blog.
Since you mention Scala as a superior alternative to "Java" I assume you agree that the Java VM is not dying.
Renaming this article to "Is the Java language dying?" would not only proof you're more intelligent than this article suggests, it would also indicate you're making an effort not to insult the intelligence of your readers.
A reader.
Well said.
Hi,
Well, programming languages are ... just programming languages.
Programming is about elegance: some programming languages offer more elegant syntax constructs to express semantic concepts than others. Personally I do not think that Java is 'just a programming language'. It was necessary to realise Sun's vision: the network is the computer. If we take that statement seriously, then we should offer a programming environment where the most important concept of Object Orientation, polymorphism, is something that can be realized in its full glory over the network. That is (one of the many things) that Java has realized!
That being said, I agree that, maybe, adding new constructs (in casu: closures) to Java is sub-optimal because they are added as an 'afterthought'. To cite Martin Odersky (the author of Scala): maybe we're adding wings to an elephant (it won't fly anyway). But, that is not a reason to 'throw away the child with the dirty bath water' (as we say Belgium). If you look at Zdenek's blog (good idea to include some hyperlinks to it in your blog, Neal), then you cannot ignore that closures offer some elegance that Java did not offer before. Agreed, it is also possible to push the capabilities of Java closures to their limits (actually, I do exactly that in my own blog lucdup.blog.com). For some usage patterns Scala is probably a better choice ...
So, what is my conclusion: I also think that Java is still a living language, but, like all living things: it will stop living one day or another. Refusing to add new features (in casu: closures) will only speed up that (inevitable) process. So, yes, add closures to Java and inform programmers about best practices. The closure proposal is a sound extention to Java. It is, in general, a bad idea to 'blindly fall in love' with new technologies (in fact with anyhing!). My blog shows how to do pure functional higher order programming using Java closures, but, I have to admit that I have to be much to verbose about type information to keep the type inferencer/checker happy. Scala has a more powerful type inferencer (and more concise statically typed language constructs, for example: covariance and contravariance are better dealt with at development time). Java closure support can certainly be improved (more natural syntax, more powerful type inferencing, better error messages (probably at the price of changing the covariance contravariance suport), ...).
So, maybe, while making Java more useful for programmers that know how to make use of its new language constructs, we should strongly support new languages like Scala. Especially because when they are fully compatible with the original vision of Java (Scala is such a language).
If you ask me (probably nobody does :-) ): do not throw away the vision behind Java, and let Scala be the future Java!
Luc Duponcheel
> Is it really time to move on?
Yes.
> I believe it is worth adding support for closures and control abstraction.
Again - yes. It's going to be a long time until corporations realize that Java is past its prime. I want to spend at least part of this time with closures.
Like others have mentioned, the Java *platform* (JVM) is definitely not dying.
If Scala ever gets nice IDE integration like Java has (gui designer, not just highlighting and refactoring) and RIA stuff (like GWT, JavaFX, etc.), I think a lot of developers will switch.
But the Scala community doesn't seem to be too interested in gui designers or RIA/Ajax/JavaFX/applet related things. They probably like things the way they are just fine.
So if Javascript gets static typing + type inference + speeds approaching java/scala, it's another serious contender, and has a much larger user-base, plus a simpler language to learn.
Neal,
I’ve seen lots of comparisons of the various closure proposals. I was wondering how something like BGGA would measure up with the C# form of closures (delegates)? What would something like BGGA have over C# delegates?
-Serge-
Scala? Without industrial support Scala can't win. No company has made a committment to Scala right now and I doubt it will ever happen because......the successor of Java is in incubation. Look here: http://x10.sourceforge.net/x10home.shtml
Apple just introduced its first 8-core PC. IBM announces the 32 + 2 core Cell-processor for the first half of 2010. A true parallel programming-language like X10 (successing both Java and C++) is needed. X10 can be thought as „Parallel Java“ and definetely is the way to go for us Java-heads. And we don't need Sun Microsystems for creating „Parallel Java“ by the way. I guess Mr. Gafter's employer will team up with IBM and Intel to create the next-big-thing aka „Parallel Java“..
i just don't get it. java has already one loosely implemented feature (generics) and you're about to break it up again with closures. just give up man, java is alive even without generics and still will be as c++ is (take a look at linux community). if you want new features, turn to scala or so.
I agree with you that Java should continue to develop and I think it is probably necessary to break some backward compatibility to achieve this. I have suggested introducing a source keyword to enable this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519124
With this you put source 7 at the start of a file and the source code doesn't have to be compatible with Java 6. (Neal - I know you think this is a bad idea, but I think it allows Java to progress more when you remove the constraint of absolute backwards compatibility.)
I do think that the demise of Java is greatly exaggerated, e.g.:
http://www.tiobe.com/tpci.htm
List the most popular programming language as Java and its 'market share' as increasing. They also currently have an analysis of the trends over the last 12 months that is an interesting read on their web site. Their analysis includes OO vs procedural, garbage collection vs. manual, and static vs. dynamic.
Adding a keyword to allow for new language constructs not being backward compatible in my opinion is pointless. Rather increase the integration abilities of Java/JVM to allow Java and other JVM-based languages to live in a common environment/eco-system. If the Java language will be changed incompatibly to prior versions, there is no need or benefit to sticking with the term Java.
I still think, new features should find their way into Java keeping compatibility with older code in style and functionality. The goal should be to ease a developer's daily work, i.e., removing boilerplates, increase compile-time usage safety, etc. One should not stop these efforts, only because some people seem to be afraid. A programmer's daily life includes learning new patterns, algorithms, approaches, features, tools, etc. Any serious company considers that fact and supports it.
Java is mature language. WIth great community, a lot of jobbs are out ther for Java programmers... many books, frameworks... it is eays to learn... can do many things... Last few years people are claiming that Java is dead but probably some of them died and Java is still living...
Hi,
I'm programming in Java for years now and I definitely don't think that Java will die any time soon (probably in decades). I also discovered Scala sometime ago and it was a smooth experience for me. I find Scala more attractive than Java, it is by far more complex (if you take functional side and the new model for composition like mixins) but at the end of the day it allows you o write more concise and cleaner code than in Java. My experience is that it allows you to write less error prone code. It is by far more extensible than Java (see implicit views for example, mixins) but it is not accessible to average developers.
I think Scala has a great community and more and more people are looking at it as a viable alternative to Java. Scala is a general purpose language and you can do anything you do in Java and with pretty much similar performance. Funny enough sometimes even better (see http://www.javalobby.org/java/forums/t101157.html).
But what about Java enterprise technologies? ... well I think most of them reduces to web technologies and from Scala site LiftWeb is by far a better technology than may "mature" Java web frameworks.
So I don;t think that java is a dying language as long asa there are efforts )like yours Neal to revitalize it. But keep an eye to Scala is growing fast !
Br's,
Marius
Br's,
Marius
This article seems to say that Java is dying because it doesn't have some language syntax that the author's favorite new language has. Maybe you should have wrote an article about "How I love concurrent programming with Scala". But then hardly anyone would have read that.
I was at Sun when Java took off, and I remember it being a huge leap over C++, because of the garbage collection, and the abstraction from the OS-- Write Once Run Anywhere (WORA).
I have not seen any new language which provides a quantum leap in productivity like C++ to Java did. The trend seems to be highly dynamic languages, but when you are working on a large project with 30-50 engineers, it's a blessing that the compiler and Java IDEs can catch many problems before it is even checked into the repository. Inexperienced developers + dynamic languages is a bad combination.
I also question whether we really need new language constructs for concurrency in Java. I have worked on several highly multithreaded servers and we used the Doug Lea's concurrent library for synchronization to great effect. I personally have few pain points as far as concurrency capabilities within Java.
-Alex L.
Alex,
I'm not really in favor of dynamic languages as I find a great value in static type checking as IDE's and compilers really help you determine compiler errors. So I'm a big fan of type safety.
As a side note Scala is not a dynamic language as it has quite a powerful type system. Yes there are much more type inference cases than in Java.
Br's,
Marius
Java is here to stay as long as there isn't a massive migration to dynamic typing.
Ruby looks promising, but if you want to be conservative, Java still has more tools, support, experience, etc.. behind it to take the risky move to Ruby.
But that is sure to get better. In the meantime something else (like Scala or whatever) may emerge.
I'm not in the business of supporting peoples favorite tech. I just want to make the surest gamble. What is known is less scary than the unknown.
Better to wait and let others find the best practices in the meantime. Unless your project is not very high risk.
Mr. Gafter,
I think it is a mistake to spread such blogs that many people see as message that Java is seen as dead by relevant persons. It is not, and will not be until it either becomes too complicated for the average programmer, something you catalyze with the BGGA closure proposal, or until a new necessity and its simple solution arises, most probable parallel programming. And even then its not clear. E.g. C is around and stable for a while now and no one would suggest its anywhere near dead. C++ will "die" well before I think . If you like Scala more than Java it is a valid opinion, but do not tell people that at the expense of Java and do not try to transform Java in a copy of Scala or Ruby or whatever. These languages have a different audience each.
Neal,
Thanks for an interesting article.
I don't think that Java is "dying" (by your definition), but I also think that perpetual modification of the language severely conflicts with backward compatibility.
I don't believe that the jump to an entirely new language (Scala) is the necessary conclusion. But I do think that maybe it's time for Java 3, which is not compatible with Java 2.
We could clean up things (libraries and language), do closures without being constrained by existing semantics, etc.
Java 2 would still run, new projects could use Java 3 (where all the fantastic existing support material would not be completely wasted), and migration tools could go along way in aiding those that want to move from one to the other.
Regards,
Michael
Java 3:: It is time to break compatibility for certain forms. We should have
Full generics
Removal of wrappers
Removal of Primitive types
Thread abstractions
Every type should be object based
Closures and Function blocks and control abstracts are the way to go.
java2++
Also retrofit stupid interfaces.
In fact the whole idea of interfaces leads to problems.
2 kinds:
Addition of methods (that can be been supported by abstract classes, however these don't allow multiple implementations)
Modification of methods (I really don't think this can be solved without client code modification)
@Neal
Nice monologue. Talk back!
I say continue working on Java 1.x and keep the compatibility, but start working on 2.x now. There is a very good reason for this: I feel embarrassed when my .NET colleagues start talking about generics, delegates... ;) On the other hand, their 'tool' sucks for enterprise apps...
Please, Please Neil - instead of extension methods (UGLY) try to retrofit interfaces so that they can be traits.
I like this idea : http://www.artima.com/weblogs/viewpost.jsp?thread=220916
PLEASE.
SUGGESTION TO WIN MORE PEOPLE TO CLOSURES: For me, closures are unavoidable to increase productivity. It's unfortunate some people want to invent another new language and spend huge amounts of time and money to bring it to maturity. Java must evolve in a controlled fashion the way it is done now. I suggest that you follow your presentation on closure to dig deeper on how closure can be used in business. You demonstrated that it can simplify programatic idoms, but you also said that it can simplify API usage and surely business idioms also. Why not take some established APIs like JMS, JMail and other and see briefly how closures can simplify their usage. Also, you could imagine how closures can be used in business to implement business idioms into the programming language.
QUESTION ABOUT CLOSURES: Based on your video, closures are run-time idioms. Can we have a compile time Closure? That is a closure that acts during the compile time. Declarations of annotations could be considered "compile-time" idoms. I want to see an closure to generate getters/setters idiom for JavaBeans. Is that possible?
A suggestion for the last-statement-no-semicolon issue: Require parentheses for the last statement - much like if/while require them around the condition.
i.e. instead of {x,y => x < y} require {x,y => (x < y)}.
Or,
{x,y => System.out.println("Comparing " + x + " and " + y); (x < y)}
Languages lose support both when they fail to evolve (Fortran, Cobol, etc.) and when there are alternatives with cleaner, clearer syntax (Python vs. Perl, Java vs. C++ (initially), etc.).
The goal is, therefore, to take the best new language features with minimal disruption to good features of the existing framework and overcoming as many bad ones as possible.
The current form of BGGA adds an interesting new feature, but I haven't seen anything that really nails why closures are saving Java from the Fortran fate instead of condemning it to the C++ one.
The key topic to address is how closures can simplify and improve things in compellingly better ways than other, less dramatic changes.
For example, with closures, one might be able to write
Collections.sort( list , {Integer a,Integer b => a-b } );
which is a lot cleaner than the Comparator<Integer> babble that we have to do now. But it looks a little weird. But wait! What about
Collections.sort( list , int ?(a,b) { a-b } );
That's even cleaner *and* the compiler can completely unambiguously figure out that this actually means the Comparator<Integer> babble with just a few simple, common-sense rules about how to form sensible defaults. (One can argue whether the ? and int are even necessary.) Of course, the compiler could also figure out either of
Collections.sort( list , {a,b => a-b} );
Collections.sort( list , (a,b){ a-b } );
but the point here is that closures need to have a really valuable use case that *cannot* be handled easily by defaults, or Java is in danger of losing the comprehensibility battle to a language that *does*.
Likewise, with resource management applications of closures, adding a resource interface with acquisition and release methods which then could be used in a foreach-like style (e.g. maybe with a try (my_class_implements_resource) { } block) that really expanded to using the long form of grabbing a resource, then trying stuff, then finally cleaning up. This gives the nice syntactic sugar of automated resource management while fitting nicely into the existing Java model and without the overhead complexity of closures.
Custom looping could have some nice applications, but I haven't seen any examples that are particularly compelling as common use cases.
Note the dramatic popularity of Python due in large part to its power *and* clean syntax. That's why I use it, and that's why I encourage others to use it. People program in Python because it feels tidy and painless.
To keep Java as lively as possible, it needs to put up a good showing in Python-like cleanliness and consistency as well as Ruby/Scala/etc. like novelty. For closures to be part of Java's life rather than death, it needs to show compellingly that it strikes the right balance.
(sorry, this got a bit long, hope nobody minds...)
I find it strange, how you seem to equate the possible non-addition if features that completely change a language's character to equate the death of that language. I must say that I really disagree with that. To a certain degree, I am also a feature-junkie, but nonetheless, I prefer to learn completely new approaches through a language that was designed for them.
I am not completely against things like anonymous functions or closures, *IF* somebody comes up with a syntax that integrates nicely with existing code. So far, I have not seen any syntax proposal that feels really natural to me.
The bigger problem however is librararies: You may introduce closures, but that won't change the (sorry) braindead way, how UI events were done in AWT and Swing or the (IMO acceptable way) how Runnables are working. These libraries are baked and either you find a way of making them work with closures/anonymous functions/whatever elegantly, or the whole approach will not be of much use (except in very complicated edge cases, but the question is, if a generic language should be overly optimized for academic edge cases).
I am not against syntax extensions, if they are done carefully. I am very happy with foreach-loops and enums, for example and also with the simple use of Generics that has been retrofitted into the Collections API. (I don't use Generics for anything sophisticated though and I am doubtful whether too many people do really make use of the Generics and the complexity they are able to introduce).
I consider the problem with closures in Java to be similar to Autoboxing: autoboxing is a compiler-level hack around the fact that when designing Java, not all types were made into Objects. Autoboxing blurs this distinction a bit, but is in my opinion also an example of simplexity - it makes typing a bit easier, but in some situations (mostly when it comes to performance) it requires you to start thinking a bit like a compiler. Thus, it is not a really elegant construct and I think it would have better been left out of the language completely.
My concern about adding closures and function-type variables are going into that direction. If you are not very careful, you will end up with a half-baked language feature, that will be more confusing than helpful and that will not be supported by the main libraries anyway (unless you are interested in doubling the size of the Java plattform and providing packages like java.swing2.*, java.util2.*, etc.).
It's funny however that some people refer to ECMA4 as a more simple alternative to Java. ECMAscript suffers from exactly the same problems. Adding normal classes to an existing prototype-based language is about as horrible as adding functional programming constructs with a completely alien syntax to an OO-oriented language with a huge existing base of OO-oriented libraries.
JAVA has separable parts to live or die each on their own. I need a language that has 10x improvement in learning curve and productivity for people writing abstract algorithms that try to automate aspects of human thought. It would be great if that language would compile into JVM and be inter-operable with compiled JAVA code. Also these algorithms are compute intensive so a performance oriented compiler is important. Dynamic language features are not important in this new language.
Today I have a team of people that codes in Matlab and another that codes in VisualBasic. Then a smaller team manually translate and wrap into JAVA bundles for SOA integration. Currently, this is the most productive approach that seems to be available. A new language Could replace that and make everyone more productive, happier, and worth more $.
Maybe call the new language pseudoJAVA; pseudocode that compiles to JVM. Might be useful if a pseudoJAVA-to-JAVA compiler also existed. If the new language appeals to people who today write in Basic, MatLab, etc., it could grow the user base for JAVA and JVM and rejuvenate both.
... think an option that has some appeal is to leave Java 5 as the standard language for developing common libraries on the JVM, and to introduce a "new Java" which learns from the mistakes of the original (as well as from other languages developed since 1995) which is what is recommended moving forward ...
Right. Almost.
I will not go deep into discussion about what is a dead language. My opinion is that the language is alive until there is a single line of code on it.
I agree that Java was a great success. A fast improoving in time. Up to 1.4. We should not say at the same time "generics is bad" and "let us start again from Java5" That is not logical.
Telling "Java was good, now it has moved to a wrong direction - so let us get a new language - is not logical either. It is stupid to through away such a heap of gold.
IHMO what we all need is to restart from a different point: Java 5 - ( generics + annotations). And from this point (suggest a better one) to rethink and move on. And that should be named still Java and still have Java 4 as a subset. Only this may spare the whole thing. It does not mean thete there will be no generics at all - it will be but not this one.
Would there be many enough people trying to define this point and what to do starting from it then it WILL happen. We are the People, not Sun Academy.
On generics. A beautiful scientific success. Not now - back 15 years in C++. Blindly borrowed. Needs of the most typical Java User miss-estimated here. What was needed - to be able to specify that a specific collection contains elements of type X or of its subtipe. Actually to make it impossible to add wrong objects there, which has nothing to do with types of iterators. And should not lead to "warnings".
Why did the do that? - "Premature optimization is the root of all evil". This way it permits to go without dynamic type controll. In my suggestion we would not change the other code (and se no warnings) but any reasonable compile should find itself that iterator casting is not needed any more. And OPTIMIZE.
And let us not be afraid of new keywords - that is a "problem" for source converter.
I have a long background of programming (started with about 8 years) so I yet have more than 28 years of experience in software development using many different languages. During the last two years I have evaluated new languages from different point of views.
For new projects I use Java (and I am new to it).
Post a Comment