-
Website
http://blog.dhananjaynene.com -
Original page
http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
It will certainly take a long time for enterprises to feel comfortable using something like Erlang but I write software for lots of companies and the most astute among them use Ruby to build domain-specific languages, Python to glue things together, and tools like Groovy (yuck) when they want to have their legacy code at arm's length. I still see a ton of Java and I'm sure I will for some time. Still, I find lots of forward-thinking organizations that don't put so much value on backwards compatibility as they do on productivity and keeping their developers happy and engaged.
Well established enterprises on the other hand have too many other users and customers depending upon them. They have an entrenched and large management team which wants to make sure they don't take too many risks since they can get pulled up for it. They have access to positive cashflows which they have to spend by the year end (at least when the year has been a good one). And they have corporate subempires that work within the dungeons seeking to ever expand themselves. Finally they have a tremendous accumulated brand value and reputation which is too critical to risk. This requires them to make their decisions based on a very different set of criteria (that what we call the enterprise criteria).
These are the kind of differences in the context that often influence which language is selected. Sure many of these are not facets of software engineering - but these are real actors in the context and we have to recognise that all of these and not just the inherent aspects of the language itself play a role in selection and the long term viability and sustainability of a language.
The JVM is the bottleneck for change. It is the foundation that keeps the bytecode backward and forward compatible. But its development has been driven (by Sun) only to improve performance for server applications.
If the JVM was allowed to evolve then it could become more capable without sacrificing the compatibility. If the JVM changed to efficiently execute dynamic languages (Scheme,Perl,Python,Ruby) then it could give you a Python on JVM experience you might prefer to CPython. And indeed there have been small improvements in some JVMs. But the main experience has been to turn away those who want to improve the scope of the JVM.
Note that Microsoft seems to be evolving their VM's support in this direction much faster than Sun. IronPython seems to be farther along than JPython. And F# will be released by 2010.
Having once dominated a constituency of the serverside processing domain as Java has done, I must confess, that Sun would indeed find it difficult to move away from the high performance focus.
I think the issue really is how do you enhance the JVM without impacting backward compatibility. I am not sure that the answer is going to be that easy. Microsoft has had it a little easier since the entrenched code base which depended on their VM (unlike their OS) was small compared to Java due to the lesser duration of its existence, and a little slower rate of adoption. But if that goes up (Microsoft VM adoption) substantially, I am certain Microsoft will pull back on changes - thats very essential when you are serving a corporate enterprise market.
I don't know that there is an easy option - I suspect we shall all come to some state of minimised unhappiness rather than maximised happiness, but a state that will allow Java and the JVM to defend its current constituencies (ie. reduce losses to other VMs and languages) rather than adopt newer ones.
Similarly, there comes a point when you application becomes a product. Product without solid middleware plugged into it will not function/scale well. Also I think Java is moving towards right direction with JavaFx and other JSRs that are under way. It made huge jump with Java6/JSF/EJB3.0 releases. Also now since Java (ie Sun) has become more open to receive feature request from community, incorporating those features in the specs thanks to competition from .Net, I think Java will keep moving in the right direction. Plus the kind of open libraries available for Java is phenomenal. I never consider Java minus the open source community which is supporting it. Though PHP/Python/Ruby and others have a strong community support as well, but Java put together with all the libraries around it is way better than what you can get out of newer languages.
One problem with having zero backward compatibility is, it becomes very difficult for someone to get on learning a technology as all the time you have to make sure you are reading info about the release you are using. And this is plain waste of time and interest.
I personally like integrating Python/Django and Java/GWT to get best of 2 worlds if I have to code a web app for myself and prefer using GWT if I am going to maintain it for more than 6 months.
I would also contest the very last line of your comment. I actually would today prefer Python or Ruby to code scenarios where I needed to maintain something over a long period of time. The sheer brevity of the code makes sure you have far fewer lines to maintain and the stronger language capabilities will allow to make the changes far faster. So long as one is careful in writing code using say Python, it is actually far easer to maintain and sustain it than the reams of java code required.
and using python ruby for code that needs to be maintained, i am not sure. I use lot code generation techniques, few utilities i have developed on my own over these years to help me keep coding as less as possible. and specially with GWT since I dont have to maintain HTML/JSPs/JavaScripts it makes life much more easier.
Thanks for this article
Sri
-To learn all Java stuff(Spring, Struts vs other MVC, Hibernate, many enterprise technologies)
-Rapidly develop solutions
-Poor client side (Voluminous Struts/JSF makes it hard, not much libraries as one can find in PHP, Python, etc)
Many such factors influenced me to pick PHP. I am happy that we picked PHP; it has helped my startup to rapidly develop scalable solutions. However as you said there is a limitation on what you can do with PHP, Python. For enterprise solutions, we are still with Java; for consumer apps we are using Enterprise PHP (php5 with MVC, 3 tier architecture patterns).
However ,as the computer paradigm shifts from standalone machines to distributed computing, maybe Java would fill in as an excellant middleware.
On a personal note, I support Python. Ruby is good, but its syntax makes it look somewhat too exotic for beginners. Esp its sugar coated syntax. Ruby on Rails is a different story.
Ruby & Python are very nice on that part & thats why their communities have strong feeling ...
But the recent emergence of new languages on the JVM & CLR has made a different story..., read my post on Young & Upcoming Languages on my blog..
This really changes the statement in the sense that may be JAVA is dead but JVM is very much alive & is gonna live long life..
I'm in a similiar mind to you overall. While I did pick Python for my most recent work project, it's of moderate size - I wonder how a large Python project with many programmers would really work - yet I don't really have specific objections that I can formalize.
The one problem I see is that with Python's duck typing, if you put the "wrong thing into a slot", you can carry it around forever and then only get an obscure error when you finally use it. But if it happens, it's easy to debug - override the setter for that variable and check the type right then.
I think the advantages you get from being able to easily put a mock anywhere (because "everything's a function") would out-weigh it.
But when I went to do a rewrite of my Java open-source project (a model of turn-based games), I thought long and hard - but eventually went again with Java. Android compatibility was a lot of it but when it came down to it, I wanted strong typing for this general framework.
This is what makes programming interesting!
Thanks for the thoughts.
Depends upon the level of discipline and commitment to refactoring regularly. If these are focused on, I think Python will work out far better than Java, else I would recommend one should avoid Python
While duck typing has its own bunch of issues, it does compensate for the same as well. I blogged on some of its implications in http://blog.dhananjaynene.com/2008/09/python-fr... . Duck typing is a highly nuanced aspect and I quickly am unimpressed by people who have a strong opinion about it either way - its good or its bad.
I would look at Python on JVM in the following ways. If JVM is a necessary requirement or is likely to be a very positive factor in the overall scheme of things then I would consider using Jython as the implementation if the remainder of my analysis seems to be suggesting Python language as the better choice. Otherwise jpython and cpython are merely two implementation choices that one can choose to leverage (and in this case at least cPython is the only reasonably stable, full featured and performant choice today).
Oh I think Java will make it for the next 10 years and many more. At the risk of being proved wrong in the future, I suspect the way C has entrenched itself into the plumbings of system software, so will Java entrench itself into some deep world of enterprise architecture plumbings. However I do believe a fair amount of business logic will start shifting out of java in that period - not sure where it will end up - on the JVM / CLR based implementations or the native implementations.
But when I think of "dead", I mean that the language is no longer at the forefront--it's not a language that knowledgeable practitioners usually choose for general programming projects. As you point out yourself, you'd only use Java for that set of tasks for which Python is not suited. And for a variety of reasons that set is growing smaller quite rapidly.
I still recall back in 1988 trying to decide whether to learn the X Window System or HP's propietary windowing system. X seemed a little ugly and clunky, whereas the alternative looked slick and quick. One of my mentors gave me a great piece of advice on this, pointing out that X11 was the future--and of course HP's software is now long forgotten.
Python is the future, it has a significant role. Java has already transitioned into legacy mode, and it's hard to see what might give it a second wind. Because of its installed base it has to play things "safe", and that will kill it.
I understand that some liberty can indeed by taken with the language and would assume that "dead" could cover cases where severe reduction in capabilities and importance into a vegetative state is near imminent. But java is not dead by that standards. I just think it is middle aged and has a long life ahead of it though all the excitement seems to be getting distributed amongst the newer kids on the block (often quite rightly so).
Nevertheless, Java has lost the bleeding edge: it has a stable market share on enterprise software but otherwise it's just catching up with the more advanced languages these days for the sake of the illusion that "Java evolves too. Really!".
It doesn't and it doesn't need to evolve; IMHO Java 1.4 delivered pretty much what you ever wanted from Java. The enterprise guys can get their comfy security without awkward adaptations of generics, closures and rest of the stuff that is copied from elsewhere. But you don't seem to get the interesting jobs with Java skills anymore and it's not the number one language if you want to learn new stuff. That's bad because if you're not riding on the wave that drives the new stuff you're being obsoleted. First slowly, then at once.
What Java has to do to survive is not technical. Technically, Java is good enough (or, not bad enough). But as it's the market leader on enterprise software it must reinvent itself on that very same market before some of the new languages come and eat the cake that currently belongs to Java. It could take five years, even less if Java doesn't fight back. On the other hand, if Java has already reinvented a new cake at that time, it's going to continue to lead the market to a new direction in the future.
And the name of the cake seems to be "secure, reliable, and not too smart enterprise solutions". By "not too smart" I mean something that can be practically averaged over dozens of developers. Python is smart because one whizbang Python hacker can rewrite and obsolete much of the Java stuff in one corporation, but they couldn't easily find a replacement for him when things turn boring. "Not smart" means low contribution rates per developer but lots of interchangable developers. The Java way. But with a new toolbox.
By the way, Python isn't an upstart: it's older than Java.
On a separate note, Python is an upstart that is older than Java.
Check modperl before u make a comment about enterprise software. Most companies I am dealing with use modperl for enterprise applications. Perl is unbeatable.
Also, WxPerl takes off recently. Till recently, I was waiting for a Tk plugin in browsers to embed graphic applications in a server page for perl (just like swing application put in JSP using plugin). But, DOJO, AJAX stumped me and made me feel -----> "No need of Java any more for anything"
and finally::::::::::::"There is nothing that you can't do in Perl" ----> "I can challenge any one in the world for a better program in perl"
Love,
Ignaci