<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>/var/log/mind - Latest Comments in Java : the perpetually undead language</title><link>http://var-log-mind.disqus.com/</link><description>Dhananjay Nene’s free (as in free speech) opinions on all things related to Software Engineering</description><atom:link href="https://var-log-mind.disqus.com/java_the_perpetually_undead_language/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Tue, 09 Jun 2009 15:53:01 -0000</lastBuildDate><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-442489698</link><description>&lt;p&gt;Hi Dhananjay,&lt;/p&gt;&lt;p&gt;nice post, but I differ on the 10+ year maintenance front. I wrote my first webapp in python in 1996, it is still in use today with few modifications... :)&lt;/p&gt;&lt;p&gt;Keeping software simple and making good use of the underlying platform (unix/linux) seems to work wonders :)&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Willem van den Ende</dc:creator><pubDate>Tue, 09 Jun 2009 15:53:01 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4930463</link><description>&lt;p&gt;Boss!! and Bossess!!!! Please use perl for everything. Perl is ultimate for any purpose. Python is slow (even with psycho, pypy) and Java is over verbose. (But Java is faster)&lt;/p&gt;&lt;p&gt;Check modperl before u make a comment about enterprise software. Most companies I am dealing with use modperl for enterprise applications. Perl is unbeatable.&lt;/p&gt;&lt;p&gt;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 -----&amp;gt; "No need of Java any more for anything"&lt;/p&gt;&lt;p&gt;and finally::::::::::::"There is nothing that you can't do in Perl" ----&amp;gt; "I can challenge any one in the world for a better program in perl"&lt;/p&gt;&lt;p&gt;Love,&lt;br&gt;Ignaci&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Ignaci</dc:creator><pubDate>Tue, 06 Jan 2009 03:02:54 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4370327</link><description>&lt;p&gt;I agree with you totally. There are people, companies and corporate who's survive because of Java. I admit, I've been lured by python, scala, groovy and all other languages which offer you syntactic nirvana, but none of them address issues that are so important to me and my customer who's day to day business depends on software. Imagine in case of some ( god forbid  ) medical emergency you wanted money from ATM and you couldn't get it because some program written in fancy language crashed. I rather have an unproductive, ugly language on whom people can trust their money and lives with.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">ranjan</dc:creator><pubDate>Fri, 12 Dec 2008 13:44:23 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4347778</link><description>&lt;p&gt;My examples were all cross platform, but I agree that there may be reasons (a big one for me being the pain of deploying cross-platform binaries vs. jars or html/js).&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tom</dc:creator><pubDate>Thu, 11 Dec 2008 22:15:07 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4347464</link><description>&lt;p&gt;Java in on track to becoming COBOL, and nobody wants to be a COBOL programmer, do they?  Like C++ before it, Java will wane and plateau and eventually be relegated to legacy usage.  Ruby seems likely to take over, but it, too, will go away for the next thing.  But, it's not like it's going to happen tomorrow.  I just think that Java Developers need to accept that Java will go away and something else will be where Java is now, and they ought to get on the stick to learn it.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave</dc:creator><pubDate>Thu, 11 Dec 2008 21:51:42 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4335981</link><description>&lt;p&gt;Your description of the cake is extremely well done. You've managed to comment on the underlying issues as well in a concise and effective fashion. Nicely put.&lt;/p&gt;&lt;p&gt;On a separate note, Python is an upstart that is older than Java.&lt;/p&gt;&lt;p&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dhananjay Nene</dc:creator><pubDate>Thu, 11 Dec 2008 17:51:15 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4335643</link><description>&lt;p&gt;To be direct, it's hard and partially impossible to compare those two languages because they're on different markets.&lt;/p&gt;&lt;p&gt;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!".&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;By the way, Python isn't an upstart: it's older than Java.&lt;br&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">yason</dc:creator><pubDate>Thu, 11 Dec 2008 17:33:06 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4334245</link><description>&lt;p&gt;I appreciate your approach to this ongoing subject.  While the sport in me enjoys language feature vs. language feature debates, the pragmatic professional understands that comfort pays the bills.  Customers want to be comfortable with their decisions.  Well written.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jamie McIlroy</dc:creator><pubDate>Thu, 11 Dec 2008 16:18:38 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4333651</link><description>&lt;p&gt;If we have access to such a rich english language why do we then end up confusing the middle aged and the dead ? This entire argument of then valuing only the youth which generally is the most vibrant and exciting stage substantially underemphasises the contributions that we make to society when in our middle ages.&lt;/p&gt;&lt;p&gt;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). &lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dhananjay Nene</dc:creator><pubDate>Thu, 11 Dec 2008 15:46:57 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4333511</link><description>&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;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).&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dhananjay Nene</dc:creator><pubDate>Thu, 11 Dec 2008 15:38:35 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4333370</link><description>&lt;p&gt;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**&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;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.&lt;br&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike</dc:creator><pubDate>Thu, 11 Dec 2008 15:30:55 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4333268</link><description>&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;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).&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dhananjay Nene</dc:creator><pubDate>Thu, 11 Dec 2008 15:25:56 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4332271</link><description>&lt;p&gt;Corrected it.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dhananjay Nene</dc:creator><pubDate>Thu, 11 Dec 2008 14:34:14 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4332215</link><description>&lt;p&gt;Sorry, I can't take an article seriously when the author doesn't know the difference between "loose" and "lose".&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anonymous</dc:creator><pubDate>Thu, 11 Dec 2008 14:31:15 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4331523</link><description>&lt;p&gt;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. &lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Brian</dc:creator><pubDate>Thu, 11 Dec 2008 13:52:32 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4330682</link><description>&lt;p&gt;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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">heardthisbefore</dc:creator><pubDate>Thu, 11 Dec 2008 13:04:24 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4330523</link><description>&lt;p&gt;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).&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Daniel Spiewak</dc:creator><pubDate>Thu, 11 Dec 2008 12:56:18 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4330132</link><description>&lt;p&gt;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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dhananjay Nene</dc:creator><pubDate>Thu, 11 Dec 2008 12:33:15 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4330063</link><description>&lt;p&gt;I was referring to the fact that I was uncomfortable with Ruby having the special characters in its variable names - not Python.&lt;br&gt;&lt;/p&gt;&lt;blockquote&gt;I wonder how a large Python project with many programmers would really work &lt;/blockquote&gt;&lt;p&gt;&lt;br&gt;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&lt;/p&gt;&lt;p&gt;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 &lt;a href="http://blog.dhananjaynene.com/2008/09/python-from-java-how-duck-typing-influences-class-design-and-design-principles/" rel="nofollow noopener" target="_blank" title="http://blog.dhananjaynene.com/2008/09/python-from-java-how-duck-typing-influences-class-design-and-design-principles/"&gt;http://blog.dhananjaynene.c...&lt;/a&gt; . 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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dhananjay Nene</dc:creator><pubDate>Thu, 11 Dec 2008 12:29:06 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4329808</link><description>&lt;p&gt;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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tom</dc:creator><pubDate>Thu, 11 Dec 2008 12:15:07 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4329744</link><description>&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;I think the advantages you get from being able to easily put a mock anywhere (because "everything's a function") would out-weigh it.&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;This is what makes programming interesting!&lt;/p&gt;&lt;p&gt;Thanks for the thoughts.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tom Ritchford</dc:creator><pubDate>Thu, 11 Dec 2008 12:10:59 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4329444</link><description>&lt;p&gt;very nice said.., and even this criticism may work in positive way..., SUN really desperately needs to show more interest for developers &amp;amp; they should enhance the language.., &lt;br&gt;Ruby &amp;amp; Python are very nice on that part &amp;amp; thats why their communities have strong feeling ...&lt;/p&gt;&lt;p&gt;But the recent emergence of new languages on the JVM &amp;amp; CLR has made a different story..., read my post on Young &amp;amp; Upcoming Languages on my blog..&lt;/p&gt;&lt;p&gt;This really changes the statement in the sense that may be JAVA is dead but JVM is very much alive &amp;amp; is gonna live long life..&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gaurav</dc:creator><pubDate>Thu, 11 Dec 2008 11:53:02 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4329387</link><description>&lt;p&gt;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.&lt;br&gt;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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">nanreh</dc:creator><pubDate>Thu, 11 Dec 2008 11:50:41 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4326680</link><description>&lt;p&gt;They are diving into RIA space too with Java Fx. &lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Priyank</dc:creator><pubDate>Thu, 11 Dec 2008 07:36:45 -0000</pubDate></item><item><title>Re: Java : the perpetually undead language</title><link>http://blog.dhananjaynene.com/2008/12/java-the-perpetually-undead-language/#comment-4326616</link><description>&lt;p&gt;well do still think java made lot progress post jdk 1.4 but we have our differences there. &lt;br&gt;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. &lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Sushrut</dc:creator><pubDate>Thu, 11 Dec 2008 07:25:50 -0000</pubDate></item></channel></rss>