It has been quite some time that people have been coming out with statements of Java’s demise. But to see Elliotte Rusty Harold in his post Java is Dead! Long Live Python! do it caused me consternation to no end. You may want to check out his web page to get a sense of his contributions. He has written at least four books on Java including those related to XML Processing, IO, network programming. Incidentally he has also written a book on Beautiful Code (more on that later). I would suggest you read the post first, if the remainder of this post is to make any sense.
I must confess that after having spent years in Java, I like Python more. But I like Python more because of the nature of language that it is. It is natural in its flow (I like the mandatory indentations), its ultra slick programming constructs (ruby actually is a tad slicker but I dont find myself comfortable with its syntax / style and the special characters in the variable names), and its ability to really get a lot of work done with very little code. But having said that, I have no reason to believe or assume that Java is getting threatened in any particularly significant manner from these upstarts such as PHP, Python and Ruby. They are collectively not strong enough as java and are unlikely to pose a threat to Java in the market the matters the most (at least yet) – corporate enterprise software development. Corporates need comfort, and they need comfort that stems from a strong support and promise that they can count on. And they especially need that for enterprise (non workgroup / non department level) applications, and enterprise level application development hires most of the programmers (I can almost hear others starting to yell – buts its true).
I don’t intend to suggest that the newer languages cannot take on the challenges of enterprise software development. But choice of language and platforms in this context is a rather complex process – a process that involves far more than syntax and aesthetics of coding. Backward compatibility is a big deal. A very big deal in this world. You can (and I do) blame Microsoft for all its sloppy software and bloated code base but the fact remains – they made sure that they maintained backward compatibility. In fact, I believe maintaining backward compatibility and compatibility across a large number of devices is what definitely bleeds Microsoft of a lot of time and attention that they could have spent elsewhere.
So we find the academics sitting on large campuses, joined by many people in the web 2.0 / cloud computing environment and some from the workgroup / department application development space, getting gung ho about the newer languages and their cuter syntax, the brevity and the sheer power of productivity (I am one of them). But what they miss is that java solves important plumbing problems. They will realise it even more if they had attempted to deal with distributed cross platform computing in the years of yore with tools such as RPC / DCE / Encina / the various CORBA servers and services etc. etc, and deliver on the same across a whole range of platforms. Through 1996 – 2005 I believe Java solved the problem of platform independence, distribution and binary portability. And that too in an extremely impressive and credible way. You have to realise that the strength of Java is its inclusivity. It attempts to work with everyone and everybody who may want to work with it. Including those who long since adopted it in its early versions and continue to use those versions today. While many language communities attempt to crowd the etherspace with pro-my-language messages, java stands out in the fact that it doesn’t attract deliberately but it does not turn anybody away. Ever.
Sure Python 3.0 made some very welcome changes, and sure many of the changes make the code become much more intutive, but make no mistake if java generics had broken backward compatibility, its economic impact would’ve been far in excess of that triggered by all the version upgrades of Python, Ruby and PHP put together. I do believe that this approach will eventually lead to substantial subobtimisation but thats still some time away. Moreover Java needs new features and enhancements like Yul Bryner required a hair cut. Java already has so many features and capabilities, new features wont matter much in the overall scheme of things for quite some time. Java is fine, it doesn’t particularly need to grow.
Whenever I write a new application for myself, Python shall always have the first right of refusal (ie if Python doesn’t meet the requirements adequately, only then will I evaluate other languages). However when required to build an application for a customer, who wants the comfort that his application will continue to run for another 10 years at least without him having to make any changes or enhancements to the code and be able to move it around from hardware to hardware, you exactly know which language I shall choose – Java. Thats why despite all the assertions of java being threatened, and even as other languages continue to grow thanks in no small part due to the additional developer productivity promise, I think java shall remain undead for a long long time (all the versions continue to coexist). For java we shall have to say something of the sort – Java 6 is undead, Long live java 7. And 10 years from now just like today, no one is likely to lose his job for having chosen Java. Thats why I strongly believe Eliotte was so wrong.
Related posts: (Automatically Generated)
Very interesting analysis indeed. I actually referred to discussions that happened during late 90s and early 00s about demise of mainframe. Actually sales of mainframe have increased as per IBM (dont know if thats only marketing).
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 very strongly contest that Java is making huge jumps with the new JRSs / Java6 / JSF / EJB3 – in fact I think post JDK1.4 if Java had stopped evolving, it wouldn't have mattered much. In fact I am quite disappointed that Java is becoming bigger and bigger with each new day and each new JSR.
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.
Turning away is done to other syntaxes and languages.
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.
I think what is happening is that changes to support other languages will require changes to the JVM which will influence backward compatibility. That is indeed a bit of a tricky area. However there are sufficient indications to suggest that scripting languages such as groovy or jruby are actually performing very well on the JVM. I am afraid I am not sufficiently aware of why Jython seems to be apparently not “yet” doing as well but I don't know that it has anything to do with the JVM.
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.
I 'discovered' your blog yesterday and one of the usp's of your blogs is that it is readable-even by the non -programmer.
Thanks for this article
Sri
Dhananjaya, very passionately written post. Felt to share my experience. Having started my tech life with Java and developing 90% of products in last 10 years, I moved to PHP (Enterprise style) in 2007 because I found that new comers are finding it hard
-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).
Java wont die anytime soon, but we wont see the 'learn java-get a decent job' thing anymore. .NET platform is emerging strong as a multipurpose solution while Python and Ruby, the open source languages have to attain a 'true' commercial value before they actually make a dent in general computing. Considering the current recession, its a safe bet to study languages that fetch you jobs, regardless of being expertise in one field. .NET appears more natural choice today.
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.
Santosh, You might find one of my earlier blog posts a little relevant – http://blog.dhananjaynene.com/2008/06/whyhow-i-...
well do still think java made lot progress post jdk 1.4 but we have our differences there.
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.
They are diving into RIA space too with Java Fx.
Every time I've heard people say that Java is dead or dying it's usually in the context of startups and I think it's a very true statement. Startups are the canary in the coal mine–they have to build software that works with very few resources in a short amount of time. Internet startups and enterprises today use lots of the same approaches and technologies when it comes to software development so when they make a move everyone seems to notice.
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.
very nice said.., and even this criticism may work in positive way…, SUN really desperately needs to show more interest for developers & they should enhance the language..,
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..
Interesting article! But I don't understand what you mean about “special characters in the variable names” in Python? This is a legitimate complaint with Perl, but there are only two special characters that have anything to do with variables, * and %, and even those are very specifically to do only with parameter passing.
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.
I agree that Java isn't dead, but Java _does_ turn people away. I'm not arguing (de)merits, just giving examples. Swing preferred to native toolkits (like SWT or WxWidgets). JRuby instead of integrating with normal Ruby. JBullet instead of using Bullet directly. HSQLDB instead of SQLite. Most other languages integrate with the same packages. They all share. Java always makes its own. Maybe there are good reasons, but Java frequently promotes apartheid (100% pure Java!) rather than integration.
I was referring to the fact that I was uncomfortable with Ruby having the special characters in its variable names – not Python.
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 implication 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.
Most other languages depended upon an OS. Java depends upon a JVM which in turn depends upon a OS. Thats probably a reason for the apartheid. This is also likely to be driven by the fact that such apartheid is likely whenever there is introduced a new intermediate level of abstraction. Thats precisely the reason why web applications work well with each other and not with client server apps – they try to create their own equivalent web applications – the browser and the HTTP protocol introduced an intermediate level of abstraction which all web applications depend upon but which client server applications do not.
I would be curious how you consider other JVM languages or even Python on the JVM (Jython). The main reason you listed for choosing Java over Python is portability and long-term relevance. In order for Java to make it for the next 10 years, the JVM will also need to stick around. If that's the case, then other languages like Jython, JRuby, Groovy and *especially* Scala will be able to run without a hitch. (I say “especially” because Scala's output bytecode is much closer to Java's than the other three languages, meaning that future changes to the JVM intended for Java will affect it less).
Everyone goes through a Python honeymoon period. Then you get over it and realize python's an order of magnitude slower than Java, C#, Scala, etc. etc. and has even less tool support for things like refactoring or visually designing interfaces.
The vast majority of code is not CPU bound, and refactoring is less of a deal in more expressive languages because there's less code to manage in the first place.
Sorry, I can't take an article seriously when the author doesn't know the difference between “loose” and “lose”.
Not sure why I miiised such an error. Corrected it
Actually my argument above did not allow me to bring in the main reasons why I would consider Java instead of Python – performance (in situations where it really makes a difference) and relatively easier availability of trained people, in addition to the portability and enterpriseyness that I referred to.
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.
I think it depends on your definition of “dead”. I would regard FORTRAN as “dead” and COBOL as “dead as a doornail”, but advocates can surely point to large collections of libraries and job postings, and the fact that many schools still teach programmers to program using these languages. **shudder**
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 am not sure if startups are the canary in the coal mine. They actually are early stage businesses with little entrenchment into customers, users and other stake holders and thus can afford to take more risks just like kids fresh out of college. They are in a hurry. They need to make their investment run the furthest it can even if they take some risks along the way. The most they lose in the early stages are big dreams and the series X funding.
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 finally they have corporate subempires that work within the dungeons seeking to ever expand themselves. 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.
I am not sure if startups are the canary in the coal mine. They actually are early stage businesses with little entrenchment into customers, users and other stake holders and thus can afford to take more risks just like kids fresh out of college. They are in a hurry. They need to make their investment run the furthest it can even if they take some risks along the way. The most they lose in the early stages are big dreams and the series X funding.
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 finally they have corporate subempires that work within the dungeons seeking to ever expand themselves. 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.