Jason Hunter wrote a passionate blog entry talking about the Innovator's Dilemma in Java - "how you can listen to customers, provide them with what they want, but still lose out -- because a cheaper, not-as-good but good-enough competitor comes in and eats your market."

His thought process was spurred on by the interest in Ruby on Rails at a No Fluff Just Stuff conference.

I think people (myself included) are drawn to Rails because it promises simplicity. In programming these days, cheaper isn't about price, it's about mental effort. So a language like Ruby and an environment like Rails that promise us *less* has a strong appeal.

Java's trying to deliver simplicity through new features. Oh the irony! Java Generics were added in Java 5 to make things easier, and while they can help newbies ignore casting, they make guru-level knowledge of the language all the harder to maintain.

He ends with these two paragraphs:

Ruby on Rails today looks poised to eat Java's mindshare on the web tier. If not Rails, then something else. Empirically 10 years seems like the right point. Java's viewed as solid and stable, mature enough for the most stodgy business folks. That leaves a large soft underbelly for a technology intended to help small teams (10 or fewer) who just want to make a site that's good enough without paying a high price in mental effort.

My advice to Sun: Own the disruptive technology. Create a group of 7 creative engineers and charge them with approaching the problem from beneath. Tell them to come up with technology that's "good enough" and a whole lot easier. To be modern, it must solve the full web application problem, not just help with individual pages. It must also be AJAX-enabled through and through. Tell this team they aren't required to leverage existing Java libraries unless they want to. Their only requirement is that this new technology should run on the Java Virtual Machine (JRuby or Groovy would be fine, if the team so judged). This should be what's important to Sun. Give the team six months to produce an early prototype. Their eventual success will be judged on if they can eat into Java EE's mindshare. If Sun doesn't start providing Java heads with "cheaper" technology, someone else will. They already are.

What do you think?

Their only requirement is that this new technology should run on the Java Virtual Machine

Is it not obvious what we are talking about?

Like Ruby but Java like.
Hm.
So I could use all the 3rd party jars.
Hm.
Better, Faster, Lighter than J2EE.
Hm.
Anyone? Anyone?
Hint: It starts w/ G...

Ahm, why to we need Sun? There is a JSR and when we all start using it, what's wrong w/ Sun talking about PetStore and Adventure Store and Sparc? We can still date them.

I allrady do ALL my back end in G.... (front end is in JDNC)
(I use it to improve readbility, and becuase it's like Python). It has exceeded my expectations big time. Works in jEdit fine. Perfect balance of backwards Jar use, and huge improvment in productivity.
(Look, last year I talked about iBatis, and now I see lots of iBatis projects in production, so just do yourself a favor and try it).

.V
http://roomity.com (version 1.09 up)

Is it not obvious what we are talking about?Like Ruby but Java like.Hm.So I could use all the 3rd party jars.Hm.Better, Faster, Lighter than J2EE.Hm.Anyone? Anyone?Hint: It starts w/ G...Ahm, why to we need Sun?

To those who date not speak its name: Groovy: heavily influenced by Ruby. So good the Ruby people are copying ideas from it (http://onestepback.org/index.cgi/Tech/Ruby/BuilderObjects.rdoc)

Groovy potentially has huge advantages over ruby because it has all rubys power *and* can happily chat to all the java apis (jdbc, swing, swt, antlr, etc).
<irony>Ahm, why to we need Sun? [or IBM or Apache or anybody]</irony>

IMO Because its not finished and its a very big job and it will need lots of resources, luck, politics, timing (and maybe a name change) to get it to the same level of maturity as Ruby. (Ruby was started in 1993.) Groovy is more complex than ruby in that it mixes Java and Ruby.

We have been developing using JSP+JSTL/Spring MVC+AOP+IoC/Acegi/Hibernate (and Maven, Eclipse, svn... but no struts MVC though) for almost a year now and we find it to be vastly more productive than a full classical J2EE based web system implementation (plain JSP+JSTL, plain Servlet, EJB Session+Entity, JDBC...).

However, I do find the criticism of verbosity and seemingly redundant XML configuration to be valid when compared to language/framework like RoR. At least based on my understanding of RoR by my casual reading on the web... though I have yet to develop a real-world app with RoR yet.
Also, I have played with LAMP based apps too and understand the temptations, both good and bad...

The central concept of RoR for me is the notion of convention over configuration, and I was almost tempted to try RoR out, until I discover Groovy and its associated MVC framework - Grails.

I understand that neither is quite mature yet, and Grails especially so. But I sense its potential and promise...

I hope more java and non java people can collaborate and contribute to these projects instead of criticising each others favorite toolset, so that developers like myself may be able to use them for real and enjoy all the benefits soon. :-)

Is it not obvious what we are talking about?Like Ruby but Java like.Hm.So I could use all the 3rd party jars.Hm.Better, Faster, Lighter than J2EE.Hm.Anyone? Anyone?Hint: It starts w/ G...

Sure, Groovy could rock RIA. As for development that's "better, faster, lighter than J2EE", whatever happened to Sun's <href a="Acehttp://research.sun.com/ace">Ace> and Rave ? Is a scripting language that wraps Java and XML as well as Groovy does really superior to Ace and Rave?

When development teams pick Ruby or Ruby on Rails for their projects, they do so because they feel Ruby is better than Java for their project. Conversely, more conservative folks do not look into Ruby because they are familiar with Java, and they feel Java is good enough.

Certainly Ruby, and Ruby on Rails are lacking many things that Java and J2EE have: efficient threading, clustering, refactoring support, etc. Ruby is not as mature as Java. As the author points out, it's in the same position to Java that Java was to C++ 10 years ago. But Ruby on Rails is building on a better foundation than J2EE -- Ruby is a better language than Java. Unlike Java, everything is Ruby is an object. Ruby supports closures naturally. Ruby has better meta-programming support, which makes it easier to create DSL's (domain specific languages), as Rails has done. Java can partially make up for these deficiencies by adding more complexity - generics, auto-boxing, etc. But long term, Ruby (or something like it) has a huge advantage over Java because it's building on a better language foundation. This doesn't mean that we should choose Ruby over Java for all projects, just as it would have been unwise to choose Java over C++ for all projects 10 years ago. But Java developers who ignore Ruby are sticking their heads in the sand.

Ruby is nice, but Ruby as its current state is not fast enough for many type of applications. Java is. Web applications are just one side of the story.

As the author points out, it's in the same position to Java that Java was to C++ 10 years ago.

I do not know where this came from, but Ruby is not anywhere near in the same position as Java 10 years ago.

There no technology boom driving Ruby...like the Internet. That alone inflates the hopes of Ruby ever really becoming more than a marginal offering.

There is no serious financial backing behind Ruby, nothing really pushing it forward other than a few enthusiastic fellows.

Also, Ruby is nowhere near even in the ballpark being as much better than Java, as Java was better than C++. Java is a paradigm shift away from C++, Ruby only has few nuances over Java. Seriously.

All glory to Ruby and its developers, but I don't see a revolution.

I do not know where this came from, but Ruby is not anywhere near in the same position as Java 10 years ago.There no technology boom driving Ruby...like the Internet. That alone inflates the hopes of Ruby ever really becoming more than a marginal offering.There is no serious financial backing behind Ruby, nothing really pushing it forward other than a few enthusiastic fellows.

Fair enough. Much of Java's popularity is due to Sun's hype, and much of it's complexity is due to the need to create markets for tool and application server vendors. Although Linux didn't have any corporate backing at first either. But yes the dot com days are over, so things will move more slowly now in general.

Also, Ruby is nowhere near even in the ballpark being as much better than Java, as Java was better than C++. Java is a paradigm shift away from C++, Ruby only has few nuances over Java. Seriously.All glory to Ruby and its developers, but I don't see a revolution.

How is Java, as a language, a paradigm shift away from C++? I switched from C++ to Java fairly easily; I always though of Java as C++ minus -- no templates, destructors, etc. But no new concepts either. The Java implementation had some import new concepts, new to a C++ developers at least -- garbage collection and the JVM. But of course neither was new with Java. Smalltalk had garbage collection and a virtual machine, for example.

But Ruby is a paradigm shift away from Java. Blocks, closures, open classes, meta-programming, pure object-orientation (even classes are objects), dynamic ('duck') typing -- these things can really rock your world. Combined, they offer a huge productivity benefit. That's why folks are claiming to be able to code Ruby programs in 5 - 10 times less code than the equivalent Java version. And the code is usually cleaner and easier to read too. That's a revolution. (At least to Java developers. If you want to argue that Smalltalk has had all of this for years, I won't argue with you! But Ruby is a very easy language to understand.)

Also, Ruby is nowhere near even in the ballpark being as much better than Java, as Java was better than C++. Java is a paradigm shift away from C++, Ruby only has few nuances over Java. Seriously.All glory to Ruby and its developers, but I don't see a revolution.

How is Java, as a language, a paradigm shift away from C++? I switched from C++ to Java fairly easily; I always though of Java as C++ minus -- no templates, destructors, etc. But no new concepts either. The Java implementation had some import new concepts, new to a C++ developers at least -- garbage collection and the JVM. But of course neither was new with Java. Smalltalk had garbage collection and a virtual machine, for example.

Amen to that. I choke with fury each time I hear ignorant oppinions about Java being an improvement over C++. It's so obviously a mellowed down, half-assed C--, VMised and coming with a fairly large standard library that covers everything from arrays to database integration - and that's what made it work, together with GC.

I choke with fury each time I hear ignorant oppinions about Java being an improvement over C++. It's so obviously a mellowed down, half-assed C--, VMised and coming with a fairly large standard library that covers everything from arrays to database integration - and that's what made it work, together with GC.

Better prepare yourself for more choking then! Having used both C++ and Java since they were first released, I consider Java a huge improvement over C++. Java avoided so many of the mistakes that C++ made that made it a complex language and made so much C++ code unreadable. I was glad to give up C++ with its obscure syntax. C++ definitely needed to be mellowed down!

I choke with fury each time I hear ignorant oppinions about Java being an improvement over C++. It's so obviously a mellowed down, half-assed C--, VMised and coming with a fairly large standard library that covers everything from arrays to database integration - and that's what made it work, together with GC.

Better prepare yourself for more choking then! Having used both C++ and Java since they were first released, I consider Java a huge improvement over C++. Java avoided so many of the mistakes that C++ made that made it a complex language and made so much C++ code unreadable. I was glad to give up C++ with its obscure syntax. C++ definitely needed to be mellowed down!

Steve, you seem to be quite a reasonable fellow, so I'm not choking :)
Consider that C++ is so much more powerful than Java and it is _also_ multi-paradigm. The standard is a huge, complicated, mathematically precise piece of work that's extremely difficult to understand fully and get right when implementing. With power comes complexity. Java cut back on the complexity, while definitely losing power. If what you're saying that Java is thus a lighter, more comfortable, more readable, less error-prone, more entry-level ready etc etc - fine, it's a totaly reasonable oppinion. But, what was never true and never will be is that Java is an improvement as a programming language over C++. That's just not true. C++ offers so much more control and is so much more powerful than Java.
Just out of curiosity, what did you find unreadable about C++ ? I've put about as much effort into understanding the Java generic Enum declaration as I've put into understanding how computation at compile-time using templates.

Steve, you seem to be quite a reasonable fellow, so I'm not choking :)

Thank you!

Consider that C++ is so much more powerful than Java and it is _also_ multi-paradigm. The standard is a huge, complicated, mathematically precise piece of work that's extremely difficult to understand fully and get right when implementing.

I would disagree that it is mathematically precise. There are many issues that a problematic, such as multiple inheritance.

Java cut back on the complexity, while definitely losing power.

As Java is turning up in all sorts of places that used to be where C++ was used - things like real-time control and embedded applications, I can't see that it is that much less powerful.

If what you're saying that Java is thus a lighter, more comfortable, more readable, less error-prone, more entry-level ready etc etc - fine, it's a totaly reasonable oppinion. But, what was never true and never will be is that Java is an improvement as a programming language over C++. That's just not true.

I would argue the reverse. Java is an improvement because it is lighter, more comfortable, more readable, less error-prone. That is progress!

C++ offers so much more control and is so much more powerful than Java.Just out of curiosity, what did you find unreadable about C++ ? I've put about as much effort into understanding the Java generic Enum declaration as I've put into understanding how computation at compile-time using templates.

This has to be a matter of opinion, but, for example, I got into a deep mess a few years back trying to do something that should have been simple: defining a copy constructor for a very simple class. I simply could not believe the obscure and strange error messages I was getting. In the end I gave up, thinking that a modern programming language should not be that obscure!

C++ tries to do far too much, and does it based on the fragile and dangerous foundation that is C's memory handling. That is my opinion anyway.

That's just not true. C++ offers so much more control and is so much more powerful than Java.

Define "powerful".

Actually, don't, it's a silly discussion.

Usenet advocacy groups are filled with megs of discussions on this topic and you simply need to accept the fact that "powerful" means different things to different people.

To some people, manual memory management is powerful and to others, it's the opposite of powerful. And it's just an example among dozens.

--
Cedric

That's just not true. C++ offers so much more control and is so much more powerful than Java.

Define "powerful".Actually, don't, it's a silly discussion.Usenet advocacy groups are filled with megs of discussions on this topic and you simply need to accept the fact that "powerful" means different things to different people.To some people, manual memory management is powerful and to others, it's the opposite of powerful. And it's just an example among dozens.-- Cedric

Agreed, it's a rather sterile debate.
But consider that C++ allows you to write code in different styles (procedural, OO, sorta-functional), whereas Java does not; C++ allows you to perform manual memory management (heap store), semi-automatic memory management (stack allocated objects/destructors/auto_ptr/custom new/alloca()) and automatic memory management (use with some GC library), whereas Java does not. Shall I go on ?.. Just look at the spirit parser framework, that uses operator overloading to allow coders to write almost-BNF straight in the code.

I like Java, I've been writing Java code professionaly for 6 years now. My brainbench java2 exam says "Scored higher than 98% of all previous test takers" - my C++ score is way lower than that (78%). As far as _programming languages_ are concerned, Java is definitely less elegant and less powerful compared to other programming languages, including C++. Again, _at the language level_.


This is a moot point, Java is the new cobol anyway. There's more important stuff in software development than the language you code in.

Well, I also come from a C->C++->Java development and I too disagree STRONGLY that Java is a step backwards. IMO, Java got right everything that C++ did wrong because C++ needed to support C.

Yes, I used to be C++ programmer too, probably C++ compilers are better at this time (my skills are outdated), but is was better to use plain C for "low level" stuff than C++. I think JAVA is better OOP compromise for application development.

This is a moot point, Java is the new cobol anyway. There's more important stuff in software development than the language you code in.

The combination of Java being "powerful enough", and the OSS phenom combine to make the important aspect of Java being the multitude of frameworks and such that surround the core of the language.

Yes, the language is stifling in some ways compared to others, but still mostly capable, and the frameworks leverage it to make it even more useful.

While I see a lot of libraries for things like C++, they're mostly low level -- GUIs, imaging, etc. There are very few frameworks on the same scale as Java. Partially because C++ is in a different space than Java. But, where's "Spring C++" for example.

Ruby on Rails is interesting because of Rails, not because of Ruby. Ruby empowers Rails, certainly, Ruby enable Rails, absolutely, but what is interesting most people, what is getting "the buzz" is not Rubys inherent power, but how Rails leverages it.

Years ago, the Servlet/JSP spec quickly followed by things like Tomcat and Struts made Java "interesting" to a wider audience trying to solve problems. People were using Java because of Servlets, not necessarily specifically because of Java.

Now, with its entrenched base, while something like RoR looks compelling, it needs to be compelling enough to throw away all of the other bits that come along in the Java community.

It's the whole that makes Java powerful, not just the language.

Ruby on Rails is interesting because of Rails, not because of Ruby.

RoR appeals to me because it's a great framework, and because it allows me to code database driven web apps in Ruby, which for me at least is a much more productive and flexible language than Java. YMMV.

Some folks think that the only appealing thing about RoR is the framework itself, so if we just coded RoR in Java (a la Trails), this whole Ruby fad would go away. For me at least, much of the attraction is the language itself, in addition to it's core libraries, and RoR. Trails + Java won't give the same synergy that Ruby + RoR gives. Would Smalltalk (or pick your favorite dynamic language) + a RoR equivalent work as well as RoR? Maybe, maybe not, but that's a different topic.

Would Smalltalk (or pick your favorite dynamic language) + a RoR equivalent work as well as RoR? Maybe, maybe not, but that's a different topic.

Of course it would! There is nothing magic about RoR. For example, there have been very easy-to-use ORMs and MVC web frameworks in Smalltalk for years, and with far more advanced features like continuations. I know this is going to sound like flamebait, but I do see a huge amount of wheel-reinvention going on, often based (I strongly suspect) on simple ignorance of what has been done in other languages.

Here's an interesting blog posted yesterday by Glenn Vanderburg on what Rails is about. He's responding to a posting by Ted Neward.

http://www.vanderburg.org/Blog

A quote:

Ted writes: "Look, guys, at the end of the day, if Rails is about Ruby and the things that a scripting language can do that a compiled, statically-typed language can’t, then Rails definitely has a place in the world and I’ll take the time to learn it." My position is that that’s precisely what Rails is about. Sure, some of the lessons that Rails teaches can be carried across to statically-typed languages just fine, but some of the most important ones simply won’t translate. Rails is a testament to the power of dynamic languages in general, and of Ruby in particular.

Yes, the language is stifling in some ways compared to others, but still mostly capable, and the frameworks leverage it to make it even more useful.

That's what I meant however when I said that Ruby was building on a better foundation. Many Java frameworks and features like dependency injection (Spring), mock object frameworks, AOP, annotations, etc. aren't as necessary in Ruby due to it's extreme object orientation (even classes are objects) and meta-programming facilities. Java has corporate backing and a head-start, but more baggage. Ruby is starting at a higher level of abstraction. It's a higher level language.

I liked C++ but unlike many C++ programmers, I really prefer Java's single inheritance model over C++'s multiple inheritance model. I can remember the nightmares of going through people's code that inherited a single class from 9000 other classes (remember the MFC anyone?).

-Adam

A single class from 9000 other classes? Now that is Power! :)

A single class from 9000 other classes? Now that is Power! :)

Until you have to debug the mess and 10 different subclasses all have a doFoo() method that each do radically different things. :^0

A single class from 9000 other classes? Now that is Power! :)

Until you have to debug the mess and 10 different subclasses all have a doFoo() method that each do radically different things. :^0

Most definitely. Hence the saracism in my post and the irony in certain others.

A single class from 9000 other classes? Now that is Power! :)

Until you have to debug the mess and 10 different subclasses all have a doFoo() method that each do radically different things. :^0

Most definitely. Hence the saracism in my post and the irony in certain others.

oops - sarcasm

Also, Ruby is nowhere near even in the ballpark being as much better than Java, as Java was better than C++. Java is a paradigm shift away from C++, Ruby only has few nuances over Java. Seriously.All glory to Ruby and its developers, but I don't see a revolution.

How is Java, as a language, a paradigm shift away from C++? I switched from C++ to Java fairly easily; I always though of Java as C++ minus -- no templates, destructors, etc. But no new concepts either. The Java implementation had some import new concepts, new to a C++ developers at least -- garbage collection and the JVM. But of course neither was new with Java. Smalltalk had garbage collection and a virtual machine, for example.

Amen to that. I choke with fury each time I hear ignorant oppinions about Java being an improvement over C++. It's so obviously a mellowed down, half-assed C--, VMised and coming with a fairly large standard library that covers everything from arrays to database integration - and that's what made it work, together with GC.

I prefer Java, even just as a language, over C++. I think C++ needed some simplifying. I was just responding to the assertion that C++ to Java was, at the language level, a 'paradigm shift', while Ruby just adds 'nuances' over Java. Features like Dynamic typing, meta-programming, closures, open clases, everything being an object, etc. add up to more than just nuances. To a Java developer, switching to Ruby is a paradigm shift. To a Smalltalk developer, it's not.

Why Ruby and not Smalltalk then? Hard to say. Could be that Ruby just came along at the right time. Or that it's syntax is more palatable to many folks. (I'm not saying that's how one should judge languages, just that some folks do base their impression on superficial syntax issues.) Or it could be that Ruby works well as a scripting language. That makes the barrier to entry really low. Another way of 'nibbling away at the bottem end'. You can start off writing short scripts, that don't even look OO at all, and start using Ruby for scripting tasks. That could be another reason why folks dismiss Ruby as a toy, because the initial syntax looks so simple. But gradually you realize that you have a really powerful yet easy to learn language in your hands, that combines many of the best features of Smalltalk, Lisp and Java.

I think C++ needed some simplifying. I was just responding to the assertion that C++ to Java was, at the language level, a 'paradigm shift', while Ruby just adds 'nuances' over Java.

That's a fascinating perspective because I have the exact opposite impression. To me, Java is a "gentler" C++ (reuse a similar syntax, remove complexity from it and add a few new features) while Ruby is a comlete paradigm shift.

I'm not talking about syntax, of course, but more in terms of functionalities: closures, mix-ins, meta-programming model, etc...

Again, a subject worth discussing but not fighting about.

--
Cedric
http://testng.org

I think C++ needed some simplifying. I was just responding to the assertion that C++ to Java was, at the language level, a 'paradigm shift', while Ruby just adds 'nuances' over Java.

That's a fascinating perspective because I have the exact opposite impression. To me, Java is a "gentler" C++ (reuse a similar syntax, remove complexity from it and add a few new features) while Ruby is a comlete paradigm shift.I'm not talking about syntax, of course, but more in terms of functionalities: closures, mix-ins, meta-programming model, etc...Again, a subject worth discussing but not fighting about.-- Cedrichttp://testng.org

We're in agreement. I think Java to Ruby is closer to a paradigm shift, while C++ to Java is a smaller more evolutionary change. At least at the language level. I was responding (indirectly) to another poster who feels the opposite.

I think C++ needed some simplifying. I was just responding to the assertion that C++ to Java was, at the language level, a 'paradigm shift', while Ruby just adds 'nuances' over Java.

That's a fascinating perspective because I have the exact opposite impression. To me, Java is a "gentler" C++ (reuse a similar syntax, remove complexity from it and add a few new features) while Ruby is a comlete paradigm shift.I'm not talking about syntax, of course, but more in terms of functionalities: closures, mix-ins, meta-programming model, etc...Again, a subject worth discussing but not fighting about.-- Cedrichttp://testng.org

We're in agreement. I think Java to Ruby is closer to a paradigm shift, while C++ to Java is a smaller more evolutionary change. At least at the language level. I was responding (indirectly) to another poster who feels the opposite.

The jump from C++ to Java is huge. To run the same software on many platforms unaltered, to ease the memory management burden, are those fundamental changes. At least for me, those changes are far more impacting than the syntax differences between Java and Ruby.

We're in agreement. I think Java to Ruby is closer to a paradigm shift, while C++ to Java is a smaller more evolutionary change. At least at the language level. I was responding (indirectly) to another poster who feels the opposite.

Exactly. At the language level, Java is not evolutionary at all. It removes a bunch of things, adds a couple, takes nothing to the next step that was already in C++. No, really, think about it. Absolutely nothing that was in C++ is now made easier or better. It just _removes_ things, pointers for instance. Automatic memory management with garbage collection ? That's an _optional_ VM feature, you can have (and there are) a VM that does not implement a GC and is still compliant. It renames pure virtual to interface, removes MI, removes templates only to realise a decade later that people are not _that_ stupid and generic programming is a good thing, then implements it in a hackish manner, removes operator overloading - now roumored to make a come-back, and so on. Now look at how microsoft has managed to bring C++ (granted with some additions) to a managed environment - just like that. No need to chop and hack at the language to do that. Ironic isn't it, the VM we love and trust is written in 1st class C++; it's portable and it's more complex than 99.999% software writen to run on the VM.

Exactly. At the language level, Java is not evolutionary at all. It removes a bunch of things, adds a couple, takes nothing to the next step that was already in C++. No, really, think about it. Absolutely nothing that was in C++ is now made easier or better.

This simply isn't true. Examples of things that were made better or added include the ability to define variables and methods in any order, the addition of range checking to array accesses (a HUGE step forward), the use of a ClassLoader to allow code to be loaded dynamically from a variety of sources.

Hardly 'absolutely nothing'! The equivalence of pointers and arrays, and the lack of range checking in C/C++ has been one of the most serious problems in IT for nearly 20 years.

This simply isn't true. Examples of things that were made better or added include the ability to define variables and methods in any order, the addition of range checking to array accesses (a HUGE step forward), the use of a ClassLoader to allow code to be loaded dynamically from a variety of sources.Hardly 'absolutely nothing'! The equivalence of pointers and arrays, and the lack of range checking in C/C++ has been one of the most serious problems in IT for nearly 20 years.

Granted, array access guaranteed in the JLS is better than C++ that does not mandate that. It's a philosophical issue here: you don't pay for what you don't use. So array checking has been available in C++ for years, at the compiler/library level.
The order of initialisation issue is again due to performance reasons and guarantees, if that's what you mean by "define variables and methods in any order".
Classloaders are not in C++ at the language level, but for when they're needed, libraries are available. I'm sure you've seen hundreds of programs loading plugins, and switching them at runtime.
You don't seem to comment much on the rest of my statements though. They refer to things a bit more abstract than safety and convenience issues, that in C++ were left to be implemented by compiler and library vendors.

I think C++ was a hack at the C language level to solve convenience issues too.

But reinvententing removed C++ features using workarounds in JAVA looks ironic(it happens with most attemts to make things "simple").

I think C++ was a hack at the C language level to solve convenience issues too.

That is so totaly misinformed it's sad. But whatever.

I think C++ was a hack at the C language level to solve convenience issues too.

That is so totaly misinformed it's sad. But whatever.

Why do you think it is a misinformation, C++ just added OOP concepts to C. It solves convenience issues only and It helps C programmers to learn OOP. As I understand JAVA is similar to C++ for the same reason, it solves some convenience issues like modulization at language level ("import").

When I started using C++, the compiler would first convert the C++ to C and then compile. I'm sure it's gotten better since then.

So, I think you have a valid point.

Granted, array access guaranteed in the JLS is better than C++ that does not mandate that. It's a philosophical issue here: you don't pay for what you don't use.

I disagree. Other languages at the time were very safe, and had both range checking AND speed. Pascal, for example.

The order of initialisation issue is again due to performance reasons and guarantees, if that's what you mean by "define variables and methods in any order".

This is not true. It was due to the requirement that C could be a very small language compilable in a single pass.

Classloaders are not in C++ at the language level, but for when they're needed, libraries are available. I'm sure you've seen hundreds of programs loading plugins, and switching them at runtime.

This is not true either, as there is no equivalent in C++ to byte codes. You can do dynamic library loading, but not in a standard, cross-platform way.

You don't seem to comment much on the rest of my statements though.

Because I don't disagree with it!

They refer to things a bit more abstract than safety and convenience issues, that in C++ were left to be implemented by compiler and library vendors.

And that is one of the failings of the language.

I disagree. Other languages at the time were very safe, and had both range checking AND speed. Pascal, for example.

Steve, sorry mate, but that's just hilarious, comparing Pascal to C++.

This is not true. It was due to the requirement that C could be a very small language compilable in a single pass.

Ah so you mean the need for forward declarations then, not the order of initialisation issue.

This is not true either, as there is no equivalent in C++ to byte codes. You can do dynamic library loading, but not in a standard, cross-platform way.

Well, dooh! Obviously there's no bytecodes, and obviously dynamic library loading differs from platform to platform.
But there's libraries to help with the PITA.
And MS got C++ compiled to CIL didn't they...

You don't seem to comment much on the rest of my statements though.

Because I don't disagree with it!

Good, then it's only fair to say so, not just comment on the parts that you disagree with.

As for the the issues left outside the languages, I don't think that's a failing of the language. Quoting Bjarne, hopefully not out of context, "Don't compromise C++ as a systems programming language / 0-overhead principle".

I disagree. Other languages at the time were very safe, and had both range checking AND speed. Pascal, for example.

Steve, sorry mate, but that's just hilarious, comparing Pascal to C++.

Glad to amuse. I was not comparing Pascal to C++. My point was that certain features of C++ (such as having arrays equivalent to pointers) did not provide any significant performance benefit, as other languages that did allow sensible checking of bounds (at least during testing and debugging) provided equal performance. I won't let you get away with saying 'but libraries provided this', this was a fundamental feature of the languages.

Ah so you mean the need for forward declarations then, not the order of initialisation issue.

yes.

Well, dooh! Obviously there's no bytecodes, and obviously dynamic library loading differs from platform to platform.But there's libraries to help with the PITA.And MS got C++ compiled to CIL didn't they...

There have been many examples of C and C++ being compiled to intermediate languages. This does not make the language any safer or more (or less) powerful. The lack of standard bytecodes means that there features of Java that can never be reproduced in C++, no matter how many additional libraries you add.

Good, then it's only fair to say so, not just comment on the parts that you disagree with.

Who says posts have to be fair? Interesting, witty, informative - perhaps - but not fair.

As for the the issues left outside the languages, I don't think that's a failing of the language. Quoting Bjarne, hopefully not out of context, "Don't compromise C++ as a systems programming language / 0-overhead principle".

Of course it is a failing of the language! This means these things aren't guaranteed on each platform and each implementation! Quoting Bjarne on C++ is like quoting Gates on Windows - the phrase "he would say that, wouldn't he" comes to mind.

Maybe it is just me, but I don't feel it is appropriate or safe to code business logic in a systems language....

I'm not sure we are going to make progress, as you seem a huge (and very knowledgable) C++ fan. I'm not - it has 'bitten' me too often. I have spend too much of my career struggling with obscure C++ pointer bugs, which a language not having to allow the freedom of C would not have allowed.

As for the the issues left outside the languages, I don't think that's a failing of the language. Quoting Bjarne, hopefully not out of context, "Don't compromise C++ as a systems programming language / 0-overhead principle".

Yes, it is not systems programming language failing.
 But JAVA is an application development language and this fact doe's not make it good or wrong. JAVA language constructs are similar to C++, but It makes more sence to compare C++ to C (as systems programming languages)

BTW it explains system programming
http://www.ee.ic.ac.uk/docs/software/unix/programming/sys/sysprog.html

Exactly. At the language level, Java is not evolutionary at all. It removes a bunch of things, adds a couple, takes nothing to the next step that was already in C++. No, really, think about it. Absolutely nothing that was in C++ is now made easier or better. It just _removes_ things, pointers for instance. Automatic memory management with garbage collection ? That's an _optional_ VM feature, you can have (and there are) a VM that does not implement a GC and is still compliant. It renames pure virtual to interface, removes MI, removes templates only to realise a decade later that people are not _that_ stupid and generic programming is a good thing, then implements it in a hackish manner, removes operator overloading - now roumored to make a come-back, and so on.

So, a language, absolutely not better than C++, came out of nowhere and made it big? Someone must be selling a lie and the fools are buying. On the contrary, history has already shown Java to have the right stuff, not only as a language but as a mix of commercial backing, standards and so on.

I do not know where this came from, but Ruby is not anywhere near in the same position as Java 10 years ago.There no technology boom driving Ruby...like the Internet. That alone inflates the hopes of Ruby ever really becoming more than a marginal offering.There is no serious financial backing behind Ruby, nothing really pushing it forward other than a few enthusiastic fellows.

Fair enough. Much of Java's popularity is due to Sun's hype, and much of it's complexity is due to the need to create markets for tool and application server vendors.

As I understand free JDK download and applets made JAVA popular 10 years ago, it was not so many free development tools at this time and it was very important for students. RoR is not any kind of JAVA competitor at this time, it must try to take PHP market first (I think it has no chances to become PHP competitor too).

Much of Java's popularity is due to Sun's hype, and much of it's complexity is due to the need to create markets for tool and application server vendors.

An RoR proponent has absolutely no right to accuse Sun of hype ;-)

Java's popularity also had something to do with the fact that it solved a whole bunch of problems that needed to be solved, and it solved them in an elegant manner.

How is Java, as a language, a paradigm shift away from C++? I switched from C++ to Java fairly easily ..

Syntax is just lipstick on a pig. Of course you moved from C++ to Java easily -- that was the plan!

Java is fundamentally different from C++. I know that from experience, not from literature.

Dissing Java is not a good way to market Ruby and RoR. Try sticking to what you like about Ruby.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Syntax is just lipstick on a pig.

Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

Thanks for the laughs. On a more absurd note, does a pig look lovely with lipstick or without? Or should one just barbeque up some ribs and have dinner :)

peter

Much of Java's popularity is due to Sun's hype, and much of it's complexity is due to the need to create markets for tool and application server vendors.

An RoR proponent has absolutely no right to accuse Sun of hype ;-)

OK, fair enough! But Java hype and Rails hype is coming from two different sources. As many have pointed out, RoR does not have any commerical sponsers. The hype is coming from developers, some of whom have a vested interested in Java. A lot of the Java hype came from Sun, or companies selling Java products. I believe that has effected the evolution of Java. As David Geary said of JSF, 'JSF was made for tool vendors, Rails for developers'. Arguably this has lead to some of the complexity of Java. For example instead of simplifying a process, let vendors market tools that help with that process.

How is Java, as a language, a paradigm shift away from C++? I switched from C++ to Java fairly easily ..

Syntax is just lipstick on a pig. Of course you moved from C++ to Java easily -- that was the plan!Java is fundamentally different from C++. I know that from experience, not from literature.Dissing Java is not a good way to market Ruby and RoR. Try sticking to what you like about Ruby.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

Thanks for the link and ad-vert to your Java product. ;) But just to make myself clear: I'm not dissing Java. Criticizing, not dissing. I like Java. I feel Java was a big step forward over C++. I've programmed in Java professionally full-time for 5 years; before that I was programming in C++ full time. Java is much better. I was just making the minor point, in response to a poster saying that the Java language was a 'paradigm shift' from C++ while Ruby just adds 'nuances', that as a language, Java was not a paradigm shift compared to C++. Everyone keeps quoting me on that, skipping the all important 'as a language' qualifier. (Context is everything.)

But this is all a distraction from my main point -- many folks are choosing Java and RoR because they feel it is better, in some ways, than Java. Whether Ruby stole all it's best ideas from Smalltalk and Lisp(as Java stole ideas like a virtual machine, garbage collection, etc. from Smalltalk and Lisp) doesn't address the question of whether, and in what areas, Ruby might be better than Java.

A lot of the Java hype came from Sun, or companies selling Java products. I believe that has effected the evolution of Java.

The way I remember things is that there wasn't that much Java hype when it first appeared; when I encountered promotion of Java it was from enthusiastic fellow developers who had found this small neat language that was truly cross-platform and allowed them to do clever things on their Windows PCs and also on their Solaris and SGI boxes. My personal impression was that the uptake of Java was driven by the developer community. For example, the first ports of Java to Linux were done without any help or encouragement from Sun. The first tools that Sun provided for Java development were hardly an encouragement to use the language!

As David Geary said of JSF, 'JSF was made for tool vendors, Rails for developers'.

There has been a big debate about this statement! (My view is that I would rather have something suitable for easy use in tools).

many folks are choosing Java and RoR because they feel it is better, in some ways, than Java. Whether Ruby stole all it's best ideas from Smalltalk and Lisp(as Java stole ideas like a virtual machine, garbage collection, etc. from Smalltalk and Lisp) doesn't address the question of whether, and in what areas, Ruby might be better than Java.

I think there are other very important factors in the interest in Ruby similar languages. Ruby has a 'cool Open Source' vibe about it, which, for many, contrasts it with the 'controlled by big bad commercial companies' label that some developers place on Java.

I can imagine that if Open Source Java is successful, then much of the fuss around languages like Ruby will fade away.

Probably before then, some other language or framework will temporarily be the 'next big thing'...

many folks are choosing Java and RoR because they feel it is better, in some ways, than Java.

People like to sell Ruby with RoR and RoR with Ruby. To many RoR is the killer application, and they put all their money on it. The proponents keep beating on their drums, pulling out comparisons between JEE and RoR, never mind that the whole setting is absurd.

RoR is just a framework. Similar frameworks are available for Java as well (Trails, and others). RoR is not something that is unique to Ruby like RoR proponents are trying to sell it. Oddly enough, these Java frameworks do not really break any news and people are not rushing to use them. Why would somethign so 'revolutionary' be ignored?

Interestingly, do you ever hear anything else about Ruby? Not much, if anything.

When development teams pick Ruby or Ruby on Rails for their projects, they do so because they feel Ruby is better than Java for their project. Conversely, more conservative folks do not look into Ruby because they are familiar with Java, and they feel Java is good enough.

I can understand your view that Ruby is a better language than Java. However, is Ruby better than everything else? There's THOUSANDS of scripting languages. What makes Ruby better than all of them that we have to endure these endless Ruby posts?

Of course, there's always something better. If not today, then tomorrow. The question is: is it better enough? I have yet to see anything remotely scietific that shows Ruby (or any other language) to be significantly better than Java. All I see is annecdotes of guys talking about how they made a simple webapp in a couple of hours.

I can understand your view that Ruby is a better language than Java. However, is Ruby better than everything else? There's THOUSANDS of scripting languages. What makes Ruby better than all of them that we have to endure these endless Ruby posts? Of course, there's always something better. If not today, then tomorrow. The question is: is it better enough? I have yet to see anything remotely scietific that shows Ruby (or any other language) to be significantly better than Java. All I see is annecdotes of guys talking about how they made a simple webapp in a couple of hours.

Better enough for what? If you're doing a new project, and A is better than B, why not pick the better tool? Well, I guess becuase one is more comfortable with B -- thus Java is 'good enough'. Kind of faint praise though. As a developer, I serve my customers best if I use the best tools out there. Might as well learn them.

Accounts of writing a Ruby application with 5 to 10 times less code than the Java version (and fewer lines Ruby code than lines in the J2EE version's XML configuration files) are at least semi-scientific, as they at least involve measurable numbers. But as an industry we do not have a good way of measuring productivity. Ultimately all we have to go on is personal experience, and the experience of those we trust. If expert Java guys like Mike Clark, Bruce Tate (Better Faster Lighter), James Duncan Davidson (creator of Ant) and others are getting into Ruby, that says something.

Is Ruby the best dynamic language out there? I have no idea. I do think that Ruby is better than Python or Groovy. There are thousands of statically typed languages as well (Nice, Eiffel, Objective C...). Is Java the best? Among languages that are currently popular, have solid documentation, a good set of standard libraries and a decent sized user community, Ruby may be one of the best.

To be clear: I am not saying that Ruby is ready to replace Java. Just that it may be better, perhaps a lot better, for some projects, and the number of projects that it would be a good fit for will probably only increase over time. We all need to get out more, learn something else besides just Java!

The problem is that, while learning a language is easy, learning all the libraries and tools that go with it can take a very long time. It's not easy being good in more than one language for this very reason. I can spend hours just trying to keep up with all the latest crap that's happening in the Java world. There's only so many hours in a day. So, for me, at least I have to pick one thing and go with it. That's not to say I couldn't pick up something like Ruby for the sake of doing some quick scripts on occassion but that's all it would ever be. Of course, if all I need it for is the occassional script, then I would be better off with Groovy since it's the same syntax as Java and has most of the features that people seem to think makes Ruby so wonderful. At the end of the day I just don't see how Ruby helps me.

Ultimately all we have to go on is personal experience, and the experience of those we trust. If expert Java guys like Mike Clark, Bruce Tate (Better Faster Lighter), James Duncan Davidson (creator of Ant) and others are getting into Ruby, that says something.

Actually, I have to disagree with this. This has become the accepted norm but I don't think it's right. "Computer scientists" should start thinking more about the "science" part of development. There's too much heresay, annecdotes, etc. that prove, in the long term, to be either questionable, overly simplistic, or flat wrong. Almost every article I read about a new Ruby convert has that smell of a kid with a new toy. I can appreciate their excitement but it really isn't useful at all for making a decision on a language. I find it especially discouraging considering that the features they rave about have been in Smalltalk for 20 years. There's nothing new here.

Of course, science, heresay, etc. aside, ultimately the market will make the decision for me. The first question I have to ask is: can I get a job doing this? If the answer is "no", then I really don't care how cool language is. I've tried being the techno-idealist before and it's just too painful.

But Ruby on Rails is building on a better foundation than J2EE -- Ruby is a better language than Java. Unlike Java, everything is Ruby is an object. Ruby supports closures naturally. Ruby has better meta-programming support, which makes it easier to create DSL's (domain specific languages), as Rails has done. Java can partially make up for these deficiencies by adding more complexity - generics, auto-boxing, etc. But long term, Ruby (or something like it) has a huge advantage over Java because it's building on a better language foundation.

*sigh*

And Common Lisp towers over both Ruby and Java and still sits adrift.

The only thing that make RoR interesting is simply the "Rails" part. Ruby has been around for quite some time. It's the Rails part that is grabbing the attention. There's nothing spectacular that happened to Ruby that made Rails possible, no new feature that made Hansson suddenly go "ah HA! This is exactly what I was missing!" and off running to RoR fandom and fame. There are intriguing frameworks for other dynamic languages, languages that are far more mature than Ruby. But Ruby gets the spotlight for the day.

Can Rails be written in Common Lisp? Yup, there's a project already on it. Python? Maybe. Perl 6 when it arrives? Certainly. Scheme? Sure.

Then we have the Trails framework leveraging all of the other work already in the Java space.

The framework is what makes this work.

Are these other ones "also rans" following Rails footsteps? Well, they're certainly inspired by Rails.

So, while RoR is the current Flash in the Pan, that's pretty much all it is, because while the framework is the magic, the language is what provides the foundation for it, and the language that will give it new life. RoR will only get as big as Ruby gets, even with new adopters. If Java Trails is "clsoe enough" to offer enough benefits for Java, then we get the "industrial strength" of the JVM and the containers in which to deploy applications "for free", something Ruby won't have for a long long time.

Sun, IBM and others have poured a boatload of money into strengthening the Java platform. IBM has traveled down the dynamic language route with its LARGE Smalltalk effort, which it has since abandoned because it found another large company willing to create an adequate platform that offered enough of what the Smalltalk environment provided. Smalltalk is now dead at IBM.

So, unless a company like Sun decided to pick up the Ruby Ball and run with it, Ruby won't penetrate well into the corporate space.

The only thing that make RoR interesting is simply the "Rails" part. Ruby has been around for quite some time. It's the Rails part that is grabbing the attention.

Actually lots of smart folks (Dave Thomas, Martin Fowler) have been Ruby fans for quite a while. Rails was bound to happen -- the DNA for it was in the language. And there are several other intersting Web and O/R mapper Ruby frameworks. Ruby is a very good language, much easier to read for most folks than common lisp, and more consitently OO. Way better than Java.

There's nothing spectacular that happened to Ruby that made Rails possible, no new feature that made Hansson suddenly go "ah HA! This is exactly what I was missing!" and off running to RoR fandom and fame.

Actually, there was: it's much easier to write DSL's in a dynamic language that supports meta-programming, like Lisp, Smalltalk, or Ruby, than Java. Why not Lisp or Smalltalk? Well, most folks find these languages hard to read and get started with. Can you do meta-programming in Java, with annotations? Yes, sort of, and that's where Trails comes in. But it's not quite the same. Anotations are another example of and older technology adding more complexity to play catch up with a newer, cleaner technology.

IBM has traveled down the dynamic language route with its LARGE Smalltalk effort, which it has since abandoned because it found another large company willing to create an adequate platform that offered enough of what the Smalltalk environment provided. Smalltalk is now dead at IBM. So, unless a company like Sun decided to pick up the Ruby Ball and run with it, Ruby won't penetrate well into the corporate space.

Good point; the best technology doesn't always win. Java wasn't revolutionary, but it had more hype. Still, open source tools like Apache, Linux, and Perl (strictly for scripting) have made some headway into the corporation, with major industry backing, at least intially. And if Ruby gets popular enough at the bottom end of the market, someone will pick it up.

The world may not have been ready for dynamic languages 10 years ago. Among other things because they were too slow. But machines are faster now, and for many apps the bottleneck isn't the CPU. Kind of reminds me of how us C++ folks used to bash Java back in the day, saying "Yeah, virtual machines, garbage collection -- lot's of esoteric languages like Smalltalk and Lisp tried to sell those concepts before. Java's a flash in the pan, it will never catch on."

But Java is a sitting duck. Some sort of dynamic language will replace it, eventually.

with major industry backing, at least intially

Sorry, should read:

without major industry backing...

Some sort of dynamic language will replace it, eventually.

I fail to see the argument here. There is a project call http://jruby.sourceforge.net/ JRuby, so the argument doesn't hold any water. I like ruby and the dynamic features it provides, but to claim that Java or J2EE is dead because Ruby is dynamic is untrue.

There a half dozen scripting languages out there for JVM, so there's a mountain of proof that Java is incapable of providing the kinds of features Ruby provides. I think there are changes SUN could implement to make it easier to write dynamic scripting languages for Java, but clearly it can be done. I code in LISP syntax within JESS rule engine just fine, so clearly java is very capable.

In fact, I'd argue that using something like JRuby provides the syntax sugar and dynamic features some people prefer with the ability to use existing mature products in a relatively seamless way. I've never used JRuby on a project and only read the samples. Perhaps someone that has used JRuby can post a comment.

peter

serves me right for not proof reading. I meant "there's a mountain of proof java is capable".

good nite before my brain rots further

peter

Actually lots of smart folks (Dave Thomas, Martin Fowler) have been Ruby fans for quite a while.

A lot of smart folks are/were CL and ST advocates as well. Lets reference Gregor Kiczales, for example.

Actually, there was: it's much easier to write DSL's in a dynamic language that supports meta-programming, like Lisp, Smalltalk, or Ruby, than Java. Why not Lisp or Smalltalk? Well, most folks find these languages hard to read and get started with.

And any advocate of their environment will tell you that folks didn't more handwaved CL or ST based on it "looking funny" rather than actually trying it. Syntax bigots, and baby out with the bathwater type people.

My point was that Ruby has had the power for Rails for quite some time, nothing special (save for Hansson just Doing It) enabled it over CL or ST. He could have easily picked any of them.

Good point; the best technology doesn't always win. Java wasn't revolutionary, but it had more hype.

What Java had was Sun smart enough to essentially give it away and rally the rest of the industry around its standards. You can call that hype, but for whatever reason IBM felt it in their best interest to replace the Smalltalk program that they had invested heavily in, no doubt hyped themselves, and had proven experience and deployments with, with an unproven Java program and EJB.

That's a VERY curious thing to do, don't you think? That change over was not cheap, but they felt it worth doing.

Still, open source tools like Apache, Linux, and Perl (strictly for scripting) have made some headway into the corporation, with major industry backing, at least intially. And if Ruby gets popular enough at the bottom end of the market, someone will pick it up.

The commerical webservers weren't "better enough" for most deployments thatn Apache was, most folks STILL use Apache 1.3.x, which has been developmentally dead for several years, and 2.0 doesn't have much force behind it, and certainly no corporate advocate selling it to industry.

Save for Linux and IBM/RedHat, very few OSS projects have a large company behind them, and notably, none of the languages do. Python, Perl, PHP, Ruby, etc. You have ActiveState selling tools AROUND Python and Perl, but I don't know that they're improving the internals of the languages so much. I have NO idea who is funding Wall and Perl 6.

Part of IBM's attraction to Java was the fact that Sun was behind it, and developing it hard. I don't know anyone who is working to get any of the other languages performing well on large N-Way SMP servers, for example. The others may be picking low hanging fruit from Suns and other JVM research, but there doesn't seem to be a major force behind them.

Python and Perl have both been around longer than Java, and while certainly very capable for web CGI, haven't made the leap to where Java is, and no one has picked them up to lift them. Both of them could have ridden the "Internet Boom" wave. Python's ZOPE barely made a ripple, though I'd argue that Perl certainly succeeded, but never really broke through to the Enterprise and back office off the web tier(yes I know large sites run Perl).

So, yea, someone COULD pick up Ruby, but I'm not going to hold my breath.

The world may not have been ready for dynamic languages 10 years ago. Among other things because they were too slow. But machines are faster now, and for many apps the bottleneck isn't the CPU.

Absolutely, but here's the deal. Dynamic languages WERE here 10 years ago, and they performed well even then. GC has gotten better over time, but Smalltalk was well proven 10 years ago, and Common Lisp has been "industrial strength" for quite some time. Most of the "problems" with Dynamic languages have been worked out out for quite some time. The biggest addition that Java has added to the pot is better JITs, better GC, and a lot more experience with multi-threading across CPUs (a rarer beast back in the day), but most of that started in the Self project, and that was 10 years ago.

But Java is a sitting duck. Some sort of dynamic language will replace it, eventually.

The problem with the dynamic languages is simply that -- they're dynamic. Their power and passion and benefit is their curse. All of that flexibility TENDS to become unmanageable in large projects with lots of people.

Many folks lament that lack of static type checking during builds that are not available within most dynamic languages.

Dylan worked out a nice balance between the two issues, but never caught on. Common Lisp CAN be made to work that way, but, of course, it hinders the dynamic nature of the development, and most of the time you type your code for performance.

Look at the classic concepts of scope within Java and C++, things like private and protected. These concepts keep coming back in languages, this ability to lock the interface down and completely hide (and more importantly, protect) the implementation.

For large projects, with assembly line "coders", it IS important to protect the programmer from himself. One of the key tenets in Java is to do that, keep it "safe". Dynamic language, by definition, are "unsafe". There are many ways to do odd things that will not crop up until runtime.

Corporations like "safe". Safe is predictable. Safe is schedulable. Safe makes planning easier, especially in the dynamic environment of software development.

AOP, for example, is welcomed in to the Java community, not with open arms, but with scrutiny, with distrust. Some folks love it, others loathe it specifically because of its dynamic nature. They want things more explicit in their code. They want the code to do what it says it's going to do. AOP tends to blur the edges of dynamic coding and static Java.

Note, I love dynamic languages. I am a Common Lisp "Fanboy", but I'm not the world. I am glad we're not using something as flexible as Common Lisp on my project with the team I have here, and I imagine my team is just like most every other team with it's combination of Stars and dim bulbs. The wild goose chases alone would be just be murder.

When you're alone, when you're working in a very small group of similar minded and talented people, dynamic languages can be very powerful. But to mis-quote "Men in Black": "Yes, Programmers are smart, but Projects are stupid, panicky animals and you know it."

Communication is the killer in large groups, and it's too easy to play "telephone", where what's said at one end gets corrupted and confused by the time it goes through several people, with a dynamic language than a more static one that enforces barriers along each step of the path.

So, dynamic languages will have their place, and they're wonderful tools, but until you change the people, I fear you're not going to be able to change the process to where a dynamic language really goes mainstream.

Some good points. But I think the argument has shifted slightly from Jason's original assertion that "Java is better, but Ruby is cheaper and 'good-enough' for many projects", to "OK, maybe Ruby is better than Java in some ways, but better doesn't always win; Ruby will never over take Java because it doesn't have corporate backing so I don't need to learn it", etc. Many of the posts are tacitly admitting that Ruby is better than Java in some ways. (But it's not better than X, Y or Z! OK, maybe, but it's still a better choice than Java for some projects.) The main point of my original post was to dispel the idea that Ruby as a language is inferior to Java, a play to for CS students who aren't smart enough to learn Java. As a language, Ruby is better than Java. For smaller teams, Ruby and RoR might be a better choice than Java for some projects. Better for the business because you can develop a scalable, more maintainable and flexible application faster. Now I can't predict the future. I don't know how far Ruby will catch on. But at a certain level I'm not sure if I care. Some folks are choosing Ruby because they feel it is better than Java for their project. And the Ruby community is large enough that you don't have to fear it will just go away. Ruby will be around for a long time.

Common Lisp CAN be made to work that way, but, of course, it hinders the dynamic nature of the development, and most of the time you type your code for performance.Look at the classic concepts of scope within Java and C++, things like private and protected. These concepts keep coming back in languages, this ability to lock the interface down and completely hide (and more importantly, protect) the implementation. For large projects, with assembly line "coders", it IS important to protect the programmer from himself. One of the key tenets in Java is to do that, keep it "safe". Dynamic language, by definition, are "unsafe". There are many ways to do odd things that will not crop up until runtime.Corporations like "safe". Safe is predictable. Safe is schedulable. Safe makes planning easier, especially in the dynamic environment of software development.

This is perhaps the core difference. But consider this: why not off-shore those large assembly line projects? If you want a safe, predictable assembly line, why not go with cheaper workers? I know, the first wave of off-shoring didn't steal all our jobs. But they'll get better. To stay competitive on-shore, we need to raise the level of abstraction. The future of on-shore development might be smaller teams using higher level tools that increase productivity dramatically -- like dynamic languages. That evens things up again. And the dim bulbs might lose their jobs.

I think Jason's main point is valid. Ruby (or something else like it) will continue to nibble away at Java from the bottom end. But not because Ruby is 'good enough and cheaper', but because Ruby is better and more productive for smaller or more flexible projects, where there isn't a huge corporate investment in Java. Ruby is the innovator, not Java. (Ruby is the innovator in relation to Java, not necessarily in relation to Smalltalk or whatever.)

However, it's unfair to say that dynamic languages are "unsafe by definition". Ruby is strongly typed. But the checking occurs runtime, not at compile time. Ruby has 'projected' and 'private' just like Java. Yes those are good ideas. Again, it's just that it's enforced at runtime. If you've ever gotten a ClassCastException, you know that many things in Java are enforced at runtime as well. And Java is gradually becoming a more dynamic system anyway, with annotations, AOP, byte code manipulation, proxies, lazy loading proxies like Hibernate uses, etc. It's just that it's all kind of ad-hoc. In a dynamic system, you may need more unit tests. But if you're keen on safety, you'd be doing that anyway.

Some good points. But I think the argument has shifted slightly from Jason's original assertion that "Java is better, but Ruby is cheaper and 'good-enough' for many projects", to "OK, maybe Ruby is better than Java in some ways, but better doesn't always win; Ruby will never over take Java because it doesn't have corporate backing so I don't need to learn it", etc. Many of the posts are tacitly admitting that Ruby is better than Java in some ways. (But it's not better than X, Y or Z! OK, maybe, but it's still a better choice than Java for some projects.) The main point of my original post was to dispel the idea that Ruby as a language is inferior to Java, a play to for CS students who aren't smart enough to learn Java. As a language, Ruby is better than Java. For smaller teams, Ruby and RoR might be a better choice than Java for some projects.

Does that all depend on what "better" means to each person? I've met plenty of guys who were whizzes at Perl, but were horrible at OOP. I've also met plenty of VB guys who couldn't get C#. If you look at the JESS mailing list, you'll see that declarative programming using LISP style syntax has a big learning curve.

It's better to you, but others are different. Some people simply can't think declaratively and see things crystal clear in imperative languages. Each language has strengths and weaknesses and there are no clear winners. It's rather easy to create artifical scenarios to prove one language is "better" than language X.

peter

It's better to you, but others are different.

Fair enough. Again, I'm just trying to correct the original assertion that 'Java is better, Ruby is good enough'. For many, Ruby is better. I wouldn't say that folks choose Ruby or RoR because they feel it's not as good as Java, but 'good enough'. They probably choose Ruby/RoR because they feel it's better for their project.

Ruby is the innovator, not Java.

Ruby isn't that innovative at all. It is based on many previous languages, and lacks many of the features that implementations of those languages have posessed as standard for a long time: refactoring browsers, interactive debuggers and object inspectors, high-performance VMs etc.

Better for the business because you can develop a scalable, more maintainable and flexible application faster.

There has been detailed discussion in previous threads about technical issues with Rails that mean that at least some of us would argue strongly that it works against maintainability and flexibility.

Ruby is the innovator, not Java.

Ruby isn't that innovative at all. It is based on many previous languages, and lacks many of the features that implementations of those languages have posessed as standard for a long time: refactoring browsers, interactive debuggers and object inspectors, high-performance VMs etc.

OK, I'm getting misquoted again (a sign that the argument has degraded). Here's the full quote:

Ruby is the innovator, not Java. (Ruby is the innovator in relation to Java, not necessarily in relation to Smalltalk or whatever.)

If you had read the second sentence I think that would have addressed all your objections. Yes, Ruby stole from Smalltalk and Lisp. Likewise, many of the innovative features that Java had compared to C++, like garbage collection and a virtual machine, were also stolen from Smalltalk and Lisp. But, when choosing between C++ and Java, that's irrelevant and a distraction. Likewise when choosing between Ruby and Java. Back to my original point -- for some applications, many folks feel Ruby is better, not just 'good enough', than Java.

OK, I'm getting misquoted again (a sign that the argument has degraded).

You weren't misquoted. I assumed that sentence could stand alone, as it did not seem to me to connect to the following one.

Here's the full quote:

Ruby is the innovator, not Java. (Ruby is the innovator in relation to Java, not necessarily in relation to Smalltalk or whatever.)

If you had read the second sentence I think that would have addressed all your objections. Yes, Ruby stole from Smalltalk and Lisp.

This did not address my objections, as stealing from those languages (although that is a harsh term) is certainly not innovation.

Likewise, many of the innovative features that Java had compared to C++, like garbage collection and a virtual machine, were also stolen from Smalltalk and Lisp.

Likewise, Java is not innovating in these areas either.

'Innovation' is a much misused term. Innovation is the implementation of new ideas, or significant improvements on existing ones. This is why I disagree with your use of it.

Ruby is the innovator, not Java.

Ruby isn't that innovative at all. It is based on many previous languagesWell, sure, like pretty much any other language out there.

and lacks many of the features that implementations of those languages have posessed as standard for a long time: refactoring browsers, interactive debuggers and object inspectors, high-performance VMs etc.

Fair enough, but I would argue you are talking about the Ruby "platform", not the Ruby "language".

By my standards, the Ruby language is quite innovative. Even though I can probably relate every single Ruby feature to an older language, the fact is that Ruby combined all these features in a very elegant and compelling manner.

--
Cedric

Doh, let me try again, with proper quoting this time (I hope).

Ruby isn't that innovative at all. It is based on many previous languages

Well, sure, like pretty much any other language out there.

and lacks many of the features that implementations of those languages have posessed as standard for a long time: refactoring browsers, interactive debuggers and object inspectors, high-performance VMs etc.

Fair enough, but I would argue you are talking about the Ruby "platform", not the Ruby "language".By my standards, the Ruby language is quite innovative. Even though I can probably relate every single Ruby feature to an older language, the fact is that Ruby combined all these features in a very elegant and compelling manner.

--
Cedric

Ruby is the innovator, not Java.

Ruby isn't that innovative at all. It is based on many previous languages

Well, sure, like pretty much any other language out there.

exactly.

and lacks many of the features that implementations of those languages have posessed as standard for a long time: refactoring browsers, interactive debuggers and object inspectors, high-performance VMs etc.

Fair enough, but I would argue you are talking about the Ruby "platform", not the Ruby "language".

I think it is hard to separate the two - I mean who uses a language without the associated platform? Virtually no-one uses Smalltalk as a stand-alone language. I find a language that does not have any associated full-featured platform or IDE to be unappealing, and a huge step backwards in the way that development is done.

By my standards, the Ruby language is quite innovative. Even though I can probably relate every single Ruby feature to an older language, the fact is that Ruby combined all these features in a very elegant and compelling manner.-- Cedric

Maybe it is just me, but I think Ruby is plain ugly in many ways. One example is the way that prefixes are used to indicate scopes of variables (local/global/instance) - this would seem to me to make re-use of code in different contexts awkward.

Piqued by some of the conversations here, I downloaded RoR, to do "Four Days on Rails".

I did like the ability to pull and integrate dependencies from remote locations, and the ability to generate the framework of a CRUD application by pointing at a database.

On the other hand, I never could get fastcgi integration to work, so it was a very sloooooooooooooow experience. I'm afraid I gave up on the tutorial in frustration because the examples were so slow to run.

Richard Gabriel, in "The Rise of 'Worse is Better'", made the point that a technology doesn't have to be perfect, just good enough on the average machine. I don't think RoR's there yet.

Developing webapps with Java doesn't need a new "disruptive" framework, or whole new language. I simply needs to get easier. There are a few steps Sun could take to simply make developing webapps /easier/. All you have to do is talk to a few PHP programmers to hear the top level gripes about Java and webapps. They'll tell you.

1) Cut out the deployment step. At least make it optional. It's insane that I have to do any work at all to see if my change worked or not. With PHP, I simply edit the file, and then reload the page.

2) Allow for explicit destruction of a Classloader. This will immediately solve all the "hot deployment doesn't work" issues. Memory leaks on redeploy, which are the central bane of java webapp development, will be a thing of the past. Imagine, just for a second, that the first E in JEE actually means Enterprise, and that you can keep Tomcat up and running 24/7 after deployments and undeployments of applications. See issue #1 above.

3) Run, don't walk, to a MVM and isolates. Give each application running its own space inside a JVM. This, again, will keep the app server running longer and remove the frustrations with deployment. Again, I can't simply redeploy an app because there will be a memory leak, which forces me to bounce my app server. Introduce isolates and a transparent app reloading scheme. Never let me, as a developer, know that my app is "reloading".

4) Acknowledge that most developers play the "deployer" role. Cut the time from software change to confirmation that it worked. To near zero. PHP and RoR seems to have gotten this right.

I think it's premature to run to Ruby on Rails. Java has a very mature library and its IDEs are top notch. Giving up Eclipse is a very hard thing.

So please, let me keep programming in Java. Just stop making me jump through so many hoops just to develop webapps. It can be easier, but it requires a mindshare change.

Why do you think RoR is so popular, other than it addresses the issues above? It's because there's no more choice involved! No more "Should I use iBATIS, or JDO, or Hibernate?" No more "Should I use Struts, Spring MVC, WebWork, etc etc etc?" When RoR developers get together, they are all talking the same language. That's a good thing. When Java developers get together, all we talk about is How <insert framework> sucks, <insert another framework> is so much better.

Imagine, for a second, if someone said "Here's the stack you'll use to build webapps. This is it, nothing else." Would Java developers allow that? Or would they simply say, "Yeah, but what if I want to change X? I want to use Y!"

Seth Ladd wrote (sorry, "Quote Original Message" doesn't seem to work in Opera):

<quote>
2) Allow for explicit destruction of a Classloader. This will immediately solve all the "hot deployment doesn't work" issues. Memory leaks on redeploy, which are the central bane of java webapp development, will be a thing of the past. Imagine, just for a second, that the first E in JEE actually means Enterprise, and that you can keep Tomcat up and running 24/7 after deployments and undeployments of applications. See issue #1 above.
</quote>

This isn't required, and actually flies in the face of automatic memory management. The only thing we need is to have those bitter bugs fixed that cause JVM internals (i.e. HotSpot etc.) to keep a private strong reference to class loaders, this one being the biggest culprit: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990

It only has 34 votes at the moment -- would need at least 30 more to appear in the "Top 25 Bugs" listing, so if you feel like it, go over there and vote for it.

The question is - will Sun listen? My fear is they're too worried about the mega-enterprise customer to care.

What do you think?

This seems more suited to Slashdot; they regularly post 'Java is dying or doomed' articles. Java is showing no signs of declining; on the contrary, it is expanding into areas such as real-time and embedded applications and high-performance numerical work. Java use is growing to the extent where it is poised to take over from C++ as the most used development language.

The problem with frameworks such as Ruby on Rails is not that they promise less - on the contrary, they are frequently put forwards as scalable, robust full-replacements for J2EE.

As for mental effort, I would rather handle development, debugging and refactoring with Java in a full-featured and well-designed IDE with compile-time checks and plug-ins to help with many areas of development than a script-based system like Ruby.

There will always be room for new (or even re-hashed) ideas. Java can be, and has been, influenced by these (look at the effect of Spring and Hibernate).

I would rather handle development, debugging and refactoring with Java in a full-featured and well-designed IDE with compile-time checks and plug-ins to help with many areas of development than a script-based system like Ruby.

Totally agree on that one , but what if you have all that and can script java while developing and compile on deployment. Man that would be the perfect world for me. I have read somewhere that the guy who wrote the "hot code replace" actually wanted to achieve this but the people above him didn't thought we where all waiting for that. Well let me scream out , I am waiting for that!!! It is possible I know it.

but what if you have all that and can script java while developing and compile on deployment. Man that would be the perfect world for me.

Me too! I am hoping that a combination of Java and Groovy in a modern IDE will work like this soon.

Something that I dislike is when languages like Ruby say that they are based in some ways on Smalltalk. Smalltalk was not just a language, it was an environment - a dynamic system for creating objects, exploring them and debugging them. Anything that claims to be related to Smalltalk should have equal capabilities - after all, if Smalltalk could fit a full graphical IDE and GUI in a few MB in the 80s, what is holding languages like Ruby and Python back from doing that?

My advice to Sun: Own the disruptive technology. Create a group of 7 creative engineers and charge them with approaching the problem from beneath. Tell them to come up with technology that's "good enough" and a whole lot easier. To be modern, it must solve the full web application problem, not just help with individual pages. It must also be AJAX-enabled through and through. Tell this team they aren't required to leverage existing Java libraries unless they want to. Their only requirement is that this new technology should run on the Java Virtual Machine (JRuby or Groovy would be fine, if the team so judged). This should be what's important to Sun. Give the team six months to produce an early prototype. Their eventual success will be judged on if they can eat into Java EE's mindshare. If Sun doesn't start providing Java heads with "cheaper" technology, someone else will. They already are.

As long as businesses are serious enough to run their business as business, they will go for the better solution, rather than just "good enough" solution. Most of the companies that use Java today, are not building Toy projects, and I believe that would be same case in next 10 years or so!

And by the way, what exactly merits this blog to appear in TSS?? (Editor's authority?) May be, you should send this material to Hani, this will raise his Bile level beyond limits, I guess!

As long as businesses are serious enough to run their business as business, they will go for the better solution, rather than just "good enough" solution. Most of the companies that use Java today, are not building Toy projects, and I believe that would be same case in next 10 years or so!

You need to read the book. Digital had the machines that serious businesses wanted. PC's were toys that could barely do anything. They were cheap so more people could afford them, then they got good enough that they could do enough to put Digital out of business. RoR is a toy that most CS students can use to make a ToDo list app in a weekend. If it evolves to where a compentent professional can make a CRM package in a few weeks... Sure, that's a big if, but the point is that Java and all it's frameworks are moving up the stack. Something will come along at the low end of the stack that is good enough and change the whole game. People who are stuck on Java as the be-all/end-all are in for a rude awakening.

I just want to say this is a wonderful eye opener. Jason is in no way saying that Java is doomed, but rather it's taking it's place among the greats.

I've been thinking for a long time that there's a need for a solid Web Development language. Not a language that has frameworks and libraries that help you write web applications, rather something that was designed from the ground up around working with HTML and HTTP.

So far aside from PHP, it looks like Rails is the closest we've got to this.

..Not a language that has frameworks and libraries that help you write web applications, rather something that was designed from the ground up around working with HTML and HTTP.

So far aside from PHP, it looks like Rails is the closest we've got to this.

But Rails isn't such a language. It isn't even a language as such. It is simply a framework and set of libraries for Ruby that help you write web applications.

But Rails isn't such a language. It isn't even a language as such. It is simply a framework and set of libraries for Ruby that help you write web applications.

Rails is a DSL for web apps.

But Rails isn't such a language. It isn't even a language as such. It is simply a framework and set of libraries for Ruby that help you write web applications.

Rails is a DSL for web apps.

If that is the case, then I would say that Struts/Spring/Hibernate (SSH) would be cable. It is faster, more scalable, and more common.

At my company we are really hitting the sweet spot of the work done using SSH for projects small and medium(or niche has yet had any large apps). And customers are noticing. I had a meeting with a customer last week to discuss the SSH framework being used deliver their application, and it appeared to be a success. Their internal developers were pleased with our choices. I informed then how their project is the 4th or 5th being developed on a mature codebase that powers small and medium applications alike.

That is appealing. I'm about to turn over a small one to another developer. Instead of using ROR, he is using the same framework that the larger applications use.

Guess what? That throw together app is now being enhanced with more features and last week my manager requested that I move it to the production system.

Prototypes become production, gentlemen. It is a marathon not a sprint.

Another new person who just started is working on another application based on the same framework and when he is done, he can jump to practically anything we have in house.

I'll take that kind of stable, resuable code over something that has questionable productivity advantages any day.

One more thing, we are in the early stages of evaluating Tapestry and JSF for view technologies. Our framework can easily incorporate those.

I think he meant a different kind of DSL.

It was a joke. Perhaps a smiley? :-) My points were the SSH stuff!

But Rails isn't such a language. It isn't even a language as such. It is simply a framework and set of libraries for Ruby that help you write web applications.

Rails is a DSL for web apps.

No it isn't. Let me quote from the Ruby on Rails website:

"Rails is a full-stack, open-source web framework in Ruby"

Actually, Cold Fusion is by far the best solution for writing web applications quickly and effectively. Of course, it is not open source. I think it is a lot easier to use than php. For commercial use, paying about $1.500 for the low end version, is earned in one day of programmer's hours saved. There are also some MVC frameworks around based on Cold Fusion.

My biggest gripe with these kinds of languages is the lack of solid IDE support.

Marc

Why should sun be responsible for creating it? Why can't a couple of OSS Java guys do exactly the same with less resources and time :)

Just playing devil's advocate. I see no reason SUN has to be the one to fund it. Why can't IBM, Novell, RedHat or some other group whip up a framework that improves on ROR? Not that I work on small projects anymore, but I think there's plenty of room for people to innovate or re-invent a better tire.

peter

Why should sun be responsible for creating it? Why can't a couple of OSS Java guys do exactly the same with less resources and time :)Just playing devil's advocate. I see no reason SUN has to be the one to fund it. Why can't IBM, Novell, RedHat or some other group whip up a framework that improves on ROR? Not that I work on small projects anymore, but I think there's plenty of room for people to innovate or re-invent a better tire.peter

That's right. Why Sun? Sun is a hardware company, is it not? Except the silly coffee mug, what else does Sun have to offer?

That's right. Why Sun? Sun is a hardware company, is it not? Except the silly coffee mug, what else does Sun have to offer?

Sun hasn't been just a hardware company for a very long time. Solaris isn't hardware, and neither is Java, or their compiler suites for their OSes. I have not always been impressed with some of their offerings (HotJava and their early Java IDEs were pretty dreadful), but they do have decades of experience.

Forcing them to use the JVM itself is limiting. Much of the power of Ruby comes from its language and VM facilities - runtime replacement of methods, realtime class updates when source changes, etc. I'm unclear how much of this is an inherent limitation in the JVM but Java will never be able to match the development speed of Ruby while it is still compile-based with primarily static classloading.

Forcing them to use the JVM itself is limiting. Much of the power of Ruby comes from its language and VM facilities - runtime replacement of methods, realtime class updates when source changes, etc. I'm unclear how much of this is an inherent limitation in the JVM but Java will never be able to match the development speed of Ruby while it is still compile-based with primarily static classloading.

If ruby can do it in the VM why can java not do it. This is actually a question because i really don't understand :(

If ruby can do it in the VM why can java not do it?

Is there any dynamic language feature of Ruby that rhino.jar does not already offer for JavaScript in the JVM?

Brian Miller wrote:

<quote>
Is there any dynamic language feature of Ruby that rhino.jar does not already offer for JavaScript in the JVM?
</quote>

This remark has a very strong point. I don't believe there is anything Rhino can't do that JRuby can. As a matter of fact, starting from 1.6, Rhino even has full continuations support which is -- for one thing -- ideal for developing scalable webapps where you can store the state on the client. Or store it on the server, but write a multiple request-response flow in a single script. Instead of scattering it across several controller actions.

It's just that JavaScript is somewhat neglected because of its "toy language for dynamic HTML" stygma, where in reality it is much more akin to "Lisp with C++ syntax". Maybe Rhino's inclusion in JDK 1.6 will change this for better.

Oh, and we package it as "js.jar", not "rhino.jar" :-)

If development speed is always tied to how long code takes to compile, then I suppose you are correct. However, my development time is largely unaffected by compile time. You have to ask where is most of the time being spent during development before you can make the statement that "Ruby will always be faster to develop...".

People also seem to confuse the semantics of the language with how quickly you can build apps with it. However, if I have a Java IDE that makes up for Java's ugliness, what then?

runtime replacement of methods, realtime class updates when source changes, etc. I'm unclear how much of this is an inherent limitation in the JVM but Java will never be able to match the development

Check out Beanshell if you want to see a way, in Java, to replace methods and source in realtime. Beanshell is Java scripted. You can do this:

String hello(){ return ""; }

hello(); // returns nothing

String hello(){ return "hello"; }

hello(); // returns "hello"

The magic of Beanshell is you can mix it with interpreted Java. You can also serialize objects created in Beanshell and reload it in interpreted code.

Java does not natively allow changing of methods/source code for performance and stability reasons.

Also note that JEE was designed to have a big deployment and packaging step - this was to make space for tools vendors. Rails was written by developers for developers and has gone the opposite direction: making deployment and packaging essentially nil. The deployment step is what everyone hates.

Also note that JEE was designed to have a big deployment and packaging step - this was to make space for tools vendors. Rails was written by developers for developers and has gone the opposite direction: making deployment and packaging essentially nil. The deployment step is what everyone hates.

And the step witch can be more improved!

Domingo Sebastian
JCP
http://www.prestigevillas.com

Is a step witch sort of like a bridge troll? :)

" If Sun doesn't start providing Java heads with 'cheaper' technology, someone else will. They already are."


Do any one think sun is ahead of inventing after java1.2.
EJB is flop.
Struts. (JSF took a while)
Hibernate. (JDO took a while)
Log4j. (java logging still sucks)
Ant. (still waiting.....)
Eclipse. (Any one seriously using netbeans raise ur hands)
XML support also was late. (ibm parsers were first, I know of)
JSP came long after asp was a hit.
Sun App server dont have much share.

Some one invents it.It takes lot of time for sun to even adopt them. Is this their (intentional) strategy??.


""My advice to Sun: Own the disruptive technology""
I dont know about technology. But most of time (in their webcasts) Sun CEO and CTO (disruptive)commenting about IBM or MS. (not anymore about MS, its new best frnd)

Eclipse. (Any one seriously using netbeans raise ur hands)

::raises hand::

Eclipse. (Any one seriously using netbeans raise ur hands)

::raises hand::

+1

Raises hand

Eclipse. (Any one seriously using netbeans raise ur hands)

::raises his hand as well::

Eclipse. (Any one seriously using netbeans raise ur hands)

::raises his hand as well::

Me too

I remember when I first read that book. You tend to look around and see opportunities for disruptive technologies everywhere. However, I think you are probably right that RoR is a disruptive technology. Similarly, PHP is a disruptive technology. They both target the now-traditional multi-tier ASP models provided by JavaEE and the .NET framework.

However, I don't agree that Sun should try to come up with their own disruptive technology to compete with PHP and RoR. Entrenched technology owners like Sun cannot come up with disruptive technologies, and the JCP/JSR process basically guarantees this. Instead they must embrace the disruptive technologies that are already out there.

One might say that Sun has shown some signs of this with PHP (see JSR 223.) At the same time they continue to make their product "better" (JSF) while making it more "expensive" (steeper initial learning curve.) The latter is a classic move of an entrenched technology on the decline. Maybe the right move would be to ditch JSP/JSF altogether and make PHP (or some future variant of RoR) the web presentation technolog for JavaEE.

Maybe the right move would be to ditch JSP/JSF altogether and make PHP (or some future variant of RoR) the web presentation technolog for JavaEE.

People talk about PHP and RoR like they do not have serious problems.

PHP 5 looks and smells like Java with all its object oriented features (classes, interfaces, visibility scopes etc.). These changes are clearly driven by inability of PHP to scale to larger applications. Other symptoms incude the need of creating templating engines with PHP...I ask what for??? Wasn't templating easy enough with PHP? Obviously it was not flexible enough. The end result is that a PHP application looks and feels like Java...why bother.

RoR, on the other hand, has a very marginal sweet spot. It is very difficult to take it seriously at all.

RoR doesn't seem to be as much about disruptive technology as disruptive salespeople.

It will scale better. It will add two-phase commits and fancy message queues.

These sentences from Jason's post is a bit optimistic to me. Writing a transaction monitor isn't easy or child's play. Writing a robust and mature message queue is also not easy. These important pieces require deep experience that most developers do not have. I certainly don't have that level of expertise, nor do most developers I know.

I'm sure Ruby will improve performance and ROR will improve performance, but saying "it will" is a far stretch from it actually happening. There are plenty of scripting frameworks like PHP that have problems handling transactional applications. If you don't need those features then, really anything will do. Why bother with a database at all. Just use a flat file. All this non sense about "too hard" and "too many" choices is rather silly to me.

If I choose ROR for an application and it fails to meet the performance requirements, I have to completely rewrite it in J2EE or .NET. Did I really save myself time and work? Heck no. I made it worse for myself and now my boss/customer is going to be furious. Someone make a java port of it already so all the ROR people will shut up and get back to work.

flame on!

peter

I have in my opinion a different take on this.
I think FOSS (Free Open Source Software) is the real
paradigm shift.

The language that will support or do FOSS better is the
language that will be the most popular.

Ruby is mostly a FOSS language, Java comes from a
pre-Foss era. For example I read in a book
(I dont remember which one exactly but I think it's
the free EJB book on this site), that Java's J2EE
encourage specialization, which really scared me.

Technology advancement suggest that people will
do more.
Specialization suggest that people will do less.

Of course one can argue what is more, are we
talking about depth or breadth.

I am talking about breadth, not depth.
Technology empowers the individual, give him
more power, less dependance on others.
The support my argument, imagine if driving
a car was so complex that it was a speciality
not everyone can drive a car, you either
get your own driver or you take a taxi.

Compare this to driving planes, not anyone
can drive a plan, but it must be the objective
or a technology to allow anyone or simply
more people to drive planes

If one of Java's technologies objective was to
promote specialization, which I think fit the
corporate model better, than Java is doomed to
loose ground in our FOSS era.

FOSS support the "technology gives me more power"
idiom better.
Ruby seem to do FOSS better.

Java comes from a pre-Foss era.

FOSS has been around for far longer than Java, so I don't see how this can be true.

Java comes from a pre-Foss era.

FOSS has been around for far longer than Java, so I don't see how this can be true.

Perhaps he means prior to the hype around FOSS? the widespread acceptance of FOSS products in major corporations? the emergence of commercial companies that promote and support FOSS?

But even then, it does not make that much sense.

Richard Stallman started the GNU project founded the FSF over 20 years ago and Apache has been around for over 10 years now.

Jason wrote: "Remember back: Java wasn't as "good" as C++. It did less; it ranslower. Its sole advantage was simplicity --"

Actually that wasn't its biggest advantage. The biggest advantage was that it ran on many platforms without recompilation.

Remember, in those days people actually still used 20 different flavors of Unix and Linux wasn't widely spread. It took a while for Windows to become a prominent platform for Java - Windows releases of Java came later than Unix releases because Sun didn't think Windows was the most important platform.

Simplicity was an advantage, yes, but it caught on because it was multi-platform.

- Erwin

Jason's blog is in many ways a wonderfully positive expression of the credo that human creativity and the urge to innovate will always prevail. No matter how well-established a technology or mindset or paradigm is, someday someone younger will come along who doesn't care how self-important the establishment acts and will just do what makes sense from her point of view. And this renegade's way of seeing the world will usually have formed on the basis of what already is established and will thus be a more valid, less prejudiced view. I think this is just wonderful!

Jason says "My advice to Sun: Own the disruptive technology. Create a group of 7 creative engineers and charge them with approaching the problem from beneath." That's remarkably close to how Java/Oak came to be, isn't it? Yes: organisations can innovate and re-invent themselves, but it takes an unusual amount of "organisational wisdom" to do so - let's wait and see...

  cheers,
  gerald

http://www.gerald-loeffler.net

Richard Gabriel had thoughts on this quite some time ago:

http://www.jwz.org/doc/worse-is-better.html

RoR is a very productive approach to building web sites, but it's confusing to me why people so often confuse "productive web framework" with "platform to run and operate an enterprise application".

I suppose RoR may be disruptive to other web frameworks and/or technologies, but let's first recognize that Java is *not* the only one, and probably isn't the primary one. PHP and ASP.NET are pervasive.

It is completely unclear if the RoR disruption (assuming it "is" a disruption, which has nothing to do with someone's blog entry, and has everything to do with how the market reacts) will affect the web frameworks market or the entire J2EE application server market. I would believe the former, but have a hard time believing the latter. Jason seems to think RoR is targetted at replacing application servers and distributed transaction processors: "Like all disruptive technologies, it'll only get better. It will scale better. It will add two-phase commits and fancy message queues."

It is unbelievably frustrating to me to suggest that these features are in any way related to a web framework, in terms of engineering effort. Or that they are somehow sideshow features. Perhaps to an average web site, but this again assumes that web sites will be the primary application for the forseeable future.

There are many disruptions on the horizon: the intense interest I see in integration technologies and web services, for example, are re-emphasizing the importance of high-speed, reliable messaging and data transformation. RoR is a very productive approach to building web sites, but it's confusing to me why people so often confuse "productive web framework" with "platform to run and operate an enterprise application".

I suppose RoR may be disruptive to other web frameworks and/or technologies, but let's first recognize that Java is *not* the only one, and probably isn't the primary one. PHP and ASP.NET are pervasive.

It is completely unclear if the RoR disruption (assuming it "is" a disruption, which has nothing to do with someone's blog entry, and has everything to do with how the market reacts) will affect the web frameworks market or the entire J2EE application server market. I would believe the former, but have a hard time believing the latter. Jason seems to think RoR is targetted at replacing application servers and distributed transaction processors: "Like all disruptive technologies, it'll only get better. It will scale better. It will add two-phase commits and fancy message queues."

It is unbelievably frustrating to me to suggest that these features are in any way related to a web framework, in terms of engineering effort. Or that they are somehow sideshow features. Perhaps to an average web site, but this again assumes that web sites will be the primary application for the forseeable future.

There are also many opportunities for incumbent vendors to start their own disruptions, or to adopt scripting languages and incorporate it into their platforms. There's already a trend to use Jython as an administrative scripting langauge in the BEA WebLogic community, for example.

Besides web frameworks, there are many disruptions on the horizon. The intense interest I see in integration technologies and web services, for example, are re-emphasizing the importance of high-speed, reliable messaging and data transformation. Another disruption is what I would call the "process & operations revolution", or "grid computing". Grids indicate a re-focus on how to reliably handle the process of software development, provisioning hardware in a utility-based fashion, promotion /rollback of all changes, troubleshooting, monitoring, and diagnostics. This is arguably a major reason why Oracle rules the database world, and I think it may serve to hold off startup frameworks, languages, platforms from capturing application server market share from the incumbents. It also at intersects and is a necessary condition to support SOA as another potential disruption, which is much less to do with web services than it is the drive to evolve from projects to product-lines and applications to more managable & re-usable services.

Perhaps another way to look at the current environment is this: the past 15 years have seen developers as the driving force in what has pushed IT forward: first, the Windows developer base, second the Java developer base. I would claim that the open source movement has fragmented developer opinions so much between .NET, Java, and "scripting language du jour" that the next major disruption in IT infrastructure will not necessarily be developer-led. There's too much cacaphony. I think it might be (for lack of a better term) "architect-led" or "infrastructure-led".

The focus on declarative configuration in modern frameworks (whether AOP or IoC or attribute metadata) is an indicator of this drive -- the next step is to disentangle the amount of knowledge requried to understand the chorus of frameworks and allow specialist roles to emerge, while an "architect" (in the sense of the "broad+deep developer" sense of the term, not the UML-junkie sense) ensures all the appropriate pieces are chosen, and the appropriate roles are filled by the people that can best do the work.

Anyway, the computing industry has a hard time to accept, en masse, a new technology. Java was the fastest adopted development platform in the history of computing for one reason: the Internet took off at that exact time. Before that, Windows was the fastest adopted platform because it was the first mass-market GUI. It would take another major shift to bring about another language & platform revolution. Until that time, the cacaphony will reign.

looks like my cut'n'paste editing messed up my post above a bit... I posted a blog entry without the redundancy: http://www.stucharlton.com/blog/archives/000084.html

I think I agree with the author on the impending demise of Java. The question really is about simplicity and how one can achieve it. The author does extend his analogy to the work done by Clayton Christiansen. The real challenge is about complexity. My thoughts are elaborated on http://www.jroller.com/page/vivekv

I do not think Ruby on Rails will take over Java on the web. Just like Perl, Python, TCL and a slew of other excellent scripting language did not take over Java or C++.
I agree that many will take the quick "cheap mental effort" route with Ruby, but just like the first generation of Application Servers did not last long due to the "cheap" java route, systems with longevity need serious engineering and Java excels in that. Take Tapestry for instance. It is not mentally "cheap" but worth the investment.
The real problem with web development is HTML which is limited.
In my view something like open laszlo points towards the future of web development not Ruby on Rails.

Has it really been a week since the last "Java is dead" post?

I think that Jason's basic premise is exactly right.
Java is good for just about everything except building web applications.

Unfortunately it also seems that all attempts at frameworks so far are also IMHO trying to do too much. Take struts for example. It is a decent MVC framework (although its becoming out-dated rapidly), but if I need to change the name of a HTML form field, I could have to change it in up to 3 or 4 places. Code generation not with-standing, this is ridiculas. As a java (web) programmer, this is about par for the course. The best I have seen still requires me to make a change to a XML file (and redeploy) on top of changing the HTML/JSP source itself. So what happens when one of my designers messes with the page?

Arent we all just looking for a 'light' View layer alternative? Preferably one that is safe for non-programmers to use as well and editable in WYSIWYG HTML editors like Dreamweaver without special extensions/plugins. This is the main reason why I think that the Struts, etc. al, HTML form tags are evil.

I think that Jason's basic premise is exactly right. Java is good for just about everything except building web applications.Unfortunately it also seems that all attempts at frameworks so far are also IMHO trying to do too much. Take struts for example. It is a decent MVC framework (although its becoming out-dated rapidly), but if I need to change the name of a HTML form field, I could have to change it in up to 3 or 4 places. Code generation not with-standing, this is ridiculas. As a java (web) programmer, this is about par for the course. The best I have seen still requires me to make a change to a XML file (and redeploy) on top of changing the HTML/JSP source itself. So what happens when one of my designers messes with the page?Arent we all just looking for a 'light' View layer alternative? Preferably one that is safe for non-programmers to use as well and editable in WYSIWYG HTML editors like Dreamweaver without special extensions/plugins. This is the main reason why I think that the Struts, etc. al, HTML form tags are evil.

For the sake of exploring pros and cons. Say you have to build a website that supports internationalization. I've done this with Java just fine. Can ROR do that? What would one need to do to build a website which supports internationalization easily in a maintainable way?

Or how about this scenario. I need to build a website which has the flexibility of changing the look and feel for each customer. A common example of this would be co-branding a service for a customer. How easy is it to do that with ROR? Would it be more painful to do it in ROR? I've also done this with servlets, jstl and jsp without any problems. Adding a co-brand basically takes 1-2 weeks.

Now, I don't doubt that I could spend several months extending ROR to do all these things and basically completely rewriting the entire framework, but is that the best use of my time?

peter