Home

News: rc3.org: Java is what it is

  1. rc3.org: Java is what it is (119 messages)

    Rafe Colburn has posted "Java is what it is," a blog commenting on the sentiment that "new and interesting work will not be done in Java, nor will it be done on the JVM." According to him, this isn't much of a change - Java's never been all that great of a platform, just one that we've managed to do stuff in.
    Java is what it has always been. It’s cumbersome, the learning curve is steep, and the sheer number of APIs, libraries, application servers, and IDEs is impossible to keep up with. You don’t hire a Java developer, you hire a server-side Java developer with experience in Java Server Faces, WebSphere, and EJB, or a developer who knows Eclipse, Tomcat, Hibernate, and Spring. The most interesting stuff has never been going on in the Java community. Yes, some big, important applications have been written on the Java platform but by and large, the most innovative stuff happens elsewhere. The main focus of innovation in the Java world has been in making it easier to deal with Java. There’s a reason why Java development tools like Eclipse and IDEA are awesome — they have to be in order to enable people to work productively in Java. Likewise for many of the frameworks people have built for creating Web applications in Java. Without them we would have all gone insane.
    Ouch! The discussion started with Russell Beattie:
    ...many of today’s current hot trends in programming are a direct result of a backlash against everything that Java has come to represent: Lengthy code and slow development being the first and foremost on the list. In Java you generally need hundreds of lines of code to do what modern scripting languages do in dozens (or less). The general up tick in interest in Ruby, Python and PHP during the 2000s all has its roots in programmers who had to work on one Java project too many, and were desperate to find something more efficient and less painful to use. You all know the story - less XML and cleaner, leaner code - and once you’ve experienced it, believe me, you won’t go back.
    Russell's close to the mark here, honestly. While having a distinct (and thus verbose) syntax is good sometimes, it can also be a problem long-term - consider the "write-only" nature of Perl for people who aren't really parrotheads. (Experts in Perl are able to decipher write-only code, by virtue of their expertise.) Ruby's syntax can be seen as either more expressive (by those who know it) or less expressive (by those who don't). That said, Ruby is arguably more powerful than Java - not only by virtue of its syntax, but in the nature of its runtime libraries, which are far more able to react than Java's runtime library is. (Ruby's runtime library can be added to without the JCP, for example.) The assertion here, however, is that not only is Java the language an archaism comparable to COBOL, but the platform, too, is archaic. This means that JRuby, Groovy, and Jython aren't being seen as relevant; what do you think? Are there enough integration points to make the platform worthwhile? Is the assertion about the Java language accurate? Where do you think the future is, and why has Java been as successful as it has been, considering that expressive script languages predate Java yet hadn't overtaken it? Even more importantly - why did Java ascend when it did?

    Threaded Messages (119)

  2. Excellent post for TSS. Thread will be long with lots of eyeballs... and I'll bite first. Needless to say this has been beaten to death already. According to some (like the author of the post) Java (as a language or as a platform) has been rapidly “dieing” for the last 3-4 years. It should have been dead by now :-) and we should all have been switched to a new reincarnation of Perl “write-once” programming model. It didn't happen, of course. Java has an absolute grip on non-Microsoft enterprise software development and it has plenty of well known explanations. There always going to be some alarmists or disavowed newcomers screaming that the grass is greener on the other side. Software engineering field is littered with “innovations” and flavor of the day technologies over the decades. Most of the them died, rather naturally. Java is the best ecosystem today for enterprise software development. The only close competitor is .NET and in my opinion Java is winning rather handily. It is not ideal but it has been improving steadily while being stable and maintaining its elegance – and that's one of they keys to its success. Nikita Ivanov. GridGain - Grid Computing Made Simple
  3. Re: rc3.org: Java is what it is[ Go to top ]

    I really think the whole "Java sucks" mantra comes from 4 groups of people: 1) Those with an agenda, 2) Those who just like to whine, 3) Those who are ivory tower academic types searching for utopia, and 4) Those who have to deal with the horrific complexities some portions of the Java community have created in certain problem domains. I think the first 3 groups should simply be told to shut up and summarily ignored. In the last case, however, I think it is critical to distinguish between Java the language/VM and the complexities various interests have created in certain domains. For instance, I don't see Java as broken in [D]HTML/AJAX web space, but most of the Java frameworks created for this space reek of over-engineering. Similarly EJB specs until 3.0 were a complete mess. This wasn't a fault of Java, just a host of interests, corporate and otherwise, who were keen on complexity and over-engineering for various reasons. It is possible Java is not the best language for all domains -- it is after all a general purpose language. That said, I can't see someone *maintaining* a multi-million line application for many years written in a dynamic language without any compile-time type safety either.
  4. Totally agreed! It's hard to keep up with the step of Java. However, it's very important for Java to make progress everyday, otherwise, will be beated by its competitor (.NET) . java Development
  5. Acceptable.[ Go to top ]

    I, for one, would welcome the end of Java (now mentioned for the 1,000,000th time), if it guarantees the end of TSS, and its flame-bait posts referencing idiotic bloggers. Roy Russo http://www.loopfuse.com
  6. Re: Acceptable.[ Go to top ]

    I, for one, would welcome the end of Java (now mentioned for the 1,000,000th time), if it guarantees the end of TSS, and its flame-bait posts referencing idiotic bloggers.

    Roy Russo
    http://www.loopfuse.com
    Roy... did you ever consider *why* people keep saying Java is the new COBOL or Java's dead or Java as a platform sucks or whatever? I'm not necessarily agreeing with the sentiment - hey, I use Java all the time - but the sentiment keeps coming up. It's either not being answered well or it's correct. Pick one. Now fix it.
  7. Re: Acceptable.[ Go to top ]

    Roy... did you ever consider *why* people keep saying Java is the new COBOL or Java's dead or Java as a platform sucks or whatever?
    Because they're pushing their own agenda? When I start seeing empirical data that Java truly is dieing, then I'll listen (RoR/PHP growing != Java dieing). Until then, we should all dismiss this as sensationalist news coverage about a guy with a brain fart. Frankly Joe, I think its your duty as a journalist to be as critical in thought as your educated readers. I think you owe it to everyone on here. Then again, TSS survives on ad-revenue, and I don't want to see you guys go under. ;-) Roy Russo http://www.loopfuse.com
  8. Re: Acceptable.[ Go to top ]

    Roy... did you ever consider *why* people keep saying Java is the new COBOL or Java's dead or Java as a platform sucks or whatever?
    Because they're pushing their own agenda? When I start seeing empirical data that Java truly is dieing, then I'll listen (RoR/PHP growing != Java dieing). Until then, we should all dismiss this as sensationalist news coverage about a guy with a brain fart. Frankly Joe, I think its your duty as a journalist to be as critical in thought as your educated readers. I think you owe it to everyone on here. Then again, TSS survives on ad-revenue, and I don't want to see you guys go under. ;-) Roy Russo
    http://www.loopfuse.com
    Roy, did you actually read what I wrote? Or just the blockquotes?
  9. Re: Acceptable.[ Go to top ]

    It's either not being answered well or it's correct. Pick one. Now fix it.
    Lets analyze the nonsense: Q: 1. Everything that can be invented has already been invented in Java. 2. Java is too difficult to use. 3. The API is "too big". 4. I make little websites using PHP and RoR, why use Java? A: 1. I'm sure they innovate a lot more in the RoR world - when you start from ZERO, its easy to reach 1. Lets applaud RoR for reaching "1". 2. Go code some PHP (get hacked). Go code some RoR (how's that app with 100,000 concurrent users looking for you now?) 3. The engine in my '68 Chevelle is bigger than in my Civic. (Chicks really dig the Civic with purple lights and shiny rims.) 4. You probably shouldn't. If you prototyping or putting together some shiny web-too-dot-oh site, then, by all means use RoR, Perl, PHP. I would say thats a wise move. So its the same old tired arguments. I can tell you from personal experience, when we started LoopFuse, we investigated RoR and PHP as alternate base languages. However, we wanted our application to actually scale, perform, and grow comfortably. We employed best-of-breed technologies: Hibernate, JBoss AS/Clustering/Cache, JSF, Richface/AJAX4J, etc... I would think that for most enterprises looking to produce a quality and scalable product, they will gladly sacrifice a shorter development time for increased security and robustness (and possibly commercial support and service offerings). ... and so it goes. I fell for Joe's trap once again. Roy Russo http://www.loopfuse.com
  10. Re: Acceptable.[ Go to top ]

    did you ever consider *why* people keep saying Java is the new COBOL or Java's dead or Java as a platform sucks or whatever? I'm not necessarily agreeing with the sentiment - hey, I use Java all the time - but the sentiment keeps coming up. It's either not being answered well or it's correct. Pick one. Now fix it.
    I don't think it's either. It keeps coming up because Java is the top dog and people have an inherent desire to find something better and explore the other options. If it was correct, one of the other options would have surged into the lead. If it was not answered well, it would be declining as people jump ship. But neither happens. We're at a steady state where people try to find criticisms of Java. Most criticisms are unsound. A few are sound and they generally get addressed. The reason java has had such staying power is that unlike other communities, java users are motivated by the objective measures of success that business require them to have. Java doesn't let fanboys run amok like some of the other languages. We LISTEN to the valid criticisms and fix them -- that's why Java has the biggest mind share of any single language. They said java was slow, massive investements were made and it sped up. They said EJB was bloated, so spring and hibernate gained favor. They said development was hard, so we created Eclipse and IDEA. They said Struts 1 had problems, so a host of next generation tools appeared. Struts liked one of the better and adopted it as Struts 2. SpringMVC rolled. JSF appeared. Very few other communities receive so much criticism. Believe me they WOULD if they had java's mindshare. (Take Ruby: slow, no spec, no open standards, write-once, excessive use of symbols, crappy app servers, web framework too "opinionated", really really slow, etc...) Java remains on top because when the criticism is valid, we fix it. Others respond by raising the fanboy volume.
  11. Duhh![ Go to top ]

    I, for one, would welcome the end of Java (now mentioned for the 1,000,000th time), if it guarantees the end of TSS, and its flame-bait posts referencing idiotic bloggers.

    Roy Russo
    http://www.loopfuse.com
    Roy... did you ever consider *why* people keep saying Java is the new COBOL or Java's dead or Java as a platform sucks or whatever? I'm not necessarily agreeing with the sentiment - hey, I use Java all the time - but the sentiment keeps coming up. It's either not being answered well or it's correct. Pick one. Now fix it.
    Maybe there are people who just like to complain and will never be happy with anything, in opposition to those who get work done.
  12. Re: Acceptable.[ Go to top ]

    I, for one, would welcome the end of Java (now mentioned for the 1,000,000th time), if it guarantees the end of TSS, and its flame-bait posts referencing idiotic bloggers.

    Roy Russo
    http://www.loopfuse.com
    TSS will die when people stop reading and posting. There must be someone holding a gun to your head forcing you to read this and post to the thread.
  13. Re: Acceptable.[ Go to top ]

    TSS will die when people stop reading and posting. There must be someone holding a gun to your head forcing you to read this and post to the thread.
    I fell for Joe's bait. He pulls the same stunt every few months.
  14. Re: Acceptable.[ Go to top ]

    I, for one, would welcome the end of Java (now mentioned for the 1,000,000th time), if it guarantees the end of TSS, and its flame-bait posts referencing idiotic bloggers.

    Roy Russo
    http://www.loopfuse.com
    I second that.
  15. I am still waiting for the magic "platform" that requires a low learning curve and has very few APIs that are standard and quite perfect. With this platform I can build anything from space ship software to coffee machine controllers. I am convinced that Java can't do it! That language is already here, and it's called Assembler.
  16. Re: rc3.org: Java is what it is[ Go to top ]

    I am still waiting for the magic "platform" that requires a low learning curve and has very few APIs that are standard and quite perfect. With this platform I can build anything from space ship software to coffee machine controllers. I am convinced that Java can't do it! That language is already here, and it's called Assembler.
    Or it's called Lisp...although I'm not sure anyone has ever used it for a coffee machine.
  17. Java is powerful[ Go to top ]

    Assembler is eady to learn, but hard to use. Java Development
  18. Yeah, right...[ Go to top ]

    ... Java is dead, Linux is a gaming platform and the earth is flat. Hoogla Boogla
  19. everything that is not java looks like a streaming pile of you know what to me, I pitty the fool that steels my juwelery
  20. Hi, I was trying to keep out of this one for once, but I read this in the "Future of Java" link on Rafe Colburns blog post:
    At one point I thought I hated programming because I was just so sick it... It turns out I don't hate programming, I just hate programming in Java.
    I had exactly the same experience. It's uncanny! Paul.
  21. Hi,

    I was trying to keep out of this one for once, but I read this in the "Future of Java" link on Rafe Colburns blog post:

    At one point I thought I hated programming because I was just so sick it... It turns out I don't hate programming, I just hate programming in Java.


    I had exactly the same experience. It's uncanny!

    Paul.
    But does that mean that JRuby, JPython, Groovy have the same issues?
  22. Hi,

    I was trying to keep out of this one for once, but I read this in the "Future of Java" link on Rafe Colburns blog post:

    At one point I thought I hated programming because I was just so sick it... It turns out I don't hate programming, I just hate programming in Java.


    I had exactly the same experience. It's uncanny!

    Paul.
    But does that mean that JRuby, JPython, Groovy have the same issues?
    I don't know. I cam across a presentation by Gilad Bracha a while ago, that clearly shows that the JVM platform is highly coupled to Java-like languages and is not ideal for dynamic languages. So I sort of see JRuby, JPyhton etc as not that significant. If these dynamic languages become as half as popular as Java is today, then they will probably end up with high performance purpose built VMs of their own. For example, I believe YARV (Ruby VM) is due for release early 2008. Paul.
  23. Re: rc3.org: Java is what it is[ Go to top ]

    Paul,
    I don't know. I cam across a presentation by Gilad Bracha a while ago, that clearly shows that the JVM platform is highly coupled to Java-like languages and is not ideal for dynamic languages. So I sort of see JRuby, JPyhton etc as not that significant. If these dynamic languages become as half as popular as Java is today, then they will probably end up with high performance purpose built VMs of their own. For example, I believe YARV (Ruby VM) is due for release early 2008.
    Can we please have a link? Every time someone cites Gilad Bracha and I go read what he actually wrote it turns out to be intelligent, insightful, generally great stuff quoted out of context.
  24. Re: rc3.org: Java is what it is[ Go to top ]

    Paul,

    I don't know. I cam across a presentation by Gilad Bracha a while ago, that clearly shows that the JVM platform is highly coupled to Java-like languages and is not ideal for dynamic languages. So I sort of see JRuby, JPyhton etc as not that significant. If these dynamic languages become as half as popular as Java is today, then they will probably end up with high performance purpose built VMs of their own. For example, I believe YARV (Ruby VM) is due for release early 2008.


    Can we please have a link? Every time someone cites Gilad Bracha and I go read what he actually wrote it turns out to be intelligent, insightful, generally great stuff quoted out of context.
    http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/GiladBracha-final.wmv
  25. Re: rc3.org: Java is what it is[ Go to top ]

    http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/GiladBracha-final.wmv
    That was a really interesting talk. I highly recommend it. Who knew that Gilad Bracha had such a keen sense of humor. Paul, you are a Smalltalk guy right? If so, do you know what's going on with StrongTalk? I've been curious about it but I can't seem to pierce the surface of the information I find. I should probably learn Smalltalk somewhere else I guess.
  26. Re: rc3.org: Java is what it is[ Go to top ]

    I don't know. I cam across a presentation by Gilad Bracha a while ago, that clearly shows that the JVM platform is highly coupled to Java-like languages and is not ideal for dynamic languages. So I sort of see JRuby, JPyhton etc as not that significant. If these dynamic languages become as half as popular as Java is today, then they will probably end up with high performance purpose built VMs of their own. For example, I believe YARV (Ruby VM) is due for release early 2008.

    Paul.
    I just finished downloading it and I'm listening to it now. He doesn't seem to be suggesting that the JVM cannot be adapted to dynamic languages. He's actually saying that the benefits of being able to run specifically Ruby on the JVM with dynamic support could yield huge benefits. He claims that Ruby could easily be 10 times faster than it is native and 50 to 100 times with more work. From my own perspective, I think that a Ruby VM is going to be largely irrelevant unless it gains the industry wide support that Java has. The other huge benefit of a language like JRuby is that companies with a lot of Java can continue to use it. If you have a huge Java code base, changing all at once is not an option. Being able to use the two together creates a way to migrate. Personally, I don't see a whole lot of difference between using C to implement libraries for say Python and using Java to do so. I'm not not convinced that everything should be done in a dynamic language.
  27. Re: rc3.org: Java is what it is[ Go to top ]

    I don't know. I cam across a presentation by Gilad Bracha a while ago, that clearly shows that the JVM platform is highly coupled to Java-like languages and is not ideal for dynamic languages. So I sort of see JRuby, JPyhton etc as not that significant. If these dynamic languages become as half as popular as Java is today, then they will probably end up with high performance purpose built VMs of their own. For example, I believe YARV (Ruby VM) is due for release early 2008.

    Paul.


    I just finished downloading it and I'm listening to it now. He doesn't seem to be suggesting that the JVM cannot be adapted to dynamic languages. He's actually saying that the benefits of being able to run specifically Ruby on the JVM with dynamic support could yield huge benefits. He claims that Ruby could easily be 10 times faster than it is native and 50 to 100 times with more work.

    From my own perspective, I think that a Ruby VM is going to be largely irrelevant unless it gains the industry wide support that Java has. The other huge benefit of a language like JRuby is that companies with a lot of Java can continue to use it. If you have a huge Java code base, changing all at once is not an option. Being able to use the two together creates a way to migrate. Personally, I don't see a whole lot of difference between using C to implement libraries for say Python and using Java to do so. I'm not not convinced that everything should be done in a dynamic language.
    Hi James, I really don't know whats going to happen here, and I've never tried JRuby so it's impossible for me to form an opinion. Today JRuby is about the same speed as the MRI (Matz Ruby Interpreter) which is notoriously slow. With optimisation then yes JRuby would be faster - but that isn't much of an achievement. A specialist dynamic VM would be much faster still. BTW I believe that YARV will execute Ruby source code, by doing ahead of time compilation to byte code at runtime, so unlike Java and the JVM, the runtime platform will interpret Ruby source not bytecode. So Ruby code will be portable amongst competing Ruby implementations (JRuby, YARV etc) without a re-compile (I think). I agree we don't want to use a dynamic language for everything. I also agree that we don't want to replace one type of lock-in with another. The key here I believe is language choice. Paul.
  28. Re: rc3.org: Java is what it is[ Go to top ]

    I don't know. I cam across a presentation by Gilad Bracha a while ago, that clearly shows that the JVM platform is highly coupled to Java-like languages and is not ideal for dynamic languages. So I sort of see JRuby, JPyhton etc as not that significant. If these dynamic languages become as half as popular as Java is today, then they will probably end up with high performance purpose built VMs of their own. For example, I believe YARV (Ruby VM) is due for release early 2008.

    Paul.


    I just finished downloading it and I'm listening to it now. He doesn't seem to be suggesting that the JVM cannot be adapted to dynamic languages. He's actually saying that the benefits of being able to run specifically Ruby on the JVM with dynamic support could yield huge benefits. He claims that Ruby could easily be 10 times faster than it is native and 50 to 100 times with more work.

    From my own perspective, I think that a Ruby VM is going to be largely irrelevant unless it gains the industry wide support that Java has. The other huge benefit of a language like JRuby is that companies with a lot of Java can continue to use it. If you have a huge Java code base, changing all at once is not an option. Being able to use the two together creates a way to migrate. Personally, I don't see a whole lot of difference between using C to implement libraries for say Python and using Java to do so. I'm not not convinced that everything should be done in a dynamic language.

    Hi James,

    I really don't know whats going to happen here, and I've never tried JRuby so it's impossible for me to form an opinion. Today JRuby is about the same speed as the MRI (Matz Ruby Interpreter) which is notoriously slow. With optimisation then yes JRuby would be faster - but that isn't much of an achievement. A specialist dynamic VM would be much faster still. BTW I believe that YARV will execute Ruby source code, by doing ahead of time compilation to byte code at runtime, so unlike Java and the JVM, the runtime platform will interpret Ruby source not bytecode. So Ruby code will be portable amongst competing Ruby implementations (JRuby, YARV etc) without a re-compile (I think).

    I agree we don't want to use a dynamic language for everything. I also agree that we don't want to replace one type of lock-in with another. The key here I believe is language choice.

    Paul.
    BTW. The low level core Ruby APIs and many Ruby libraries are currently implemented in C - a static language (I believe Python does the same). With YARV I believe this will remain the same. Although there should be less reasons to use C for performance. Paul.
  29. Re: rc3.org: Java is what it is[ Go to top ]

    Hi James,

    I really don't know whats going to happen here, and I've never tried JRuby so it's impossible for me to form an opinion. Today JRuby is about the same speed as the MRI (Matz Ruby Interpreter) which is notoriously slow. With optimisation then yes JRuby would be faster - but that isn't much of an achievement. A specialist dynamic VM would be much faster still. BTW I believe that YARV will execute Ruby source code, by doing ahead of time compilation to byte code at runtime, so unlike Java and the JVM, the runtime platform will interpret Ruby source not bytecode. So Ruby code will be portable amongst competing Ruby implementations (JRuby, YARV etc) without a re-compile (I think).

    I agree we don't want to use a dynamic language for everything. I also agree that we don't want to replace one type of lock-in with another. The key here I believe is language choice.

    Paul.
    I don't make any claims to the correctness of his statements but Gilad Bracha makes a number of comments about how a modified JVM would 'likely be much better' than the scripting version. He basically says that the JVM has some capabilities that dynamic languages can't really use because it doesn't support invokedynamic. He says they are committed to implement this. In terms of portability, I don't think that's an issue. For example, when I work with Jython, I always deliver Python source and execute it. The Jython interpreter compiles it on the fly (and recompiles if it changes.) You could precompile it if you like and I can imagine there are cases one might want to inside a closed environment but it's not necessary at all. Honestly, I can see any downside to an improved JVM for dynamic languages. It will only make them more appealing and increase adoption. In the end, as long as everything is compatible, what you use under the hood will only matter to nerds like us who love to argue about this kind of stuff.
  30. Re: rc3.org: Java is what it is[ Go to top ]

    Hi James,

    I really don't know whats going to happen here, and I've never tried JRuby so it's impossible for me to form an opinion. Today JRuby is about the same speed as the MRI (Matz Ruby Interpreter) which is notoriously slow. With optimisation then yes JRuby would be faster - but that isn't much of an achievement. A specialist dynamic VM would be much faster still. BTW I believe that YARV will execute Ruby source code, by doing ahead of time compilation to byte code at runtime, so unlike Java and the JVM, the runtime platform will interpret Ruby source not bytecode. So Ruby code will be portable amongst competing Ruby implementations (JRuby, YARV etc) without a re-compile (I think).

    I agree we don't want to use a dynamic language for everything. I also agree that we don't want to replace one type of lock-in with another. The key here I believe is language choice.

    Paul.


    I don't make any claims to the correctness of his statements but Gilad Bracha makes a number of comments about how a modified JVM would 'likely be much better' than the scripting version. He basically says that the JVM has some capabilities that dynamic languages can't really use because it doesn't support invokedynamic. He says they are committed to implement this.

    In terms of portability, I don't think that's an issue. For example, when I work with Jython, I always deliver Python source and execute it. The Jython interpreter compiles it on the fly (and recompiles if it changes.) You could precompile it if you like and I can imagine there are cases one might want to inside a closed environment but it's not necessary at all.

    Honestly, I can see any downside to an improved JVM for dynamic languages. It will only make them more appealing and increase adoption. In the end, as long as everything is compatible, what you use under the hood will only matter to nerds like us who love to argue about this kind of stuff.
    I Agree. JRuby, Jython, Groovy etc. increase the choices available which can only be a good thing. BTW. If you want to learn Smalltalk, then I wouldn't start with Strongtalk. The choices of Smalltalk reduced the other day. Dolphin Smalltalk a windows only dialect finally bit the dust. I would still recommend it though as a learning tool ( I believe you can still download a free version). VW Smalltalk is another good option for learning and I believe they do a free non-commercial option aswell. If you feel a bit braver there is always Squeak with is the leading open source Smalltalk. Squeak is a bit unconventional though and basically wants to be an OS rather then an IDE so you may find it confusing. Google and you'll find links to all of these. As for Strongtalk, I believe it is languishing as an open source project. Not enough interest! Regards, Paul.
  31. Re: rc3.org: Java is what it is[ Go to top ]

    Hi James,

    I really don't know whats going to happen here, and I've never tried JRuby so it's impossible for me to form an opinion. Today JRuby is about the same speed as the MRI (Matz Ruby Interpreter) which is notoriously slow. With optimisation then yes JRuby would be faster - but that isn't much of an achievement. A specialist dynamic VM would be much faster still. BTW I believe that YARV will execute Ruby source code, by doing ahead of time compilation to byte code at runtime, so unlike Java and the JVM, the runtime platform will interpret Ruby source not bytecode. So Ruby code will be portable amongst competing Ruby implementations (JRuby, YARV etc) without a re-compile (I think).

    I agree we don't want to use a dynamic language for everything. I also agree that we don't want to replace one type of lock-in with another. The key here I believe is language choice.

    Paul.


    I don't make any claims to the correctness of his statements but Gilad Bracha makes a number of comments about how a modified JVM would 'likely be much better' than the scripting version. He basically says that the JVM has some capabilities that dynamic languages can't really use because it doesn't support invokedynamic. He says they are committed to implement this.

    In terms of portability, I don't think that's an issue. For example, when I work with Jython, I always deliver Python source and execute it. The Jython interpreter compiles it on the fly (and recompiles if it changes.) You could precompile it if you like and I can imagine there are cases one might want to inside a closed environment but it's not necessary at all.

    Honestly, I can see any downside to an improved JVM for dynamic languages. It will only make them more appealing and increase adoption. In the end, as long as everything is compatible, what you use under the hood will only matter to nerds like us who love to argue about this kind of stuff.


    I Agree.

    JRuby, Jython, Groovy etc. increase the choices available which can only be a good thing.

    BTW. If you want to learn Smalltalk, then I wouldn't start with Strongtalk. The choices of Smalltalk reduced the other day. Dolphin Smalltalk a windows only dialect finally bit the dust. I would still recommend it though as a learning tool ( I believe you can still download a free version).

    VW Smalltalk is another good option for learning and I believe they do a free non-commercial option aswell.

    If you feel a bit braver there is always Squeak with is the leading open source Smalltalk. Squeak is a bit unconventional though and basically wants to be an OS rather then an IDE so you may find it confusing.
    I tend to prefer to start off with a simpler form of a language (or at least constrain myself to that) until I become comfortable. Have you seen this? http://web.engr.oregonstate.edu/%7Ebudd/SmallWorld/ReadMe.html I've found that over time I've tended to use maps for more and more things in Java. They allow for a lot of techniques that are just too hard to implement in Java with static code. Working with Python confirmed this but I'm getting annoyed with all of its warts. I understand that a lot of people think that Lisp and/or Smalltalk are the best languages ever created. Why do you think it is that these languages remain as niche tools? Is it that performance was holding them back? If so perhaps that's why these languages or at least the paradigms they created are becoming more relevant.
  32. Re: rc3.org: Java is what it is[ Go to top ]

    I've found that over time I've tended to use maps for more and more things in Java. They allow for a lot of techniques that are just too hard to implement in Java with static code.
    What kind of applications do you build?
  33. Re: rc3.org: Java is what it is[ Go to top ]

    I understand that a lot of people think that Lisp and/or Smalltalk are the best languages ever created. Why do you think it is that these languages remain as niche tools? Is it that performance was holding them back? If so perhaps that's why these languages or at least the paradigms they created are becoming more relevant.
    Hi James, Lots of reasons. Some of which have been clearly illustrated in this thread :^) Goods ideas are eternal, so they are bound to find their way through eventually. People tend to forget that automatic memory management was seen as esoteric until Java 'borrowed' the idea from Smalltalk. Also using a VM and bytecode was seen as obviously inefficient and scorned upon by C++ers for years until Java made the idea acceptable. Ignorance plays it's part too. The JVM has been praised, but how many people know that that the JVM JIT was developed by a bunch of Smalltalkers who 'invented' the idea with Self and Strongtalk? Developers are lazy and generally do not like change. Most have followed the confortable C/Unix path. One of Ruby's strengths is that it plays well in the Unix ecosystem which is why it is likely to succeed where Smalltalk failed. IMO we tend to get the technology we deserve, and the vendors have mostly taken the safe root. With open source things are changing. Paul.
  34. Re: rc3.org: Java is what it is[ Go to top ]

    Also using a VM and bytecode was seen as obviously inefficient and scorned upon by C++ers for years until Java made the idea acceptable. Ignorance plays it's part too. The JVM has been praised, but how many people know that that the JVM JIT was developed by a bunch of Smalltalkers who 'invented' the idea with Self and Strongtalk?
    No, Java didn't invent garbage collection, the VM, JIT, or bytecode. But, IMO, without Java we wouldn't have had the advances we've had in VM technology. The widespread popularity of Java justified the amount of money poured into improving the JVM so you could use Java for performance intensive logic.
  35. Re: rc3.org: Java is what it is[ Go to top ]

    No, Java didn't invent garbage collection, the VM, JIT, or bytecode. But, IMO, without Java we wouldn't have had the advances we've had in VM technology. The widespread popularity of Java justified the amount of money poured into improving the JVM so you could use Java for performance intensive logic.
    I think if you look at the history of the JVM, Java was more a means of monetizing/popularizing advancements in VM technologies made in Strongtalk and Self than the source of the advancements. Maybe it would be more appropriate to say that advancements made in VM technology would never have been productionized sufficiently for large scale systems without the investment that Java enabled.
  36. Re: rc3.org: Java is what it is[ Go to top ]

    I understand that a lot of people think that Lisp and/or Smalltalk are the best languages ever created. Why do you think it is that these languages remain as niche tools? Is it that performance was holding them back? If so perhaps that's why these languages or at least the paradigms they created are becoming more relevant.
    I think you've mentioned some of the problem in another thread. An attitude prevails that the lower level you code, the better your skills are. As a result, it's macho (in a geeky way) to work in languages "close to the metal": "Wow, I can use "register" in C for my index variable whenever I have to iterate through an array! My program will run really fast!" (Of course, the flip side is the register keyword is only a hint to the compiler, which may blissfully ignore the suggestion.) As the systems we write become larger and more complicated while the timeframe for delivery gets shorter, we need to move away from the metal by using languages that express a solution to the business/science problem more concisely and with good abstractions. Managing resources like memory; having to provide iteration routines for collections; these things get in the way of solving problems. This, in part, is a reason we're looking towards languages that provide higher level mechanisms. Another part of the reason we're looking back to the future with Lisp and Smalltalk is that many of us are looking for languages that cause us less work. The next time I ENJOY debugging a memory leak, dangling pointer, or smashed buffer will be the first time. One more thought occurs to me. As hardware has become so much faster and now with parallelization available, many of the performance issues of Lisp and Smalltalk have likely gone away. For my own part, I'm looking into Scala currently and intend to look into Scheme and Erlang in that order in the near future. At some point, I'd like to check out Haskell and there's a language called E that's taking an interesting approach to asynchronous processing. Oh well, as always only my $0.02.
  37. Re: rc3.org: Java is what it is[ Go to top ]

    One more thought occurs to me. As hardware has become so much faster and now with parallelization available, many of the performance issues of Lisp and Smalltalk have likely gone away.
    I actually think most Lisp and Smalltalk implementation are behind when it comes to parallelisation.
    For my own part, I'm looking into Scala currently and intend to look into Scheme and Erlang in that order in the near future. At some point, I'd like to check out Haskell and there's a language called E that's taking an interesting approach to asynchronous processing.
    If you're curious, I've been trying to sort out what makes a language "productive" and recently did a blog entry comparing Lisp and Scala for the GPS program from Chapter for of PAIP. http://erikengbrecht.blogspot.com/2007/08/scala-vs-lisp-for-gps-part-i.html
  38. Re: rc3.org: Java is what it is[ Go to top ]

    If you're curious, I've been trying to sort out what makes a language "productive" and recently did a blog entry comparing Lisp and Scala for the GPS program from Chapter for of PAIP.

    http://erikengbrecht.blogspot.com/2007/08/scala-vs-lisp-for-gps-part-i.html
    Definitely curious and checking it out now. Thank you Erik.
  39. Re: rc3.org: Java is what it is[ Go to top ]

    I don't know. I cam across a presentation by Gilad Bracha a while ago, that clearly shows that the JVM platform is highly coupled to Java-like languages and is not ideal for dynamic languages. So I sort of see JRuby, JPyhton etc as not that significant. If these dynamic languages become as half as popular as Java is today, then they will probably end up with high performance purpose built VMs of their own. For example, I believe YARV (Ruby VM) is due for release early 2008.
    Did we watch the same presentation? It seemed to me that he was pretty enthusiastic about what the JVM could bring to dynamic languages with some extension, some of it minor (invokedynamic) and to be delivered in the next version of Java. As for class hotswapping, his proposal seemed very reasonable but I have mixed feelings about it. Changing code "live" during development can be very useful, but the truth is I don't classes magically changing at runtime (especially post class loading).
  40. Re: rc3.org: Java is what it is[ Go to top ]

    I don't know. I cam across a presentation by Gilad Bracha a while ago, that clearly shows that the JVM platform is highly coupled to Java-like languages and is not ideal for dynamic languages. So I sort of see JRuby, JPyhton etc as not that significant. If these dynamic languages become as half as popular as Java is today, then they will probably end up with high performance purpose built VMs of their own. For example, I believe YARV (Ruby VM) is due for release early 2008.


    Did we watch the same presentation? It seemed to me that he was pretty enthusiastic about what the JVM could bring to dynamic languages with some extension, some of it minor (invokedynamic) and to be delivered in the next version of Java.

    As for class hotswapping, his proposal seemed very reasonable but I have mixed feelings about it. Changing code "live" during development can be very useful, but the truth is I don't classes magically changing at runtime (especially post class loading).
    Hi Eric, At the time he was still working for Sun, and he was comparing the possiblities of of the JVM versus open source interpreters, and yes I agree he was optomistic and I am optomistic too. Ask Gilad to compare the JVM to a dynamic VM like Strongtalk for example, when it comes to running dynamic code, and you would get a completely different response. So yes, the JVM with it's millions of dollars price tag can compete well, with the Matz Ruby Interpreter, but it wouldn't stand a chance against a purpose built dynamic VM with or without "invokedynamic". If you follow the technical details in the presentation, Gilad makes it clear why. It's not just the JVM, the CLR suffers from the same limitations too. In the same series of presentations there is a detailed description of Ruby running on the CLR, and Gilad makes it clear that the same limitations apply to the JVM. To explain why in detail, would take longer then I'm willing to spend here, but yes JVM versus MRI is credible, but JVM versus YARV or Strongtalk or any purpose built dynamic VM is no match, when it comes to running a dynamic language like Ruby. Paul.
  41. Re: rc3.org: Java is what it is[ Go to top ]

    To explain why in detail, would take longer then I'm willing to spend here, but yes JVM versus MRI is credible, but JVM versus YARV or Strongtalk or any purpose built dynamic VM is no match, when it comes to running a dynamic language like Ruby.

    Paul.
    That's reasonable. But, by chance, do you know of any (no subscription) references that you could point us to?
  42. Re: rc3.org: Java is what it is[ Go to top ]

    I have no idea why people keep saying Java is dying? I see it nowhere and anytime soon. I am not a Java geek or whatsoever but I just pick the best tool for my job. The very first thing that I think of a language though is the scalability of the entire platform. Software Development is not something like "I can make my own game" century. A single piece of software can involve more than tons of programmers, analysts, designers and even business! When see dotNET out there, all I see is a team of individual programmers who work on their own. When business hears dotNET in middleware, they just shake their heads and want something else cuz Blue Screen still scares people away, you know. For business applications, the thing that I have seen so far, correct me if I am wrong, is reliability with scalability in which business people need a platform rather than just one language. Web 2.0 towards the direction of becoming a platform instead of just a content publishing site. I believe you have to take that into account that RoR/PHP cannot really do the job for enterprise.
  43. Re: rc3.org: Java is what it is[ Go to top ]

    To explain why in detail, would take longer then I'm willing to spend here, but yes JVM versus MRI is credible, but JVM versus YARV or Strongtalk or any purpose built dynamic VM is no match, when it comes to running a dynamic language like Ruby.
    I'll assume he brought these issues up and I just missed them...I prefer transcripts... http://groups.google.com/group/strongtalk-general/browse_thread/thread/27acebc398a6db53/c3dc3bc4e6054a89?lnk=st&q=strongtalk+jvm&rnum=4# None of these are really "the JVM can't be made to do X..." type arguments. They are all "the JVM won't be made to do X..." type arguments. So it's a technical argument for why the JVM is ill-suited today, and a crystal-ball reading argument for why it won't be in the future. Given that YARV are Strongtalk are still betaware, and the MRI Ruby interpretter to far to unstable for any intensive task, I'll place my money on the JVM being production-ready with the features over YARV or Strongtalk being production-ready with them. The class verified issue is also a very, very interesting one. I imagine it would be relatively straightforward to make it "optional," but as he points out that has all sorts of issues. It breaks the strong security model (something ENTIRELY MISSING from dynamic language VMs) which results in a very interesting engineering trade.
  44. Re: rc3.org: Java is what it is[ Go to top ]

    To explain why in detail, would take longer then I'm willing to spend here, but yes JVM versus MRI is credible, but JVM versus YARV or Strongtalk or any purpose built dynamic VM is no match, when it comes to running a dynamic language like Ruby.


    I'll assume he brought these issues up and I just missed them...I prefer transcripts...

    http://groups.google.com/group/strongtalk-general/browse_thread/thread/27acebc398a6db53/c3dc3bc4e6054a89?lnk=st&q=strongtalk+jvm&rnum=4#

    None of these are really "the JVM can't be made to do X..." type arguments. They are all "the JVM won't be made to do X..." type arguments. So it's a technical argument for why the JVM is ill-suited today, and a crystal-ball reading argument for why it won't be in the future.

    Given that YARV are Strongtalk are still betaware, and the MRI Ruby interpretter to far to unstable for any intensive task, I'll place my money on the JVM being production-ready with the features over YARV or Strongtalk being production-ready with them.

    The class verified issue is also a very, very interesting one. I imagine it would be relatively straightforward to make it "optional," but as he points out that has all sorts of issues. It breaks the strong security model (something ENTIRELY MISSING from dynamic language VMs) which results in a very interesting engineering trade.
    Hi Eric, The VW Smalltalk VM is prodution ready and Ruby would definately run faster on that. I would hazard a guess that even the Squeak VM would out perform the JVM when it comes to running Ruby code and the Squeak VM isn't even optimised for performance. Why I can say this? Well it comes down to the requirement for a polymorphic message send. This is how Ruby (and Smalltalk and Python) do their dynamic magic. It is basically a method lookup from a method dictionary that occurs at runtime (so James is kind of right, you can do almost anything with an hashmap :^)). For languages like C++ and Java this indirection is optimised out at compile time and replaced by a VTable (this is why Java and C++ are not fully polymorphic like Smalltalk). So if you want to run Ruby on the JVM you need to place back this indirection. The way they do this is to write a dynamic VM on top of the JVM in Java. So with JRuby your Ruby code is run on Java not the JVM. This is why Sun are working on a common Java library to run dynamic languages. Here is a presentation that shows how it is done on the CLR. The situation is exactly the same on the JVM: http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/JohnGough-RubyOnTheCLR.wmv This presentation was at the same dynamic language symposium as Gilad Bracha's presentation, and Gilad refers to it. You can see the full set of presentations here: http://www.langnetsymposium.com/speakers.asp All I'm saying is that a better solutions then this is sure to appear soon :^) Paul.
  45. Re: rc3.org: Java is what it is[ Go to top ]

    The VW Smalltalk VM is prodution ready and Ruby would definately run faster on that. I would hazard a guess that even the Squeak VM would out perform the JVM when it comes to running Ruby code and the Squeak VM isn't even optimised for performance.
    Is anyone even working on porting Ruby to these VMs? You're comparing less than vaporware to existing software.
    Why I can say this? Well it comes down to the requirement for a polymorphic message send. This is how Ruby (and Smalltalk and Python) do their dynamic magic. It is basically a method lookup from a method dictionary that occurs at runtime (so James is kind of right, you can do almost anything with an hashmap :^)). For languages like C++ and Java this indirection is optimised out at compile time and replaced by a VTable (this is why Java and C++ are not fully polymorphic like Smalltalk).
    invokedynamic is for dynamic message sends, as you put it, and I believe it is a planned for Java 7. So in the world on reasonably expected software, the questions are: (1) When will YARV be "enterprise ready?" (2) Will JRuby on Java 7 be faster or slower than YARV? - that covers Ruby - (3) When will StrongTalk be cross-platform and enterprise ready? - that covers SmallTalk - I, personally, have a lot more confidence in Sun and the open-source Java community to support dynamic languages than I do in the Ruby or StrongTalk communities to reach JVM level cross-platform robustness (and performance, in the case of Ruby). In my opinion StrongTalk is on superior technical footing for dynamic languages than the JVM, but they have a long way to go in other areas. I think moving the dynamism of StrongTalk into the JVM will happen more quickly than the StrongTalk VM will become enterprise ready. Based on some quick perusal of the StrongTalk mailing lists I expect open-source JVM code to start migrating back to its progenator. I actually saw some serious discussion of switching to the JVM now that it is open source and porting the necessary pieces of StrongTalk to it. It seems that idea ways killed because maintaining a fork of the JVM would be harder than just borrowing some code for StrongTalk, and Sun+JCP are unlikely to see a merger with the StrongTalk VM as important. Anyway, I bet you see cross-pollination there. A for Ruby, well, it needs to be proven that they can be more stable than the MRI with YARV. I've received the distinct impression that the Ruby interpretter is very unready for intensive tasks from people who have tried and failed to use it that way, and that the Ruby community isn't overly concerned with it. Maybe YARV will chage that, maybe it won't. JRuby does change that and it change it NOW, not at some indeterminate point in the future.
  46. Re: rc3.org: Java is what it is[ Go to top ]

    The VW Smalltalk VM is prodution ready and Ruby would definately run faster on that. I would hazard a guess that even the Squeak VM would out perform the JVM when it comes to running Ruby code and the Squeak VM isn't even optimised for performance.


    Is anyone even working on porting Ruby to these VMs? You're comparing less than vaporware to existing software.

    Why I can say this? Well it comes down to the requirement for a polymorphic message send. This is how Ruby (and Smalltalk and Python) do their dynamic magic. It is basically a method lookup from a method dictionary that occurs at runtime (so James is kind of right, you can do almost anything with an hashmap :^)). For languages like C++ and Java this indirection is optimised out at compile time and replaced by a VTable (this is why Java and C++ are not fully polymorphic like Smalltalk).


    invokedynamic is for dynamic message sends, as you put it, and I believe it is a planned for Java 7.

    So in the world on reasonably expected software, the questions are:
    (1) When will YARV be "enterprise ready?"
    (2) Will JRuby on Java 7 be faster or slower than YARV?
    - that covers Ruby -
    (3) When will StrongTalk be cross-platform and enterprise ready?
    - that covers SmallTalk -

    I, personally, have a lot more confidence in Sun and the open-source Java community to support dynamic languages than I do in the Ruby or StrongTalk communities to reach JVM level cross-platform robustness (and performance, in the case of Ruby).

    In my opinion StrongTalk is on superior technical footing for dynamic languages than the JVM, but they have a long way to go in other areas. I think moving the dynamism of StrongTalk into the JVM will happen more quickly than the StrongTalk VM will become enterprise ready.

    Based on some quick perusal of the StrongTalk mailing lists I expect open-source JVM code to start migrating back to its progenator. I actually saw some serious discussion of switching to the JVM now that it is open source and porting the necessary pieces of StrongTalk to it. It seems that idea ways killed because maintaining a fork of the JVM would be harder than just borrowing some code for StrongTalk, and Sun+JCP are unlikely to see a merger with the StrongTalk VM as important.

    Anyway, I bet you see cross-pollination there.

    A for Ruby, well, it needs to be proven that they can be more stable than the MRI with YARV. I've received the distinct impression that the Ruby interpretter is very unready for intensive tasks from people who have tried and failed to use it that way, and that the Ruby community isn't overly concerned with it. Maybe YARV will chage that, maybe it won't. JRuby does change that and it change it NOW, not at some indeterminate point in the future.
    Hio Erc, You're an old friend. Invokedynamic is just a bytecode. I suggest you watch the presentation. Paul.
  47. Re: rc3.org: Java is what it is[ Go to top ]

    You're an old friend. Invokedynamic is just a bytecode. I suggest you watch the presentation.
    Isn't dynamic dispatch in SmallTalk "just a bytecode?" Maybe I missed something in the presentation. Is there a transcript somehwere? Bracha definately seemed disappointed in the JVM, but aside from the irreversible consequences of allowing type-based method overloading his laments seemed to be more "won't"'s than "can't"'s. I'll take a look at the presentation again and do some more research. I'm having trouble separating long-range speculation about what various parties will and will not do from arguments regarding technical merit. Also, I'm not arguing that SmallTalk VMs aren't better than the JVM at running SmallTalk, and that in their present state they could be better for running Ruby.
  48. Re: rc3.org: Java is what it is[ Go to top ]

    You're an old friend. Invokedynamic is just a bytecode. I suggest you watch the presentation.


    Isn't dynamic dispatch in SmallTalk "just a bytecode?"

    Maybe I missed something in the presentation. Is there a transcript somehwere? Bracha definately seemed disappointed in the JVM, but aside from the irreversible consequences of allowing type-based method overloading his laments seemed to be more "won't"'s than "can't"'s.

    I'll take a look at the presentation again and do some more research. I'm having trouble separating long-range speculation about what various parties will and will not do from arguments regarding technical merit.

    Also, I'm not arguing that SmallTalk VMs aren't better than the JVM at running SmallTalk, and that in their present state they could be better for running Ruby.
    Hi Eric, The "wont's" are all "cant's" because of the need for backward compatibility on the JVM. Remember at the time Gilad headed up the JSR to make the JVM run dynamic code, so hence his diplomatic style. Yes, you could make the JVM great for dynamic code, but It wouldn't run Java bytecode anymore (Fancy recompilng all those Java jars?) :^(. I understand why you find Gilads words a bit confusing. Look at the presentation by John Gough which I provided a link to and Gilad refers to on several occasions. This presentation makes the issues involved painfully clear. http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/JohnGough-RubyOnTheCLR.wmv Paul.
  49. Re: r2d2.org: Java is what it is[ Go to top ]

    At one point I thought I hated programming because I was just so sick it... It turns out I don't hate programming, I just hate programming in Java.
    I had exactly the same experience. It's uncanny!
    And that's the reason, why you are a Java Coach ;-)
  50. Re: r2d2.org: Java is what it is[ Go to top ]

    At one point I thought I hated programming because I was just so sick it... It turns out I don't hate programming, I just hate programming in Java.
    I had exactly the same experience. It's uncanny!
    And that's the reason, why you are a Java Coach ;-)
    Actually, I'm an Agile Coach - but I'm trying to avoid using the label "Agile" nowadays :^). BTW. This is my honest personal experience which I chose to share - just one data point. Why do you find it so offensive? Paul.
  51. Re: r2d2.org: Java is what it is[ Go to top ]

    Actually, I'm an Agile Coach - but I'm trying to avoid using the label "Agile" nowadays :^).
    So, what is a Agile Coach doing at work (no joking)?
    Why do you find it so offensive?
    Well, I thought you are a Java Coach.
  52. Re: rc3.org: Java is what it is[ Go to top ]

    I will agree with the general complaint that the JRE/JDK stack is damn big. Why does a server side JVM have to deal with Swing and AWT classes? But is it too big? The days of 28.8 are long behind us. Everyday users are downloading movies, video, etc that are much larger than a JDK. Client machines are getting JDK updates pushed to them. Operating Systems are having Java loaded onto them on delivery. An issue that troubles me when it comes to complaints about Java is when someone complains about having to write dozens or hundreds of lines of codes for tasks that they do over and over again. The most common example is with date computation issues. I remember being very annoyed with that too. IN 1998! And you know what I did? I wrote some code that did that was annoying at that time. And I haven't had to write it again. Wait until the user communities revolt against the browser. It is going to happen in the near future and AJAX, JSF, JSP, ASP, PHP, RoR,and all the other browser/HTML hacks will start to crumble into dust. John Murray Sobetech
  53. Re: rc3.org: Java is what it is[ Go to top ]

    Personally I see *no* issue whatsoever with the JDK/JRE stack being rather big. Really, what's the problem as long as: (1) it is segmented up so you don't need to download what you're not using in client scenarios -- which is coming real soon now with the kernel VM and (2) things that are really not good to use are deprecated. I do admit that there should be more done along the lines of (2). There should potentially be an even stronger variation of deprecated, e.g. "obsolete", available. Javadoc should have options to filter out deprecated and/or obsolete stuff. Further the JDK/JRE stack should be refactored to put the implementation of deprecated/obsolete stuff into a separate jar where possible and thus lazily loaded by the kernel VM. Otherwise, who cares? Backwards compatibility with existing libraries beats ivory tower purity any day. Breaking this backwards compatibility would split the Java community and cut it off from the wealth of libraries existing in it today.
  54. IMO, open tech + lots of open source + lots of current users = long life. We already see signs of evolution with JRuby and Scala on top of the JVM, and with the opening of the JDK the rate of change is only going to speed up. (More here: http://www.cwinters.com/news/display/3597)
  55. Re: rc3.org: Java is what it is[ Go to top ]

    Java has its problems, no doubt, everything does. One of the largest is that "Java" has come to mean more than just a language; someone called it an ecosystem which is probably appropriate. With that name you talk about a language, platform, and to some extent a framework for browser-based development. Knocking each of these technologies knocks what Java has become. Are we forgetting what it offered developers starting back around 1994? Please let me set perspective. Back in 1994, if you did anything other than 2-tier - GUI to database - development, you "rolled your own". Companies didn't buy application servers on which to provide a middle tier. As far as I remember, there were no commercial application servers, at least none my companies evaluated. Everytime you wanted to provide a middle tier, you wrote it and did all the IPC through sockets in either C or C++. We used serialized objects to communicate between client and server. Serialization didn't come by default in C/C++ libraries: you had to write routines to do it. Communication with a database didn't happen in a standardized API. Each vendor provided their own API that you'd call from C/C++, often basically writing a driver yourself. Returns from the database didn't come in a standardized object with methods for extracting the data you queried. You wrote your own. String libraries were not standard. Your choices were to write or buy one. Developing for *nix meant having to fool with compilation on different environments. While not being a complex task it was tedious and time-consuming. Developing for *nix and DOS/Windows was yet another matter with library differences. The first time I developed a server in a Windows based IDE using a graphical debugger, ftp'ed the class file to AIX, and ran it without any extra fuss, I thought I'd gone to heaven. Java as an ecosystem certainly deserves constructive criticism. However, I'm starting to detect the "demonization" of it that, unfortunately, C++ received 10+ years ago. Certainly another language will evolve to meet current needs while adding polish to some of the add-ons that Java and older languages are sporting. Certainly the development community will move onto it. Let's please keep perspective that Java came around and answered some needs of the time successfully.
  56. Re: rc3.org: Java is what it is[ Go to top ]

    Certainly the development community will move onto it. Let's please keep perspective that Java came around and answered some needs of the time successful
    +1 I totally agree - I remember having to track down memory leaks in C++. It was an absolute nightmare! I don't believe Java is being demonised, what I think is happening is that a lot of people are becoming frustrated because they feel that they have no freedom of choice. In a lot of Java shops Java/J2EE is mandated for everything and you do not get the choice to use anything else even if you feel that another language would be more productive and more appropriate for a given project or sub-system. Paul.
  57. Re: rc3.org: Java is what it is[ Go to top ]

    Certainly the development community will move onto it. Let's please keep perspective that Java came around and answered some needs of the time successful


    +1

    I totally agree - I remember having to track down memory leaks in C++. It was an absolute nightmare!

    I don't believe Java is being demonised, what I think is happening is that a lot of people are becoming frustrated because they feel that they have no freedom of choice.

    In a lot of Java shops Java/J2EE is mandated for everything and you do not get the choice to use anything else even if you feel that another language would be more productive and more appropriate for a given project or sub-system.

    Paul.
    As an example of what I mean, last year we where faced with developing a defect tracking database for defects in a transportation system. The budget for the project ran into hundreds of thousands. My colleague quickly reconised that all the requirements could be readily met by customising Bugzilla. So he hacked together some Perls scripts and created some customised screens and bingo delivered a solution in a fraction of the time and at a fraction of the cost. This solution has been in production successfully for over a year and the users love it. Unfortunately now the IT department are complaining that it is "unsupportable", because it isn't written in a supported language "Java" and doesn't use the strategically selected platform "Websphere". So people are suggesting that we re-write it! This is the type of lunacy that I believe is leading to the frustrations that are popping up in blogs all over the place. Paul.
  58. Re: rc3.org: Java is what it is[ Go to top ]

    This solution has been in production successfully for over a year and the users love it. Unfortunately now the IT department are complaining that it is "unsupportable", because it isn't written in a supported language "Java" and doesn't use the strategically selected platform "Websphere". So people are suggesting that we re-write it!

    This is the type of lunacy that I believe is leading to the frustrations that are popping up in blogs all over the place.

    Paul.
    That really is insane. It makes me wonder how many trillions of dollars, and thousands of years of human development, have been lost due to the stupidity of the few.
  59. Re: rc3.org: Java is what it is[ Go to top ]

    This solution has been in production successfully for over a year and the users love it. Unfortunately now the IT department are complaining that it is "unsupportable", because it isn't written in a supported language "Java" and doesn't use the strategically selected platform "Websphere". So people are suggesting that we re-write it! This is the type of lunacy that I believe is leading to the frustrations that are popping up in blogs all over the place.
    This is a management issue, and whether the tool is Ruby or Blorfle, they'll run into the same problems.
  60. This solution has been in production successfully for over a year and the users love it. Unfortunately now the IT department are complaining that it is "unsupportable", because it isn't written in a supported language "Java" and doesn't use the strategically selected platform "Websphere". So people are suggesting that we re-write it!

    This is the type of lunacy that I believe is leading to the frustrations that are popping up in blogs all over the place.


    This is a management issue, and whether the tool is Ruby or Blorfle, they'll run into the same problems.
    Yes that is the management issue. But try to look at the business side of it. They do not want to create an employee with guaranteed employment. Who would support that Bugzilla customization if the developer would decide that he likes Ruby now? But there is a pool of Java developers out there...
  61. Re: rc3.org: Java is what it is[ Go to top ]

    As an example of what I mean, last year we where faced with developing a defect tracking database for defects in a transportation system. The budget for the project ran into hundreds of thousands.

    My colleague quickly reconised that all the requirements could be readily met by customising Bugzilla. So he hacked together some Perls scripts and created some customised screens and bingo delivered a solution in a fraction of the time and at a fraction of the cost.

    This solution has been in production successfully for over a year and the users love it. Unfortunately now the IT department are complaining that it is "unsupportable", because it isn't written in a supported language "Java" and doesn't use the strategically selected platform "Websphere". So people are suggesting that we re-write it!

    This is the type of lunacy that I believe is leading to the frustrations that are popping up in blogs all over the place.

    Paul.
    This has nothing to do with Java. If your organization had standardized on .NET, your colleague would have exactly the same problem. What you are facing is a business/political problem within your organization, which incidentally happens to use Java, and blaming "Java" for this is missing the point.
  62. Buy JIRA...[ Go to top ]

    as simple as this :). It costs something around $4000 (how much is this? 10 man-days at most?), is written in Java and runs on WS. regards Artur
  63. Re: rc3.org: Java is what it is[ Go to top ]

    As an example of what I mean, last year we where faced with developing a defect tracking database for defects in a transportation system. The budget for the project ran into hundreds of thousands.

    My colleague quickly reconised that all the requirements could be readily met by customising Bugzilla. So he hacked together some Perls scripts and created some customised screens and bingo delivered a solution in a fraction of the time and at a fraction of the cost.

    This solution has been in production successfully for over a year and the users love it. Unfortunately now the IT department are complaining that it is "unsupportable", because it isn't written in a supported language "Java" and doesn't use the strategically selected platform "Websphere". So people are suggesting that we re-write it!

    This is the type of lunacy that I believe is leading to the frustrations that are popping up in blogs all over the place.

    Paul.
    Is this a large corp? In large corporations, the IT department is a MAJOR expense, more than any SW development by miles. The reason for this was identified a long time ago as the vast number of different technologies an IT department typically have to face. So corps will always try to mandate a small number of standard platforms/technologies to give themselves a chance of keeping the complexity under control. If this wasn't a large corp, I guess the CTO heard a talk on IT strategy in large corporations and decided he needed some of that. The rest is hysteria. Kit
  64. Certainly the development community will move onto it. Let's please keep perspective that Java came around and answered some needs of the time successful


    +1

    I totally agree - I remember having to track down memory leaks in C++. It was an absolute nightmare!

    I don't believe Java is being demonised, what I think is happening is that a lot of people are becoming frustrated because they feel that they have no freedom of choice.

    In a lot of Java shops Java/J2EE is mandated for everything and you do not get the choice to use anything else even if you feel that another language would be more productive and more appropriate for a given project or sub-system.

    Paul.


    As an example of what I mean, last year we where faced with developing a defect tracking database for defects in a transportation system. The budget for the project ran into hundreds of thousands.

    My colleague quickly reconised that all the requirements could be readily met by customising Bugzilla. So he hacked together some Perls scripts and created some customised screens and bingo delivered a solution in a fraction of the time and at a fraction of the cost.

    This solution has been in production successfully for over a year and the users love it. Unfortunately now the IT department are complaining that it is "unsupportable", because it isn't written in a supported language "Java" and doesn't use the strategically selected platform "Websphere". So people are suggesting that we re-write it!

    This is the type of lunacy that I believe is leading to the frustrations that are popping up in blogs all over the place.

    Paul.
    there always be guys who are against the system. Against the strategy... I would guess if those people would be the strategy makers, there would be at least one person that could say that they should have selected smthn other than perl! Development of an app does not always account for the whole cost of the system.
  65. Re: rc3.org: Java is what it is[ Go to top ]

    I don't believe Java is being demonised, what I think is happening is that a lot of people are becoming frustrated because they feel that they have no freedom of choice.

    In a lot of Java shops Java/J2EE is mandated for everything and you do not get the choice to use anything else even if you feel that another language would be more productive and more appropriate for a given project or sub-system.

    Paul.
    Developers should absolutely feel frustrated about technology lockin. (It's in the nature of good developers to search for better solutions.) I don't see a solution to that problem other than good developers stepping into management roles. I mostly wanted to convey that I see more successes than failures with Java. I saw a reduction of effort in the programming I did back when Java was in its infancy. I remember a GUI developer I worked with sometime around 1998 being really excited that he could use a standard set of libraries across Windows and *nix. Previously, he was more of a Motif/X expert with some background in the MFC's. Almost overnight he could remove from his bookshelf the entire Motif/X collection (10 books maybe) along with a massive MFC foundation classes text and replace them with a single AWT book - later a Swing book as well. That's a huge load off a developer's plate in terms of knowing the ins and outs of libraries, windowing managers, and OS differences. In terms of what its designers tried to make better about development back in the early 90's, Java succeeded - mostly. Thanks for reminding me, though, that there are people out there facing a different kind of frustration from what mine were. Bill
  66. Re: rc3.org: Java is what it is[ Go to top ]

    Wow, your message is so accurate and describes my work almost perfectly before Java came along.
  67. Re: rc3.org: Java is what it is[ Go to top ]

    Can I see Java dying one day? Yes. But not anytime soon. Java is alive on momentum. Which shouldn't be underestimated -- there is a *ton* of momentum. People know Java, project managers know what to expect from it. We all know it can scale, and we all know more or less what we are getting ourselves into when we start something. New stuff can and will be done in Java. It isn't in its death throes. Part of that momentum is also the ecosystem that surrounds Java. Alfresco, Lucene, Jboss Rules, Quartz, I'd miss them quite a bit if I moved to another language (Jboss Rules especially is not easy to integrate with a non-jvm language). In the end, however, Java doesn't have the "bare metal" advantage that keeps C/C++ going, nor is it the language of choice for operating systems. Thus, it is denied that "free ticket" C/C++ have for seemingly perpetual life. The language is fine, sure. But honestly, Ruby, Python, etc. are a ton more flexible. The JVM could be a different story, however. For now, the various scripting languages on it have plenty of usefulness. I can use Ruby & all my favorite tools. Yay! Think that's not a great advantage? Look at AMD vs Intel. Intel tried to push the Itanium -- a completely new architecture requiring porting. AMD took the x86-64 route, which was compatible with all your old 32-bit apps. Intel was eventually forced to play follow the leader. Farther into the future, the life of the JVM will depend entirely on how well it competes in features & performance with the other various VMs out there, language specific or not. I'm not giddy with optimism -- the JVM has a lot of, lets say, emotional baggage, to overcome with the community. But it would be nice to be able to use a bunch of different languages under a common VM. Honestly, I don't see why this debate is so hard. Look back at Java vs C++. Java was slow, couldn't scale, had horrible tools & libraries, and no one knew it, but was easier & more concise. Today, Ruby/Python/etc. is slow, can't scale, has horrible tools & libraries (sorta), and no one knows it. But it is easier & more concise. We have been through this before.
  68. Re: rc3.org: Java is what it is[ Go to top ]

    Can I see Java dying one day? Yes. But not anytime soon.
    If Java is the new COBOL, it will never go away. Not in our lifetimes.
  69. ...ouw yeah, i'm getting myself convinced that it will be died at soon. And when it shall be died, it must be replaced by its successor along with its fine-easy to use-high productivity oriented tools, yup , i cannot think anything else except point my mind to C# & Visual Studio .NET , hehehehehee...:-D
  70. In Java you generally need hundreds of lines of code to do what modern scripting languages do in dozens (or less). Do you know what a library is? Built-in libraries/behavior into the language syntax is not a good design, because usually they are going to be irrelevant surpassed by new more powerful and customizable libraries. For instance arrays, any language supports native arrays ok it works but sometimes you will need ArrayList, a new Java could integrate ArrayList into the language (changing size arrays) but what is the real advantage? what if you need an automatic distributed ArrayList? what if you need some kind of triggers fired when the array is modified? then you will use a new external library. Built-in libraries are bread for today, hunger for tomorrow (an Spanish very old expression). Another example: the "transient" keyword, this keyword is almost today unused because it was defined to serialization (a feature almost built-in into the language), but these days serialization is not used very much. Say to Gosling that to built-in an ORM into the Java syntax is a very good idea, would have a new "persistent" keyword? an object would be automatically persisted using new?, wow what concise the language is it! (ironic). Most of the "magic" syntax of your preferred scripting language may be replicated in Java (or C++) with a very simple API. An example: - Java: List list = Arrays.asList("Rod","Carlos","Chris"); for (String item : list) if (item.length() <= 4) System.out.println(item); - Groovy def list = ["Rod", "Carlos", "Chris"] list.findAll { it.size() <= 4 }.each { println it } OK Groovy is shorter. - Java + minimal API List list = Arrays.asList("Rod","Carlos","Chris"); list.findAll(list,4); public static void findAll(List list,int val) { for (String item : list) if (item.length() <= val) System.out.println(item); } This new API may be reused again and again... Are they so different? I've read this argument again and again, again and again, but almost nobody talk about the *real* true advantages of scripting: hot code changes, easier setup and deployment, no types (useful for very small programs), AOP easier... no much more. Jose M. Arranz JNIEasy C/C++ in Java.
  71. If the argument for Ruby vs Java vs Python is all about productivity then I don't see that as compelling. Great - that one could code the same algorithm in marginally less keystrokes but I don't see the business advantage. Java when I started was a text editor and basic JDK jobby. I still moved to it because there was a serious cost associated with the platform dependence of C++. Now you can argue away on the success of that one but the net result is that relative to C++, Java IS/WAS more portable and write-once test everywhere was cheaper than write-everywhere test everywhere. Now that portability is less of a headline issue than it was a dozen years ago, what's the productivity gain for the new fangled languages? Is it dynamic typing? Given generics as, I don't see any huge-fold increase in productivity. Also from a design point of view - I'm still going to design based on OOA/OOD. So now my UML tool allows me to design in a language neutral fashion and I use the model driven generator features of the UML tool to drive it into a physical language. So the programming aspect is about algorithms only - I still have to think in terms of objects. So now if the UML tool guys can bring more generators for algorithms into their products.... So why bother? The 10,000 truck that is Java will survive until someone comes up with a compelling alternative... Happy days..
  72. If the argument for Ruby vs Java vs Python is all about productivity then I don't see that as compelling.

    Great - that one could code the same algorithm in marginally less keystrokes but I don't see the business advantage.
    I think this is a fairly big misunderstanding of the difference in productivity. Using a language like Ruby isn't just like programming in Java with less keystrokes. It's that it provides features that don't exist in Java that eliminate a lot of boilerplate and make it easier to reuse code and in some cases it allows for approaches that are just not really feasible in Java. I've tried to explain this same kind of thing to people about the difference between COBOL and Java. I hear a lot of people saying things like 'all languages are the same' and 'you can do all the same things in any language'. Essentially, their feeling is that moving to Java is just adopting a new syntax over COBOL. Paul Graham has a better explanation in his 'blub' essay but it's hard to know how features you don't know exist/understand help you build systems. When I talk to COBOL people, they can't understand what objects are and why they help you. Likewise, it's almost impossible to understand what advantages using a dynamic language provides until you try it. I was once firmly in the static camp. When I would see these threads, I would look at people like Paul Beckford (actually I think it really was Paul) and think they just didn't get it. That they didn't understand the problems of business and the like. One day it occurred to me that I was just being a partisan. I hate partisans so that had to change. I tried out a dynamic language. I'm no expert but I realized it wasn't Paul that didn't get it; it was me. I'm still not of the mind that everything needs to be written in dynamic code but a lot of stuff is better in dynamic code. I would encourage everyone to at least give a dynamic language at try. Python or Ruby and maybe even Ruby are good choices for a start.
  73. Alternative?[ Go to top ]

    What's the alternative? Other than that, would we really have the improvements in VM garbage collection technology without Java? How about all the new object stack allocation stuff in Java 6 (or is it 7 i forget). Using a scripting language is like going to McDonalds. The food is quick and tastes great, but the time you spend on the toilet after just isn't worth the whole experience. -- Bill Burke JBoss, a division of Red hat http://bill.burkecentral.com
  74. Re: Alternative?[ Go to top ]

    Using a scripting language is like going to McDonalds. The food is quick and tastes great, but the time you spend on the toilet after just isn't worth the whole experience.
    Bill, This might be the greatest thing that I have ever seen you post. John Murray Sobetech
  75. Re: Alternative?[ Go to top ]

    What's the alternative? Other than that, would we really have the improvements in VM garbage collection technology without Java? How about all the new object stack allocation stuff in Java 6 (or is it 7 i forget).

    Using a scripting language is like going to McDonalds. The food is quick and tastes great, but the time you spend on the toilet after just isn't worth the whole experience.

    --
    Bill Burke
    JBoss, a division of Red hat
    http://bill.burkecentral.com
    Replace McDonalds with Taco Bell.
  76. Re: Alternative?[ Go to top ]

    What's the alternative? Other than that, would we really have the improvements in VM garbage collection technology without Java? How about all the new object stack allocation stuff in Java 6 (or is it 7 i forget).

    Using a scripting language is like going to McDonalds. The food is quick and tastes great, but the time you spend on the toilet after just isn't worth the whole experience.

    --
    Bill Burke
    JBoss, a division of Red hat
    http://bill.burkecentral.com

    Replace McDonalds with Taco Bell.
    I don't know...I think taste of Taco Bell overrides the toilet time. At least, IMO.
  77. Re: Alternative?[ Go to top ]

    What's the alternative? Other than that, would we really have the improvements in VM garbage collection technology without Java? How about all the new object stack allocation stuff in Java 6 (or is it 7 i forget).

    Using a scripting language is like going to McDonalds. The food is quick and tastes great, but the time you spend on the toilet after just isn't worth the whole experience.

    --
    Bill Burke
    JBoss, a division of Red hat
    http://bill.burkecentral.com

    Replace McDonalds with Taco Bell.



    I don't know...I think taste of Taco Bell overrides the toilet time. At least, IMO.
    You have a good point. But TB counteracts it, somewhat, with extend toilet time. :)
  78. Re: Alternative?[ Go to top ]

    What's the alternative? Other than that, would we really have the improvements in VM garbage collection technology without Java? How about all the new object stack allocation stuff in Java 6 (or is it 7 i forget).

    Using a scripting language is like going to McDonalds. The food is quick and tastes great, but the time you spend on the toilet after just isn't worth the whole experience.

    --
    Bill Burke
    JBoss, a division of Red hat
    http://bill.burkecentral.com

    Replace McDonalds with Taco Bell.



    I don't know...I think taste of Taco Bell overrides the toilet time. At least, IMO.


    You have a good point. But TB counteracts it, somewhat, with extend toilet time. :)
    This food analogy has got it all wrong. Java is like bad Chinese food, diluted for European tastes. We all know that Java is a C-like, dumbed down Smalltalk for mass consumption. The thing is though in 1995 it was a big improvement on the mainstream diet back then C++. Which says more about mainstream 'enterprise' programming then it does about Java :^). Times move on, and a cleverly marketed C-like language built to drive toasters was never going to be the last word in computer science. Don't get me wrong. Lots of great things have been done with Java, but the fundamental architecture of the language has always been flawed. A bunch of home hobbyist borrowing ideas that have been lying around in the archive since the 1950's have managed to build an open source language that embarrasses Java when it comes to developer productivity and higher levels of abstraction. Doesn't that tell you something? Ruby has opened the eyes of many to what is possible. The truth is that the mainstream has never had a taste for fine food. The few that do, have found it difficult finding work with the type of productive languages they love. Think of the number of disgruntled Smalltalkers forced to earn a living writing Java. These are the ones that weren't lucky enough to make their living writing about OO programing instead (like Kent Beck, Martin Fowler, Ward Cunningham, Ron Jefferies etc. to name a few). We live in a dumbed down world filled with dumbed down programmers. The corporate world like it this way. Developers are people to be hired and fired at will - and if the could offshore the lot of us to India/China they would. I like DHH and his opinions. He has ruffled a few feathers and stirred things up a bit. At least we are talking about the right issues. Programming as a skill, the language as the programmers most important tool, and the economics of good programming. When I hear people describe 'scripting' languages as 'McDonald's', especially supposed industry leaders, I shudder at the ignorance on display. I could list all the architectural flaws in Java and why it will never be as powerful as Ruby or Lisp or Smalltalk or (place the name of any Lisp derived language here), but there is no point. Ignorance is bliss for some! Paul.
  79. Re: Alternative?[ Go to top ]

    Actually, I'm an Agile Coach - but I'm trying to avoid using the label "Agile" nowadays :^).
    So, what is an Agile Coach doing at work (no joking)?
  80. Re: Alternative?[ Go to top ]

    Actually, I'm an Agile Coach - but I'm trying to avoid using the label "Agile" nowadays :^).
    So, what is an Agile Coach doing at work (no joking)?
    On an XP team, an Agile/XP Coach is the team member who coaches the team in XP practices and reminds everyone "to do the right thing". The coach keeps the team honest and focused, much like a sports coach. Scrum has the same idea, but they call it a Scrum Master. Most Agile coaches use both XP and Scrum together. Incidentally, agile values play a role in the current backlash against mainstream programming norms. I believe that we are going through a cultural shift similar to the shift that the automobile industry went through in the late 70s, early 80's. The old ways of working are no longer globally competitive and we need to work smarter. Interestingly the impetus for change is coming from the same place it did for the automobile industry - Japan. I recently watched a video of keynote speeches at RailsConf. Lots of small start-ups manned by young teams of empowered programmers. These guys are self confident and self organised. They are not subservient to the corporate world and corporate culture, and they do not depend on greedy vendors. They build their own tools and make their own choices. As a consequence they are massively productive and are dominating the Web 2.0 development space. The world is changing, and Java is not at the leading edge. Paul.
  81. Re: Alternative?[ Go to top ]

    They are not subservient to the corporate world and corporate culture, and they do not depend on greedy vendors. They build their own tools and make their own choices.
    That's how all start ups begin, and building your own tools simply does *not* scale. These people will soon learn this lesson the hard way. While Java can arguably be seen as a bit behind in terms of expressivity of the language, the incommensurable size and quality of its libraries, frameworks and tools puts it in a position that will make it the language supreme for the next ten years. -- Cedric (Groovy and Ruby fan, still undecided about Erlang)
  82. Re: Alternative?[ Go to top ]

    They are not subservient to the corporate world and corporate culture, and they do not depend on greedy vendors. They build their own tools and make their own choices.

    That's how all start ups begin, and building your own tools simply does *not* scale. These people will soon learn this lesson the hard way.

    While Java can arguably be seen as a bit behind in terms of expressivity of the language, the incommensurable size and quality of its libraries, frameworks and tools puts it in a position that will make it the language supreme for the next ten years.

    --
    Cedric
    (Groovy and Ruby fan, still undecided about Erlang)
    Hi Cedric, At least you seem wiser to the merits of dynamic languages then you use to be :^) You've finally worked out that expressivity counts, good. Another lesson for you; one that 13th century stone masons learned: Architecture counts too. When building a building out of stone there is a finite size to which you can reach before the wait of the stone causes the building to implode upon itself. So the stone masons where stuck with finding ways to build ever larger buildings because the populous demanded large cathedrals. How did they achieve this? Well they worked out that arches had a unique property. They could be relatively light, but still very strong. So they employed the elegant architecture we see today in 13th century arched Cathedrals. The same is happening with software. People have learned that just adding more code, doesn't necessarily increase the levels of abstraction, and they are looking at new ways to abstract. So high order functions, mixins, meta-programming, open classes, open objects, closures are all ways to increase the level of abstraction. Think of it as creating your own unique language or as creating a domain specific langauge as Martin Fowler would say. It is this ability of Ruby the Rails folks are exploiting. Think of it as a new programming architecture, one that allows you to build more with less, much like arches in 13th century Cathedrals. A simple test of what I say is to take a look at the plugins for Rails, where people are extending Rails to cover their specific needs, with very little code. Think about how you could achieve the same with Java? Paul.
  83. Re: Alternative?[ Go to top ]

    Hi Cedric,

    At least you seem wiser to the merits of dynamic languages then you use to be :^) You've finally worked out that expressivity counts, good.

    Another lesson for you;
    Could you please drop the condescending tone? It's annoying and not very conducive to a reasoned debate. Now, if you read my words more carefully, you'll see that my skepticism about the viability of dynamically typed languages for enterprise software remains. Apart from this, it seems to me you are basically paraphrasing something I wrote about a month ago praising the importance of design patterns: http://beust.com/weblog/archives/000453.html Interestingly, we draw different conclusions from these observations, since to me, it means that development environments like Ruby and others have a lot more of catch up to do with Java then they really think. -- Cedric
  84. Re: Alternative?[ Go to top ]

    Hi Cedric,

    At least you seem wiser to the merits of dynamic languages then you use to be :^) You've finally worked out that expressivity counts, good.

    Another lesson for you;

    Could you please drop the condescending tone? It's annoying and not very conducive to a reasoned debate.

    Now, if you read my words more carefully, you'll see that my skepticism about the viability of dynamically typed languages for enterprise software remains.

    Apart from this, it seems to me you are basically paraphrasing something I wrote about a month ago praising the importance of design patterns:

    http://beust.com/weblog/archives/000453.html

    Interestingly, we draw different conclusions from these observations, since to me, it means that development environments like Ruby and others have a lot more of catch up to do with Java then they really think.

    --
    Cedric
    Hi Cedric, Two points. Firstly sorry for sounding condescending. My tone was light hearted and aimed at provoking thought. Humility is a great trait. Perhaps if you re-read my post through the lense of humility then it may appear less offensive to you. We are both on the same side. Knowledge and truth. Humility is necessary for learning, and I am more then happy to learn from you and I take no offense at your assertions. Perhaps we can learn from each other? Second point. I paraphrase nobody (other then Alan Kay from whom I borrow the Cathedral analogy, borrowed form his 1997 keynote speech at OOPSLA). And to compare my post with your blog entry on patterns shows you've missed my point. You make a good point about patterns in your blog. The patterns movement has been taken to mean that there are fixed remedies to most problems, and all you need to do is find the right recipe. I am pretty sure that this was not the intent of the original proponents of the idea, but like so many things it has been co-opted into the general dumbing down I describe. What I am saying is something else. I am saying that programmers need to be free to experiment and discover new recipes. To do this they need access to a broader range of raw ingredients. Languages like Ruby give them those ingredients and provide more power to the programmer; moving us away from the "cookie cutter" approach where it is assumed that all problems can be neatly fit into pre-defined templates. In raising the level of abstraction many have found that the constraints of the Java language is posing an artificial barrier. Some in an attempt to overcome this barrier have co-opted things like CGLIB and XML others are exploring alternative languages. My main point, is that it isn't the amount of stuff that matters (libraries, APIs etc), but the quality of the abstractions they represent. My other point is that the quality of the abstractions in Rails are very good and would be difficult (if not impossible) to achieve with Java. I attribute this to the Ruby language. So we should be looking at the host language itself if we want to raise the level of abstraction not the libraries and APIs available. BTW you chose not to respond to my point about Rails plugins. In the spirit of learning and humility, I would be interested to know your thoughts on how you would achieve the same with Java. Finally, I really do not want to sound partisan, and the point of my discussion here is not to say that one language is inherently better then the other. I do not believe this to be true, and I believe that there is merit in knowing and practicing several languages. I am merely trying to prompt thought and point out that the host language itself is more important then the frameworks and tools available. Paul.
  85. Re: Alternative?[ Go to top ]

    When I hear people describe 'scripting' languages as 'McDonald's', especially supposed industry leaders, I shudder at the ignorance on display. I could list all the architectural flaws in Java and why it will never be as powerful as Ruby or Lisp or Smalltalk or (place the name of any Lisp derived language here), but there is no point.

    Ignorance is bliss for some!


    Paul.
    Please don't put Lisp and Ruby in the same sentence! They are not equivalent nor interchangeable. Lisp is logical in its syntax with S-expressions and allows a power of expression greater than Ruby. Metaprogramming is not some hyped up "brand new thing" but it integrates to the point that when you program in Lisp you inevitably end up doing it, even if you didn't go to any Conference or watched any Consultant's video. Ruby supporters can't express in words what they think, simply because they don't know anything beyond the hype. They always come up with "fun" and everyone that disagrees with them is "stupid". Ruby is stupid, was Matz drunk when he designed that thing to be so "Perlish"? Its arbitrary syntax and OO style is what bothers me the most, it couldn't be farther from Lisp than already is.
  86. Re: Alternative?[ Go to top ]

    Please don't put Lisp and Ruby in the same sentence! They are not equivalent nor interchangeable. Lisp is logical in its syntax with S-expressions and allows a power of expression greater than Ruby.
    I second that thought. Have you every noticed that Ruby people tend to talk about how Lisp-like Ruby is, yet hard-core Lisp people seem to spend more time talking about Python?
  87. Re: Alternative?[ Go to top ]

    When I hear people describe 'scripting' languages as 'McDonald's', especially supposed industry leaders, I shudder at the ignorance on display. I could list all the architectural flaws in Java and why it will never be as powerful as Ruby or Lisp or Smalltalk or (place the name of any Lisp derived language here), but there is no point.
    Many of us have tried "scripting" languages. And have been bit because they've been used as more than scripting languages.
    have managed to build an open source language that embarrasses Java when it comes to developer productivity and higher levels of abstraction
    I am sure at some level this is true. But TCO? Over the lifetime of the application/code? Maybe for you and what you do.
    Ignorance is bliss for some!
    It seems that the other person is always ignorant from our viewpoint.
  88. Re: Alternative?[ Go to top ]

    Hi Mark,
    When I hear people describe 'scripting' languages as 'McDonald's', especially supposed industry leaders, I shudder at the ignorance on display. I could list all the architectural flaws in Java and why it will never be as powerful as Ruby or Lisp or Smalltalk or (place the name of any Lisp derived language here), but there is no point.

    Many of us have tried "scripting" languages. And have been bit because they've been used as more than scripting languages.
    I'll take a gentler tone, because I know you are an intelligent guy :^). The term 'scripting' language is used almost like a derogatory term. It isn't relevent in this context. For me a scripting language is something like Bash or Awk. We are talking about dynamic languages with strong typing, exception handling, mixins, high order functions, object memory, open classes, closures, ... the list goes on. You can't compare Ruby with Bash or Perl.

    Ignorance is bliss for some!

    It seems that the other person is always ignorant from our viewpoint.
    Well please describe the alternative point view point. I am happy to hear it. I was responding to bigoted comments. When did you last use Ruby or Rails? On what experience do you base this alternative point of view? If you haven't spent significant time understanding how to work with these languages (e.g. Test Driven Development, interative, emergent design, REPL style feedback, creating DSLs, DRY, etc), then you have no basis upon which to base an opinion. hence the label ignorant fits! Paul.
  89. Re: Alternative?[ Go to top ]

    Using a scripting language is like going to McDonalds. The food is quick and tastes great, but the time you spend on the toilet after just isn't worth the whole experience.
    It is a nice analogy :-) I would also add that this “food” is: - Cheap, and - Will kill you in a long run. Best, Nikita. GridGain - Grid Computing Made Simple
  90. Java's footprint is quite large and getting larger. There is tons of stuff to choose from, and you can solve many problems with Java. The language is not perfect, but it is easy enough, and there are usually good solutions to solve a problem. The level of software commoditization is quite high so you can get started with relatively low cost. The tools are also quite mature and good, and often free. So what is the alternative? .NET? But is there really any other serious competition? No. We have Ruby and other marginal platforms. I think people do not really understand how extremely marginal and limited they are in comparison to Java. There are better ways to deal with certain point problems. Ruby is good for certain things, maybe PHP for in another case. But for them to become what Java is, they will become just as complex, just as bloated, just as full of alternatives and tons of APIs. So what is the solution? Shoestring applications together made with many domain specific approaches? Alone they might be simple enough, but all together they are just as complex as Java with a high learning curve, and with poor integration out of the box. JVM is bad? Sure, it is not perfect, but you have to give it credit for what it does very well. VMs are important, especially good ones. Ruby suffers quite a bit from a lack of a good VM, for example. Other VM solutions suck quite a bit as well in comparison to JVM. Maybe there is no ultimate VM but JVM is pretty darn good in comparison.
  91. Peanut Gallery Comment[ Go to top ]

    Hi. I'm an ordinary "small time" Java developer with some comments about Java: Around '97, I was looking for a new technology to learn and get good at. I'm a competent C programmer but shied away from C++ because while it offers great OO power, it forces programmers to do too much low level plumbing. Like Peter van der Linden's friend, Java rescued me from C++. Yay! Java, with dynamic strings and containers with automatic memory management has greatly increased my productivity over, say, Pascal, FORTRAN, C and Clipper. Like Delphi, Java has saved me from memory management and the Windows MFC. It's made Internet-type communication a snap and RPC likewise. I haven't needed (much) to shop for 3rd party libraries, because it comes with the kitchen sink included. But now some years have passed and the expectations on my abilities (and everybody else's) grow: We're expected to do Web apps, 3-tier behemoths, SOA... you name it. And we're expected to do it quickly and on a shoestring. We're able to program more abstractly now, and this has given us a boost for a while. But the bar keeps rising. It's not that Java is dying, but it's not improving productivity as quickly as the market is screaming for it. When Java came out, some developers claimed their productivity had tripled. To achieve another boost like that, we'd probably need another language change. Investors are looking for 20% ROI. Developers cannot keep up. To maintain the illusion of steadily increasing cost effectiveness, our PHBs are throwing Indians at the problems. Soon, Chinese children will be hammering out enterprise apps in their sweatshops. Meanwhile, I'm wishing Java could do some of its cool stuff with a fraction of the code. Why do I need to define and instantiate a new class just to define and call a single method, in one place? Delphi lets you do this with function pointers. Why do I need to write get() and set() for every attribute? Ruby does a fine job of (optionally!) automating this BS, and since Anders Hejlsberg defected to Microsoft, so does C#. Why is XML the lingua franca of configuration? Won't somebody think of the humans? Pushing auto-generation of verbiage into IDEs and wizards rather than into the language is a short-sighted and cowardly solution: It makes writing faster but doesn't do a thing for reading. Today's tasks in Java call for as much code as yesterday's tasks in COBOL. In spite of the unfairness of this comparison, that's where those disparaging comments come from. If Java doesn't want to look like COBOL, it should add more programmer-enabling shorthand in a hurry: The ability to express what you want, tersely yet human-readably, perhaps like Ruby. Abstraction-raising stuff like FP, with currying and closures like Haskell, maybe the LISPish idea of classes and procedures as first-class objects. Java is much better than COBOL, but it mustn't sit on its butt or soon it will fall behind for failing to keep up.
  92. Re: Peanut Gallery Comment[ Go to top ]

    To maintain the illusion of steadily increasing cost effectiveness, our PHBs are throwing Indians at the problems. Soon, Chinese children will be hammering out enterprise apps in their sweatshops.
    Great post. Just to follow up this comment, at least a year ago some Indian developers I worked with told me that Indian IT outsourcers have started outsourcing some of their work to China because of the cheaper labor. So, a US company outsources to an Indian company who turns around and outsources to a Chinese company. At some point, no labor is going to be cheap enough and we'll have to turn to better technology, which hopefully we'll have some of in the US. (With decreasing enrollment of US citizens in science and engineering graduate programs, I'm skeptical.) James Watson posted something interesting on Artima a few weeks ago about small Italian companies (mom and pop shops) being the cheapest place in the world to outsource machining. They use a high level of automation. Presumably the automation is possible through newer technology. I think the same will happen in our field as soon as we get through the outsource to the cheapest body phase we're in. (The link is here http://www.artima.com/forums/flat.jsp?forum=106&thread=210434&start=45&msRange=15 .)
  93. Re: Peanut Gallery Comment[ Go to top ]

    At some point, no labor is going to be cheap enough and we'll have to turn to better technology, which hopefully we'll have some of in the US. (With decreasing enrollment of US citizens in science and engineering graduate programs, I'm skeptical.)
    I think that the US and Western Europe may be better positioned for the future than you might think. My experience is that the fantastic growth of IT jobs in India (and possibly China) has caused the same kind of talent dilution that occurred in the US during the run up to the dot-com bubble bursting. There are a lot of great and talented developers in India, but they are harder to find. Conversely in the US, the dearth of jobs in the last few years led a lot of people who never were that good at development in the first place to go move to different careers. There's still room for cleaning, though. I any event, the US really should fix immigration in this area. H1B visas are really a form of indentured servitude. It pushes down wages and a lot of really good developers from India and elsewhere are not putting up with this anymore.
  94. Re: Peanut Gallery Comment[ Go to top ]

    I think that the US and Western Europe may be better positioned for the future than you might think. My experience is that the fantastic growth of IT jobs in India (and possibly China) has caused the same kind of talent dilution that occurred in the US during the run up to the dot-com bubble bursting. There are a lot of great and talented developers in India, but they are harder to find.

    Conversely in the US, the dearth of jobs in the last few years led a lot of people who never were that good at development in the first place to go move to different careers. There's still room for cleaning, though. I any event, the US really should fix immigration in this area. H1B visas are really a form of indentured servitude. It pushes down wages and a lot of really good developers from India and elsewhere are not putting up with this anymore.
    Talent dilution is still a problem here, but you're right that the dot-com bubble bursting did push out people "along for the ride". My experience working with native and non-native workers is that a few are really good and most are mediocre. (And then there are the few who are bent on destroying the US's software one line of code at a time.) What I'm more concerned about is research in the US. Research budgets have been reduced over the past 10 years in corporations. As far as university research goes, my father-in-law is an Atmospheric Science professor. He told me that for years he made every effort to recruit native US students to his graduate program, but few were interested. The ones who were interested had such a poor background in applied mathematics that they weren't qualified. His colleagues in other science disciplines have the same complaints. Research paves the road to new technology. It concerns me that we don't seem to value it enough.
  95. Re: Peanut Gallery Comment[ Go to top ]

    My experience working with native and non-native workers is that a few are really good and most are mediocre.
    Absolutely. I think this is an argument for better tools that allow the few to do more. Instead, this argument is used to require that the few write 'designs for dummies'.
    What I'm more concerned about is research in the US. Research budgets have been reduced over the past 10 years in corporations. As far as university research goes, my father-in-law is an Atmospheric Science professor. He told me that for years he made every effort to recruit native US students to his graduate program, but few were interested. The ones who were interested had such a poor background in applied mathematics that they weren't qualified. His colleagues in other science disciplines have the same complaints. Research paves the road to new technology. It concerns me that we don't seem to value it enough.
    I recall seeing some figures recently that show the US is pretty much in the middle for research spending but that it has been going down. I think the problem with math education is this country is that we focus too much on mundane repetition. This kind of teaching discourages the kinds of minds that would be good at higher level math at a young age and teaches them to hate math. I was reading "A Beautiful Mind" (very different story than the movie btw) and one thing that was interesting to me was that John Nash performed poorly in arithmetic and only became interested when he stumbled across a highly abstract math text. This is not uncommon. Similarly, dyslexics have (on average) much greater ability to 'think-in' 3 dimensions. The way that we teach children brands these people as slow or low-performers early on. We base predictions on who will do well at higher level math on who does well at arithmetic. This is completely wrongheaded and comes from an education system that has, as a whole, has no understanding of what talent in math truly is. In a nutshell, the best memorizers are considered to be the most skilled. Combine that with the fact that skilled engineers and scientists are paid almost nothing in comparison to managers, salespeople and of course, athletes. It's a clear message that society doesn't value these careers. If you are smart, you become a doctor or a lawyer. OK, we could use more doctors, but lawyers, I think we are full-up.
  96. Re: Peanut Gallery Comment[ Go to top ]

    I've found that over time I've tended to use maps for more and more things in Java. They allow for a lot of techniques that are just too hard to implement in Java with static code.
    What kind of applications do you build?
  97. Re: Peanut Gallery Comment[ Go to top ]

    I've found that over time I've tended to use maps for more and more things in Java. They allow for a lot of techniques that are just too hard to implement in Java with static code.

    What kind of applications do you build?
    Lately, most of the code I write is integration type stuff. Communicating between two applications or between to organizations. In this kind of code, it's definitely a lot easier to use a dynamic map type structure whether it's actually a java.util.Map or a custom map type structure. One of the things I worked with was taking data from a flat file formats specified by COBOL copybooks, doing a little logic and a lot of lookups and writing out to another flat file structure. The main advantage of maps from my perspective is that they are inherently composable. For example, one of the things I was able to implement was a target set of fields could be populated merely by passing in a list of maps where each map would be checked for until one was found. If I were to do this in a static way, I would have to define all the fields in each class and then hard code the copying of these values into the target type and then hard code the serialization from that type to the flatfile. With the way I did it, it's a two-line method. Actually one of the things that I would like to have is an OO language that is composition biased instead of the inheritance biased languages like Java or Python.
  98. Re: Peanut Gallery Comment[ Go to top ]

    Combine that with the fact that skilled engineers and scientists are paid almost nothing in comparison to managers, salespeople and of course, athletes. It's a clear message that society doesn't value these careers. If you are smart, you become a doctor or a lawyer. OK, we could use more doctors, but lawyers, I think we are full-up.
    I don't think this is a fair statement. In many of the extremely high-paid professions individuals take on a significant amount of personal risk. Salespeople work on commision. Lawyers, accountants, etc. need to make partner in order to make uber-bucks - and in order to become partner you have to buy your share of the firm. People save and take out second mortgages and other loans to do this, and sometimes have to turn it down because they cannot afford it. Doctors spend countless years in school building up debt all the while with no gaurantee they will actually make it. Athletes dedicate enormous amounts of time and risk career-ending injury to become professionals and almost none of them make it. At the entry-level engineering jobs are among the best paying available and can be had with only a BS. Technology entrepreneurs (again, people who take personal risk) are very well represented in the world's wealthiest people. For most people, in order to get rich you have to be compensated for what you produce, not the work you put in. Working for a big company decouples you from the risk that your output has no market value, and is consequently rewarded (or punished) for what you produce. If you take away the risk, you take away the reward.
  99. Re: Peanut Gallery Comment[ Go to top ]

    Combine that with the fact that skilled engineers and scientists are paid almost nothing in comparison to managers, salespeople and of course, athletes. It's a clear message that society doesn't value these careers. If you are smart, you become a doctor or a lawyer. OK, we could use more doctors, but lawyers, I think we are full-up.


    I don't think this is a fair statement. In many of the extremely high-paid professions individuals take on a significant amount of personal risk. Salespeople work on commision. Lawyers, accountants, etc. need to make partner in order to make uber-bucks - and in order to become partner you have to buy your share of the firm. People save and take out second mortgages and other loans to do this, and sometimes have to turn it down because they cannot afford it. Doctors spend countless years in school building up debt all the while with no gaurantee they will actually make it. Athletes dedicate enormous amounts of time and risk career-ending injury to become professionals and almost none of them make it.

    At the entry-level engineering jobs are among the best paying available and can be had with only a BS.
    I don't disagree completely but I'm not arguing fairness. Risk is not the only factor that determines market value. What services you provide and how in demand those services are what ultimately determines your price. Risk in a career is pertinent to the employee, not the employer. The athletes that don't make it take on as much risk as those that do. They are not rewarded for their risk, they are rewarded for the value they provide to their employer. My brother in law has a Phd in music composition. He spent about a decade in school and in terms of risk, he was vying for one of a handful of teaching jobs in the whole country. Even so those jobs don't pay that well anyway. It's because there is very little demand. There are a number of extremely risky jobs that do not pay well. Any low risk job that does pay well is quickly inundated with applicants. This is what we saw in the US in the 90s and in India now.
    Technology entrepreneurs (again, people who take personal risk) are very well represented in the world's wealthiest people.

    For most people, in order to get rich you have to be compensated for what you produce, not the work you put in. Working for a big company decouples you from the risk that your output has no market value, and is consequently rewarded (or punished) for what you produce. If you take away the risk, you take away the reward.
    I think this is suspect as an economic theory. The reward is lower in a company because the risk is lower but not because people are paid for their risk. It's that the lower risk tends to make the pool of potential employees larger. The supply goes up. When the supply of developers was tight in the US during the 90s, it was a really well paying, low risk job. Every young person wanted to do it. I worked with almost no one who actually studied computer science at that time. Anyway, this isn't really my point. Atmospheric science is actually a pretty risky field to go into. Like music composer, it's atmospheric science is not in high demand. We as a society don't place much value on it. If we want more atmospheric scientists, we'll need to pay them better and employ more of them. I don't think it should be surprising that few US citizens choose this as a path.
  100. Re: Peanut Gallery Comment[ Go to top ]

    Today's tasks in Java call for as much code as yesterday's tasks in COBOL. In spite of the unfairness of this comparison, that's where those disparaging comments come from. If Java doesn't want to look like COBOL, it should add more programmer-enabling shorthand in a hurry: The ability to express what you want, tersely yet human-readably, perhaps like Ruby. Abstraction-raising stuff like FP, with currying and closures like Haskell, maybe the LISPish idea of classes and procedures as first-class objects. Java is much better than COBOL, but it mustn't sit on its butt or soon it will fall behind for failing to keep up.
    I'd never really known anything about COBOL before recently and if anyone is seriously comparing Java to COBOL for anything other than its ubiquity then they really need to stop. Sit down and work with COBOL for a while and Java will seem like an oasis in the Sahara. There's really nothing similar between these languages other than some of the ridiculous design approaches that have been used in both. The other thing to remember is that there is an OO COBOL. I can't state any figures but I imagine this is not commonly used. The language is and was too tired and fundamentally flawed. It's the proverbial old-dog. In that aspect, Java could become like OO-COBOL. A bizarre oddity that resembles an anachronism more than anything else. It would be like a steam powered automobile, possibly adopted initially and then ultimately recognized as fundamentally deficient. There are a few things that could be added to Java to relieve some of the pain points and make it easier to use in combination with dynamic languages in the JVM: function pointers and anonymous functions and/or closures. I might even throw in reification, if only to repair the damage caused by generics. But other than that, I think it's time for Java to stabilize and become a legacy language like C.
  101. From my perspective.[ Go to top ]

    I think good things are happenging is Java. But because everybody are creative in Java. Everyday a new tool, library or other stuff appears. For me, first it was JSP ,then EJB, then Spring, then I'm thinking about JSF (Of course it was out there for a long time, but I was convinced to use it). From language wise, we can complain about it, But in 5.0, Generics & annotations appear, there are several blogs about them. But, they are good, better than not be there & keep using Xdoclet (& of course I used all of them). In 6.0 javascript support added to it, indeed I haven't gone to the details of that. But maybe it's the answer for several complains out there. The thing that I'm saying, I like to see these discussions & I expeect to hear new features emerging in Java. But they can not be done in one night. They are fast enough right now for me to diggest them (I'm not lazy, I should deliver the project & enjoy my family). About other languages. I Just heard about Ruby. But even for that, I have not dared to get close to that though, yet. Because, definitely, it's not as mature as Java is today with all of these IDEs, libraries & tools. So I will wait few more years & enjoy just emerging stuff in Java & watch what will be the result of those bluffs out there.
  102. The average business is not interested in "hot trends in programming". Only programmers are. It's convenient to say that COBOL, Visual Basic or Java are deficient. But the reality is altogether different. If languages like Ruby ever end up solving the same business problems these other languages did, they will end up on the suck list as well. Oh well... I guess the world will continue to label what works with what's not cool. Maybe it's the answer to staying young forever :)
  103. Garbage..[ Go to top ]

    So, Russell Beattie would never use Java to power his personal blog. Crap, there goes like 80% of the enterprise market. Ruby, Python, and PHP(?) are certainly gaining some popularity - and for good reason (well, except PHP maybe). I think all of these still lack both features and support to really make headway in the enterprise area right now. I use Ruby (mostly) and a bit of PHP, and I'm learning Python - all to build my personal/business websites and goof around on the side. I likely won't use Java to build websites for myself very much in the future, but it is more of an issue of deployment, not development. I'm also not too blind to see that the requirements of my personal blog may be different from requirements of the multi-million dollar enterprise apps I work on at my day job. People who continue to complain about all the XML and nasty code you have to use in Java haven't developed in Java recently or are using really old stuff. I am working on a fairly large (several hundred thousand LOC) Java project at work, and the amount of time I spend with XML isn't that much more than the amount of time I spend messing with yaml files in my considerably smaller rails app I'm working on now. Get a new argument. The date stuff does suck, but you can use Joda Time. And Joda time is the basis for a JSR to fix date/time stuff in Java. A little late, yeah, but it is being fixed. Lastly, he conjures up an image of hordes of Erlang programmers overtaking Java as we speak. I did a quick job search: Monster.com Java - 5k results (5k is the max, apparently) Erlang - 10 Dice.com Java - Over 17k results Erlang - 5 I realize job postings aren't the end-all of comparing language popularity, but when the disparity is that big, come on.. Also, on the other page, this is a real gem: Previously, in private conversations, I had put the time window on the demise of Java in the three to five year range. Given the reactions I've seen, I think Jonathon's move just shaved a year or two off that estimate. That is just absurd. TheServerSide.Com - Your Enterprise Java Troll!
  104. Re: rc3.org: Java is what it is[ Go to top ]

    Look at the number of posts in this thread. It shows the interest of developers in Java. No matter weather they favour it or not, but they all are eager to know whts happening. This interest will never let Java die. jYog
  105. A theory[ Go to top ]

    I have a theory: The complaints about Java follow a pattern. They complain about the lots of XML, complexity, of many frameworks they have to use to get anything done, etc. Does it sound familiar? They are talking about Spring! Nowhere in the Javaland there's so much XML as there. The Spring+Hibernate duo is a XML hell. Definitely Spring in an abomination, and I believe the quantity of mediocre egocentric bastards spreading around that you can't do anything good in Java without it is beginning to scare people away. If I had to work with Spring I would definitely love to switch to Perl! Haha Some Java developers have lost the sense of simplicity. They create solutions for non-existing problems just for appeasing their own ego. Although language-wise Java is simple, and that doesn't mean "bad", it means only simple, I tend to consider the platform as whole as something good. We have plenty of tools (some awful ones, such as Spring), APIs and high quality IDEs to work with. This gives us a great productivity boost. The language is simple, and that makes it very easy to give maintenance to as well. I believe Ruby supporters don't get what exactly makes Java popular. They just assume that if they scream loud enough that will make it happen. And Sun is just as lost as a blind man in a shooting.
  106. Re: A theory[ Go to top ]

    Definitely Spring in an abomination, and I believe the quantity of mediocre egocentric bastards spreading around that you can't do anything good in Java without it is beginning to scare people away. If I had to work with Spring I would definitely love to switch to Perl!
    I won't go so far was to call Spring an abomination but I do a sense of cognitive dissonance when people advocate the benefits of static typing and then advocate using Spring. Or, when people who believe Spring is the only way to develop a system in Java refuse to consider combining a dynamic language with Java. From what I can tell, Spring is basically a specialized dynamic language with tons of keywords and syntax built on top of XML.
    Although language-wise Java is simple, and that doesn't mean "bad", it means only simple, I tend to consider the platform as whole as something good.
    That's it exactly. Java is simple (generics kind of messed that up, though) and should stay that way. It shouldn't try to become something more. Sometimes simple and stable is what you want. But saying it's a good choice for everything is also misguided.
  107. Re: A theory[ Go to top ]

    From what I can tell, Spring is basically a specialized dynamic language with tons of keywords and syntax built on top of XML.
    You know nothing.
  108. Re: A theory[ Go to top ]

    From what I can tell, Spring is basically a specialized dynamic language with tons of keywords and syntax built on top of XML.
    You know nothing.
    Is that supposed to be an argument?
  109. Re: A theory[ Go to top ]

    From what I can tell, Spring is basically a specialized dynamic language with tons of keywords and syntax built on top of XML.
    You know nothing.
    Is that supposed to be an argument?
    No, that's my argument: http://www.theserverside.com/news/thread.tss?thread_id=46697#239039
  110. Re: A theory[ Go to top ]

    From what I can tell, Spring is basically a specialized dynamic language with tons of keywords and syntax built on top of XML.
    You know nothing.
    Is that supposed to be an argument?
    No, that's my argument: http://www.theserverside.com/news/thread.tss?thread_id=46697#239039
    Wow, what a genius response! You really got me! This seems more like a insolent child pouting than an argument. Have you ever tried debating in a non-passive-aggressive way? Do you even know how to formulate a logical argument? There's no sign here that you do. Other than this kind of statement being rude and pointless, it makes you like you can't defend your own points.
  111. Re: A theory[ Go to top ]

    From what I can tell, Spring is basically a specialized dynamic language with tons of keywords and syntax built on top of XML.
    You know nothing.
    Is that supposed to be an argument?
    No, that's my argument: http://www.theserverside.com/news/thread.tss?thread_id=46697#239039


    Wow, what a genius response! You really got me!

    This seems more like a insolent child pouting than an argument. Have you ever tried debating in a non-passive-aggressive way? Do you even know how to formulate a logical argument? There's no sign here that you do.

    Other than this kind of statement being rude and pointless, it makes you like you can't defend your own points.
    + I'm ignorant.
  112. Re: A theory[ Go to top ]

    + I'm ignorant.
    I won't argue with that.
  113. Re: A theory[ Go to top ]

    + I'm ignorant.
    I won't argue with that.
    At least some agreement... ;-)
  114. Re: A theory[ Go to top ]

    + I'm ignorant.
    I won't argue with that.
    At least some agreement... ;-)
    Seriously, why would you post something like that? Do you get off on being a dick to strangers or something? You've gained nothing but ill will.
  115. Re: A theory[ Go to top ]

    + I'm ignorant.
    I won't argue with that.
    At least some agreement... ;-)


    Seriously, why would you post something like that? Do you get off on being a dick to strangers or something? You've gained nothing but ill will.
    I regret. I hope you accpet my apology.
  116. Re: A theory[ Go to top ]

    I regret. I hope you accept my apology.
    Absolutely. Can you do me a favor? If you feel that my approach in the post you referenced is sub-optimal (or crap, whatever) could you explain why? Can you offer a better solution? My statement about Spring is made the presumption of at least some ignorance on my part. Maybe I didn't make that clear enough or explain what I meant well enough. I studied physics for a couple of years before switching to computer science. In physics, direct challenges to ideas are not only the norm, they are expected. I think this may seem aggressive to people who aren't used to that type of discourse. But I strive never to make these things personal and I never intend to use rhetorical arguments to 'win'. In any event, I'm really curious as to what Spring 'is'. It definitely seems like more than just a framework to me. It seems to occupy a larger space than that. And even more than that, can any non-trivial framework be considered a special purpose language? What is a framework in format terms. This is all just fun. You might even convince me to try Spring more than my previous cursory attempts.
  117. Re: A theory[ Go to top ]

    Absolutely.
    Thanks.
    Can you do me a favor? If you feel that my approach in the post you referenced is sub-optimal (or crap, whatever) could you explain why? Can you offer a better solution?
    Sure, choose the contract first approach: create a Meta-Data file. Use simple code generation (but avoid code generation in general) to create your parser and domain classes from your Meta-Data. Avoid the Maps approach, it's a maintenance hell (maybe not for you, but for the next guy who has to deal with it).
    In any event, I'm really curious as to what Spring 'is'. It definitely seems like more than just a framework to me. It seems to occupy a larger space than that. And even more than that, can any non-trivial framework be considered a special purpose language? What is a framework in format terms.
    Spring is about freedom. If you don't need that, don't use it. For sure this also applies to Guice, but I didn't use it so far. Actually that's my last post on TSS. So have a good time...
  118. Re: A theory[ Go to top ]

    Sure, choose the contract first approach: create a Meta-Data file. Use simple code generation (but avoid code generation in general) to create your parser and domain classes from your Meta-Data. Avoid the Maps approach, it's a maintenance hell (maybe not for you, but for the next guy who has to deal with it).
    I appreciate your view but I have to respectfully disagree. I've worked with code generated from meta-data in the past and it was maintenance hell. That's why I came up with this solution. In this case, the most of the Java doesn't need to be maintained at all. This sounds like BS but it's true. It's kind of the same reason that you don't need to modify the JAXB libraries when you want to change a schema. This solution is agnostic to the data. The only thing the developer has to modify for most changes is the SQL and/or the copybook. For example, I found that halfway through the project I need more data. I didn't change the Java code. I changed the SQL and the copybook. Later I was asked to rename every field. I did it without changing the Java classes. A type had the wrong precision in the copybook. I changed it and retested. For things that I need to execute logic against, I created getters and setters but they were backed by the dynamic data, so changing say the length of a char field didn't require any code updates. But these were a minority. I didn't see any point in adding getters and setters that are never called. I've had years of experience with the kind of approaches you mention here and it's never been a picnic. Essentially these layers are repeating information from other parts of the system. They add nothing new. And in the end the data is always dynamic anyway and you can't escape that.
  119. Re: A theory[ Go to top ]

    LOL! I don't know if Spring is an 'abomination'. I would rather not use it, but it has done a lot of good by just pointing out some real abominations that were all the rage in Java enterprise programming a few years ago. Spring, for me, is now simply obsolete. But I might agree to an extent with the original post as far as saying that most of the innovation is happening outside Java. I am fine with that. Java is a real language for the real world, not some experimental tool to do magic. Enterprise software needs to be written after all, and Java is great for that. Paul Casal Sr Developer jbilling.com The Enterprise Open Source Billing Software
  120. Remember the good ol' days...[ Go to top ]

    when TSS posted news and not flame bait? Good times. Good times.