Beyond Java

beyond... what?

 link_to_remote "Delete this post",
     :url => { :action => "destroy", :id => post.id },
     :update => { :success => "posts", :failure => "error" }

Beyond Java

Beyond Java

they were able to recreate the application in Ruby in 4 nights...

Could Ruby and frameworks such as Ruby on Rail be the next big thing?

Isn't that for script hype, repeating PHP story

Making Java more Dynamic

Beyond Java

I Hate JavaBeans

public class Foo {
private String msg = "Hello, ";
private String name = "World";
public String getMsg() { return msg; }
public void setMsg(String inMsg) {
if (inMsg == null) throw new IllegalArgumentException("msg cannot be null!");
if (inMsg.equals("")) throw new IllegalArgumentException("msg must not be blank!");
msg = inMsg;
}
public String getName() { return name; }
public void setName(String inName) {
if (inName == null) throw new IllegalArgumentException("name cannot be null!");
if (inName.equals("")) throw new IllegalArgumentException("name must not be blank!");
name = inName;
}
public void sayHello() { System.out.println(msg + name + "!"); }
}

public abstract attribute Attribute<T> {
public instance T get(); // invoked when accessed via syntax obj.attrName
public instance void set(T value); // invoked via syntax obj.attrName = newValue;
}

public attribute NonBlankString implements Attribute<String> {
// this constructor is execucted at compile time or maybe class load time
public NonBlankString(String defValue, String nullMessage, String blankMessage)
{
if (defValue == null) throw new IllegalArgumentException("defValue cannot be null");
if (nullMessage == null) throw new IllegalArgumentException("nullMessage cannot be null");
if (blankMessage == null) throw new IllegalArgumentException("blankMessage cannot be null");
defVal = defValue;
nullMsg = nullMessage;
blankMsg = blankMessage;
}
public instance String get() { if (value == null) return defVal; return value; }
public instance void setValue(String inVal) {
if (inVal == null) throw new IllegalArgumentException(nullMsg);
if (inVal.equals("")) throw new IllegalArgumentException(blankMsg);
value = inVal;
}
private instance String value;
private String defVal;
private String nullMsg;
private String blankMsg;
}

public class Foo {
// introduce the arrow operator for compile-time assignment
public String name <- new NonBlankString("World", "name cannot be null", "name cannot be blank");
public String msg <- new NonBlankString("Hello, ", "msg cannot be null", "msg cannot be blank");
public void sayHello() { System.out.println(msg + name + "!"); }
}

Thanks for your thoughts.

Beyond Java

they were able to recreate the application in Ruby in 4 nights.

Reduced configuration...

I Hate JavaBeans

Some predictions

Could Ruby and frameworks such as Ruby on Rail be the next big thing?

Thanks for your thoughts.

I didn't use PHP or Perl because I think they are quick and dirty. I think Ruby on Rails is quick and clean.

Beyond Java

they were able to recreate the application in Ruby in 4 nights

Reduced configuration...

I'm learning Ruby now, so I can't really say a whole lot about it. However, having tried out Rails, the reduced configuration is really nice.That said, it's only nice until you have to do something out of the ordinary. The Rails list and IRC channel are *full* of people asking how to do things a little different from the standard way, and the response is basically that you have to recreate some or all of that configuration that you initially lost.

Doing portlet-style development is one example, your mapping file doesn't look that different from a typical Spring configuration before long.Maturity of the APIs and the developers is a big ding against Rails. I don't want to get into a philosophical debate over DB constraints, but I think a lot of experienced developers here appreciate why DB constraints are valuable. More importantly, our ORM tools in the Java world can model simple constraints like foreign key refs with no problem. In the Ruby world they're still arguing that your constraints should be enforced solely at the controller layer, and ActiveRecord, convenient as it is, has no knowledge of foreign key constraints.

If you're writing an app which can be written in 4 days, it's likely that these sorts of concerns don't really pertain. I will posit that a significant percentage of the web apps which get written today in Java are good candidates for the Rails framework. Perhaps the percentage is as much as half.

However, for those of us who live in a world where we don't control our schema, or where our schema has lived beyond 3 major revisions to the app, or where we need the rich, enterprise-class APIs that exist in the Java world, Rails is not really a compelling solution.I think everyone who writes Java apps should also know how to write Rails apps. You should be able to judge when something you're writing is trivial enough to throw away most of the complexity you get writing big Java applications. But the need to write big Java applications isn't going to go away, and there are still going to be plenty of Java jobs around. They'll probably pay better too, because if you need that complexity, you realize it costs, at all levels. ;)--james

PHP and Perl

I didn't use PHP or Perl because I think they are quick and dirty. I think Ruby on Rails is quick and clean.

So try PHP or Perl, probably it is not so dirty as you think ( but I am afraid it is too late to write best sellers about this stuff).

One point on configuration and defaults.

I'm learning Ruby now, so I can't really say a whole lot about it. However, having tried out Rails, the reduced configuration is really nice.That said, it's only nice until you have to do something out of the ordinary. The Rails list and IRC channel are *full* of people asking how to do things a little different from the standard way, and the response is basically that you have to recreate some or all of that configuration that you initially lost. Doing portlet-style development is one example, your mapping file doesn't look that different from a typical Spring configuration before long.

Thanks for your comments, Keith.

Thanks for your thoughts.

I'll blog a little more about my experiences today, but I thought I should talk about them some here first, because this community has meant so much to me. I should probably point out what I have to lose.- All of my clients are Java clients.- I've got 3 JavaOne best sellers in 4 years. All of my best books are about Java.- I've worked to establish a brand in the Java business. Indeed, my company name, is based on the Java brand.Look...no technical book is going to make an author a lot of money. Generally, for a book like this, I'll get less than two bucks a book. A very good Java book sells around 10,000 copies, and if you put much effort into it at all, you can see that you'd make more money flipping burgers. Writing is about the love of the craft. So you should be asking yourself, why would a Java evangilist cut his own throat like this? And the answer is this: for my readers, I think it's the right thing to do. For at least one class of applications, web-based apps on a relational database where you control your own schema, you'd be crazy not to consider Rails. It's just too productive. I didn't understand either until I used the framework in anger. What's different?- Rapid turnaround time. Save and reload. That's it. Very compelling.- Starting point. You start with basically a working CRUD app per table. Windows to do list, show, edit, delete, new. Sure, you'll rewrite some, but you can put something in front of your customer instantly. That's compelling. To get all of this, you can either do a one-time code generation pass (it's not that much code in Rails), or you can do a scaffold :person command. - Reduced configuration. For us it was a 10-1 reduction. I think that's fairly typical. More for some extreme struts apps, less if you don't count annotations (but I think we're often making a big mistake with annotations.)- Better mapping strategy for the Rails problem set. Here's an active record class, that maps a Person class to a table called people, and belongs to a department:class Person < ActiveRecord::Base&nbsp;&nbsp;belongs_to :departmentendEnd of story. You want syntax? That's syntax. You get a property for every column in the database, custom finders like find_by_last_name, and other goodies to manage the belongs_to relationship. No repetition of column names. No code generation. - Much better AJAX, and cleaner view technology. As to quick and dirty, I used Java because it was clean, although slow. I didn't use PHP or Perl because I think they are quick and dirty. I think Ruby on Rails is quick and clean.But it's not for every Java project. I think that several areas are basically safe for Java: hard core ORM, heavy threading, two-phased commit. Rails is for one well-defined niche, but it's probably the most important one, and that niche is rapidly expanding. More comments in my blog today...stay tuned.

Ok, not really about LOCs

Beyond Java

Ruby and DSLs

You see a blurry line between what's Rails and what's Ruby becasue the line between the two *is* blurry. Rails uses metaprogramming to dynamically add behavior and attributes to classes, and implement domain specific languages (Active Record uses a Ruby DSL for ORM).

Thanks for your thoughts.

Ok, not really about LOCs

It's about avoiding duplication. It's about grouping related related pieces of information together (which .NET attributes somewhat achieve for properties).But most of all, in my opinion, it's about making the code better reflect the intent of the programmer rather than the mechanics of the program. It's about being able to explicitly code a pattern with some parameters, and then use it over and over, rather than thinking about the pattern, and then coding it over and over again.I'm not sure how much sense I'm making. There's some Python code I've written in the past that I wish I could post, that I think really show how good use of metaprogramming can drastically change the balance between imperative and declaritive code.I'm really not sure how to explain it. I'm a huge believer in static code checking (actually in fail-fast behavior, with compile-time being ideal), which frequently makes Python drive me crazy. But once you really really get into metaprogramming, it feels like another plane of existence. I really want to see a language that effectively combines the two, and I think a JVM based language could do it (but I'm not sure about a Java derivitive).

Ok, not really about LOCs

It's about avoiding duplication. It's about grouping related related pieces of information together (which .NET attributes somewhat achieve for properties).But most of all, in my opinion, it's about making the code better reflect the intent of the programmer rather than the mechanics of the program. It's about being able to explicitly code a pattern with some parameters, and then use it over and over, rather than thinking about the pattern, and then coding it over and over again.I'm not sure how much sense I'm making. There's some Python code I've written in the past that I wish I could post, that I think really show how good use of metaprogramming can drastically change the balance between imperative and declaritive code.I'm really not sure how to explain it. I'm a huge believer in static code checking (actually in fail-fast behavior, with compile-time being ideal), which frequently makes Python drive me crazy. But once you really really get into metaprogramming, it feels like another plane of existence. I really want to see a language that effectively combines the two, and I think a JVM based language could do it (but I'm not sure about a Java derivitive).

I Hate JavaBeans

Behind Java

Could Ruby and frameworks such as Ruby on Rail be the next big thing?

DSL Java

I don't get it

Thanks for your thoughts.

For that project, I think I would have chosen the same technologies. When you need to map, use a mapper. Rails uses a wrapping strategy.

Metaprogramming == Attribute == Annotations == MDA/MDD

Groovy...

Beyond Java

Common LISP

Out of curiosity, is anyone predicting that Common Lisp will displace Java ? Why not ? It's more powerful than any scripting language, it's an ANSI standard, it has industrial-grade commercial implementations, development is amazingly fast... Isn't there any consultant willing to publish a book about Common Lisp, the "next big thing", and bet his career on that ?

10:1 compression of config?

BINGO!

Thanks for your thoughts.

For at least one class of applications, web-based apps on a relational database where you control your own schema, you'd be crazy not to consider Rails.

Thanks for your thoughts.

For at least one class of applications, web-based apps on a relational database where you control your own schema, you'd be crazy not to consider Rails. It's just too productive.

Service applications

Refactoring?

Metaprogramming == Attribute == Annotations == MDA/MDD

4 days porting != development

Thanks for your thoughts.

You start with basically a working CRUD app per table. Windows to do list, show, edit, delete, new. Sure, you'll rewrite some, but you can put something in front of your customer instantly. That's compelling.

Much better AJAX, and cleaner view technology.

Refactoring?

Please tell me how you can refactor in untyped languages. Just go down the list of IntelliJ's refactoring menu and describe to me how it is even possible to do it without a type system.

Expressivity is not it

+1

Thanks for your thoughts.

Expressivity is not it

People who use it mostly get by, but it's got problems for very simple programs and for very complex programs.

Refactoring?

Please tell me how you can refactor in untyped languages. Just go down the list of IntelliJ's refactoring menu and describe to me how it is even possible to do it without a type system.

I'm not sure what you mean by untyped (this and the term 'dynamically typed' still confuse me, after decades). However, take a look at any good Smalltalk implementation. Smalltalk is untyped (or dynamically typed) in the same way that Ruby is, but has a huge amount of refactoring tools. In fact some of the first uses of the term 'refactoring' were regarding Smalltalk.

OR you can do same thing in JAVA!!

Refactoring?

...So, if you have dynamic typing, how can you do something as simple as find all usages of a specific class? Or how about renaming a method/field in your entire code base? Those are the simple things. What about more complex things like moving methods around between classes and being automatically warned where things will get messed up?I don't know smalltalk, but have used tcl, perl, python, php. Please, i'm open minded, elaborate.thanks, bill

RoR and frameworks in general

Thanks for your thoughts.

For at least one class of applications, web-based apps on a relational database where you control your own schema, you'd be crazy not to consider Rails. It's just too productive.

Then call me crazy! I have had just such an application. I used a well-regarded scripting language (Cold Fusion), as I had to take over the website and this is what the previous developers has used.The problem is that the website (not just the schema) evolved. It required some high-performance database access and cacheing of data. It required some computation for things like best-offer calculation. Then, one day, the website was publicised in the media, and it died. It could not cope with the demand. Fortunately I had been working on a port to a Java-based version. Sooner than I had hoped, this port was put on-line, and the performance problems were solved.Since then I have refused to go near a scripting or low-performance language for the development of a website where there is even the slightest possibility of increased requirements.

Expressivity is not it

People who use it mostly get by, but it's got problems for very simple programs and for very complex programs.

I use Java for very simple programs (things others might use a scripting language for) when I need performance (simple data transforms, for example). It works fine, just in the same way that many UNIX developers will use C to write simple programs. As for complex programs, how much more complex can you get than a rich IDE or App server?I don't just get by with Java. In combination with a powerful IDE I find it rich and reasonably expressive. It has faults, but what doesn't?I'm not saying you are wrong, but I would be interested to know what you mean; what the issues are.

BINGO!

You nailed RoR's weakness on the head: Wizard code.

DoD Common Higher Order Language Program

Common Lisp, Scheme, Perl, Tcl, zorglub ...

BINGO!

You nailed RoR's weakness on the head: Wizard code.

....
 Are things different this time around for RoR?Ian

On Java!

I'am getting really tired about comments saying that fast development doesn't mean anything. It does mean a lot. Why should we wait and wait and wait forever, i'v waited enough, more than enough. Make that hotswap accept API changes, for goodness sake PLEASE!

+1

I'am getting really tired about comments saying that fast development doesn't mean anything. It does mean a lot. Why should we wait and wait and wait forever, i'v waited enough, more than enough. Make that hotswap accept API changes, for goodness sake PLEASE!

The real question we should be asking is this: Why isn't the JVM the best platform for Ruby to be running on, and how do we "fix" it so it is?
Peace,
Cameron PurdyTangosol Coherence: The Java Data Grid

BINGO!

You nailed RoR's weakness on the head: Wizard code.

....&nbsp;Are things different this time around for RoR?Ian

I would say yes. With RoR it is different because RoR is a not that of a wizard but more like DSL (Domain Specific Language ).

PHP and Perl

I don't think history is on your side here. You don't have to try either one for very long to know that they are excellent prototyping languages, but will have trouble scaling. I think Ruby on Rails is different. It's much cleaner, from a design perspective, and just as productive...even more so.

Refactoring!

Thanks for your thoughts.

For at least one class of applications, web-based apps on a relational database where you control your own schema, you'd be crazy not to consider Rails. It's just too productive.

Then call me crazy! I have had just such an application. I used a well-regarded scripting language (Cold Fusion), as I had to take over the website and this is what the previous developers has used.The problem is that the website (not just the schema) evolved. It required some high-performance database access and cacheing of data. It required some computation for things like best-offer calculation. Then, one day, the website was publicised in the media, and it died. It could not cope with the demand. Fortunately I had been working on a port to a Java-based version. Sooner than I had hoped, this port was put on-line, and the performance problems were solved.Since then I have refused to go near a scripting or low-performance language for the development of a website where there is even the slightest possibility of increased requirements.

Exactly. Why not, instead, start with a base that you KNOW can scale up. I told our management that I can do anything Coldfusion can, at least *almost* as quickly. At least. Except, any of our java guys can maintain this project. And if it grows, the systems will grow with it.

PHP and Perl

I didn't use PHP or Perl because I think they are quick and dirty. I think Ruby on Rails is quick and clean.

So try PHP or Perl, probably it is not so dirty as you think ( but I am afraid it is too late to write best sellers about this stuff).

I don't think history is on your side here. You don't have to try either one for very long to know that they are excellent prototyping languages, but will have trouble scaling. I think Ruby on Rails is different. It's much cleaner, from a design perspective, and just as productive...even more so.

On Java!

The real question we should be asking is this: Why isn't the JVM the best platform for Ruby to be running on, and how do we "fix" it so it is?

10:1 compression of config?

Refactoring!

In many ways, refactoring is much easier in dynamic languages.

4 days porting != development

Java = mandated complexity

+1

After coding an app in RoR, I felt refreshed.It was nice to be able to get something up and running so quickly.However, I'm going to give a +1 to what Konstantin Ignatyev noted. The i18n support is almost non-existant at the moment.

Thanks for your thoughts.

For at least one class of applications, web-based apps on a relational database where you control your own schema, you'd be crazy not to consider Rails. It's just too productive.

Then call me crazy! I have had just such an application. I used a well-regarded scripting language (Cold Fusion), as I had to take over the website and this is what the previous developers has used.The problem is that the website (not just the schema) evolved. It required some high-performance database access and cacheing of data. It required some computation for things like best-offer calculation. Then, one day, the website was publicised in the media, and it died. It could not cope with the demand. Fortunately I had been working on a port to a Java-based version. Sooner than I had hoped, this port was put on-line, and the performance problems were solved.Since then I have refused to go near a scripting or low-performance language for the development of a website where there is even the slightest possibility of increased requirements.

Exactly. Why not, instead, start with a base that you KNOW can scale up. I told our management that I can do anything Coldfusion can, at least *almost* as quickly. At least. Except, any of our java guys can maintain this project. And if it grows, the systems will grow with it.

Ruby is much more dynamic, and handles complexity very well. It's a model-view-controller style design pattern. It defaults everything, but many Java developers confuse this with hard wiring. It isn't. And Ruby metaprogramming gives me things Cold Fusion could only dream about.

Thanks for your thoughts.

RoR's specific niche is a very dangerous one, which may be too narrow for too many types of projects: if app grows too complex, which BTW is what I've seen in 90% of the projects I've worked on, I wonder how will RoR behave. Will it have too many growing pains? If so, the immediate gains would be lost down the road when people try to maintain the unmaintainable, as further on your system will need to integrate with other systems, migrate to a diferent database, etc, as usually happens specially in big corporates. At least where I work, this happens very often. Does someone know how RoR compares to Java WRT maintainability and scalability?

+1

I'am getting really tired about comments saying that fast development doesn't mean anything. It does mean a lot. Why should we wait and wait and wait forever, i'v waited enough, more than enough. Make that hotswap accept API changes, for goodness sake PLEASE!

The real question we should be asking is this: Why isn't the JVM the best platform for Ruby to be running on, and how do we "fix" it so it is?Peace,Cameron PurdyTangosol Coherence: The Java Data Grid

Beyond Java

Right then. Someone then says 'Sorry wrong database - we need this on a different vendor's system and it will need to cope with future schema changes'.

Rapid development does not always (or I would say 'often') outweight long-term maintainability.

Exactly how? I have found the much of Java 5.0 has made the simplest problems far, far easier to solve, with less verbose and faster code.

public static int binarySearch(List list,
                               Object key)

public static <T> int binarySearch(List<? extends Comparable<? super T>> list,
                                   T key)

As Spring, Hibernate and other technologies start to move into the mainstream of Java use, and as the latest release of Java (5.0), which has more changes than any release of Java for years, moves into mass use, saying Java 'is showing signs of wear' seems a bit strange.

Groovy...

... SInce it's JSR'd, it should rapidly develop into a formal scripting language for java-land, but I imagine its close association with Java may hamper its toolset and infrastructure, relative to Ruby which has full freedom to start anew.

Refactoring!

invokedynamic

The real question we should be asking is this: Why isn't the JVM the best platform for Ruby to be running on, and how do we "fix" it so it is?

+1

After coding an app in RoR, I felt refreshed.It was nice to be able to get something up and running so quickly.However, I'm going to give a +1 to what Konstantin Ignatyev noted. The i18n support is almost non-existant at the moment.

An excellent point. I'd add 2pc, orm, and database constraints.

thanks for the link

The real question we should be asking is this: Why isn't the JVM the best platform for Ruby to be running on, and how do we "fix" it so it is?

See this for a start.

Common LISP

Because I don't think anyone can explain Common LISP to the average programmer.Maybe we can create a *real* role for the fabled "software architect."It's the architect's job to implement the metaprogramming functionality that allows the rest of the team to work more efficiently.Thinking that way is hard. Communicating it is even harder. If someone can do it, and do it repeatedly, then they really do deserve a lofty title.

Some more thoughtful posts please?

I was working an a project with Justin Gehtland with a small startup in Austin. We implemented a simple application with Spring, Hibernate, and Webwork, the classic lightweight stack of technologies for Java. We were pleased," recalls Tate. "On a whim, we both decided to try Ruby on Rails over the same weekend. I called Justin to tell him I'd implemented the model on Rails, but he told me he'd implemented the whole application, in four nights! We were both blown away. As a Java guy, I pulled back to do some research, and I found that compared to the so called dynamic languages, Java was limited. Further interesting innovations in dynamic languages were happening, and some of them were doing things that Java couldn't. Then, this book came pouring out.

The community

And the availability of a massive amount of high-quality open-source libraries and tools.

more links for ya

assuming this gets implemented in a future JVM, and there's a robust ruby interpreter for the JVM, wouldn't that mean java can accomodate ROR fans and provide an easier way to integrate java components?peter

Some more thoughtful posts please?

A lot of the posters here seem a tad, um - defensive. Many of the responses run the line of: 4 nights != development, blah blah.It sure is easier to crank out a knee-jerk reaction to the serverside poster's one-paragraph summary than to take the time to read and possibly think about Bruce's article.Here is an actual quote from that article to help clarify some of the lazier posts:

I was working an a project with Justin Gehtland with a small startup in Austin. We implemented a simple application with Spring, Hibernate, and Webwork, the classic lightweight stack of technologies for Java. We were pleased," recalls Tate. "On a whim, we both decided to try Ruby on Rails over the same weekend. I called Justin to tell him I'd implemented the model on Rails, but he told me he'd implemented the whole application, in four nights! We were both blown away. As a Java guy, I pulled back to do some research, and I found that compared to the so called dynamic languages, Java was limited. Further interesting innovations in dynamic languages were happening, and some of them were doing things that Java couldn't. Then, this book came pouring out.

Regardless of the details, Bruce was impressed with how productive RoR was on this task. This impression led Bruce to think about many of Java's "limitations" and then to write a book about it. Is that a controversy?I think it is fairly certain that some development technology will come along to replace Java as king in the next few years if computer science history is any indicator. I don't think Bruce's point is that RoR is for sure that technology but that it spotlights some of the Java platform's weaknesses. It is those weak spots that newer technologies can overcome more easily. Why? Partly I think because the more successful a technology becomes the less it can (or is allowed to) change. See all the freak-out posts regarding Java 1.5's new features for proof. Every one of them was seen as the end of the world by some purists. Auto-boxing, Generics, Annotations, oh my!Will Java ever die? Probably not in our career-span so relax your job is somewhat safe. Will it be sidelined? Most assuredly, so maybe start paying attention to the new ideas.

more links for ya

more links for ya

assuming this gets implemented in a future JVM, and there's a robust ruby interpreter for the JVM, wouldn't that mean java can accomodate ROR fans and provide an easier way to integrate java components?
peter

Absolutely. And here are some more links to innovations coming someday to a virtual machine near you (in this case mostly the CLR, sorry, but we can expect similar stuff for the JVM too):Composable memory transactionsLanguage-integrated queryC-omegaF-sharp, an ML-derived language for the CLRIBM's X10 programming language (targetting the JVM)All these things explain why I get annoyed at the sheer ignorance of people who imagine that a simple-minded little framework for building toy apps in a currently non-scalable language is where the true innovation is. Ha! Happy reading.

some links

Thanks for your thoughts.

RoR's specific niche is a very dangerous one, which may be too narrow for too many types of projects: if app grows too complex, which BTW is what I've seen in 90% of the projects I've worked on, I wonder how will RoR behave. Will it have too many growing pains? If so, the immediate gains would be lost down the road when people try to maintain the unmaintainable, as further on your system will need to integrate with other systems, migrate to a diferent database, etc, as usually happens specially in big corporates. At least where I work, this happens very often. Does someone know how RoR compares to Java WRT maintainability and scalability?

The structure of RoR applications is much cleaner than Java counterparts. I'd guess the maintenance will be simpler, but I can't say for sure.

more links for ya

But don't those links suggest that there's more to life than the Java language? Im my book, I clearly state that the next successful language will need a credible JVM implementation.In fact, in a conversation with Dave Thomas this weekend, I told him that JRuby, with Rails, was the most important Ruby project going. I still believe that.

Thanks for your thoughts.

That can be said of VB programs too, but everyone knows what we got from that (in)famous language/tool. Let's wait and see if RoR will live up to its expectations.

more links for ya

10:1 compression of config?

Convention over configuration. Look at a typical Spring context and tell me how much could be defaulted. And I think that Spring one of the most productive Java frameworks. Look at the amount of Struts configuration related to navigation. Could you short circuit that? When you make assumptions about naming and navigation, and suggest those conventions, you only have to break your rules a small fraction of the time.

Some more thoughtful posts please?

A lot of the posters here seem a tad, um - defensive.

This is about saying, hey, maybe our baby is ugly. At least, it was for me.

Beyond Java

Actually it's the emergence of projects like Spring and Hibernate that showcase Java's age the most. If you wanted to teach newbie programmer to write a simple web application, would you just tell him to learn JDBC and JSPs? Or would you tell them to learn JDBC and JSP, then JSTL, then JSF, and then EJBs? Or would you tell them to learn JDBC and JSP, then Struts, then Hibernate, and maybe then also Spring? Struts, Hibernate, and Spring all came about because of the shortcomings of "standard" Java technologies. It winds up being a huge stack of technologies to learn and you really see the age of things as you see how these incremental technologies cover up the wrinkles of the standard technologies they were built on and complement.

Some more thoughtful posts please?

A lot of the posters here seem a tad, um - defensive. Many of the responses run the line of: 4 nights != development, blah blah.It sure is easier to crank out a knee-jerk reaction to the serverside poster's one-paragraph summary than to take the time to read and possibly think about Bruce's article.Here is an actual quote from that article to help clarify some of the lazier posts:

I was working an a project with Justin Gehtland with a small startup in Austin. We implemented a simple application with Spring, Hibernate, and Webwork, the classic lightweight stack of technologies for Java. We were pleased," recalls Tate. "On a whim, we both decided to try Ruby on Rails over the same weekend. I called Justin to tell him I'd implemented the model on Rails, but he told me he'd implemented the whole application, in four nights! We were both blown away. As a Java guy, I pulled back to do some research, and I found that compared to the so called dynamic languages, Java was limited. Further interesting innovations in dynamic languages were happening, and some of them were doing things that Java couldn't. Then, this book came pouring out.

Regardless of the details, Bruce was impressed with how productive RoR was on this task. This impression led Bruce to think about many of Java's "limitations" and then to write a book about it. Is that a controversy?I think it is fairly certain that some development technology will come along to replace Java as king in the next few years if computer science history is any indicator. I don't think Bruce's point is that RoR is for sure that technology but that it spotlights some of the Java platform's weaknesses. It is those weak spots that newer technologies can overcome more easily. Why? Partly I think because the more successful a technology becomes the less it can (or is allowed to) change. See all the freak-out posts regarding Java 1.5's new features for proof. Every one of them was seen as the end of the world by some purists. Auto-boxing, Generics, Annotations, oh my!Will Java ever die? Probably not in our career-span so relax your job is somewhat safe. Will it be sidelined? Most assuredly, so maybe start paying attention to the new ideas.

+1

I'am getting really tired about comments saying that fast development doesn't mean anything. It does mean a lot. Why should we wait and wait and wait forever, i'v waited enough, more than enough. Make that hotswap accept API changes, for goodness sake PLEASE!

The real question we should be asking is this: Why isn't the JVM the best platform for Ruby to be running on, and how do we "fix" it so it is?Peace,Cameron PurdyTangosol Coherence: The Java Data Grid

that's the question I asked myself when the thread first appeared. clearly, the JVM can support a language like jython, so it should be able to support ruby. I'm sure the .NET team is working hard to make the CLR more friendly towards scripting languages like IronPython. Would anonymous types in .NET make it easier to write a ruby interpreter? Maybe someone from the jython or groovy team can shed some light.peter lin

dynamic stuff

The concepts behind Ruby on Rails are radical and important. RoR may not be the next great thing, but metaprogramming is extremely important. Look at how much effort we're spending on metaprogramming. Spring, Hibernate, and Seam. AOP. Annotations. EJB. JDO. All of these frameworks have thousands of lines of code invested in metaprogramming. But Ruby, Smalltalk, Lisp and even Python to some extent make metaprogramming much easier. You say to look beyond the language to the JVM. I agree with the importance of the JVM, but I say to you "look beyond the tool to the language that enables it."RoR could well be just the first in a wave of metaprogramming frameworks. That, with the configuration, conventions and defaulting stragegies, are what has me so excited.The JVM needs to get more dynamic...closures, continuations, and dynamic typing are all very important to some of the most productive environments in the world.

Beyond Java

No, it is the emergence of Spring and Hibernate that show Java's maturity. There is NOTHING in Java language that is a shortcoming that is addressed Spring or Hibernate. I would say that the strength and vitality of Java is demostrated by the fact that it can successfully be all things to all people something Ruby or ROR hasn't proven.By comparision Ruby is narrow and IMO restricted. And if the day ever comes with it can match Java's breadth of technologies, I suspect that it will look every bit as complex as Java does today. It is easy to look simple when a given tool doesn't do as much. That's why I've never bought into the arguements about why PCs cannot be as simple as toasters. A PC is more complex and can do more.Again, many of these arguments are the same that were used for every scripting language that challenged the static accepted brother and as we've seen time and time again, the only thing that replaced a static langugage as another static language.

Beyond Java

You're not too familiar with RoR are you?

It uses an O/R layer, similar in some ways to Hibernate, to hide DB specific code/queries from the application developer.

In addition, its "out of the box" functionality make it so that a schema change is automatically reflected in the UI, with no code change at all. So if you add a column to table and have a web page that lists entries from that table or one that shows details about a row of data, this pages will show the new column without any code being written, or even any configuration files changed.

But you must recognize that for somebody new to Java, these things can look like voodoo.

As Spring, Hibernate and other technologies start to move into the mainstream of Java use, and as the latest release of Java (5.0), which has more changes than any release of Java for years, moves into mass use, saying Java 'is showing signs of wear' seems a bit strange.

Actually it's the emergence of projects like Spring and Hibernate that showcase Java's age the most. If you wanted to teach newbie programmer to write a simple web application, would you just tell him to learn JDBC and JSPs? Or would you tell them to learn JDBC and JSP, then JSTL, then JSF, and then EJBs? Or would you tell them to learn JDBC and JSP, then Struts, then Hibernate, and maybe then also Spring? Struts, Hibernate, and Spring all came about because of the shortcomings of "standard" Java technologies. It winds up being a huge stack of technologies to learn and you really see the age of things as you see how these incremental technologies cover up the wrinkles of the standard technologies they were built on and complement.

dynamic stuff

The concepts behind Ruby on Rails are radical and important. RoR may not be the next great thing, but metaprogramming is extremely important. Look at how much effort we're spending on metaprogramming. Spring, Hibernate, and Seam. AOP. Annotations. EJB. JDO. All of these frameworks have thousands of lines of code invested in metaprogramming. But Ruby, Smalltalk, Lisp and even Python to some extent make metaprogramming much easier. You say to look beyond the language to the JVM. I agree with the importance of the JVM, but I say to you "look beyond the tool to the language that enables it."RoR could well be just the first in a wave of metaprogramming frameworks. That, with the configuration, conventions and defaulting stragegies, are what has me so excited.The JVM needs to get more dynamic...closures, continuations, and dynamic typing are all very important to some of the most productive environments in the world.

On this last point we are in full agreement. This blog entry by Cedric Beust should also be of interest to you. If Sun needs 3 years to add a byte code to the JVM (if I may oversimplify a bit), then I'm afraid the fun is going to shift to .NET where innovation seems much faster nowadays...

Some more thoughtful posts please?

When the next real language innovation emerges, a statically typed one, no doubt, I'll be right there. But Ruby, yawn...

RoR's problem is that its too complex.

more links for ya

The JVM needs to get more dynamic...closures, continuations, and dynamic typing are all very important to some of the most productive environments in the world.

jerk...

Refactoring?

Please tell me how you can refactor in untyped languages. Just go down the list of IntelliJ's refactoring menu and describe to me how it is even possible to do it without a type system.

RoR's problem is that its too complex.

Heck, I cranked out 5 whole applications while I was writing this response.RoR is totally yesterdays news, VOE is the wave of the future.:-)

dynamic stuff

This blog entry by Cedric Beust should also be of interest to you. If Sun needs 3 years to add a byte code to the JVM (if I may oversimplify a bit), then I'm afraid the fun is going to shift to .NET where innovation seems much fas
ter nowadays...

The trade off between moving forward and backward compatability is tricky. I'd argue it's much easier to screw that up than get it right. If Sun were to totally break the JVM compatability and introduce several new low level features, I'm sure there are plenty of businesses that would be furious.

dynamic stuff

The concepts behind Ruby on Rails are radical and important. RoR may not be the next great thing, but metaprogramming is extremely important. Look at how much effort we're spending on metaprogramming. Spring, Hibernate, and Seam. AOP. Annotations. EJB. JDO. All of these frameworks have thousands of lines of code invested in metaprogramming. But Ruby, Smalltalk, Lisp and even Python to some extent make metaprogramming much easier. You say to look beyond the language to the JVM. I agree with the importance of the JVM, but I say to you "look beyond the tool to the language that enables it."RoR could well be just the first in a wave of metaprogramming frameworks. That, with the configuration, conventions and defaulting stragegies, are what has me so excited.The JVM needs to get more dynamic...closures, continuations, and dynamic typing are all very important to some of the most productive environments in the world.

On this last point we are in full agreement. This blog entry by Cedric Beust should also be of interest to you. If Sun needs 3 years to add a byte code to the JVM (if I may oversimplify a bit), then I'm afraid the fun is going to shift to .NET where innovation seems much faster nowadays...

I'd hammer in the morning...

Refactoring?

The first refactoring support to appear was for Smalltalk, a dynamically language as you know.

 Smalltalk and Ruby aren't "untyped", they are strongly but dynamically typed.

Rename method is probably the hardest commonly used refactoring in a dynamically typed lanauage but for example extract method is much easier, and so are introduce variable, rename variable, rename field (all fields are private in Ruby), pull up method, introduce constant and so on.

Thanks for your thoughts.

Ruby is much more dynamic, and handles complexity very well. It's a model-view-controller style design pattern. It defaults everything, but many Java developers confuse this with hard wiring. It isn't. And Ruby metaprogramming gives me things Cold Fusion could only dream about.

dynamic stuff

Beyond Java

dynamic stuff

The point in my blog entry was actually to observe that adding a bytecode to the JVM is completely backward compatible, as opposed to changes such as adding keywords to the language (assert, enum), which, even now, are still wreaking havoc on existing codebases.-- Cedric

Refactoring?

As I said above, Smalltalk refactorings don't even come close to what we do today with Eclipse and IntelliJ. They were also working on projects that were much simpler than today's.

Again, I would love to be proven wrong, but I'm getting tired of hearing "IDE's for dynamic languages will appear any day now". By now, I am thinking that considering the amount of interest in dynamic languages of late, these IDE's should already be here.

Don't abandon Java just yet

Don't abandon Java just yet

I think it's a pity that Java developers are so quickly grasping for Ruby on Rails

Personally I cringe when I see class properties being auto-generated from database tables. I think that's the wrong way 'round.

I'd hammer in the morning...

Anyone else out there feel like becoming a carpenter? How the heck is a SW practioner supposed to have a real life these days, keeping up with every spasm/twitch that shakes the foundation of software development. Can everyone here imagine what our business users would make of this conversation? Could we imagine how we would feel if the same conversations happened on the building sites of our new homes and offices?

Beyond Java

they were able to recreate the application in Ruby in 4 nights.how long did they worked on the original , 2 nights;-) Now serious, this statement doesn't mean anything. The second time you build something it goes always faster, regardless wherein.

dynamic stuff

This blog entry by Cedric Beust should also be of interest to you. If Sun needs 3 years to add a byte code to the JVM (if I may oversimplify a bit), then I'm afraid the fun is going to shift to .NET where innovation seems much faster nowadays...

The trade off between moving forward and backward compatability is tricky. I'd argue it's much easier to screw that up than get it right. If Sun were to totally break the JVM compatability and introduce several new low level features, I'm sure there are plenty of businesses that would be furious.

The point in my blog entry was actually to observe that adding a bytecode to the JVM is completely backward compatible, as opposed to changes such as adding keywords to the language (assert, enum), which, even now, are still wreaking havoc on existing codebases.-- Cedric

Java -> Ruby

Refactoring?

As I said above, Smalltalk refactorings don't even come close to what we do today with Eclipse and IntelliJ. They were also working on projects that were much simpler than today's.

&nbsp;Smalltalk and Ruby aren't "untyped", they are strongly but dynamically typed.

They are *easy* refactorings, whatever the language (except Intercal, but that's by design).

Don't abandon Java just yet

I think it's a pity that Java developers are so quickly grasping for Ruby on Rails

I don't think there is any evidence that they are. All that is happening is that Ruby on Rails hype is being widely discussed.

Personally I cringe when I see class properties being auto-generated from database tables. I think that's the wrong way 'round.

+1

Java -> Ruby

Rails's ZTT absolutely cannot be overstressed compared to the standard 2 minute J2EE deployment cycle. It makes development more about creativity rather than patience.

Remember what people said about Java in 1996, "it's slow and really only suitable for applets", and keep in mind that Ruby/Rails is only going to get better...

Beyond Ruby

How long to come up to speed?

Overloaded

Great Topic - DRY

+1

Don't abandon Java just yet

I think it's a pity that Java developers are so quickly grasping for Ruby on Rails

I don't think there is any evidence that they are. All that is happening is that Ruby on Rails hype is being widely discussed.

Personally I cringe when I see class properties being auto-generated from database tables. I think that's the wrong way 'round.

+1

I firmly believe auto-generation in either direction is just plain wrong. Maybe some fancy middlegen tool can create both from a common definition, but I think that if you are going to create a db schema from java objects or create java objects from a db schema then you are just going to make a mess of one of them. Just phoning in the database schema design is a sure way to cripple a project.Taking the extra time to do both right will pay off dividens for YEARS to come for most projects. Sure, it doesn't mean anything for a throw away demo. But how many of those "throw-aways" suddenly become the initial production version.

Great Topic - DRY

Most of the J2EE frameworks have a strong "architectural" bias towards loosely coupled layering. The advantange of this approach is that you can that you can swap out the different pieces. For example you can swap JDO <-> Hibernate, and the Struts framework is not affected.The disadvantage of this approach, is that we have to write all the glue code to support this loose coupling. Hence the importance of frameworks like Spring which help us with this task.

Great Topic - DRY

This is a great topic.Most of the J2EE frameworks have a strong "architectural" bias towards loosely coupled layering. The advantange of this approach is that you can that you can swap out the different pieces. For example you can swap JDO <-> Hibernate, and the Struts framework is not affected.The disadvantage of this approach, is that we have to write all the glue code to support this loose coupling. Hence the importance of frameworks like Spring which help us with this task.To see the problem with the current J2EE approach think about form valiation. We have a database table column with a not null column that has a maximum length of 10 characters. This database column maps to some Java object attribute. In a traditional J2EE we app we have this validation metadata information in:* database schema* ORM mapping files* Business tier validation, e.g. Service layer, DAO etc.* Appliation tier validation, e.g. struts Form * JSP If we change this column width to 15 characters we have to go through the entire appliction stack and make sure we haven't missed something.This is daft, and is a case in point why J2EE web app development is so painful.The RoR design principle of Dont Repeat Yourself (DRY) is very important, and will lead to more robust code and higher productivity. In OO terms this is encapsulation.I believe emerging Java frameworks will take these important design principles on board and provide us with a high productivity development environment.Malcolm Edgarhttp://click.sourceforge.net

Great Topic - DRY

I can see RoR having an advantage for "Mickey Mouse systems" which are a single developer effort, but not so much for applications which require a larger number of developers.

Java -> Ruby

Here is my J2EE database app. Under NetBeans 4.1 on my laptop I change a JSP. I redeploy ready for debugging in less than 20 seconds. What is this 2 minute deployment cycle?

The same has been said over many, many years about PERL, TCL, Python and now Ruby. There is as yet no evidence after several years that any of these scripting languages are truly general purpose. Java has had major development teams working on the VM in order to give close to C/C++ performance.

Overloaded

Good grief, the FUD-o-meter is overloaded!Re: refactoring and dynamic languages:Please don't make comments like "refactoring can't be done in dynamic languages" or "nothing like IDEA" or some such nonsense unless you know what you are talking about, or you at least google a little :). Someone at least mentioned Will Opdykes' paper (which in turn, if you at least read it before you comment, was influenced by work done by Ralph Johnson at UIUC and Brian Foote in the mid 80s). Anyone at all who used Smalltalk on any significant project can tell you about the refactoring browser, and the capabilities of most all Smalltalk IDEs, starting with Objectworks/ST-80. So saying "dynamic" languages don't support refactoring is just plain ignorance.And as for ROR, use it. Read about it. Pick up the pickaxe book by Dave Thomas, and read about Ruby. Get the Agile book by Ruby's creator. Write some projects using Rails. Look at some applications created using Rails (try http://www.37signals.com for a few links). The creator of Rails, David Heinemeier Hansson, maintains a blog at http://www.loudthinking.com, where he discusses everything Rails related. In other words, for Pete's sake, educate yourself. If you don't believe that Ruby is more productive than Java, or Rails lets you build Web applications easier, or Ruby or Rails somehow isn't ready for the "Enterprise" (whatever that means), then don't listen to Dave Thomas, or Andy Hunt. Or Bruce Tate, or Bruce Eckel, or James Duncan Davidson, or...I didn't listen to them either. But then several months ago I tried Ruby, then Rails, and I saw for myself. Maybe you will too.I teach Java and J2EE to feed my kids. But when I want to write an application to solve a problem, its not what I turn to first, at least, not anymore. This community is starting to remind me a whole lot of the C/C++ community when I first learned Smalltalk so long ago, and the C/C++ community when I first learned Java so long ago.

As they say, those that forget history.....--Brian

RE: Great Topic - DRY

... To see the problem with the current J2EE approach think about form valiation. We have a database table column with a not null column that has a maximum length of 10 characters. This database column maps to some Java object attribute. In a traditional J2EE we app we have this validation metadata information in:* database schema* ORM mapping files* Business tier validation, e.g. Service layer, DAO etc.* Appliation tier validation, e.g. struts Form * JSP If we change this column width to 15 characters we have to go through the entire appliction stack and make sure we haven't missed something. ...

Having to change all layers because of a column length shift sounds like you ever architected your system. This is not a J2EE problem. This is a *your* team problem.

Java -> Ruby

Here is my J2EE database app. Under NetBeans 4.1 on my laptop I change a JSP. I redeploy ready for debugging in less than 20 seconds. What is this 2 minute deployment cycle?

Now change an EJB. Change a Struts Action class. Yeah, maybe two minutes is pushing it but my Websphere cycle requires me to run a 300MB IDE, 300MB server and redeploying the app with every change takes 30 seconds while the app starts. .

RE: Great Topic - DRY

... To see the problem with the current J2EE approach think about form valiation. We have a database table column with a not null column that has a maximum length of 10 characters. This database column maps to some Java object attribute. In a traditional J2EE we app we have this validation metadata information in:* database schema* ORM mapping files* Business tier validation, e.g. Service layer, DAO etc.* Appliation tier validation, e.g. struts Form * JSP If we change this column width to 15 characters we have to go through the entire appliction stack and make sure we haven't missed something. ...

Having to change all layers because of a column length shift sounds like you ever architected your system. This is not a J2EE problem. This is a *your* team problem.

Please be reasonable and don't look for something to be wrong in the details. What if the data type was an integer but was insufficient and needed a long? What if a boolean needed to be turned into a char? What if a date was stored as a string and then needed to be converted to a date and time?

RE: Great Topic - DRY

What about something like WebObjects DirectToWeb and ...

RE: Java -> Ruby

Even an EJB changes doesn't necessarily require 2 minutes, but what if you don't use EJBs? J2EE isn't EJBs. Actions can be done without a restart depending on the nature of the change with Java's admittedly poor hotswap.

Regardless, the code reuse and maintainence is more than made up by the reuse and flexibility offered by Java.

Again, all we here is
1) faster restart
2) faster prototyping
Not thick enough.

One likes Ruby because his team is unable to design their app to withstand minor changes without a dozen updates.You like Ruby because you had problems setting up eclipse(no offense). This tells me the other guy over-engineered is app and you have issues with Eclipse.

What if you don't have these problems? What if you can write your apps quickly, without 2 minute deployments, and no tool issues?

What if you want your application architecture and subsequent applications based on it to run run on anything from Tomcat to Websphere with declarative AOP, transaction support, messaging, etc and is backed by industry heavyweights?What then?

Not paying enough attention.

Again, all we here is
1) faster restart
2) faster prototyping

crazy idea

crazy idea

Not paying enough attention.

But for starters, try these benefits in Rails:- Rapid feedback cycle....

Not even the next thing

What I do see is that RoR tries persistively and desperately pretend it _is_ a next big thing. Well, it is next, but not that big. I admit there might be some reasonably good ideas in RoR, but to overthrow Java it would need to become much more than it is now.

Java -> Ruby

The same has been said over many, many years about PERL, TCL, Python and now Ruby. There is as yet no evidence after several years that any of these scripting languages are truly general purpose. Java has had major development teams working on the VM in order to give close to C/C++ performance.

They didn't have rails. Rails is the key because its productivity increase makes it a real contender for small-site development.

Ruby/Rails can fulfill the vast majority of web site performance requirements and it will only get better over time.

One simple question, Steve: have you actually tried Rails?

Java -> Ruby

Even an EJB changes doesn't necessarily require 2 minutes, but what if you don't use EJBs? J2EE isn't EJBs.

Again, all we here is
1) faster restart
2) faster prototyping
Not thick enough.

What if you don't have these problems? What if you can write your apps quickly, without 2 minute deployments, and no tool issues?

c /c++/Java/, and c /Ruby/Java/

Behind Java

Java -> Ruby

So Rails gives Ruby C/C++ performance? Neat! How?

Let me know when there is a Ruby VM that matches Java performance.

Yes. I gave up when I saw that there was no portable query language (I routinely switch my development between PostgreSQL, MySQL and Oracle and I want to use the full features of each, not some minor SQL subset)

c /c++/Java/, and c /Ruby/Java/

Where have I heard that before?

JRuby

Java -> Ruby

Smalltalk had "close to C/C++" performance (your words).

Hell, when I was at OTI our Smalltalk VMs used to routinely beat C/C++ apps running the same functional code.

Are people still really calling Perl and Python scripting languages, or is that just sarcasm I hear?

Yes. I gave up when I saw that there was no portable query language (I routinely switch my development between PostgreSQL, MySQL and Oracle and I want to use the full features of each, not some minor SQL subset)

Honestly, enlighten me. What portable features is ActiveRecord missing that you need?

Yes it is what me too sensing

Don't abandon Java just yet

I firmly believe auto-generation in either direction is just plain wrong. Maybe some fancy middlegen tool can create both from a common definition, but I think that if you are going to create a db schema from java objects or create java objects from a db schema then you are just going to make a mess of one of them. Just phoning in the database schema design is a sure way to cripple a project.Taking the extra time to do both right will pay off dividens for YEARS to come for most projects. Sure, it doesn't mean anything for a throw away demo. But how many of those "throw-aways" suddenly become the initial production version.

Overloaded

I don't think anyone claimed refactoring is impossible, but clearly there are differences in terms of how refactoring would work.

It's easier because it's much more limited :-)

Your examples only touch the very easy (and somewhat rare) cases of refactorings. They also only show dynamic refactorings as opposed to simple static (at the text editor level, not design).

With dynamic languages, something as simple as renaming a method in a class can pretty much only be done by text replacing, which is of course unacceptable.

People who say that Smalltalk showed that it was possible have obviously never used Smalltalk IDE's, which only did the simplest refactorings (such as extracting methods).

Modern Java IDE's have raised the bar very high in terms of refactorings, and as far as I can tell, it's just plain impossible to reach that bar with dynamic languages.

As I said above, Smalltalk refactorings don't even come close to what we do today with Eclipse and IntelliJ. They were also working on projects that were much simpler than today's.

And it's not a coincidence: in my opinion, some of these refactorings are just plain impossible to achieve with dynamic languages (more details here).

This shouldn't come as a surprise: you gain some readability by omitting types here and there, but there is loss of information. Humans might be more comfortable with less typing information in the code they read, but IDE's surely aren't, and if you don't give them these types, they won't give you refactoring.

Not paying enough attention.

Tighter mapping for the intended case (you control your schema).

Ruby Performance was +1

I'am getting really tired about comments saying that fast development doesn't mean anything. It does mean a lot. Why should we wait and wait and wait forever, i'v waited enough, more than enough. Make that hotswap accept API changes, for goodness sake PLEASE!

The real question we should be asking is this: Why isn't the JVM the best platform for Ruby to be running on, and how do we "fix" it so it is?Peace,Cameron PurdyTangosol Coherence: The Java Data Grid

I'm very interested in JRuby. I'm about ready to start promoting unit tests for Java in the Ruby language. JRuby is not there yet, but it's getting very close. I think it's passing more than 90% of the existing Ruby test cases now.

Reduced configuration...

Most of us take a big fat relational database and front it with a web UI.

Some more thoughtful posts please?

A lot of the posters here seem a tad, um - defensive. Many of the responses run the line of: 4 nights != development, blah blah.It sure is easier to crank out a knee-jerk reaction to the serverside poster's one-paragraph summary than to take the time to read and possibly think about Bruce's article.

Java -> Ruby

Hell, when I was at OTI our Smalltalk VMs used to routinely beat C/C++ apps running the same functional code.

Java -> Ruby

No, not my words (or if they were, I mistyped).

The same has been said over many, many years about PERL, TCL, Python and now Ruby. There is as yet no evidence after several years that any of these scripting languages are truly general purpose. Java has had major development teams working on the VM in order to give close to C/C++ performance.

I had 4 criteria for language use. The one that Smalltalk most commonly failed on was speed. I could get very high-performance Smalltalk implementations, but they were not cross-platform

Ruby Performance was +1