Justin Gehtland recently tried re-implementing one of his web applications in Ruby on Rails instead of his normal Java Spring/Hibernate setup, according to a Slashdot post. His port resulted in a Ruby app that was as large as the configuration portion of the Java app, and 15-30% faster, echoing excitement in the Ruby community about the upcoming 2.0's new optimized byte code compiler.

The specific results:

Lines of Code
Rails: 1164
Java: 3293

Number of Classes:
Rails: 55
Java: 62

Number of Methods:
Rails: 126
Java: 549

Configuration Lines
Rails: 113
Java: 1161

...
To walk the entire application feature set, once, in Rails, without caching, took 41.801s. To walk the exact same feature set in the Java app took 58.369s. These numbers are averages over five attempts with each app, with full restart between to give the cleanest runs possible.

Justin concluded that the application he worked on was well suited for Rails, but Java is just as capable. Justin was most surprised that Rails itself could be performant. Despite the surprising numbers the Rails implementation had, Justin concludes:

I think that there is a lot to be said for Rails, and it deserves much of the press it is getting. However, I don’t think its a Java-killer. I think there are plenty of applications, and development teams, that are better suited to Java and its immense universe of available support libraries. I certainly am not going to stop developing in and learning about Java just because I’ve discovered Rails. On the other hand, I am going to spend more of my time trying to find projects that I can use Rails on.

I'm starting to wonder if that April fools day article was a joke, or a prediction?

+1

Ruby is a good OO scripting language. Rails is an excellent MVC web application generator. When you combine the two you have a compelling, domain-specific set of tools for creating typical web applications (generally a few pages talking to a few tables on the back-end). Moreover, any unskilled hack can generate a working application, as can a skilled developer.

I will be sticking with JBoss Seam and Java EE for most of my work. Typeless scripting languages didn't suddenly lose all of their many, disastrous qualities in terms of general purpose use. I am using ROR for simple applications that need to be hosted on a LAMP stack. Keep in mind, that's the VAST majority of sites which is why Ruby on Rails is so popular.

One thing this proves a Rails implementation that caches HTML is much faster than Java implementation that doesn't. I haven't worked with Spring caching (I use OSCache) but if it only goes from 70 RPS -> 80 RPS, I'm assuming its not really caching the HTML responses. Otherwise the response times would have increased much more dramatically.


Number of Classes:
Rails: 55
Java: 62

Number of Methods:
Rails: 126
Java: 549


I can only assume since that since there are roughly the same number of classes, but many more methods that quite a few of those java methods are getters and setters.

Since every Ruby vs Java comparison seems to come down to lines of code comparisons, I guess its time we java folks wake up and realize that getters and setters are a serious overhead that is killing our projects. All those IDE generated methods *must* be a significant source of bugs and developer time. I guess we should start using public fields exclusively then. [/Sarcasm off]

How many bugs are in getters and setters? Close to 0. How much time do you spend making them? Close to 0. How convenient are they when you really do need to change the implementation? Very.

Not true in my experience.. i.e. change the name of a column in a database and you need to keep getters and setters up to date.

Although it's simple code to write if you're maintaing 40 or 50 value objects against a schema then I disagree strongly that this has zero maintenace time.

How many bugs are in getters and setters? Close to 0. How much time do you spend making them? Close to 0. How convenient are they when you really do need to change the implementation? Very.

Not true in my experience.. i.e. change the name of a column in a database and you need to keep getters and setters up to date.Although it's simple code to write if you're maintaing 40 or 50 value objects against a schema then I disagree strongly that this has zero maintenace time.

Come on! If you are using a good IDE, it can handle this task for you easily!

Not true in my experience.. i.e. change the name of a column in a database and you need to keep getters and setters up to date

The getters and setters only need to change if you change the name of the attribute for java beans compliance. Changing the database schema doesn't necessarily mean you have to change your value objects. And if you do change the getters and setters you break any code you have working with the object.

Less hassle to allow the domain model and database schema to vary independantly if possible and only change the mapping.

Call me stupid, but I don't get this "lines of code" comparison. I prefer to be verbose in my code so that it is easier to read at some time in the future. I go one step further and describe the implementation algorithm, and leave notes about potential ways to extend the code if new requirements are added.

If lines of code is how people want to judge programming, then we should all write PERL and make it all one line. That way, it will be impossible to update and prevent management types from requesting new features. In fact, we should apply this to everything. All stadiums should have 1 door so that you only need one ticket person to collect the ticket. All books should be written on a scroll in one long sentence.

</joke>

If lines of code is how people want to judge programming

I'm not sure the author says that LOC is the only way to judge programming, but that he felt a lower line count has benefits.

I also think that counting lines of code is a bit stupid... Each attribute in a Java class will result in at least 6 more lines of Java code (if you use getter/setter). I'm pretty sure this will account for most of the LOC difference between Ruby and Java.

As for performance... Making many tests runs should NOT involve restarting the application as one-time initialization will be repeated and it surely does not represent how the application will be used on a day to day basis.

As many other people indicated in various forums... Performance != scalability.

Anyway all these comparison seems to be done with really small projects. A project of several man/month with one team using one stack and another team using the other stack would be the only way to have meaningful results (and to improve the result, have each team using the other stack to do the same project - this way, you will cancel out any productivity difference between the two teams).

I don't see anything with this technology/architecture that is not reproducable in Java.

Unfortunately mainstream Java architectures are falling behind compared with Ruby on Rails.

Rock Lists.
Top Rock Lists

I don't see anything with this technology/architecture that is not reproducable in Java.Unfortunately mainstream Java architectures are falling behind compared with Ruby on Rails.Rock Lists.

What you fail to consider is the fact that Java HAS a mainstream architecture, and a gazillion man hours of developement, real world use, improvement put in to it.

There seems to be this fascination with Ruby that this magic technology came out of nowhere. Just a flash of inspiration.

However, as a famous inventor once quoted: "Progress? I've made lots of progress. I know hundreds of things that don't work."

Just as Spring exists because EJB managed to get mainstream and go into production where all of the wonders and warts are available for all to see, something like Rails leverages the innate introspection of its language, along with all of the knowledge of the benefits and difficulties towards developing a web application. Being able to cherry pick the gems from the battlefields of real world experience, Rails appears "as if out of nowhere", when in fact it is just Yet Another framework that seems to have grabbed the eyes of the press.

It's an interesting project, but I don't believe it will stand the test of time, as it doesn't have the rest of the foundation upon which Java and J2EE systems rest: powerful, tested, performant infrastructures doing the grunt work on the back end, smart people and companies expanding and promoting that infrastructure, and a vast, knowledgable user base to leverage it all into modern systems.

I'm not worried about being "left behind" at all.

That's a really nice quote. I'll have to remember that.

Bought by Microsoft I say!

If you are going to do performance testing of server-side applications, at least show a semblance of rigor.

A single-threaded client test for the duration of walking a set of a pages is not a meaningful test, when you've only run it five times sequentially after a restart. It unfairly penalizes the Java application, because it has not reached a steady state, the hotspot compile times are significant, and optimization has not had a chance to work in the application's favor.

Moreover, server applications are usually operating under some level of load. Testing a server application with a single client thread is not meaningful. Unless, of course, one is trying to find a set of obscure results that conveniently support a desired conclusion, under some special circumstances.

To balance a bit the java-is-oh-so-serverside-you-script-kiddies-would-never-understand arguments in this thread, remember tada and basecamp are rails apps. They are out there and commercial and whatever, and I've tried basecamp for two weeks and it was an excellent experience.
Perhaps word on setup of a real life rails application will put a stop to all this benchmarking in the back yard trend we've seen recently. I for one think Java is something to fear performance-wise if you throw some CPU and a shitload of RAM at it. I'm still a C++ and native code (gcj) believer cause I've come after 4 years of Java to dislike it's plastic taste. Nevertheless... I hope there's hope for, what do they call it, RoR.

Cheesus Saves

my only compliant is the whole "line count" comparison. Although Ruby is not popular in the US, it is very popular in Japan and other countries. It is also fairly popular in AI research field.

peter

my only compliant is the whole "line count" comparison.

fair enough. I think it's not about actual LOC but more about "how fast and clear can this be expressed while keeping the same benefits in language X as I have in Y". This is where LOC matters. For instance you needn't write 5 lines of code with stupid exception handling to do regexp. As far as I know regexp in considered in Ruby something along the lines of trim() or tolower(), in terms of simplicity. Much like in PERL.

This is type of stuff that makes people go wow and claim productivity gains. Also exotic features like mixins account for re-design needs, opening up new approaches, much like AOP does, but without the magick involved in AOP in Java and bit more within the OO domain.

On a relativel unrelated note, regarding the plastic taste of Java, you'd expect a bit more expresiveness and power from a system that's so ... comfortably numb, safe within its VM. Something a bit more daring. If you take a look at how complete and complex C++ is you'll understand why it takes decades to approve additions (_not_ changes, additions) to the core languages and standard libraries.
He who calls C++ legacy does not know shit either about it or programming. I think it's by far the most ambitious programming project since the Burroughs 5000. It reaches so far and wide it's unbelivable, but after all, it's an infinitely complex world out there.
Java has definitely taken the path of the shadows when it comes to choice, innovation and ambition in a programming language. It's dull. It's castrated. It's so fucking boring it makes you want to scream. Granted all of this gives me huge headstart when building a transaction processing system. But there's no sparks there. It's definitely not the reason I started programming 15 years ago.

... Much like in PERL.This is type of stuff that makes people go wow and claim productivity gains...

Which, it occours to me, is exactly like I don't like Ruby: it smells like perl. When I first looked at the Python grammar I was excited (it's the best dynamically typed language I've seen); when I first looked at Ruby, all I felt was at least it's better than perl. If people want to migrate from perl to Ruby I'll lead the cheer, but it's not a real language. (when a functional web/app framework goes mainstream then I'll get excited; yes, I'm a Haskell fan)

On a relativel unrelated note, regarding the plastic taste of Java, you'd expect a bit more expresiveness and power from a system that's so ... comfortably numb, safe within its VM.
...
Granted all of this gives me huge headstart when building a transaction processing system. But there's no sparks there. It's definitely not the reason I started programming 15 years ago.

I started programming about then, I was suspicious of Java when I first started with it.. for a whole few hours.. 7 years later I'm still constantly amazed how close to right they got it (no language will ever be perfect). You can do practically anything [anything imperative/OO, anyway] in Java/JVM. I can't see any platform without checked exceptions and static typing being any threat for enterprise level apps. That said, since small apps far out number larger ones, though I prefer Python, I would not be surprised (or unhappy, like I said: not perl) to find RoR apps outnumbering J2EE one day.

That said, since small apps far out number larger ones, though I prefer Python, I would not be surprised (or unhappy, like I said: not perl) to find RoR apps outnumbering J2EE one day.

There is definitely some truth to this. If nothing else, maybe it will ursurp the untold zillions of programmers using PHP? That would be very welcome. As languages, I would say that Python, Ruby, Smalltalk, C#, and Java come naturally to the same type of people where as (versions 4 or lower, I'd abandoned it all together before 5 hit the scene) PHP... and (classic) ASP, and C, and Perl appeal to an alltogether different pattern of thinking. Having Ruby become ensconsed in the small-webapps tier would be a blessing, and it might serve to make a Java skillset more useful in other applications.

Currently I use Python for my scripting purposes and Java for anything bigger than a command line app. If Ruby could replace Python and extend itself into the creamy noogety crossection of apps one might approach otherwise with PHP, that'd be convenient.

As for whether its inherently better or not, I don't know.

Just my $.02.

As languages, I would say that Python, Ruby, Smalltalk, C#, and Java come naturally to the same type of people where as (versions 4 or lower, I'd abandoned it all together before 5 hit the scene) PHP... and (classic) ASP, and C, and Perl appeal to an alltogether different pattern of thinking

and where will be C++? may be a bridge or a doorway between the two worlds?

Having Ruby become ensconsed in the small-webapps tier would be a blessing, and it might serve to make a Java skillset more useful in other applications.

Exactly. I dont understand this thinking of dissmissing "this is not java/j2ee - so this cant be as good". I have been a java developer for years and let's face it, problems are there(where isn't?).But still it rules,setting aside predictions from a lot of people that .net will kill it completely. Has it happened? So there is nothing wrong if a different language that adheres to same thinking pattern of a average j2ee web/app developer comes up with a good framework
let's try it,knowing in our heart that java/j2ee will rule for years to come in mision-critical,scalable enterprise application development.

"knowing in our heart that java/j2ee will rule for years to come in mision-critical,scalable enterprise application development"

Which nobody has been able to prove that exist even in a single installation.

All we have is a mid-market between toy-applications and mainframes which for years has tried to be filled with rather unsuccessful J2EE projects like filling a round hole with a square pig.

Regards
Rolf Tollerud

Do you have a job Roffe? Have you seen .NET being deployed on the client-side programmed in anything but VB.NET? Have you seen ANY server-depoyment with .NET? No?

High-end server apps are still J2EE and C/C++. Mid-market apps are struts/lightweight java. Low-end toy-apps are a toss-up between PHP and oldass ASP.

Shhh roffe.

"knowing in our heart that java/j2ee will rule for years to come in mision-critical,scalable enterprise application development"

Which nobody has been able to prove that exist even in a single installation.

Three guys end up in hell: A Catholic, a Protestant and a Christ's Scientist. Satan asks them each why they're there.

The Catholic says he hadn't been to confession in a while, but "it's just a matter of time and I'll be on my way to heaven."

The Protestant admits that while he sat in church all his life, it was just for show.

"And you?" the devil asks the third one. In response, the Christ's Scientist says "Oh, there is no hell and I'm not really here."

Peace.

"knowing in our heart that java/j2ee will rule for years to come in mision-critical,scalable enterprise application development"Which nobody has been able to prove that exist even in a single installation.

Three guys end up in hell: A Catholic, a Protestant and a Christ's Scientist. Satan asks them each why they're there.The Catholic says he hadn't been to confession in a while, but "it's just a matter of time and I'll be on my way to heaven."The Protestant admits that while he sat in church all his life, it was just for show."And you?" the devil asks the third one. In response, the Christ's Scientist says "Oh, there is no hell and I'm not really here."Peace.

[writing down joke ...]

"knowing in our heart that java/j2ee will rule for years to come in mision-critical,scalable enterprise application development"Which nobody has been able to prove that exist even in a single installation. All we have is a mid-market between toy-applications and mainframes which for years has tried to be filled with rather unsuccessful J2EE projects like filling a round hole with a square pig.

RegardsRolf Tollerud

Frankly, who care about which one wins? that's just a pointless battle with no winners. I prefer to learn what it has to offer. I haven't tried RoR and don't know if it really offers something new and different. My guess is RoR will grow and add features, at which point the whole argument of simplicity goes out the window. Simplicity is good and all, until you realize feature creap and rapidly changing requirements is the defacto mode of development for business applications.

I've yet to work on a project that didn't change some part of the spec during development.

the tree does make a sound

peter

... like filling a round hole with a square pig.

Isn't that how they make sausages ?

Kit

"knowing in our heart that java/j2ee will rule for years to come in mision-critical,scalable enterprise application development"Which nobody has been able to prove that exist even in a single installation.All we have is a mid-market between toy-applications and mainframes which for years has tried to be filled with rather unsuccessful J2EE projects like filling a round hole with a square pig.RegardsRolf Tollerud

Tsk. I thought we had already agreed that you were not permitted to say this anymore, as only a day or so ago you personally accepted that EBay was a mission-critical, scalable enterprise application running J2EE/EJB.

You said, and I quote:

1) Ebay is constructed very different from ordinary J2EE/EJB projects.

Either you are suffering from memory loss, or ....

"knowing in our heart that java/j2ee will rule for years to come in mision-critical,scalable enterprise application development"Which nobody has been able to prove that exist even in a single installation.All we have is a mid-market between toy-applications and mainframes which for years has tried to be filled with rather unsuccessful J2EE projects like filling a round hole with a square pig.RegardsRolf Tollerud

Tsk. I thought we had already agreed that you were not permitted to say this anymore, as only a day or so ago you personally accepted that EBay was a mission-critical, scalable enterprise application running J2EE/EJB. You said, and I quote:

1) Ebay is constructed very different from ordinary J2EE/EJB projects.

Either you are suffering from memory loss, or ....

Spare him Steve.He is probably too scared that due to rise of these dynamic languages web frameworks, more and more developers will slip from m$ grip as they wonder about their future VB/Com->.net everywhere(OH! and MONO too)->avalon/XAML->jesus what next,when will they learn
Rolf my friend,please keep on posting these nonsense, You sure provide me with enough material to laugh my way to home at the end of a java/j2ee development day
<prediction>
THESE DYNAMIC LANGUAGES WILL CAUSE MORE DENT AT ASP.NET WORLD WHERE THE .NET STILL IS CONSIDERED FOR MID SIZE APPS
IT IS NOT J2EE/JAVA WHICH WILL SUFFER
</prediction>
Oh! And if I am a java developer I will not take that benchmark too seriously,Every good framework is nowadays compared to java/j2ee stack becuae one can prove how good it is if it competes well with the BEST
I WOULD LOVE TO SEE MORE LIKE RAILS, it gives me "choice"
something dear old M$ will never understand

Which, it occours to me, is exactly like I don't like Ruby: it smells like perl.

I don't think that's fair: you chose to pick bringing regexp into the language and turn it into an anti-feature that makes ruby perlish.
You're forgetting that Python was turned with great pains into an OO language, which is definitely not the case for Ruby. Ruby also has some very nice "exotic" features. All in all, though never seriously programmed Ruby, I find it to be quite a well designed and pleasant language. Oh and yes I cannot understand for the life of me the idiotic indentation thing in Python. Whitespace should definitely not be language construct.

my only compliant is the whole "line count" comparison. Although Ruby is not popular in the US, it is very popular in Japan and other countries. It is also fairly popular in AI research field.peter

Anime also comes from Japan. Another things us older people don't get. :)

All these discussions remind me of the famous book Crossing the Chasm. Ruby/Rails enthusiasts are the 'early adopters', and Java proponents (the outspoken ones on this subject) are the 'mainstream'.

It doesn't surprise me that the two groups are talking right past each other. It's all irrelevant anyway, because like it or not, Rails is Ruby's killer app. That's the only thing that really matters here, long term. Rails will propel Ruby into the mainstream of dynamic languages, along with Python, Perl, and PHP. This is now inevitable.

Rails is Ruby's killer app. Rails will propel Ruby into the mainstream of dynamic languages...This is now inevitable.

Please forgive my sarcasm in advance...

[sarcasm]
Wow! That single link to a blog that makes some seriously flawed conclusions based on a link to some rather iffy data convinces me, for one, that Rails' world domination is imminent!
[/sarcasm]

The blog referenced above concludes RoR is a killer app based on the traffic growth of ruby-lang.org. Where does one begin!!?? r-l.org, springframework.org, rubyonrails.org, and intellij.com all have nearly identical curves. These are just a few sites I compared. Therefore, there must be another explanation for this data than "RoR is exploding."

Maybe the lesson learned is not to over engineer your application? I always laugh when I see developers over compensating in their programming as if they are trying to make up for something....

IMHO, spring is for the birds. I would be interested in seeing someone reverse engineer Rails into a Java framework and then benchmark on that. You can't blame Java for Spring's or Hibernate's diarrhetic use of XML or processing power.

These performance and LOC numbers could also be interpreted in the slightly different way:

The Java implementation of the example app sucks. You do not use Spring and Hibernate to develop a small isolated app. If you have tens of small apps and Spring and Hibernate is a corporate standart, that is another story.

This interpretation makes much more sense to me.

However, I DO MISS closures in Java.

The Java implementation of the example app sucks. You do not use Spring and Hibernate to develop a small isolated app.

Agreed. It's ironic that Spring and Hibernate are being evangelized as light weight, when I've witnessed the combination triple the development effort of "a small isolated app". And now we see in this study, Spring and Hibernate dragging on the project like so much dead weight. I'll be glad when EJB-3 sweeps them aside.

The Java implementation of the example app sucks. You do not use Spring and Hibernate to develop a small isolated app.

I suppose raw JDBC and no IoC are the way to go then?

The Java implementation of the example app sucks. You do not use Spring and Hibernate to develop a small isolated app.

I suppose raw JDBC and no IoC are the way to go then?

The Java implementation of the example app sucks. You do not use Spring and Hibernate to develop a small isolated app.

I suppose raw JDBC and no IoC are the way to go then?

Sorry, I have a tricky mouse finger--

I would go straight model 1, use JSTL SQL or use Sun's Creator Studio to do the same thing with JSF, in probably a fraction of the time that is spent working with Spring/Hibernate.

The Java implementation of the example app sucks. You do not use Spring and Hibernate to develop a small isolated app.

Agreed. It's ironic that Spring and Hibernate are being evangelized as light weight, when I've witnessed the combination triple the development effort of "a small isolated app". And now we see in this study, Spring and Hibernate dragging on the project like so much dead weight. I'll be glad when EJB-3 sweeps them aside.

Well, my first question would be "Why?" If you don't use Spring or Hibernate, why sweep them away?

My second question that EJB3, at least what I've read, doesn't appeart to be a replacement for Spring so the sweep is unlikely.

Now, confronting your drag statement, I don't see it. As I've said before, if I can create a small app or a large one utilizing the same basic framework and it both easy to write and maintain and is scalable, both in terms of performance and maintainability, why not use it?

While you may pay some upfront initial, just like when you use any new tech, the benefits of consistency far outweigh the curve. And that's pretty steep.

I have a basic, working framework that just about any reasonably competent Java developer can start using. Any questions, you've got a rich set of resources for Spring, Struts, and Hibernate.

While you may pay some upfront initial, just like when you use any new tech, the benefits of consistency far outweigh the curve. And that's pretty steep.

Sorry, that should read "And that's not steep."

The Java implementation of the example app sucks. You do not use Spring and Hibernate to develop a small isolated app.

Agreed. It's ironic that Spring and Hibernate are being evangelized as light weight, when I've witnessed the combination triple the development effort of "a small isolated app". And now we see in this study, Spring and Hibernate dragging on the project like so much dead weight. I'll be glad when EJB-3 sweeps them aside.

Spring IS lightweight, as everyone who has spent 10 minutes understanding its architecture will undoubtly tell you. The fact you look at it and don't immediately grasp all of its features means it's *powerful*, not *heavyweight*.

In my opinion the difference between "heavy" and "powerful" is subtle. Heavy is something that can be powerful, but gives you no option about it: you activate all of it, you install all of it, you distribute all of it, you have to control, patch, manage, maintain all of it at once.

Powerful is something that gives you options when you need them, makes it easy adopting those options, but treats them as they are: options. Spring provides a good tool for weaving together a number of options, consistent configuration practices, a number of patterns that help structure an architecture and so on.

Is "webwork" + "struts" + "tapestry" + "spring mvc" + "jsf" a "heavy" web layer? Yes, if you have to use all parts of it, configure them all, and so on. But of course you needn't.

Take your spring-core jar, use it only for its ioc options: you ARE using spring, and it's only a small jar: you don't have to use all of the rest. Add data access: you add one or two new jars. Add aspects. Add web features. Add security. Add some of the integrated vertical functionality (reports, remoting, caching, etc.): dependencies are minimal between different components, and that's the main reason why all of this is "lightweight".

Saying that "spring + hibernate drag like dead weight" in a project tells two possible things: the one who architected the project is a fool (and didn't really use the features the y provide), or the project is really too simple to be considered. When you will have EJB3 it won't be much different, since it's based on hibernate philosophy and provides a number of the less powerful spring ioc features.

At that moment people who never really looked at what spring provides - and think it's heavyweight because it's well documented (in fact the spring documentation is becoming heavier, when I print the new versions of the reference manual) - will be relieved by the fact that they will more or less be able to work in a similar way using "only" a full-fledged j2ee 1.5 application server such as WebSphere 7.

And now we see in this study, Spring and Hibernate dragging on the project like so much dead weight.

Take your spring-core jar, use it only for its ioc options: you ARE using spring, and it's only a small jar: you don't have to use all of the rest. Add data access: you add one or two new jars. Add aspects. Add web features. Add security. Add some of the integrated vertical functionality (reports, remoting, caching, etc.): dependencies are minimal between different components, and that's the main reason why all of this is "lightweight".

Ok, so 'lightweight' to you means that Spring can be used ala carte. But this study implies something very different, that 'lightweight' means less custom code. And by this Mythical-Man-Month metric, I suppose Spring and Hibernate seem inferior. Will EJB-3 do much better? I hope so. We certainly deserve better POJO automation than the profusion of frameworks that predate EJB-3.

 But this study implies something very different, that 'lightweight' means less custom code.

I disagree. I think all this "study" (with quotes outrageously intentional here) implies is that Hibernate may be too heavyweight if your entire project can be implemented in 4 days.

If on the other hand it stretches out to, oh my lord, two weeks or more, then the jury is still out. :-)

Lightweight means quite a lot:
- a la carte = use what you need
- non-invasive = your core code code is not coupled with any framework or infrastructure API
- easy to use = abstracts away complexity
- consistent = similiar problems are solved with similiar approaches, at a consistent layer of abstraction
- lets you focus = the code you write directly goes to solving the domain problem, boilerplate infrastructure is eliminated, infrastructure becomes a choice selected as part of application configuration.

I could go on. Spring and Hibernate have done wonders for Java and J2EE, as Justin and any other person like David with experience with either will attest to. Neither of them are going away any time soon, and they'll both be leveraged with EJB3. --* If you want details on that, Hibernate 3 will be wrapped by a thin JBOSS's JSR 220 facade; Spring will provide EJB3 support analagous to it's current EJB2 support, for exporting well-defined service entry points of an app to the EJB server *---

Anyway, a much more interesting metric in my mind, one that Justin hopefully will provide us, is the percentage of code written in both versions that were focused on the domain problem. I'm talking core business logic here, not superflourous stuff. I imagine Java will score quite high there, largely because of Spring in play.

Furthermore, I'll go out on a limb and claim Justin's Java version could be simplified overall without any sacrafice in code maintainability--as I'll assume his, like most other small, CRUD apps are often overengineered in terms of abstraction layers, simply because it's often said to be a best practice. I've seen it time and time again, I see it now in sample applications that teach how to use Spring. Doesn't mean it's right, and it doesn't mean Spring is to blame.

I also doubt Justin is taking advantage of Spring 1.2 and Hibernate 3 features, which further reduce LoC overall.

I agree with Mike: the choice as to whether Hibernate was indeed the right tool for the job to begin with is debatable. In any case, it's architecture as a Data Mapper is fundamentally different than a Rail's Active Record, and as a result there are tradeoffs. That difference right there just throw my arms up in the air about this whole thing.

And now we see in this study, Spring and Hibernate dragging on the project like so much dead weight.

Take your spring-core jar, use it only for its ioc options: you ARE using spring, and it's only a small jar: you don't have to use all of the rest. Add data access: you add one or two new jars. Add aspects. Add web features. Add security. Add some of the integrated vertical functionality (reports, remoting, caching, etc.): dependencies are minimal between different components, and that's the main reason why all of this is "lightweight".

Ok, so 'lightweight' to you means that Spring can be used ala carte. But this study implies something very different, that 'lightweight' means less custom code. And by this Mythical-Man-Month metric, I suppose Spring and Hibernate seem inferior. Will EJB-3 do much better? I hope so. We certainly deserve better POJO automation than the profusion of frameworks that predate EJB-3.

Ok, this is reasonable: I agree that if one can prove that any app developed with ruby + ror takes 70% less code than the equivalent in SprHib this is a very significant factor: it is "light" with respect to the development experience. What I frankly can't believe is the idea that EJB3 will be substantially "lighter" than SprHib, with respect to this same "metric": it's for this reason that I find at least unfair saying that spring is some sort of a burden and naive the hope that ejb3 will relieve that burden. I have been working with spring for a year and a half, and I am constantly amazed by the quality it provided to my architecture (with the inclusion of Acegi, too).

I agree that if one can prove that any app developed with ruby + ror takes 70% less code than the equivalent in SprHib this is a very significant factor ..

.. especially if it also takes 70% less time to write, is 70% easier to maintain, takes 70% less time for someone new to it to understand it, etc.

What I frankly can't believe is the idea that EJB3 will be substantially "lighter" than SprHib, with respect to this same "metric": it's for this reason that I find at least unfair saying that spring is some sort of a burden and naive the hope that ejb3 will relieve that burden.

You haven't been paying attention to the last twenty "software revolutions" .. it is extremely clear that EJB3 will solve all manners of problems in the most simple and perfect way possible, up until the point that people actually have to start using it to build applications, at which point they will start complaining about it and saying "I told you so!"

That doesn't mean that EJB3 is bad or good, just that developers seem to have infinite trust in certain types of Technobabble Vaporware, yet they get extremely fickle when it comes to using what they actually have available.

The grass is always greener ..

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

.. especially if it also takes 70% less time to write, is 70% easier to maintain, takes 70% less time for someone new to it to understand it, etc.

since a good chunk of my work experience has been fixing existing code, I would say the last 2 are more important than the first one. I really don't care if it's 70% or 100% quicker to write. If the maintenance cost ends up being 300% more than language/platform X, you have a net loss in productivity.

After having downloaded Rails and played with for a day! ;) I have to say that it would be trivial to convert to Java, or any other language. It is really a nice environment, "sparse like a Japanese tea room, as functional as a Zen studio", but not suited for all projects. How often are you allowed to name you own tables and columns? But for the projects that suits it is nonparrarell. Amazing!

But the point is that it is not in any way limited to Ruby. So be prepared for the first port.

Regards
Rolf Tollerud

After having downloaded Rails and played with for a day! ;) I have to say that it would be trivial to convert to Java, or any other language. It is really a nice environment, "sparse like a Japanese tea room, as functional as a Zen studio", but not suited for all projects. How often are you allowed to name you own tables and columns? But for the projects that suits it is nonparrarell. Amazing!But the point is that it is not in any way limited to Ruby. So be prepared for the first port.RegardsRolf Tollerud

Good point. And I shall name it "Jails" :-)

Seriously though, Ruby on Rails uses quite a few Ruby idiosyncracies. They could definitely be ported to Java but they will lose some expressiveness in the process, so the question is: will the Java port still be compelling?

--
Cedric

Cedrik,

will the Java port still be compelling

I definitely thinks so. It will have everything that RoR has and in addition capability to generate a full Spring/Hibernate application!

And I shall name it "Jails" :-)

They already have named it "Trails".

hi hi

Regards
Rolf Tollerud
(I did not wave my hands!)

Cedrik,will the Java port still be compellingI definitely thinks so. It will have everything that RoR has and in addition capability to generate a full Spring/Hibernate application! And I shall name it "Jails" :-)They already have named it "Trails".hi hiRegardsRolf Tollerud(I did not wave my hands!)

Isn't trails based on spring + tapestry + hibernate + xdoclet?!?

and in addition capability to generate a full Spring/Hibernate application!

Ah, yes, I should read more carefully... ;)

What I frankly can't believe is the idea that EJB3 will be substantially "lighter" than SprHib, with respect to this same "metric"...

You seem to be saying that not even EJB-3 can save us from the insult of having to write by hand more error-prone lines of code than a script kiddie with the same goal. So much for POJO automation and its supposed reduction of effort.

This study shook me. Not because serious automation isn't possible in Java, but rather because the Java vanguard seem not to care about the primacy of less hand coding. This is disappointing, and a study that shows Spring/Hibernate to be a pig has miraclulously twisted into another monotonous thread about how awesome Spring is. At least in the MDA threads here, we acknowledge the lameness of hand code and the applicability of a labor/capital substitution curve to development. RoR seems also to understand this.

If you go to RoR site you will see only enthusiasm and love of technology, the site is totally free of "People That Talks In Big Letters Only". So different from the Java "computer scientist approach by well-meaning impractical theoreticians" style.

Rails could just as well be invented by Java people, (except it would be named JavaOnRails of course!) but for the "three abstraction layers and a domain model" attitude. And to think that it is still some that thinks that EJB 3.0 will change anything!

Regards
Rolf Tollerud

If you go to RoR site you will see only enthusiasm and love of technology, the site is totally free of "People That Talks In Big Letters Only". So different from the Java "computer scientist approach by well-meaning impractical theoreticians" style. Rails could just as well be invented by Java people, (except it would be named JavaOnRails of course!) but for the "three abstraction layers and a domain model" attitude. And to think that it is still some that thinks that EJB 3.0 will change anything!RegardsRolf Tollerud

Well, you are coherent with you usual opinions, as always. Now, for me I feel pretty productive with what I have now: why don't you try and develop a JOR port? ;)

https://trails.dev.java.net

You seem to be saying that not even EJB-3 can save us from the insult of having to write by hand more error-prone lines of code than a script kiddie with the same goal.

Well, actually I was only thinking and talking about java, since I don't see myself using ROR in the near future. I'm not sure that a language that is less verbose is surely to provide less errors: I think the power of the platform has a much greater role in this. Compare hand written jdbc (programmed with no libraries for pooling, templating, transaction management, etc.) with Spring code (which manages transactions, pooling, templating, ...): I think THIS is what makes the greater difference, in terms of error -proneness (please, excuse my english if the word does not make sense... ;) ).

So much for POJO automation and its supposed reduction of effort.This study shook me. Not because serious automation isn't possible in Java, but rather because the Java vanguard seem not to care about the primacy of less hand coding.

I do! That's one of the reasons I was extremely happy when I met the Spring way of doing things. The reason why I don't share the excitement about Ruby is not because I don't think Ruby is exciting, but because I have a pretty good development experience in java with what I'm using now (IDEA + Spring + Hibernate + lots of other java tools): really, I find it constantly amusing. And I know that metrics about lines of code don't reflect the amount of code that idea writes for me, nor do they reflect the easyness that a number of incredibly complex operations are possible with the development environment I'm using.

This is disappointing, and a study that shows Spring/Hibernate to be a pig has miraclulously twisted into another monotonous thread about how awesome Spring is.

Ask yourself why.

(a hint: because, simply, Spring/Hib is NOT a pig, as everyone who uses it for real work knows)

What I frankly can't believe is the idea that EJB3 will be substantially "lighter" than SprHib, with respect to this same "metric"...

You seem to be saying that not even EJB-3 can save us from the insult of having to write by hand more error-prone lines of code than a script kiddie with the same goal. So much for POJO automation and its supposed reduction of effort.This study shook me. Not because serious automation isn't possible in Java, but rather because the Java vanguard seem not to care about the primacy of less hand coding. This is disappointing, and a study that shows Spring/Hibernate to be a pig has miraclulously twisted into another monotonous thread about how awesome Spring is. At least in the MDA threads here, we acknowledge the lameness of hand code and the applicability of a labor/capital substitution curve to development. RoR seems also to understand this.

One thing is clear. While Ruby really isn't on the radar of most for the same reason that most scripting languages come and go, clearly the Spring/Hibernate combination has proven powerful.

When the less known, less used, less respected, less product wants to make a splash, who do they go after?

Notice you don't see X proven faster/better/lighter than Rails articles anywhere.

Hmmmm...one thing has occurred to me that may prove that Rails is faster and lighter. The Rails people seem to have all the free time to write these articles.

and that's the main reason why all of this is "lightweight".

So when does a framework stop being lightweight? 123k? 503k?

Lightweight has nothing to do with the size of the jars nor in how many ways you can slice and dice them.

Lightweight is about perception.

Yours is that Spring is lightweight but many people believe otherwise.

Respect people's perceptions and address them instead of doing Jedi handwaves at them.

--
Cedric
(besides, it only works on feeble minds anyway)

Come on Cedric, it seems to me Davide is just defending something he believes in. What is wrong with that? I didn't see any handwaving :-)

While I agree with you lightweight has nothing to do with .jar size, in my mind it's much more than just perception. That's the whole problem here I think, damn perception. People seem to think every Java app written needs at least three abstraction layers and a domain model. That misnomer has nothing to do with Spring. I'd still use Spring even if my app was a simple set of transaction scripts (though I wouldn't use Hibernate!), simply because it'll simplify my programming model, make it easy to configure stuff, give me proper exception handling, and eliminate any chance of resource leaks.

What can I do to change your perception? I sure did try hard to convince you on the benefits of IoC! :-)

What is wrong with that? I didn't see any handwaving :-)

... which proves it worked.

--
Cedric

What is wrong with that? I didn't see any handwaving :-)

... which proves it worked.-- Cedric

These aren't the frameworks you're looking for...

Rob

People seem to think every Java app written needs at least three abstraction layers and a domain model. That misnomer has nothing to do with Spring.

Actually the insecure urge to overengineer might be the bulk of Spring's audience. I fear this study has put Spring in a very bad light. My field observations also mesh with this study. Spring appears to be a front-loaded labor sink. Wouldn't a small application be better off without Spring's introduction cost.

I think the first architectural improvement to the study's Java implementation should be the introduction of XDoclet. That should reduce the handwritten Lines-Of-Code more than anything else.

In general, I have found that small applications are better off without over-engineering just to fit some pre-conceived idea of 'best practice'. Spring doesn't enforce any architectural model at all, other than you HAVE to use Java (for now).

You views on Spring are interesting, but I can't draw any parallels into my work. I'm not sure what kind of applications you are working on, but the clients I consult for are saving time and money with Spring. Added to this, some clients are moving into strange new territory with Spring by actually delivering working applications.

I can appreciate that RoR is a pretty cool framework, but I can't see how that casts Spring in a negative light. At the end of the day it boils down to what can you use to be successful and Spring has made a large number of very large companies successful at delivering applications.

Rob

Wouldn't a small application be better off without Spring's introduction cost.

I can't see what Spring "introduction cost" is: using for instance its db features instead of direct jdbc is a matter of using one higher level API instead of another. If you start from scratch and have a minimum spring experience (shall we say one day for reading tutorials?) it's sure to simplify your work, with respect to a normal java project. Can't tell about ruby magic, I'm only talking about java with and without spring.

People seem to think every Java app written needs at least three abstraction layers and a domain model. That misnomer has nothing to do with Spring.

Actually the insecure urge to overengineer might be the bulk of Spring's audience. I fear this study has put Spring in a very bad light. My field observations also mesh with this study. Spring appears to be a front-loaded labor sink. Wouldn't a small application be better off without Spring's introduction cost.I think the first architectural improvement to the study's Java implementation should be the introduction of XDoclet. That should reduce the handwritten Lines-Of-Code more than anything else.

Strong words. So basically, everyone who likes Spring, who wishes to use it to simply their work, who've had Spring demostrate that it is easier are in reality, incompetent developers who overengineer their solutions.

But Ruby developers, by inference, are supposed to represent the pinacle of modern development?

All this from a guy with no Spring experience and couldn't understand enough of it to provent it from being a "labor sink."?

This is why I don't feel compelled to respect the words of someone without direct experience. When I first used Spring, my intention was to simply use its factory as a way to "ease" into it. To replace my custom factories with Spring's.

However, Spring proved to be so easy to understand and setup, that we instead used its factories, Hibernate support, config files to setup certain java beans, replaced our custom config files with Springs.

In fact, it took me less than one day read, understand, and implement Springs AOP layer into our application.

But this direct experience flies in the face of a guy that thinks XDoclet is an architectural improvement.

...a guy that thinks XDoclet is an architectural improvement.

In a small project, the biggest landmark and the architect's seminal responsibility is the tooling pipeline and selection of commodity frameworks. XDoclet is a big boost here, so XDoclet is architecture for a small project. Other less-is-more springboards like XDoclet are Apache Beehive and WebLogic Workshop. Economics rules the software market, so "less-is-more" mostly means less wages paid during development, a technical metric of productivity.

Did you know that amanuensis means "a hand slave with secretarial duties". For me it means someone stuck writing or copying boilerplate.

Come on Cedric, it seems to me Davide is just defending something he believes in. What is wrong with that? I didn't see any handwaving :-)

Neither did I. ;)

I'd still use Spring even if my app was a simple set of transaction scripts (though I wouldn't use Hibernate!)

That's what I do for a number of data-transferring jobs that we had to develop in our system: spring core + db features. No web, no orm, nothing else: just IOC and templates over JDBC. Resulting code: much, much, much cleaner, shorter (and more powerful) than what would have resulted in not "carrying the burden" of the dreaded spring xml configuration. (Which, of course, is easy and enjoyable to use because it is consistent among layers ;) ).

simply because it'll simplify my programming model, make it easy to configure stuff, give me proper exception handling, and eliminate any chance of resource leaks.What can I do to change your perception? I sure did try hard to convince you on the benefits of IoC! :-)

Amen.

So when does a framework stop being lightweight? 123k? 503k?

By god Cedric you do have a fetish for 3 right there.

and that's the main reason why all of this is "lightweight".

So when does a framework stop being lightweight? 123k? 503k?Lightweight has nothing to do with the size of the jars nor in how many ways you can slice and dice them.Lightweight is about perception. Yours is that Spring is lightweight but many people believe otherwise.Respect people's perceptions and address them instead of doing Jedi handwaves at them.-- Cedric(besides, it only works on feeble minds anyway)

And many more people with DIRECT Spring experience think that it is lightweight.

I'm going with the people, like myself, who have USED the thing. I feel no need to respect perceptions when they are not based on experience.

And many more people with DIRECT Spring experience think that it is lightweight.I'm going with the people, like myself, who have USED the thing.

I would like to back up this opinion. From personal experience: the core of Spring is small(ish); for basic IoC the XML bean descriptions are concise and simple to set up; and it can be put to work with minimal code. There is another use of the term 'lightweight' I would include: I find Spring lightweight in terms of the effort required to learn how to use it. Very occasionally I come across a development tool that supplies all I need in a simple and easy-to-understand manner. Spring is such a tool. In my opinion.

From personal experience: the core of Spring is small(ish); for basic IoC the XML bean descriptions are concise and simple to set up...

Anything with deployment descriptors is automatically disqualified from being considered lightweight. It's why JSP is so popular. JSP is lightweight. Earlier here someone proposed an all JSTL implementation for the study. I suspect that it would be the solution with the fewest handwritten lines of text.

From personal experience: the core of Spring is small(ish); for basic IoC the XML bean descriptions are concise and simple to set up...

Anything with deployment descriptors is automatically disqualified from being considered lightweight.

I must disagree. I'm using Spring as a way of concisely describing configuration settings and wiring beans together. This is FAR more lightweight than having a series of (for example) properties files, and managing the loading, validation and conversion of those files, and setting up Service Locators etc. Spring has cut back considerably on the amount of engineering I have to do, and I would not expect it to add much cost to an application. In modern VMs, reflection and proxying should be very fast.

and that's the main reason why all of this is "lightweight".

So when does a framework stop being lightweight? 123k? 503k?Lightweight has nothing to do with the size of the jars nor in how many ways you can slice and dice them.Lightweight is about perception. Yours is that Spring is lightweight but many people believe otherwise.Respect people's perceptions and address them instead of doing Jedi handwaves at them.-- Cedric(besides, it only works on feeble minds anyway)

I don't agree. Perception has nothing to do with facts: I agree "perception" is something important when talking about developer tools (ease of development, pleasure of the development experience, and so on). When one talks about "lightness" of an architectural component is usually talking about other factors (resource consumption, grade of invasiveness, and so on). Am I wrong?

The Java implementation of the example app sucks. You do not use Spring and Hibernate to develop a small isolated app.

According to the TSS's recent article "Examining the Validity of IoC":

The benefits of IOC are that objects become highly focused in its functionality, highly reusable, and most of all highly unit testable.

None of these "benefits of IOC" apply to a "small isolated app". So it's easy to understand why Spring/Hibernate could impede the nimble creation of a small write-once project, the kind I'm so often paid to implement, and the kind that RoR just dominated.

The claim that Spring/Hibernate is lightweight seems dubious, else the combination would have shined in this study. Instead Spring/Hibernate posted a triple-sized source base. If big projects is your business, then you likely wouldn't even notice or care. But small projects is my business, and I'm alarmed by the results of this study.

None of these "benefits of IOC" apply to a "small isolated app". So it's easy to understand why Spring/Hibernate could impede the nimble creation of a small write-once project, the kind I'm so often paid to implement, and the kind that RoR just dominated.

Spring isn't just about IoC, it is also a very neat way to manage configuration. For a project to not need any sort of configuration, and to have virtually no possibilities of using dependency injection (which only takes a few lines of XML and a couple of lines of code in Spring) it would have to be very small indeed.

If big projects is your business, then you likely wouldn't even notice or care. But small projects is my business, and I'm alarmed by the results of this study.

I would have thought that the initial code size, even for very small projects, would not be that important as it would be easily to build up a repository of template projects and code samples. I mostly develop Spring/JDO/JSF projects and this code re-use approach works very well.

Spring isn't just about IoC, it is also a very neat way to manage configuration. For a project to not need any sort of configuration, and to have virtually no possibilities of using dependency injection (which only takes a few lines of XML and a couple of lines of code in Spring) it would have to be very small indeed.

J2EE mandates a few configuration files, but nothing I'd need Spring for. XDoclet almost eliminates my exposure to them. And a zero-administration client needs little or likely no configuration files. "Spring isn't just about IoC", and XDoclet conquered descriptors, so why do I need Spring impacting my sources?

I would have thought that the initial code size, even for very small projects, would not be that important as it would be easily to build up a repository of template projects and code samples.

Repository. You're kidding? This is a language/framework shootout, not a best team practice exercise. It's supposed to be about whipping small projects up out of nothing more than public material. Spring/Hibernate needed triple source code to do it, which struck me as embarassing. It certainly validates my interest in MDA taming J2EE.

I mostly develop Spring/JDO/JSF projects and this code re-use approach works very well.

I'm skeptical of reuse of narrowly circulated libraries. I doubt that homegrown libraries are worth the effort in most cases. I prefer to stitch widely used libraries together with a minimum of custom logic.

Less handcode is what the study's metrics are about. Worrying about reusability distracts from writing lean code. A small project can't amortize the cost of cutting code across a long schedule. A tight schedule demands less hand coding. Forecasted reuse is not a billable priority, and XP forbids implementing future requirements.

And Spring/Hibernate needed a triple-sized source base for a stupid throw-away project, huh?! I wish the word "lightweight" weren't so widely misunderstood by the J2EE community. The Spring market-speak recited in this forum might discourage innovation. But the study's metrics suggest innovation is happening.

J2EE mandates a few configuration files, but nothing I'd need Spring for. XDoclet almost eliminates my exposure to them. And a zero-administration client needs little or likely no configuration files. "Spring isn't just about IoC", and XDoclet conquered descriptors, so why do I need Spring impacting my sources?

Spring does not impact your sources, if you use XML config.

XDoclet always does.

People does not use XDoclet in order to create Spring XML config files because in general it is meaningless: would you hardcode bean dependencies in xdoclet tags? This would completely kill the usefulness of IOC. Do yourself a favour: try Spring for a couple of days, and you will understand what I mean.

worth the effort in most cases. I prefer to stitch widely used libraries together with a minimum of custom logic.

Spring absolutely shines at this. Do yourself a favor...

The Spring market-speak recited in this forum

There is something you don't understand: take me, for example. I'm not a consultant, I'm not a Spring developer, I've got no Spring books to sell. I've got two pretty complex system running on Spring + Hibernate, and I find them great: my management is absolutely happy with the rate of evolution we can put into the system, and we are progressively increasing the scope of the Spring + Hib use into the rest of our architecture. There is no market-speak: I'm not gaining money when I'm writing you this: I'm gaining money when I stop and go back using Spring.

J2EE mandates a few configuration files, but nothing I'd need Spring for. XDoclet almost eliminates my exposure to them. And a zero-administration client needs little or likely no configuration files. "Spring isn't just about IoC", and XDoclet conquered descriptors, so why do I need Spring impacting my sources?

I just don't understand this 'Spring impacts my sources' argument at all. If you are saying this, then XDoclet impacts your sources! You are putting this information somewhere. With XDoclet you are adding LoC via a few attributes. With Spring it is via a few lines of XML. Where is the impact?

I would have thought that the initial code size, even for very small projects, would not be that important as it would be easily to build up a repository of template projects and code samples.

Repository. You're kidding? This is a language/framework shootout, not a best team practice exercise. It's supposed to be about whipping small projects up out of nothing more than public material.

And when is that ever the case? How many developers truly sit down in front of a workstation with absolutely no existing code in no existing projects?

My point is that such a shoot-out is plain silly, as it does not represent a real situation.

I mostly develop Spring/JDO/JSF projects and this code re-use approach works very well.

I'm skeptical of reuse of narrowly circulated libraries. I doubt that homegrown libraries are worth the effort in most cases. I prefer to stitch widely used libraries together with a minimum of custom logic.

I was not talking about libraries. I was talking about templates - projects with most of the 'boilerplate' code already written.

Less handcode is what the study's metrics are about.

Using existing projects and files as templates helps this. (There are tools in good IDEs to help with this - such as Studio Creators code fragment libraries).

Worrying about reusability distracts from writing lean code.

I disagree. Re-usability can arise from code which is written based on principles of good software engineering - separation of concerns, encapsulation etc.

A small project can't amortize the cost of cutting code across a long schedule. A tight schedule demands less hand coding. Forecasted reuse is not a billable priority,

If this is really the situation, you should not be using RoR at all! Use something where there can be virtually no hand coding at all, like Studio Creator. You can drag and drop data-bound controls and create forms in just a few minutes. You also have a project that can easily adapt to new database schemas. By comparison, RoR development looks slow and tedious, and rigid. I can see arguments for RoR based on the use of open source etc, but it certainly does not win the LoC or speed of development argument if you use the right tools.
 

and XP forbids implementing future requirements.

One of the siller aspects of XP, I have always thought.

But the study's metrics suggest innovation is happening.

In many ways, RoR is a huge step backwards - code embedded in web pages, and development being driven by database schemas rather than object models, so that the ability to support future design changes and portability is limited.

Steve,
"In many ways, RoR is a huge step backwards - code embedded in web pages"

Let us put the “code embedded in HTML is evil” nonsense to rest.

Please tell me which one that is evil:

WebWork2:
<%@ taglib uri="webwork" prefix="ww" %>
...
<ww:iterator value="collection" id="item">

<ww:property value="#item.some.nested.property" />

</ww:iterator>

Rails:
<% for item in @collection do %>

<%= item.some.nested.property %>

<% end %>

http://defrang.com/index.php?story=837

There are no framework that can come anywhere near Rails in pure MVC separation.

On the other hand to put up Spring against Rails is the real nonsense:

All heavy-load mission critical Java sites in the world runs without EJB.
So why not ditch the Big Elephant Servers altogether , let Spring (in Java or C# version) take care of it all and let frameworks like Rails do the rest?

Some time filks have to come to their senses.

Regards
Rolf Tollerud
("What I want is something that's harmonious" Yukihiro Matsumoto)

Steve,"In many ways, RoR is a huge step backwards - code embedded in web pages"
Let us put the 'code embedded in HTML is evil' nonsense to rest. Please tell me which one that is evil:

WebWork2:<%@ taglib uri="webwork" prefix="ww" %>...<ww:iterator value="collection" id="item">

<ww:property value="#item.some.nested.property" />

</ww:iterator>Rails:<% for item in @collection do %>

<%= item.some.nested.property %>

<% end %>

Easy. The Rails one. There is procedural code embedded. See 'for' loop? It is not 'evil', but bad practise.

There are no framework that can come anywhere near Rails in pure MVC separation.

Nonsense. Having logic such as 'for' loops in the presentation layer is NOT pure MVC separation. Some may think it is a reasonable compromise, but it is certainly not 'pure separation'.

All heavy-load mission critical Java sites in the world runs without EJB.

Tsk. Shame on you. You promised never to say this again, after you agreed that EBay runs with EJB:

Ebay is constructed very different from ordinary J2EE/EJB projects

So I am assuming that your above statement about 'All heavy-load mission critical sites' must be some kind of typing error. I would not like to suggest the alternative: that you are deliberately posting misleading information.

Big Elephant Servers altogether , let Spring (in Java or C# version) take care of it all and let frameworks like Rails do the rest?

(1) Because the Big Elephant Servers have facilities that Spring alone doesn't, such as clustering. You do realise that much of Spring is designed to with WITH EJBs? Spring makes J2EE development far easier. It does not remove the need for EJB use in high-end clustered systems.

(2) Because Rails is a step backwards. It has some code embedded in web pages, it has no separation of what type of presentation you are using from the logic (as with JSF and others), and it is schema-driven, not object-domain driven, so it does not easily support modifications to schemas and is not easy to port between databases.

Some time filks have to come to their senses.RegardsRolf Tollerud("What I want is something that's harmonious" Yukihiro Matsumoto)

Its about time some people stopped saying one thing on one thread and something else on another.

Tsk. Shame on you. You promised never to say this again, after you agreed that EBay runs with EJB:

Ebay is constructed very different from ordinary J2EE/EJB projects

Rolf is a drone who was preprogrammed by some impractical scientist. The problem is that the batteries run out every now and then, and the memory gets erased. When the Rolf-drone is started again it has no recollection of his promises or what he said before, so he is repeating himself all over again according to his programming. The drone also has a library of random quotes that it reiterates every time the logic is too hard-pressed to come up with a viable solution, to confuse an average reader.

Tero,

"When the Rolf-drone is started again it has no recollection of his promises or what he said before

Rolf,

"All I want is i single example on a modest 6000-8000 tps project done for ca 5-6 mill dollar, a run-of-the-mill project according to the J2EE crowd, such as Peter Lin compare to a tree in Amazon: "if a tree falls in the Amazon, but no one hears it".
If you can show me only 1 (one) such case, thoroughly documented with emphasis on EJB use, I promise I never mention this again."

Steve mentioned EBay.

Nuggets of Wisdom from eBay's Architecture.
A couple of things are quite striking. The first is its complete lack of usage of Entity Beans. http://www.manageability.org/blog/stuff/about-ebays-architecture/view

Then Steve upholds that EBay has EJB because "they have rewritten everything" (but no proof or evidence). All he has is a interview with Sun Chief Java architect John Crupi where John says, I quote "So, two or three of the use cases I believe were implemented in J2EE".

"I believe" ;) He is not even certain - not a word of EJB.

All this has Steve taken as an excuse to silence me. Madre mia. "Thoroughly documented with emphasis on EJB use".

This discussion has been gone on over and over since "TheServerSide Calls for Real World J2EE Project Stories" back in January 10, 2003. There was not a single case proven then and not ever since either. The Java camp has not been able in 2 years to prove that there is even 1 (one) heavy load site with EJB.

(That does not mean that there is not a lot of big sites that run with Java -
Just ask Vic..)

Therefore IMO, the "State Of the Art" today for heavy lifting is Spring, that can do everything the Big Elephant Servers can do, just much better.

And regarding smaller sites, the Ruby Language/Rails framework are so much more advanced than anything in than Java world that it is a joke to compare.

Regards
Rolf Tollerud

And regarding smaller sites, the Ruby Language/Rails framework are so much more advanced than anything in than Java world that it is a joke to compare.RegardsRolf Tollerud

... be constructive then and say where and how it is so much more advanced with clear examples and code snippets. Other people can then actually compare and maybe fill in some blanks.

Rolf, "All I want is i single example on a modest 6000-8000 tps project done for ca 5-6 mill dollar, a run-of-the-mill project according to the J2EE crowd, such as Peter Lin compare to a tree in Amazon: "if a tree falls in the Amazon, but no one hears it". If you can show me only 1 (one) such case, thoroughly documented with emphasis on EJB use, I promise I never mention this again."

I don't think I stated any number in my silly "if a tree falls" joke. by the way, it doesn't matter what platform you use, 6-8K atomic transactions per second costs more than 5-6million dollars. The hardware alone will cost you 5 million, so that only leaves 1 million to build the actual application, test it, host it and run it.

Although I think it is possible to build a system capable of that kind of TPC-C throughput "cheaper than 5-6million", very few businesses have the savy and human resources to achieve it. The practical reality is, when you're building these kinds of systems, reliability and fault tolernace is more important than saving a couple thousand bucks. Saving 100K doesn't mean much if the system goes live and promptly crashes for a day. When that happens any savings is lost in the first minute.

peter

Saving 100K doesn't mean much if the system goes live and promptly crashes for a day.

If a year's salary "doesn't mean much", then no wonder you don't mind Spring/Hibernate losing a whip-it-up shootout. I guess for you, success is getting to work on a project so big that individual worth becomes relatively infinitessimal. Truly I don't want to know what frameworks work best on the mega-projects.

So how's Spring/Hibernate's standing on the TPC-C scorecard? Is Spring/Hibernate a no show, incapable of scaling up? I mean, we just saw in this study how poorly it scales down. Where exactly is Spring/Hibernate's sweet spot?

I mean, we just saw in this study how poorly it scales down

Let's get serious - one report in one blog is NOT a 'study'!

Nuggets of Wisdom from eBay's Architecture. A couple of things are quite striking. The first is its complete lack of usage of Entity Beans.

You change your argument yet again. First it was no Java, then no J2EE, then no EJB, now no Entity Beans. The quote you provided about 'complete lack of usage' was (as I have already *sigh* pointed out) from the situation as it was at EBay many years ago, not the current one.

Steve upholds that EBay has EJB because "they have rewritten everything" (but no proof or evidence). All he has is a interview with Sun Chief Java architect John Crupi where John says, I quote "So, two or three of the use cases I believe were implemented in J2EE"."I believe" ;) He is not even certain - not a word of EJB.

There was word of EJB. I have already shown it to you, but for completeness, here it is again:

Q. For those J2EE use cases how did they distribute the topology of their application?

A. So, part of the mandate of EJB is to be stateless. So basically, they're using stateless session beans,

There is also the JavaOne presentation which included descriptions from people who work at EBay of their J2EE/EJB use.

As for use cases, they started with two or three use cases at first. It was not an all-or-nothing migration.

Further down the interview:

And actually those use cases are working perfectly and now they're looking at implementing more use cases in J2EE.

All this has Steve taken as an excuse to silence me. Madre mia. "Thoroughly documented with emphasis on EJB use".

No. YOU promised you would be silent! You wanted evidence for J2EE/EJB use in a high-performance high-load site. You promised you would shut up if you got the evidence.

The evidence is presented here for everyone to see. As I said, you can either claim that TSS is publishing incorrect information, and that EBay is mistaken about their own systems, or you can keep your promise and stop spreading falsehoods about J2EE/EJB use. Carrying on like this, and disregarding facts, is perhaps not helping your reputation as a well-known IT expert....

This Therefore IMO, the "State Of the Art" today for heavy lifting is Spring, that can do everything the Big Elephant Servers can do, just much better.

No, Spring is not designed to cope with all situations. Spring can replace much EJB use, but still needs 'Elephant Servers' to host applications that use it if you need to use capabilities like, for example, distributed or remote transactions or security to be robustly and reliably implemented.

Rolf,

Show me an extensive application written in C#, created by Microsoft that they are now selling. I would be happy to know what it is so I can check it out. If not, is there an utility, gadget or something that Microsoft is selling, created with C#? Last time I asked, you stayed silent, but were happy to comment on anything else I might have had in my note.

EJB seems to be your only thread of hope in this world. Java is not EJB, J2EE is not EJB. There are valuable parts in EJB as well, so maybe you are trying to make a big leap from entity beans to the whole viability of the Java platform?

I also find it odd that you manage to find somekind of contact point between RoR and EJB. But of course it suits your puroses so you do it anyway.

If you can't find anything in the .NET camp to attack against Java, you are happy to apply the same mantra to any other language, project, platform, that is trying to chip some fame off Java. I presume, you are trolling on the .NET forums about the crappiness of .NET vs. RoR, no?

This leads me to conclude that you are really not a technology advocate at all, but you find somekind of weird satisfaction in the illusion of being right every time. The content of your postings really has no meaning to you, what is relevant though, is the reaction you get.

Tero,

I just do not like the over-architecture and the attitude in the Big J2EE world in general. From early age I have learnt that people that speak like this are fakes. And how any consultant can be willing to put 2 million lines of (potentially buggy) code between himself and the customer is more than I can understand.

Anywhere in life when you adopt such a pompous and arrogant stance you must be prepared to be attacked. EJB and the Big Elephant Servers seem to constitute the basis of the J2EE camp self-confidence. I say it is a piece of shit and I am not alone. Hundreds of other have done the same here in TSS, my favorite being a tie between Alexander Jerusalem's "Now we have server side applications that behave like 1992 desktop applications" or Vic Cekvenich's "That whole group (EJB JCP) had put quite hurting on my work for many years, helping them would be like 'Stockholm syndrome'".

If you want the links to any of the two above quotations just notify me.

Regards
Rolf Tollerud

Ohhh no looks like Rolf is in full rant mode. How many times do people have to tell you java != ejb and j2ee != ejb. You are right on one thing why over-engineer an application when it does not need to be. For the majority of projects EJB is not needed, I think this was established awhile back.

For some reason everytime you post I see more and more the same crap coming out of your mouth. EJB sucks, blah blah blah Java sucks blah blah blah J2EE sucks blah blah blah... Do you ever get tired or crap, honestly if it sucks so bad why do so many people make it work?

Could it be possible you suck, and just don't understand what choices to make with technology. This would explain why you gobble the choices MS forces on you in the .NET world. Or wait there is no msROR.... i guess .NET sucks too?@$

I honestly believe Rolf is stuck in some kinda sick while loop. Honestly we have all heard you 43152521 times. If you ever had a point trolling i'm sure we got it by now.

Darryl,
"For the majority of projects EJB is not needed, I think this was established awhile back"

Ok, then. Then you only have to put away your attitude too, and stop bashing all new young and beautiful technology - and everything will be fine.

After all, all this EJB overuse was a pretty stupid mistake wasn't it? So no longer any reason to think that you are better than the rest of the IT-humanity! ;)

Regards
Rolf Tollerud

Ok, then. Then you only have to put away your attitude too, and stop bashing all new young and beautiful technology - and everything will be fine.

Umm, i'm not bashing .NET i'm bashing Rolf logic. But I do find it funny YOU would say not bash something

I have to admit that even the attitude has grown much better. Well then I promise never to bash EJB anymore. But I must have done something right for I was very seldom marked as noisy..

The EJB craze certainly was one of the worst cases of hubris I ever saw! :)

Webster: Hubris
Etymology: Greek hybris
: exaggerated pride or self-confidence

Regards
Rolf Tollerud

Then you only have to put away your attitude too, and stop bashing all new young and beautiful technology - and everything will be fine.

Rolf, I don't see people bashing Rails, very little actually. Most people are just sceptical, and with much cause. The toy-app hype and out-of-context comparisons with Java as a constant target doesn't really make everyone jump up on and embrace it. Out of personal experience I said *nothing* against Rails at all and was almost *attacked* on my blog. To me it looks like there's a lot of gratuitous bashing going on the other way 'round.

It would be presumptuous of me to pretend that I know anything about Ruby or Rails after worked with it for a couple of days. There may be things (caveats) that will pop up later. But even if that happens, the nice things would then have to be lifted out and salvaged somehow, to be used elsewhere. Nobody can take away from the RoR guys that they have come up with something new and useful.

Regards
Rolf Tollerud

It would be presumptuous of me to pretend that I know anything about Ruby or Rails after worked with it for a couple of days. There may be things (caveats) that will pop up later. But even if that happens, the nice things would then have to be lifted out and salvaged somehow, to be used elsewhere. Nobody can take away from the RoR guys that they have come up with something new and useful.

Just as many other projects, there's always cherry picking and cross talking. I haven't seen anything revolutionary yet, besides the fact that the Ruby language now has a decent web framework.

Nobody can take away from the RoR guys that they have come up with something new and useful.RegardsRolf Tollerud

What is new?

Ruby? No.
The use of code in web pages? No.
The Object/Table mapping? No.
The use of a dynamic language to do this? No.

How useful is it? Perhaps for scripting small sites which use reasonably stable database schemas. However, there are other ways to do this (such as with visual tools) which make development far faster.

Is it ready for real production use? Well, major parts of the RoR system have version numbers well below 1.0, so are, I assume, beta versions. When I go to the RoR website and, following the instructions exactly, I attempt an install using the 'gem' command I end up with Ruby errors. I am sure I these are probably trivial, and I could work around this, but it does not inspire confidence.

Steve,

"What is new?"

Hmm. When I started in computing it was in a company that was selling Macintosh. Our salespersons often tried to sell with mactalk like "it is easy to use", "user-friendly", and the like. But people that had not seen and tried the Mac were unimpressed, "That is what everyone says". But when they tried the computer their jaws were certainly falling down...

This was the intention of the Ruby author:

"What I want is something that's harmonious"
"For me the purpose of life is partly to have joy.
So Ruby is designed to make programmers happy."

In my opinion he has succeeded to 100%, the difference between Java/C# and Ruby is as the difference between DOS and Macintosh in the early nineties. But similar to them it must be tried hands on.

"The use of code in web pages? No."

Ruby use a template system like Velocity and others, and similar to Velocity there are tags in the template. Ruby being so much more powerful makes those tags smaller and more inconspicuous than in others systems. As demonstrated before.

"Ruby? No."

When was the last time you were taking a look? Ruby is in such a ferocious development that it makes Java look like a aunt taking a pleasant and agreeable walk in the park. Also Ruby is not led by a committee but by a benevolent dictator that is leading an army of developers - Yukihiro Matsumoto, the original author - a true genius.

"The Object/Table mapping? No."
That is not a major point, but it is nice to have the whole database generated automatically. And hidden away, you will not see any CRUD code! (like JDO)

"The use of a dynamic language to do this?"No
There have been a dynamic language "craze" for a while, which Ruby is clearly winning.

But you do not mention the main thing with RoR

The whole application is generated automatically by the system. That is not new. But the real ingenuity comes when you start to build and shall force this readymade "scaffold" framework to change after your intentions. In Rails, everything is done by refactoring you could say, the entire system is planned for it. Templates and forms can be applied afterwards, everything can be applied afterwards! That you so easy can do almost anything as an afterthought is the main strength of the system.

"Is it ready for real production use?"
Why don't you take a look at the Bascamp project management?
http://www.basecamphq.com/

Regards
Rolf Tollerud

So Ruby is designed to make programmers happy."In my opinion he has succeeded to 100%,

Some of ruby is a mess. Here is a particularly bad example: the use of @ to indicate instance variables. This means that code can't be transparently re-used in different contexts. There are other ugly aspects.

The use of code in web pages? No."

Ruby use a template system like Velocity and others, and similar to Velocity there are tags in the template. Ruby being so much more powerful makes those tags smaller and more inconspicuous than in others systems. As demonstrated before.

Nonsense. Ruby requires more in the web page (such as explicit 'for' loops). How can requiring more code in the web page make tags smaller?

When was the last time you were taking a look? Ruby is in such a ferocious development that it makes Java look like a aunt taking a pleasant and agreeable walk in the park.

Nonsense. Ruby has hardly changed in years.

Also Ruby is not led by a committee but by a benevolent dictator that is leading an army of developers - Yukihiro Matsumoto, the original author - a true genius.

What? For inventing Yet Another Scripting Language?

That is not a major point, but it is nice to have the whole database generated automatically. And hidden away, you will not see any CRUD code! (like JDO)

Nonsense. The database is not generated automatically, or hidden. There is no more or less code than with JDO, as you do exactly the same things: run queries, start and end transactions, and fetch object instances.

"The use of a dynamic language to do this?"NoThere have been a dynamic language "craze" for a while, which Ruby is clearly winning.But you do not mention the main thing with RoRThe whole application is generated automatically by the system. That is not new. But the real ingenuity comes when you start to build and shall force this readymade "scaffold" framework to change after your intentions.

Nonsense. Other dynamic languages are far more successful and widely used, such as Python. Ruby programming is a minority activity, and the fact that it has finally been fitted with a web framework, and not even a particularly well-designed or modern one, has been hyped to astronomical levels. As for generating code automatically based on a database structure, I can do that with my JDO IDE and my project templates in NetBeans. No big deal.

In Rails, everything is done by refactoring you could say, the entire system is planned for it. Templates and forms can be applied afterwards, everything can be applied afterwards! That you so easy can do almost anything as an afterthought is the main strength of the system.

RoR is certainly not done by refactoring. It is done by code generation.

"Is it ready for real production use?"Why don't you take a look at the Bascamp project management?http://www.basecamphq.com/RegardsRolf Tollerud

So how does that relate to the beta status of parts of Ruby on Rails, and the installation bugs?

Oh, and by the way, regarding the title - you NEVER start with a 'finished' system. Systems always change during development. This is one of the flaws of RoR.

In Rails, everything is done by refactoring you could say, the entire system is planned for it. Templates and forms can be applied afterwards, everything can be applied afterwards!

As a Rapid Application Developer and eXtreme Programmer, I dig being able to defer effort. And I've noticed that refactoring is naturally the central praxis for evolving an application.

In Rails, everything is done by refactoring you could say, the entire system is planned for it. Templates and forms can be applied afterwards, everything can be applied afterwards!

As a Rapid Application Developer and eXtreme Programmer, I dig being able to defer effort. And I've noticed that refactoring is naturally the central praxis for evolving an application.

Well, you are going to have a lot of problems with Rails then, as, contrary to Rolf's statement, things aren't done by refactoring, they are done by one-off one-way code generations. Refacting in Rails is going to be very difficult, as the object fields in the classes representing the data are only present at run-time, and aren't accessible to refactoring tools. Also, Rails is designed around NOT deferring effort. The idea is that you generate your fixed schema at the start and then use those field names, hoping all the time that you won't have to change your schema.

The idea is that you generate your fixed schema at the start and then use those field names, hoping all the time that you won't have to change your schema.

that is the same impression I got from the docs on RoR. To be some what balanced, that often is how many people develop web applications. I see no real difference between what RoR provides and how many people use VS.NET. It is common for a .NET developer to connect to SqlServer, generate a XMLSchema from the tables, use XSD to generate code which uses only properties, autogenerate a page in VS.NET and use the properties directly to display.

The main downside of this approach is brittle-ness. Once you need to support more than 1 database model or multiple domain models, it breaks hard. In many cases, you have to throw it away completely and rewrite it from scratch. RoR may be fine for some applications, but I think they have a lot farther to go. I could be totally wrong here, since I'm going by the docs and haven't actually built an app with Ror.

peter

The main downside of this approach is brittle-ness. Once you need to support more than 1 database model or multiple domain models, it breaks hard. In many cases, you have to throw it away completely and rewrite it from scratch. RoR may be fine for some applications, but I think they have a lot farther to go. I could be totally wrong here, since I'm going by the docs and haven't actually built an app with Ror.peter

Exactly! The RoR ActiveRecord approach could hardly have been more brittle if had been deliberately designed that way! I have tried building a small app, and this is the case.

What is new? Ruby? No. The use of code in web pages? No. The Object/Table mapping? No. The use of a dynamic language to do this? No.

What's new is less hand coding. How could you read this lengthy thread and still miss that? In the spirit of Sun's Ace and Rave, and in the interest of productivity, automation is the focus. Automation is so exciting that this thread is the most popular one on TSS this week.

What is new? Ruby? No. The use of code in web pages? No. The Object/Table mapping? No. The use of a dynamic language to do this? No.

What's new is less hand coding. How could you read this lengthy thread and still miss that?

Who said I missed it? Compared other methods of creating web forms and pages, RoR is verbose.

I keep mentioning Studio Creator: Guess how many lines of code it takes for me to set up an application with a web page that shows an editable table on a database? None at all! All done in less than one minute. Add the data source, drag and drop a table control.

In the spirit of Sun's Ace and Rave, and in the interest of productivity, automation is the focus. Automation is so exciting that this thread is the most popular one on TSS this week.

Good automation should not be a once-only step; it should track changes. RoR does not cope with this. Let me quote from OnLamp.com (http://www.onlamp.com/pub/a/onlamp/2005/03/03/rails.html)
about the scaffolding in RoR:
"Be careful using this if you've already created models, controllers, or view templates, as it will overwrite any existing files as it creates the scaffold code." (My use of bold).

That is very poor automation. There is no code migration as things change - it simply overwrites files!

Guess what happens in Studio Creator when I change the database structure? A couple of mouse clicks and the appropriate part of the web page changes to reflect the structure, without destroying the rest.

Or, if I use my JDO IDE, I can migrate my schema or object model, and deal with changes very easily using refactoring tools.

I don't believe that the RoR hype is really about lines of code or speed of development, as there are obviously faster ways to produce data-bound web pages and ways that produce more adaptable and maintainable code. I think its simply some people getting excited about the latest fashion.

You have missed the point Steve. Rails does not autogenerate a lot of files like Studio Creator. It sets up a environment similar to the Java Framework Naked Objects. In fact it goes one step further since it also autogenerate the objects "that would have been the underlining objects" for Naked Objects! All in memory! Do you follow me? ;)

The command "generate scaffold Recipe" as you refer to more traditionally generates real files, it is a recent supplement, added more for completeness and not much used.

Regards
Rolf Tollerud

You have missed the point Steve. Rails does not autogenerate a lot of files like Studio Creator. It sets up a environment similar to the Java Framework Naked Objects. In fact it goes one step further since it also autogenerate the objects "that would have been the underlining objects" for Naked Objects! All in memory! Do you follow me? ;)

Yes, I understand this. This is the problem. Because it autogenerates the objects, you end up with changes that you then have to manually update in the rest of the code. The mapping configuration files in more conventional ORM systems are there for a good reason - they allow your code to be isolated from changes in the database schema. I believe the designers of the RoR ActiveRecord system have fundamentally misunderstood the ORM pattern. ORM, as they say, is supposed to "wrap and encapsulate" the database access. They aren't encapsulating anything - your code is vunerable, and can be easily broken by changes in the database. This is a major problem if the RoR developer is not the person in charge of the schema, or if the RoR application is not the only application that uses the database.

<blockThe command "generate scaffold Recipe" as you refer to more traditionally generates real files, it is a recent supplement, added more for completeness and not much used.RegardsRolf Tollerud
Well, it is mentioned in all recent RoR tutorials, and described as significant tool.

Steve,
"Well, it is mentioned in all recent RoR tutorials, and described as significant tool" (about the generate scaffold command)

Lets no haggle over how much it is used, the functionality is still fundamentally different from traditional code generators as you can delete any or all of the generated files and the application still works.. :)

And to the ORM mapping I am new to both Ruby and Rails but I am willing to get out on a limb and say that I expect the framework to let me do any mapping I want in the future. According to "the principle of least surprise". We will see.

Read Bruce Tate's "The Toy?"
http://weblogs.java.net/blog/batate/archive/2005/02/

Regards
Rolf Tollerud

Steve,"Well, it is mentioned in all recent RoR tutorials, and described as significant tool" (about the generate scaffold command)Lets no haggle over how much it is used, the functionality is still fundamentally different from traditional code generators as you can delete any or all of the generated files and the application still works.. :)

Not if you have written your own code, it doesn't - it overwrites the files!

And to the ORM mapping I am new to both Ruby and Rails but I am willing to get out on a limb and say that I expect the framework to let me do any mapping I want in the future. According to "the principle of least surprise". We will see.

Exactly! It's yet more promises of future functionality. Developers should not have to 'go out on a limb'. We need real reliable, stable product, not promises. The 'optimised byte code compiler' is a good idea, but check the version number: 0.2.0! Many serious developers won't even touch products only at version 1.0. This stuff could be years away, assuming it ever gets finished. (Of course there already is a high-performance VM that runs Ruby: the JVM).

Ruby on Rails is directly contrary to "the principle of least surprise": Even a small change in your database schema could lead to very big surprises when you try and run your application! It has all the database and schema dependence of, say, PL/SQL with none of the advantages.

Read Bruce Tate's "The Toy?"http://weblogs.java.net/blog/batate/archive/2005/02/RegardsRolf Tollerud

There is a lot to criticise in that blog entry. For example, if he has to type the name of a Java bean property five times when mapping a class to a schema, I would suggest he is using very poor development tools! I do it just once: I enter (or change) the name once in my IDE and all the rest - accessors, mapping, and field name - are auto-generated.

I believe that the sort 'magic' he says that Ruby has is already present in Java if you use the right development tools: class browsers, fast refactoring tools, visual schema designers in a JDO IDE; these are things that make my development easy and fast.

Ha ha, advantages of PL/SQL! You are speaking to man that had to waste a whole weekend last month to make a photo-collection program for a friend in Oracle/PL/SQL.

In waiting for real mapping capabilities for Rails we have to limit ourself to the cases where we control the database. Peter Lin will laugh!

But what you forgets is that the small/middleware market is much larger than the "enterprise" market.

Mike Foody:

People should remember the Fortune 5000 is composed of just about 5000 businesses. In the United States alone There are over 5.5 million small businesses with employees. There's a huge commercial middle ground and it's several orders of magnitude larger than the "enterprise" market.

Can not understand why anyone would limit oneself to only big "enterprise" kind of solutions, how boring!

BTW, Ruby On Rails is quite stable, Basecamp is a commercial site that is ISPing a RoR application.

"I believe that the sort 'magic' he says that Ruby has is already present in Java if you use the right development tools: class browsers, fast refactoring tools, visual schema designers in a JDO IDE; these are things that make my development easy and fast"

The best thing with RoR is that you don't have to use an IDE or any tools at all. And no XML descriptors!

Regards
Rolf Tollerud

In waiting for real mapping capabilities for Rails we have to limit ourself to the cases where we control the database.

This is a serious restriction, limiting use to the smallest of projects. As I have clearly indicated, it is not even that effective even if you control the database - it does not enable easy change of the database. The way RoR uses its so-called ORM is so bad it should be offically labelled an anti-pattern.

But what you forgets is that the small/middleware market is much larger than the "enterprise" market.

RoR is not suitable for the middleware market. It is not even up to much of the small market. It is suitable for quick applications where the database is effectively an embedded part of the program - a very limited set of applications indeed.

Can not understand why anyone would limit oneself to only big "enterprise" kind of solutions, how boring!

I can't understand why anyone would limit oneself to only "very small" kind of solutions - that really IS boring!

Ruby On Rails is quite stable

It certainly is not! Look at the version numbers of parts of the system: Rails: 0.11.1, AWeb service 0.6.2. Maybe I am just old fashioned, but my understanding is that anything below 1.0.0 is a beta version, and not stable.

Any developer who uses a component with a version number less than 1.0 for a major project is asking for trouble.

Basecamp is a commercial site that is ISPing a RoR application.

Yes, but this is not a good demonstration of RoR use, as Basecamp was not developed using current versions of RoR: RoR is Basecamp's infrastructure re-packaged.

"I believe that the sort 'magic' he says that Ruby has is already present in Java if you use the right development tools: class browsers, fast refactoring tools, visual schema designers in a JDO IDE; these are things that make my development easy and fast"The best thing with RoR is that you don't have to use an IDE or any tools at all. And no XML descriptors! RegardsRolf Tollerud

Obviously, you don't have to use an IDE or any tools at all with Java. The great thing is that you CAN! IDEs are wonderful even with dynamic languages, as any Smalltalk developer will tell you.

As I have clearly described, XML descriptors are a good thing, as they allow isolation of code from changes to the database. Why all this silly fuss over a few lines of XML?
Open Source hackers seem to have a strange allergy to XML, something I have never been able to understand.

I never experienced such resistance to all things new! Do you use sunglasses from last year too?

Madre Mia
Rolf Tollerud

I never experienced such resistance to all things new! Do you use sunglasses from last year too?Madre MiaRolf Tollerud

I usually walk past the salesman that tries to push his new kind of super sunglasses into my hands, you know, the kind that does everything better than the rest and that costs nothing.

I never experienced such resistance to all things new! Do you use sunglasses from last year too?Madre MiaRolf Tollerud

Ruby on Rails is NOT new. I have seen all this before. For example, Smalltalk was doing this years ago, yet the Ruby people think they are being so original! At least with the Smalltalk version you could easily debug and refactor the code.

Seeing such enthusiasm for something so primitive as RoR makes me feel very disheartened about the state of IT. RoR has a few classes that auto-generate web pages from database tables and a relatively simple ORM. Big Deal! I am looking in detail at RoR, because of all the fuss, and the more I look at it, the more I dislike it. I don't dislike it because it is new, I dislike it because it has so many design flaws.

(1) It takes database-dependence to new levels (your code is not only dependent on a particular type of database (because we are, sadly, back to vendor-specific raw SQL for most queries), it is highly dependent on specific table structures, and could collapse in unpredictable ways if this is changed). Because the schema to object mapping is done on the fly at run time, this means you can't even be sure what your object model is until you run it! All it takes is for someone who is using your code to make a change to the database structure, and *bang* - your program crashes in exciting and unpredictable ways. This, at a time when database portability is becoming popular.

(2) It uses Ruby code embedded in web pages. This at a time when such embedded code is increasingly considered bad practice, leading to unmaintainable code.

(3) You can't even use Ruby-based refactoring tools on it, as the fields in the ActiveRecord classes are only present at run time! This at a time when refactoring is considered an important technique in development.

(4) How are you supposed to debug the thing? Are we back to print statements? This at a time when serious developers expect to be able to step through their web applications with quality debuggers.

(5) You can't even use an automated text search to locate problems with field name use, as Rails allows many different names to map to the same table (e.g. table 'people' can be mapped by the class 'Person', or the class 'People'!).

(6) Development is by text editing of scripts, and command-line tools. This at a time when tool like Eclipse, NetBeans and Studio Creator are full of visual tools for the construction, modification and debugging of web applications.

(7) All the so-called 'magic' of RoR is in its automated web page and code skeleton generation. But that is all one-way. This at a time when the IT industry is packed full of tools that allow data design to be done visually, and changes to be applied in both directions: Object model to schema, and schema to object model.

Ruby on Rails is a new gloss on a very old-fashioned way of developing web pages: linking scripting languages which have a web framework to Apache is years old - PERL has been doing this for ages.

"Ruby on Rails is NOT new. I have seen all this before. For example, Smalltalk was doing this years ago"

Ha ha, You mean that someone has done something almost like this a long time ago and someone is working on something similar but not yet finished?

Spare me it is so pathetique. When Naked Objects appeared it was hailed as something revolutionary, Rails takes the concept one step further and then add the world most modern, elegant and cool computer language into the mix.

At the moment RoR has 1(one) fault, or lack. There is no mapping so it is not useful against legacy databases. That is sure to be remedied in the future. In fact there is a workaround! I leave it as an exercise to the TSS reader’s intelligence to find out how. Concerning addition or removal of columns you have less work to do in Rails than in other ORM tools. That is of course if you have done your custom forms already. Otherwise you can add and remove as much as you want and the application will still work without any new round-trip generating

Peter,

" RoR would have to copy more features of WSAD, VS.NET and other more mature development environments to be comparable. As it is today, i would say it's a great start"

You see? Peter is not as negative as you!

Regards
Rolf Tollerud

Tomorrow we shall se how RoR handle AJAX!

Tomorrow we shall se how RoR handle AJAX!

You mean even more horrible mixture of server-side and client-side logic right inside the templates? Like this:
<%= form_remote_tag( :url => url_for( :action=>'complete_task', :taskitem_id=>taskitem.id ),
                     :html => { :id=> "complete-taskitem-#{taskitem.id}" },
                     :update => "tasklist-completed-items",
                     :position => 'bottom',
                     :loading => "Form.disable('complete-taskitem-#{taskitem.id}');",
                     :complete => "new Effect.Squish('taskitem-#{taskitem.id}-container', true);"
                     ) %>
Yeah I can't wait to let my server-side framework generate even more of the client-side for me.

Q: How do you eat an elephant?
A: One bite at a time.
http://jeremy.zawodny.com/blog/archives/004373.html

If RoR is so bad, why is everyone so in a hurry to copy it?
Ports are in progress for Java, Python, PHP and more..

Listen to die hard Python (Python =main contender to Ruby) fan, Jonathan LaCour:

"I don't even like Ruby very much, but Rails is obviously the best web framework out there because of the tightly integrated simplicity of it! Rails is the Apple of web frameworks — one tightly controlled stack. Sure, you may lose some flexibility, but you gain beauty, simplicity, and ease of use! I really really wanted to pick Python, but I just couldn't do it. There are too many frameworks, none of which are as good as Rails."

Regards
Rolf Tollerud

"Rails follows the Model View Controller (MVC) pattern, but does it a lot more elegantly and simply than the Java-based competitors. You build your model almost entirely at the database level, and Rails uses reflection to bolt attributes and relationships onto your objects. Controllers are simple ruby classes with some custom macros. Views are very clean templates with no wonky template language to learn."

http://forum.textdrive.com/viewtopic.php?pid=9808

"Rails follows the Model View Controller (MVC) pattern, but does it a lot more elegantly and simply than the Java-based competitors.

This is plain nonsense. See horrid Ruby code embedded in View. To see elegant MVC, take a look at Spring MVC, JSF, or the incredible elegance of Tapestry, which is pure HTML in the view.

You build your model almost entirely at the database level, and Rails uses reflection to bolt attributes and relationships onto your objects.

Which, as almost any serious OOP developer will tell you, is exactly the wrong way to do things.

Controllers are simple ruby classes with some custom macros. Views are very clean templates with no wonky template language to learn."

Ah, so instead of some wonky template language to learn, you have to learn some wonky custom Ruby macros.

First of all Rolf, I feel really sorry for you. Every time you feel some heat from people that are criticizing your statements, you start quoting others and pasting links. How about discussing something for real for a change and stopping labeling everyone that doesn't totally agree as being haters.

If RoR is so bad, why is everyone so in a hurry to copy it?Ports are in progress for Java, Python, PHP and more..

There are many more not copying it and just ignoring it, at least some people (here) try to have some discussion about it, but it seems that's never possible. About the 'ports' I've seen, they are nothing like Rails at all and merely inspire themselves from some aspects of it, carefully cherrypicking what seems applicable for their own use. This again is nothing new.

Please don't start pasting random quotes of anywhere that's just a waste of time since if everyone does this we'll just start communicating with quotes instead.

Q: How do you eat an elephant?A: One bite at a time.http://jeremy.zawodny.com/blog/archives/004373.htmlIf RoR is so bad, why is everyone so in a hurry to copy it?Ports are in progress for Java, Python, PHP and more..Listen to die hard Python (Python =main contender to Ruby) fan, Jonathan LaCour:"I don't even like Ruby very much, but Rails is obviously the best web framework out there because of the tightly integrated simplicity of it! Rails is the Apple of web frameworks — one tightly controlled stack. Sure, you may lose some flexibility, but you gain beauty, simplicity, and ease of use! I really really wanted to pick Python, but I just couldn't do it. There are too many frameworks, none of which are as good as Rails."RegardsRolf Tollerud

Very small solutions for a limited range of problems can look simple and tightly integrated, but that is an illusion. The loss of flexibility is serious.

Tomorrow we shall se how RoR handle AJAX!

Oh great! Let's combine something that has huge database dependence on the server with something that has huge JavaScript dependence on the client!

How much worse could things get?

"Ruby on Rails is NOT new. I have seen all this before. For example, Smalltalk was doing this years ago"Ha ha, You mean that someone has done something almost like this a long time ago and someone is working on something similar but not yet finished?

Yes.

Spare me it is so pathetique.

No Rolf. 'Pathetique' is making stupid statements like 'Ruby makes Smalltalk look like Visual Basic'. This indicates you have never used Smalltalk.

Rails takes the concept one step further and then add the world most modern, elegant and cool computer language into the mix.

Oh give me a break! Its yet another OOP scripting language, and that is all. It is one of many. There are far cooler languages. Take a look at things like Haskell - really revolutionary ideas.

Why do you insist on such pointless exaggeration?

At the moment RoR has 1(one) fault, or lack. There is no mapping so it is not useful against legacy databases. That is sure to be remedied in the future. In fact there is a workaround!

Why should I have to code a workaround, when there are frameworks that work NOW? Do you have some kind of time machine so that you can access future versions of products for use today?

Concerning addition or removal of columns you have less work to do in Rails than in other ORM tools.

Don't be silly. In my Java ORM tool this involves removing a bean property with a few mouse clicks. Please explain in detail how anything can be LESS work that that?

Peter,

" RoR would have to copy more features of WSAD, VS.NET and other more mature development environments to be comparable. As it is today, i would say it's a great start"

You see? Peter is not as negative as you!RegardsRolf Tollerud

Unlike you, I think for myself.

"Don't be silly. In my Java ORM tool this involves removing a bean property with a few mouse clicks. Please explain in detail how anything can be LESS work that that?"

Sorry, I have to go. Only one question. What happens to your carefully contructed custom forms when you add or delete a "bean property". (table column) ?

"Don't be silly. In my Java ORM tool this involves removing a bean property with a few mouse clicks. Please explain in detail how anything can be LESS work that that?"Sorry, I have to go. Only one question. What happens to your carefully contructed custom forms when you add or delete a "bean property". (table column) ?

A click of the mouse and they update themselves to reflect the changes (for example, columns will appear and disappear in tables). Even better, another click of the mouse and I can test the individual form with live data. Neat, isn't it?

"Simplicity by encapsulated complexity is not the same as true simplicity"

There is a famous essay about that which just slips my mind but when I remember it I will call you!

We also obviously have very different opinions about what a "Custom Form" is..

Best Regards
Rolf Tollerud

The whole setup which you describe is a mess.

"Simplicity by encapsulated complexity is not the same as true simplicity"There is a famous essay about that which just slips my mind but when I remember it I will call you!We also obviously have very different opinions about what a "Custom Form" is..Best RegardsRolf Tollerud

What exactly is complex about dragging an table icon onto a form, and then popping up a menu to link it to a data source? (and then refreshing that link when a bean property/schema has changed?).

That is FAR simpler than having to use command line scripts - how 'pathetiqually' primitive!

A custom form is a form you have customised. The kind of customisation you can eaily accidentally wipe out using RoR.

You seem to have a strange belief that the simplest of solutions can be used everywhere. (As in your Expert's Exchange advice helping someone divert part of their company website to their personal desktop computer).

However, this is wrong. Sometimes complexity and structure are needed. ("I have discovered a truly remarkable proof which this webform is too small to contain").

Ha ha, You mean that someone has done something almost like this a long time ago and someone is working on something similar but not yet finished?

Spare me it is so pathetique.

But we all know that this doesn't stand a chance against Avalon. Microsoft's engineers are all level 19 ninja gods, and will crush this Ruby nonsense without even stopping to scratch their buttocks. Everybody knows that Microsoft is rated the absolute best place in the universe ever. See this out-of-context quote I grabbed from a blog:

.. doing my internship at Microsoft was like all my best dreams come true, because everyone here is a ninja!

RoR doesn't stand a chance against Ninjas. RoR is made by impractical theorists who theorize about computer science theories, and therefore I hate them all, and predict that Avalon will totally destroy them with a single mega karate chop.

hihi

Ralf Trollhut

Cameron,

"I hate them all, and predict that Avalon will totally destroy them with a single mega karate chop"

It is interesting that when Open Source, the only ones that have a chance to stand up against MS come up with something that can challenge .NET (Java most certainly cannot check the Yann Caroff index) then the Java camp reject it...

hihi

Ralf Trollhut

Avalon/.NET will dominate the day it will be able to run on
something besides a MS os. And before you start with the MONO crap, is MONO supported by MS? Will .NET run on zOS? Java sure as hell does, and it is supported.

-java ninja

Cameron,"I hate them all, and predict that Avalon will totally destroy them with a single mega karate chop"It is interesting that when Open Source, the only ones that have a chance to stand up against MS come up with something that can challenge .NET (Java most certainly cannot check the Yann Caroff index) then the Java camp reject it...hihiRalf Trollhut

Yes, Ruby on Rails must be the only possible answer to .NET. I should have realised that a slow scripting language which almost no-one uses, combined with a brain-dead ORM and a few classes that auto-generate HTML web forms is the only possible way to stop all those abandoned Visual Basic developers switching to .NET. I mean look at how with RoR you can do visual design of web forms, debug live applications, use APIs like ODBC to abstract the database, compile to fast executables.... Oh, sorry, I seem to have made some mistake here. Are you talking about the same Ruby on Rails I am?

Steve,

You are doing a valiant job but to no avail, I have looked in my crystal ball and Ruby is the next big thing. Dynamic languages has attracts a lot of interest for a while, it was just a question if which one. Python almost made it, but in the end Ruby won.

Best regards
Rolf Tollerud
("never been wrong yet")

An open, friendly community with nice and easygoing people.

Not like the Java world.

An open, friendly community with nice and easygoing people.Not like the Java world.

Are they Ninjas too? I love ninjas!

Steve,You are doing a valiant job but to no avail, I have looked in my crystal ball and Ruby is the next big thing. Dynamic languages has attracts a lot of interest for a while, it was just a question if which one. Python almost made it, but in the end Ruby won.Best regardsRolf Tollerud("never been wrong yet")

I really like dynamic languages. I think that they could eventually form a significant part of software development at all scales. But, there is a very, very big problem with them at the moment. It is called performance. It is very strange the way that the same developers who leap to criticise Java for its (alleged) slowness are so keen to embrace scripting languages, which can be an order of magnitude slower, as the 'next big thing'. Did you hear about the Ruby XML library that was 50 (yes, 50!) times slower than the Java version and suffered from memory problems?

As for Ruby the language, it is a sloppy mess that has not learned the lessons of previous language designs. Just to mention one horror: the use of symbols at the start of variable names to indicate their type: @instance, @@class, $global and so on. This is a nightmare for code re-use, and is completely unecessary. Smalltalk, perhaps the most powerful dynamic language of all, only had two such classifications: global variables started with an upper-case letter, the rest didn't, and some language experts even criticised that!

If you really want to see a simple, beautiful dynamic language that has successfully been used everywhere, from embedded programs to large enterprise applications, take a look at Smalltalk. GNU Smalltalk is a good place to start, then take a look at Squeak to see how powerful GUIs and multimedia can be combined. You will soon see how unoriginal and derivative small languages like Ruby are.

(So why am I not using Smalltalk? Because there are so many dialects, and there was never a single dialect that was inexpensive, cross-platform and fast).

As for Ruby being the next big thing - I wonder what the next over-hyped bandwagon you will jump on, Rolf?

"As for Ruby being the next big thing - I wonder what the next over-hyped bandwagon you will jump on, Rolf?

The only over-hyped bandwagon I have ever jumped upon was C# Steve, that I jumped upon when nobody believed in it. Not a bad decision as we know now. I take it that you know that C# has eaten another percent from Java since the last time we spoke? (the Yann Caroff index).

The last time I checked Smalltalk it was not a stand-alone language but was coming together with a graphical environment precisely as VB6. And much much slower..than VB6.

"Did you hear about the Ruby XML library that was 50 (yes, 50!) times slower than the Java version and suffered from memory problems?"

Precisely as the Java XML parser is 50 time slower that MS C++ parser.. Memory problem is the reason to that Java looses all benchmarks contest. The last time it lost against Ruby with some 2000 percent if I remember right. Ruby need a compiler and a compiler is in the works. A REAL compiler that compiles to native code - not like Java.

Ruby is such a pleasure to work in that even if it had no use whatsoever one could still imagine people play with it just for fun, as some people play with abstract mathematics. But Ruby is immensely useful.

Ruby is made by REAL men not by sissies but is still a thing of beauty - only the Japanese can pull of a thing like that.

Do you know that Don Box wish that all development att Microsoft was done in Ruby?

Regards
Rolf Tollerud

"As for Ruby being the next big thing - I wonder what the next over-hyped bandwagon you will jump on, Rolf? The only over-hyped bandwagon I have ever jumped upon was C# Steve, that I jumped upon when nobody believed in it. Not a bad decision as we know now. I take it that you know that C# has eaten another percent from Java since the last time we spoke? (the Yann Caroff index).

Did you realise that Java has grown so much that it has recently overtaken C++ in terms of job demand? So much the for C# 'eating another percent' nonsense.

The last time I checked Smalltalk it was not a stand-alone language but was coming together with a graphical environment precisely as VB6.

No. Smalltalk has always been able to run non-graphical. (the term is 'headless'). If you did as I said and checked GNU Smalltalk, you would have seen an example of this. There is a command-line version of Smalltalk for .NET - SmallScript (S#).

And much much slower..than VB6.

No. Smalltalk MT for Windows is compiled to native code, like VB6, C++ etc.

"Did you hear about the Ruby XML library that was 50 (yes, 50!) times slower than the Java version and suffered from memory problems?"Precisely as the Java XML parser is 50 time slower that MS C++ parser..

You simply invented that figure. libxml is a fast XML parser written in C. IBM's dom4j runs at about 50% of the speed of libxml.

Memory problem is the reason to that Java looses all benchmarks contest.

More rubbish. I have already shown you Java Linpack benchmarks which indicates that Java is at least as fast as some C++ implementations.

So, as I have shown you a benchmark that Java wins, you are not permitted to say 'Java looses all benchmarks contest' again, OK? As it is a provably incorrect statement...

The last time it lost against Ruby with some 2000 percent if I remember right.

Well, I have just performed an arbitrary benchmark and Java won by 2000 percent. I can invent figures too! Let's compare Java and Ruby performance for numerical iteration algorithms, and see which wins! This is fun!

Ruby need a compiler and a compiler is in the works.

Ah, you mean like the Ruby to parrot compiler? At version 0.1.0, or the Ruby VM, at version 0.2.0? Or do you mean the far more advanced Ruby compiler for the JVM (0.8.0) (but still incomplete).

A REAL compiler that compiles to native code - not like Java.

Of course Java DOES compile to native code. See GCJ (Gnu Compiler for Java, which can produce either byte codes or native code). Even conventional VMs, like Sun's, compile to native code. If it did not compile to native code, how could it the Hotspot system possibly perform native native code instruction re-ordering for optimisation?

Do you know that Don Box wish that all development att Microsoft was done in Ruby?RegardsRolf Tollerud

He has also recently posted stating that LISP (the Scheme dialect) is a wonderful language for processing XML - are you going to follow that idea as well? If you are interested, there are plenty of LISP systems that run on the JVM!

Precisely as the Java XML parser is 50 time slower that MS C++ parser.. Memory problem is the reason to that Java looses all benchmarks contest.

RegardsRolf Tollerud

ok, which benchmark are you referring to? If you're talking about benchmarks from 98/99, comparing the default lame parser versus the optimized MS C++ parser than I'd say that is accurate for 99, but not today.

In fact, if you compare XPP3 or the latest xml stream parsers, Java is one of the faster parsers. Resin used to use a C based parser because the java parser was slow. I believe the latest parser shipped with Resin is java based. I could be wrong, since I haven't used the latest version. The latest Resin uses JAXP compliant parser. If you compare C# parser vs XPP3, Java wins. By the way, the C# parser is rock solid and is one of the best. I'm sure when .NET 2.0 comes out the performance difference between XPP3 and .NET will be insignificant. At this point, XML parsers have matured enough that any difference between C/C++, Java, or C# isn't going to be significant. More important is the design of the application and how XML is used.

About the only way to get 10x improvement in parser performance is to use hardware acceleration. Sarvega and a couple other companies have been selling hardware acceleration for the last few years. Back on the topic of RoR. Not everyone is going to like Ruby or RoR. But really, who cares.

the hype claiming RoR is new is really quite wrong and does a great disservice. Reading the docs, it is clear to me the developers of RoR took time to think things through to meet their own needs. Whether that meets others needs is going to take lots of time to prove.

peter

We are talking about xslt transforming here.

Peter Peter please spare me, we are not talking about mundane SAX, to really test the parser we need to do something difficult like xslt transforming the whole King James bible.

I tried to find some large xml file 4-5 MB on the internet without success, maybe you can help?

Then we can decide this matter right here and now. This country is not large enough for two parsers!

Regards
Rolf Tollerud

Sorry, just wanted to improve the title!

We are talking about xslt transforming here.Peter Peter please spare me, we are not talking about mundane SAX, to really test the parser we need to do something difficult like xslt transforming the whole King James bible.I tried to find some large xml file 4-5 MB on the internet without success, maybe you can help?Then we can decide this matter right here and now. This country is not large enough for two parsers!Regards
Rolf Tollerud

since your post was vague and totally non-specific, I responded to see what you were referring to. go ahead and blame me for the lack of details in your post.

The last time I compared XSLT transform between .NET and Xerces/Xalan, the difference wasn't significant. your results may be different. depending on whether one uses local vs absolute path statements, one xslt processor may beat another. The structure of the XML can have a dramatic impact on performance.

I find your argument rather counter productive to RoR. Calling RoR new and claiming others aren't interested in "new" technology does more damage than good. I would think the best way to prove your point would be to provide concrete examples. For someone who constantly claims to be "ahead of others" I would think this would be a good chance to illustrate your skill.

enjoy.

peter

"The structure of the XML can have a dramatic impact on performance"

Sounds like you are preparing for the squirmy excuses already. Anyhow I found a suitable file, it is a unabridged bible commentary, a xml file on 4 MB. I would say it can do what do you say?

http://www.ccel.org/h/henry/mhc/

mhcc.xml XML file [4062 KB]

And remember xsl transformations. If sax can do the job I can just as well write a little snippet of my own and need no parser.

Regards
Rolf Tollerud

"The structure of the XML can have a dramatic impact on performance"Sounds like you are preparing for the squirmy excuses already. Anyhow I found a suitable file, it is a unabridged bible commentary, a xml file on 4 MB. I would say it can do what do you say? http://www.ccel.org/h/henry/mhc/mhcc.xml XML file [4062 KB] And remember xsl transformations. If sax can do the job I can just as well write a little snippet of my own and need no parser. Regards

Rolf Tollerud

I have no need for excuses. If it's faster it's faster. It would be silly and retarded to argue against good benchmarks. Of course, there are plenty of aweful benchmarks, which are purposely skewed. I'm not going to bother benchmarking that document using XSLT. feel free to do it yourself and publish the results though. even better, compare Ruby, .NET, JAXP, MS C++ parser and let everyone know how it went.

peter

I'm not going to bother benchmarking that document using XSLT. feel free to do it yourself and publish the results though. even better, compare Ruby, .NET, JAXP, MS C++ parser and let everyone know how it went.peter

I did, as I am interested in language performance. I compared the built-in XSLT libraries in Sun Java 5.0, with xsltproc, a wrapper to the well-known C libxslt library.

I wrote a simple stylesheet that extracted the text from within the tags, and output the result to file.

Here are the results:

Java:
real 0m1.983s
user 0m1.516s
sys 0m0.146s

xsltproc:
real 0m17.854s
user 0m15.926s
sys 0m0.112s

This surprised me! However, the files input to the programs were the same, and the result files were the same (within a whitespace character or two). Several repeats showed these results were consistent.

Oh, and the Java ran with a memory allocation of 10MB (a switch setting of -Xmx10m) and xsltproc allocated 14MB.

The moral of this is that both Java and C are fast - what matters is the quality of the code.

I'm not going to bother benchmarking that document using XSLT. feel free to do it yourself and publish the results though. even better, compare Ruby, .NET, JAXP, MS C++ parser and let everyone know how it went.peter

I did, as I am interested in language performance. I compared the built-in XSLT libraries in Sun Java 5.0, with xsltproc, a wrapper to the well-known C libxslt library.I wrote a simple stylesheet that extracted the text from within the tags, and output the result to file.Here are the results:
Java:
real 0m1.983s
user 0m1.516s
sys 0m0.146s

xsltproc:
real 0m17.854s
user 0m15.926s
sys 0m0.112s

This surprised me! However, the files input to the programs were the same, and the result files were the same (within a whitespace character or two). Several repeats showed these results were consistent.Oh, and the Java ran with a memory allocation of 10MB (a switch setting of -Xmx10m) and xsltproc allocated 14MB.The moral of this is that both Java and C are fast - what matters is the quality of the code.

the numbers for java look close to my own experience over the last 3 years. thanks for running it, though I was hoping Rolf would do it. I think he owes you one for runnig the benchmark :)

most XML parsers and XSLT processors are sufficient today for most application. unless someone is doing crazy stuff like sending 100Mb+ reports over the wire and then using XSLT to transform it to XHTML, just about any mature lib can handle it. There are people sending large reports over the internet using XML. Sorry for getting off topic, but wanted to say thanks.

peter

I'm not going to bother benchmarking that document using XSLT. feel free to do it yourself and publish the results though. even better, compare Ruby, .NET, JAXP, MS C++ parser and let everyone know how it went.peter

I did, as I am interested in language performance. I compared the built-in XSLT libraries in Sun Java 5.0, with xsltproc, a wrapper to the well-known C libxslt library.I wrote a simple stylesheet that extracted the text from within the tags, and output the result to file.Here are the results:Java:real 0m1.983suser 0m1.516ssys 0m0.146sxsltproc:real 0m17.854suser 0m15.926ssys 0m0.112sThis surprised me! However, the files input to the programs were the same, and the result files were the same (within a whitespace character or two). Several repeats showed these results were consistent.Oh, and the Java ran with a memory allocation of 10MB (a switch setting of -Xmx10m) and xsltproc allocated 14MB.The moral of this is that both Java and C are fast - what matters is the quality of the code.

the numbers for java look close to my own experience over the last 3 years. thanks for running it, though I was hoping Rolf would do it. I think he owes you one for runnig the benchmark :)most XML parsers and XSLT processors are sufficient today for most application. unless someone is doing crazy stuff like sending 100Mb+ reports over the wire and then using XSLT to transform it to XHTML, just about any mature lib can handle it. There are people sending large reports over the internet using XML. Sorry for getting off topic, but wanted to say thanks.peter

Thanks, but I did it for selfish reasons!

I have a particular interest in XML, XSLT and the relative performance of parsers and transform, as I do a lot of server-side report generation and document format conversions. This work is helped considerably by the rather useful file format of Open Office, which is nothing more than a zipped set of XML files, with formatting markup which bears a striking resemblance to XSL:FO. It is nice to confirm that Java's XML processing library is one of the best around!

(Excuse me for the quote from the Eurovision Festival)

All results in millisiconds:

Java 5.0
1125

C# 1.1
406

MsXML C++ parser 4.0
140

Binary and source code at,
http://www11.brinkster.com/monoasp/lin/perf.zip

The xml file can be downloded at this address,

http://www.ccel.org/h/henry/mhc/
mhcc.xml XML file [4062 KB]

Best regards
Rolf Tollerud

It is not enough to program in C++, you have to be good at it too..

(Excuse me for the quote from the Eurovision Festival)All results in millisiconds:Java 5.01125C# 1.1406MsXML C++ parser 4.0140Binary and source code at,http://www11.brinkster.com/monoasp/lin/perf.zipThe xml file can be downloded at this address,http://www.ccel.org/h/henry/mhc/mhcc.xml XML file [4062 KB] Best regardsRolf Tollerud

You should be using MSXSL - we are after transforms, not parsing.

That perf.zip is an empty link.

(Excuse me for the quote from the Eurovision Festival)All results in millisiconds:
Java 5.0
1125
C# 1.1
406
MsXML C++ parser 4.0
140
Binary and source code at,http://www11.brinkster.com/monoasp/lin/perf.zipThe xml file can be downloded at this address,http://www.ccel.org/h/henry/mhc/mhcc.xml XML file [4062 KB] Best regards

Rolf Tollerud

Did you test using crimson parser? If you used crimson, I would ask "why". I've benchmarked crimson enough to know XPP3 blows it away. Even without looking at the source, which I can't download, those numbers look like crimson numbers.

Anyone that has researched XML parsers know that stream parsers are much faster and much more efficient. If you haven't read the articles by Sosnoski, you really should.

peter

Did you test using crimson parser? If you used crimson, I would ask "why". I've benchmarked crimson enough to know XPP3 blows it away. Even without looking at the source, which I can't download, those numbers look like crimson numbers.Anyone that has researched XML parsers know that stream parsers are much faster and much more efficient. If you haven't read the articles by Sosnoski, you really should.peter

Sorry to break in, but what I think has happened is that the runs have been to short to permit Hotspot optimisation, and a significant fraction of the Java time would be VM and class loading. I increased the datafile size tenfold, and got very impressive results from the Sun JVM 5.0.

(Excuse me for the quote from the Eurovision Festival)All results in millisiconds:Java 5.01125C# 1.1406MsXML C++ parser 4.0140Binary and source code at,http://www11.brinkster.com/monoasp/lin/perf.zipThe xml file can be downloded at this address,http://www.ccel.org/h/henry/mhc/mhcc.xml XML file [4062 KB] Best regardsRolf Tollerud

Of course, Java gets better with time, because of the Hotspot system. A brief run in which the VM is only active for a couple of seconds is hopelessly short, so I replicated the contents of the file to make one of size 40MB.

I then tested Java 5.0 and MSXSL.EXE (version 4.0) under Windows XP:

Java: 10 seconds
msxsl: 9 seconds

There is quite a bit of inaccuracy (+/- a second or so), so I have only quoted to the nearest second for both readings, but what it illustrates is that given enough time, Sun's Hotspot optimiser does a very good job, and gives C++ speed.

Interestingly, adding the -server switch to Java made the time slightly worse (adding 2-3 seconds to the time).

This has been a useful exercise.

Funny results troll, err Rolf mhcc.xml at 15.8megs

jdk 1.5.0_02
C:\Program Files\Java\jdk1.5.0_02\bin\java.exe" -classpath . XSLTransform mhcc.xsl mhcc.xml

1922
1641
1640
1656
1703
1672

.net v1.1
xsl-trans.exe mhcc.xml mhcc.xsl
2594
2313
2313
2297
2328
2313

DateTime start = DateTime.Now;
myXslTrans.Transform(myXPathDoc, null, myWriter, null);
myWriter.Close() ;
Console.WriteLine("{0,0:0}", (DateTime.Now - start).TotalMilliseconds);

and

long startTime = System.currentTimeMillis();
transformer.transform( xmlsource, output );
System.out.println(System.currentTimeMillis() - startTime);

Since we are only measuring transforming speeds...

and the results look even worse

java
----
1485
1469
1469
1453
1516
1766

C#
---
2500
2766
2453
2344
2375
2359

Which orignal 4meg file, but with start time moved

java
562
578
578
578
579
562

C#
578
578
578
578
578
578

Well, so much for Rolf's numbers. Of course he'll make some odd claim and say the his results are "more accurate". in 2002/2003 I ran probably over 100 benchmarks comparing SAX vs .NET 1.0 and 1.1 for DOM and XSLT. both were plenty fast. My tests were more focused on parallel processes on the serverside. If I remember correctly, on a 2.4ghz system with 512mb of ram, both maxed out the CPU around 15 parallel parser processes. Now the discussion is way off topic, but oh well still interesting results.

peter

Some comments,

"perf.zip is an empty link"
"You should be using MSXSL - we are after transforms, not parsing"
"Did you test using crimson parser?"
"If you haven't read the articles by Sosnoski, you really should"
"I increased the datafile size tenfold!"
"Which orignal 4meg file, but with start time moved"
"shock horror, bad benchmark from Rolf :)"
"Well, so much for Rolf's numbers"
"Of course he'll make some odd claim and say the his results are "more accurate" in 2002/2003"

Well gentlemen I hope you all will live long!

How can I hope to get such excellent entertainment elsewhere?

Regards
Rolf Tollerud

Some comments,

"perf.zip is an empty link""You should be using MSXSL - we are after transforms, not parsing""Did you test using crimson parser?" "If you haven't read the articles by Sosnoski, you really should""I increased the datafile size tenfold!""Which orignal 4meg file, but with start time moved""shock horror, bad benchmark from Rolf :)" "Well, so much for Rolf's numbers""Of course he'll make some odd claim and say the his results are "more accurate" in 2002/2003"

Well gentlemen I hope you all will live long!How can I hope to get such excellent entertainment elsewhere?RegardsRolf Tollerud

Let me explain and summarise the facts, so they are on record:

1. Even small Java applications can have a significant start-up time as large as several hundred milliseconds on modern machinery. Why is this? As I understand it is because of the time taken to start the VM, and class loading. Java will usually have to load many more classes than the equivalent .NET application, as .NET is a relatively thin layer over Win32, whereas Java abstracts much more of the platform.

2. Java JITing and Hotspotting take time to boost performance. This does not matter for server side applications where the JVM can be active for considerable lengths of time. I would imagine there is a similar JITing time for .NET applications. With Hotspot this time is deliberate, as it allows Java apps to start up faster using just bytecode interpreting, with complation coming later.

So, to accurately test the speed of an algorithm or library in Java or .NET it is necessary to give the program a 'warm-up' period, to allow the performance to settle. Once this has happened, well-written Java programs can approach the speed of well-written C programs. The results presented leave no doubt of the relative performance of Java 5.0 and msxsl for anything but the smallest tasks.

If, like Rolf, you try and run Java, using normal J2SE/J2EE Java VMs, on tasks that take less than a few seconds it will look poor. But, this is not the way Java is used, or intended to be used. (The same issues arise with .NET).

If I can actually find an XSLT library written in pure Ruby or Python, I'll compare those, and blog the results and summary somewhere.

Rolf - you provide more than entertainment - you help provide ever better evidence of the quality of Java. I am grateful.

Oh, and that perf.zip link:
"HTTP1.1 STATUS 403 Remote Access to this object forbidden This file cannot be directly accessed from a remote site, but must be linked through the Brinkster Member's site."

I really doubt people using RoR are going to be using lots of XML for request/response. I also doubt someone would build an application with RoR, which needs to spew out 100Mb of XML to generate a report. In contrast, I know of several systems in banking and financial companies that regularly send 100Mb+ XML files. Don't ask me why they are doing this, since the idea sounds horrible to me. I'm sure there's a good reason for doing this. Documents that big eat up bandwidth like Jaba the Hut at an "all-you-can-eat" buffet. Jaba won't stop eating until the frig is empty of all food :)

peter

I really doubt people using RoR are going to be using lots of XML for request/response.

I think the XML/XSL was simply an illustration of general performance.

I also doubt someone would build an application with RoR, which needs to spew out 100Mb of XML to generate a report

But you can bet someone will try :)

"Java JITing and Hotspotting take time to boost performance"

Yes I know that Steve, and I also know that Java memory management thanks to hotspot have all kinds of problems (see below). I ran the tests again inside a loop,

Java
C:\dev\xmldata>C:\jdk1.5.0_01\bin\java.exe -classpath . XSLTransform mhcc.xsl mhcc.xml
1141
469
453
437
516

C#
C:\dev\xmldata>xsl-trans.exe mhcc.xml mhcc.xsl
422
453
422
422
438

Running more iterations do not help. So with hot-spot Java the speed is about the same as C# while the important startup time is much longer. Observe that C++ is still faster than both Java and C# by a factor of 3. So much for the "Java can be as fast as C++" mantra.

Just for completeness check a fresh and recent Quick Java & C# Performance Comparison, from february this year,
http://michael.alecti.com/archive/2005/02/15/624.aspx

Observer that C++ has the top result even when the C++ implementation was abysmal according to the author. Older Java VMs is faster than JVM 1.5.0. (Java 5.0)

What everything boils down to is that you have to be a good programmer, or you will blew it. The Microsoft programmers are among the best in the world (even if Cameron likes to make fun of them).The quality of Sun coding are well known,
http://www.internalmemos.com/memos/memodetails.php?memo_id=1321

Some people hold forth that this is an old problem. That is not the case. As you will see in the following links there are not any particular bug(s) that's the problem, but the incompetence of Sun.

"The HotSpot source code is a bad joke" by Slava Pestov (jEdit author)
the Java runtime is so badly coded that its a wonder it works at all!

But what can you expect with such hiring philosophy?

..because SUN hired most of the programmers thro some reference or someone who is related to one of the employees without proper screening or interviews.

Dynamic languages are the future. Interpret during development, compile for deployment. So much more powerful! "Strong Typing?", what a waste. "Type inference" a la Ocaml is better. Do you think that Java can stand against the .NET? Think again. Ruby is a better choise because it is going forward at a fast pace, not like Java that in 10 years has not improved more than you can see above.

The InterSystems Australian Integration 2004-05 Report.
.NET is employed by about three in five organisations (61 per cent), with J2EE supported by about two in every five (42 per cent). http://australianit.news.com.au/articles/0,7204,12824901%5E15321%5E%5Enbv%5E15306,00.html

You really do need something new..

Regards
Rolf Tollerud
Irresponsible hobbyist - Microsoft hacker - Ninja of 19th degree

Just for completeness check a fresh and recent Quick Java & C# Performance Comparison, from february this year,
http://michael.alecti.com/archive/2005/02/15/624.aspx

Observer that C++ has the top result even when the C++ implementation was abysmal according to the author. Older Java VMs is faster than JVM 1.5.0. (Java 5.0)

What everything boils down to is that you have to be a good programmer, or you will blew it. The Microsoft programmers are among the best in the world (even if Cameron likes to make fun of them).The quality of Sun coding are well known,
http://www.internalmemos.com/memos/memodetails.php?memo_id=1321

thanks for posting the link. According to the PCNN benchmark, Java5 in server mode is 20% slower than optimized C++.

JVM 1.5.0S - 17.43 200.8
C++ KAJ - 13.89 252.0

I would say that is pretty close. Once you add on application overhead, I would say the difference would be erased. C++ definitely is faster and Java/C# in the hands of a seasoned professional. I doubt Ruby could get close to C++ speeds within the next 3-4 years. In ten years, there's a good chance Ruby could match those speeds. By then, Java and .NET will likely match C++ speeds, so at that point, it boils down to preference. If someone prefers Ruby great. There are no universal tools that fit everyone.

enjoy

peter

Peter, do you know that you often are quite incoherent?
 
Webster
Main Entry: incoherent
Function: adjective
1 :lacking orderly continuity, arrangement, or relevance : INCONSISTENT
2 : lacking clarity or intelligibility : INCOMPREHENSIBLE

You say,

1) "C++ definitely is faster and Java/C# in the hands of a seasoned professional"

Ok, that is good. But just before you said "I would say that is pretty close" referring to C++ KAJ.

Didn't you read that the author said that the C++ code was abysmal?

2) "By then, Java and .NET will likely match C++ speeds"

How are going to think away the compile step? Java speed hasn't improved for many years and in the case of 5.0 has degrated.

3) "In ten years, there's a good chance Ruby could match those speeds"

10 years really! ;) That would be a reasonable estimate if Ruby moved with "Java speed".

Regards
Rolf Tollerud

"In ten years, there's a good chance Ruby could match those speeds"10 years really! ;) That would be a reasonable estimate if Ruby moved with "Java speed".RegardsRolf Tollerud

The Ruby language has not changed significantly in 10 years. COBOL has though! Compared to Ruby, COBOL is moving rapidly to adapt to the needs of developers!

Go COBOL!

Peter, do you know that you often are quite incoherent?&nbsp;WebsterMain Entry: incoherent Function: adjective1 :lacking orderly continuity, arrangement, or relevance : INCONSISTENT2 : lacking clarity or intelligibility : INCOMPREHENSIBLEYou say,1)

I think the exact same thing when I read most of your posts.
Like -

How are going to think away the compile step?

What?

  I seldom feel that way when I read Peter's posts. And then, only when he talks beyond my own experiences.

Peter, do you know that you often are quite incoherent?&nbsp;WebsterMain Entry: incoherent Function: adjective1 :lacking orderly continuity, arrangement, or relevance : INCONSISTENT2 : lacking clarity or intelligibility : INCOMPREHENSIBLEYou say,1) "C++ definitely is faster and Java/C# in the hands of a seasoned professional"Ok, that is good. But just before you said "I would say that is pretty close" referring to C++ KAJ.Didn't you read that the author said that the C++ code was abysmal?2) "By then, Java and .NET will likely match C++ speeds"How are going to think away the compile step? Java speed hasn't improved for many years and in the case of 5.0 has degrated. 3) "In ten years, there's a good chance Ruby could match those speeds"10 years really! ;) That would be a reasonable estimate if Ruby moved with "Java speed".

RegardsRolf Tollerud

I readily admit I post with little or no proof reading. I also readily admit I sounds like gibberish often. The results in the link you provided do show the performance difference is small.

those results in no way contradict the fact that C++ allows a programmer much greater level of control and therefore more opportunity to optimize code. As you stated, it is the skill of programmer that makes a difference. By "seasoned developer" I was thinking of someone with 5-10 years of hardcore C++ experience building high performance applications. I'm not that person. In fact, I suck at C++.

My interpretation is the author of the blog was saying the other implementations were abysmal, but no the KAJ optimized version. I could be totally mis-interpreting the blog, who knows. If you're talking about Sun JVM, it has been improving slowly. Probably not as fast some people would like. IBM and JRockit have been improving quite nicely thanks.

10 years would be an optimistic guess. There's absolutely no data to back up my guess, so take it as you will. I was attempting to be nice to Ruby, since there are aspects of Ruby that I like. I hope they can make progress in 10 years, but no one knows. If some mad genius decides to write an optimized VM for Ruby, it's concievable in 10 years Ruby can match C++ for the most common cases. Edge cases, it's going to be hard.

Feel free to throw as many insults at me as you feel appropriate. I don't take it personal and get a laugh out of your wild behavior.

peter

So with hot-spot Java the speed is about the same as C# while the important startup time is much longer.

Yes, and I explained why. C# does not need so many classes loaded, because .NET is a thin layer over Win32.

Observe that C++ is still faster than both Java and C# by a factor of 3.

Not on a larger file that takes longer to process.

So much for the "Java can be as fast as C++" mantra.Just for completeness check a fresh and recent Quick Java &amp; C# Performance Comparison, from february this year, http://michael.alecti.com/archive/2005/02/15/624.aspx

How many times do I have to tell you. Individual blog resports don't prove anything, as you can cherry-pick personal experiences and opinions to prove anything.

Observer that C++ has the top result even when the C++ implementation was abysmal according to the author.

How many times do I have to tell you. Individual blog resports don't prove anything, as you can cherry-pick personal experiences and opinions to prove anything.

According to a major benchmarking exercise (LinPack), and NOT just one author, Sun's Java 1.4 beats C++ in some of the tests.

"The HotSpot source code is a bad joke" by Slava Pestov (jEdit author)http://www.jroller.com/page/slava/20050102" target="_blank" the Java runtime is so badly coded that its a wonder it works at all!

How many times do I have to tell you. Individual blog resports don't prove anything, as you can cherry-pick personal experiences and opinions to prove anything.

If you don't like Sun's code quality, use IBM's VM, or HP's clean room implementation.

What do I do if I don't like the code quality of .NET?

compile for deployment. So much more powerful!

Ruby does not compile. There is no stable non-beta compiler or VM for Ruby.

The InterSystems Australian Integration 2004-05 Report..NET is employed by about three in five organisations (61 per cent), with J2EE supported by about two in every five (42 per cent). http://australianit.news.com.au/articles/0,7204,12824901%5E15321%5E%5Enbv%5E15306,00.html

How many times do I have to tell you. Individual blog resports don't prove anything, as you can cherry-pick personal experiences and opinions to prove anything.
(If you have to resort to limiting your search to a country as small in population as Australia, you must be desperate).

How many of the .NET developer are simply using it client side as an upgrade to the abandoned Visual Basic? To say that .NET is competing with J2EE in that case is silly, as J2EE is server side.

Here are current UK Jobs from monster.com:

Java - (too many to show - far more than 1000)
C# - 582
VB.NET - 250

This is one of the more Microsoft-friendly countries (and hugely bigger than Australia).

Let's look at France:

Java - 569
C# - 98
VB.NET - 32

See what I have done? I have kept searching for a single site that backs up my opinion - fun, but not that meaningful.

You really do need something new..

Perhaps one of these days you will start to really understand how to use the internet to find information, rather than picking selected out-of-date quotes and figures that just support your point of view.

Here is a suggestion - learn about statistics and how to put forward a sensible argument. Saying: "Blah, Blah, Java bad [random link], Blah, Blah, .NET rules [random link]" is pointless.

Oh, and by the way, in France:

COBOL - 56

WOW! COBOL is beating VB.NET! I think we should all go for COBOL, as (1) it is mature, (2) is its portable, (3) it compiles, (4) it is changing FAR faster than Ruby (there are new standards out every few years - the last in 2002!), (5) It now has cool things like objects and function pointers. (6) it also runs fully on the JVM and .NET, and the (7) jobs are better paid!

There is no possible argument. COBOL is the future.

in 2006 I predict punch cards will come back and be "the language" for all future software development. I also predict the value of companies producing paper will go up. lumber companies will become the next IBM, Microsoft, Sun.

</joke>

sorry, couldn't resist.

peter

"According to a major benchmarking exercise (LinPack), and NOT just one author, Sun's Java 1.4 beats C++ in some of the tests."

Why do keep reporting this when I can see on my own computer that god written C++ is about 3 times faster than Java?. And that Java that can not even keep up with C#?

About the "The HotSpot source code is a bad joke".

Slava Pestov is not just anybody. He is author to jEdit for Gods sake!

If you have to resort to limiting your search to a country as small in population as Australia, you must be desperate. During the last year I have presented 20-30 Java-negative links, from all parts of the world mostly from US though, how come there never is any Java-positive links? I really do admire someone that can take so much bad news without loosing the good faith! ;)

"Here is a suggestion - learn about statistics"

No it is you that should learn about statistics.
If you had taken even one year statistics at the university you would know that if you keep all parameters constant, and if the underlying population is larger than a few hundred, the result is Statistically Significant. A professional term that means highly probable.

What it means is that you can not be sure of the absolute numbers, but the trend, the trend as in the "Yann Caroff index" - each month, relentless and inexorable, loosing
another percent to c#/.NET - that is statistically significant. But, no information in the world can sway a religious fanatic

Regards
Rolf Tollerud

java.rmi.RemoteException: EJB Exception: ; nested exception is: kodo.util.DataStoreException: weblogic.common.resourcepool.ResourceLimitException: No
resources currently available in pool TSSPool to allocate to applications, please increase the size of the pool and retry..

Again, sigh..When shall TSS learn to ditch Weblogic?

should read:

"If you have to resort to limiting your search to a country as small in population as Australia, you must be desperate."

During the last year I have presented 20-30 Java-negative links, from all parts of the world mostly from US though, how come there never is any Java-positive links? I really do admire someone that can take so much bad news without loosing the good faith! ;)

When I first read the EBJ specification it took me only 5 min to see that it was a piece of crap. What happened to people! What?

Why do keep reporting this when I can see on my own computer that god written C++ is about 3 times faster than Java?. And that Java that can not even keep up with C#?

Why do you keep reporting this when I can see on my own computer with various benchmarks that well written Java is about the same speed as C++?

What it means is that you can not be sure of the absolute numbers, but the trend, the trend as in the "Yann Caroff index" - each month, relentless and inexorable, loosing
another percent to c#/.NET - that is statistically significant.

No. That same index shows that J2EE is GROWING in numbers.

What is happening in IT?

1. Microsoft is retiring VB6 and earlier versions of Visual Studio.

2. The only upgrade for this within Microsoft technologies is .NET

3. The fastest growing server OS is Linux. This can't host Microsoft .NET.

Bearing this in mind, look at the actual jobs! What do they say? A large proportion of them want BOTH .NET and Java skills. Why? Because a significant amount of .NET use is client side, interacting with Java server side.

Any article that simply tries to compare ".NET and J2EE" should be viewed with caution because it is comparing different things. A large proportion of .NET is client-side VB.NET and C#, as a result of VB6 migration. J2EE is a pure server side system.

So what is happening? A large part of .NET growth is eating away at VB6 and client-side C++, percent by percent!

You really have very little idea about what people are actually doing in development, have you?

how come there never is any Java-positive links?

Either you have an inability to read, or an inability to remember, as you have actually posted in a thread that was highly Java positive:
http://www.theserverside.com/news/thread.tss?thread_id=30999

If you had taken even one year statistics at the university you would know that if you keep all parameters constant, and if the underlying population is larger than a few hundred, the result is Statistically Significant. A professional term that means highly probable.

By the way, I have taught statistics at degree level in a UK University. You are, as usual, misunderstanding. You don't just need to have a decent sample size, you need to take samples from different groups that are subject to different effects, and then perform a calculation such as Analysis of Variance in order to determine the significance of the effects.

Individual governments tend to have separate country-wide IT strategies, which can be for or against MS or Open Source to varying degrees. There are also general IT cultures in each country. How can you tell that there are such effects on IT use? Simply look at the ratios of different technology use - they are all different for different countries!

So, all you are doing by looking at IT jobs in Australia is reporting on IT jobs in Australia! Statistically, you can't extrapolate to other countries unless you have some measure of how IT strategies and preferences in other countries biases things relative to Australia. Its like sampling the weather of Australia and assuming that everywhere else in the world is hot and dry all the time.

Now do you understand?

But, no information in the world can sway a religious fanatic

You are evidence of that.

Go COBOL!

(sorry, could not resist one more post on this)

Yesterday:

Let's look at France:
Java - 569
C# - 98
VB.NET - 32
COBOL - 56

Today:

Java - 572
C# - 98
VB.NET - 32
COBOL - 57

Wow! Just since yesterday, COBOL has grown by nearly 2%. Extrapolate that over a year! The .NET languages are stagnant and dying! Look how COBOL is eating away at them, day by day!

Some may say that this is meaningless, and COBOL and .NET are used for different things. But I say tosh! That has never stopped experts like Rolf micro-analysing so-called 'meaningless' figures and comparing .NET with J2EE.

(OK, I'll stop now)

You really do need something new.

Heh. Old Rolf "broken record" Tollerud telling us we need something new. Is it supposed to be funny or sad?

Regarding "Strong typing, what a waste", it just proves people don't learn from past mistakes indeed.

Oh, something funny about Microsoft's unbelieveble code quality:
http://support.microsoft.com/kb/q173741/

Regards,
Henrique Steckelberg

As you will see in the following links there are not any particular bug(s) that's the problem, but the incompetence of Sun."The HotSpot source code is a bad joke" by Slava Pestov (jEdit author)http://www.jroller.com/page/slava/20050102 the Java runtime is so badly coded that its a wonder it works at all!

This was potentially interesting, so as someone who is interested in the facts, and not someone else's opinion, I checked his facts.

The "Hotspot Source" he mentions is nothing of the kind. What he is really reviewing is the huge codebase of the entire runtime. The hotspot system itself is a small section and is very clean. The rest of the comments are matters of personal opinion, and things are not as he seems to suggest. For example, so what if Sun uses a LISP dialect to deal with CORBA. This is called 'reuse'. Sun has been using CORBA for a very long time. They use their long-term CORBA tools (which use LISP) to help build the JRE. So what? He mentions two separate Regexp implementations. Well, the JRE contains code from apache (xerces). That has its own Regex implementation.

The JRE is a combination of technologies from various sources. Good software engineering is to leave fully-tested libraries from another source alone. This is not Sun writing the same thing twice - its how you make proper use of working code from different sources.

The JRE is a combination of technologies from various sources. Good software engineering is to leave fully-tested libraries from another source alone. This is not Sun writing the same thing twice - its how you make proper use of working code from different sources.

Sometimes it is not just a matter of good engineering: sometimes it is a matter of time! It would take too long to rewrite, test and fix everything. Reuse means less risks overall.

Regards,
Henrique Steckelberg

As you will see in the following links there are not any particular bug(s) that's the problem, but the incompetence of Sun."The HotSpot source code is a bad joke" by Slava Pestov (jEdit author)http://www.jroller.com/page/slava/20050102 the Java runtime is so badly coded that its a wonder it works at all!

This was potentially interesting, so as someone who is interested in the facts, and not someone else's opinion, I checked his facts. The "Hotspot Source" he mentions is nothing of the kind. What he is really reviewing is the huge codebase of the entire runtime. The hotspot system itself is a small section and is very clean. The rest of the comments are matters of personal opinion, and things are not as he seems to suggest. For example, so what if Sun uses a LISP dialect to deal with CORBA. This is called 'reuse'. Sun has been using CORBA for a very long time. They use their long-term CORBA tools (which use LISP) to help build the JRE. So what? He mentions two separate Regexp implementations. Well, the JRE contains code from apache (xerces). That has its own Regex implementation. The JRE is a combination of technologies from various sources. Good software engineering is to leave fully-tested libraries from another source alone. This is not Sun writing the same thing twice - its how you make proper use of working code from different sources.

we are talking to Rolf right, so he believes everything should be rewritten. Just like all those cobol system should be rewritten and replaced as Rolf likes to claim over and over again. Even though it makes no sense to replace existing systems running 24/7 with 99.999% reliability, he still loves to say cobol and mainframes are dead.

life is funny if you read rolf's posts as jokes

peter

No one understands how hard it is always being right..

Never do I get any sympathy!

No one understands how hard it is always being right..Never do I get any sympathy!

No is "always right". only crazy people believe they are always right. Don't take my word for it. Go ask a psychologist or a therapist.

you have to be a little insane to live in a crazy world.

Never do I get any sympathy!

Ok. I am sorry you are crazy. Can we recommend a psychiatrist?

Never do I get any sympathy!

Ok. I am sorry you are crazy. Can we recommend a psychiatrist?

But in case you are always right - there is an opening for an infallible person somewhere in Italy (let me check the religion job board).

Never do I get any sympathy!

Ok. I am sorry you are crazy. Can we recommend a psychiatrist?

But in case you are always right - there is an opening for an infallible person somewhere in Italy (let me check the religion job board).

Oh man, thanks for the laugh. Though I think there's really only one religious job opening right now in Italy.

peter

They are doing RoR in the .NET world too. Just not a simple port. Castle On Rails will use IOC, NHibernate, nIBATIS, nVelocity and is in short a much more extensive framework. The thing is that the main author, Hamilton Verissimo doesn't dismiss Ruby On Rails in the way TSS members in this thread do, "been done before", "nothing new" etc. No no he says, I quote,

"Every time some one approaches me with a new super framework that is supposed to be the new way of doing whatever, I turn on my ultra-skeptical mode. That's reasonable for everyone, and I had them turned on when I started to develop some application with Ruby and then was introduced to Ruby on Rails web framework. Few hours later, I was astonished. How can someone come up with such a great idea and didn't win the Nobel of Science?"

That was something along those lines I felt too.

That pretty well sums up the difference between the Java world and .NET as I see it. All things new immediately sets the Java camp in defensive position and the attack comes like an instinct, without any thought.

Read Introducing Castle - Part II
http://www.codeproject.com/csharp/IntroducingCastleII.asp

And you will see what I mean.

(Please don’t dismiss Hamilton in your usual way; he is a long time Java Open Source developer.)

Regards
Rolf Tollerud

Rolf,

Do you not get it? What was going on here is constructive criticism. Yes, the comments may have leaned on the shortcomings of ROR but those are things that ROR will have addressed to actually to be competitive.

Reverse the role Rolf…

Why should you choose .NET over ROR? Can’t PHP replace .NET?

I’m sure you would be you would come up with many of the same point people in this thread did.

The bottom line is J2EE is more then just building CRUD applications.

And believe it our not 99% of ideas are recycled with minor differences. Feel free to challenge that point.

They are doing RoR in the .NET world too. Just not a simple port. Castle On Rails will use IOC, NHibernate, nIBATIS, nVelocity and is in short a much more extensive framework.

I think you must seriously misunderstand the approach of RoR, which is 'no configuration files'. Castle on Rails looks interesting, but it is completely opposite from the RoR attitude. For example, Castle uses NHibernate, which uses XML configuration files. This is the very thing which is ridiculed by RoR developers!

In fact, a better description would be Castle NOT on Rails.

Castle looks interesting, but it is interesting because it takes a more mature approach to web application design and ORM, and not the amateurish quick-and-dirty approach of RoR. When you look at the Castle system, it is extremely close to what you would get if you combined Hibernate or JDO and JSF/Shale - same objects, same types configuration files, same sort of data structures! If you had tried JSF you would have already seen the advantages supposedly introduced by Rails, and implemented in Castle: A minimal controller object, and simple binding of views. JSF was designed better than ASP.NET, with an additional object layer ("backing beans") behind the equivalent of the WebForm, so JSF already has the advantages of Rails that he is has put into .NET with 'Castle'! The Struts Shale framework will add even more optional, easy-to-use controller features.

Even better, there are many design tools that allow you to build JSF applications, along with the controller structures and data binding, in a matter of seconds using drag-and-drop and visual tools. It is all the supposed structural advantages of Rails, but easy to modify, fast, portable and scalable. When Groovy is finally released, you will even be able to do all this using a dynamic scripting language! In fact I now rename JavaServer Faces 'Java on Rails'!

"How can someone come up with such a great idea and not win the Nobel Prize?"
Yes indeed.

You can say what you want Steve but I am not an idiot. I have also been working full time more that 20 years as an software developer, I am very interested in new technology and habitually download and play with new technology several times a week. I know very well the hype around Smalltalk, Haskell, Object Oriented databases etc etc and are not in least impressed. As a matter of fact I am not easily impressed!

But after only some hours with Ruby On Rails I was more than astonished, stunned is a better word. And that someone could come up with a completely new and fresh approach for the most crowded niche in contemporary IT!

That the Java camp reacted in so grumpy and parsimonious "not invented here" way is better proof that anything that the Java world has fallen totally into backwater, take my word for it.

Regards
Rolf Tollerud

Why don't you go back and have a long and soothing discussion about "persistence" again? It will calm your nerves. How you through EJB 3.0 hope to review the most idiotic invention of all time: "The Big Java Application Server".

Why don't you go back and have a long and soothing discussion about "persistence" again? It will calm your nerves. How you through EJB 3.0 hope to review the most idiotic invention of all time: "The Big Java Application Server".

It is very easy to spot when Rolf hits a wall in an argument: just wait for an inane EJB citation. Very funny indeed reading his posts. But changing subjects that often can be a sign of schizophrenia.

Have fun,
Henrique Steckelberg

What are you doing in the discussion?
You are young. You should spend your time with Ruby and Ruby On Rails. You don't want to grow prematurely old do you?

I firmly believe there is still hope for you.

Why don't you go back and have a long and soothing discussion about "persistence" again? It will calm your nerves. How you through EJB 3.0 hope to review the most idiotic invention of all time: "The Big Java Application Server".

This is the final proof that you don't read or understand anything of significance on these threads. I have a solid reputation as someone who has argued against major aspects of the EJB 3.0 specification. I support lightweight general-purpose, store-agnonistic POJO persistence as provided by JDO. I have tried to promote JDO 2.0, not JSR 220!

The funniest thing is that your most recently posted link (regarding Castle on Rails) supposedly in favour of RoR, explained the benefits of NHibernate, a version of Hibernate, which is one of the main influences on the design of... guess what? Yes! EJB 3.0!

Yes, you have excelled yourself. To back your arguments you have actually managed to post a link in favour of the design of EJB 3.0.

I give up. How can I possibly argue against you better than you are doing yourself?

"How can someone come up with such a great idea and not win the Nobel Prize?"Yes indeed.You can say what you want Steve but I am not an idiot. I have also been working full time more that 20 years as an software developer, I am very interested in new technology and habitually download and play with new technology several times a week. I know very well the hype around Smalltalk, Haskell, Object Oriented databases etc etc and are not in least impressed. As a matter of fact I am not easily impressed!But after only some hours with Ruby On Rails I was more than astonished, stunned is a better word. And that someone could come up with a completely new and fresh approach for the most crowded niche in contemporary IT!That the Java camp reacted in so grumpy and parsimonious "not invented here" way is better proof that anything that the Java world has fallen totally into backwater, take my word for it. RegardsRolf Tollerud

I think this debate ends here, because, as always, when you have exhausted all possible quotes and links, and when every example you try and put forward to back your argument only serves to contradict you, you resort to personal opinion and statements of what you want to believe.

There is nothing at all new in RoR. I have seen objects in dynamic languages generated from schemas more than a decade ago. I have seen automated generation of model, view and controller classes way before that. Furthermore, I have seen all that within fully-functional IDEs.

I love innovation in IT. I look forward with enthusiasm to high-performance dynamic languages which integrate well with other systems and libraries, and allow developers to code elegantly and rapidly. I eagerly await new paradigms in IT and new strategies for development. In many ways, 'traditional' languages like Java, C# and VB are deeply boring: I support the recently expressed point of view of a Microsoft IT chief who said that languages like Haskell should really be the way forward - you state your problem and let the machine work out the solution. I'm sure there going to be major advances in the way development is done in the near future. But, it's not going to be a OOP dialect of PERL with a horribly fragile ORM and primitive web app code generator! Given all the ways that IT should progress, considering something so insignificant to be important is laughable.

So, I can't respect the opinion of anyone who says they have decades of experience, and yet considers RoR to be 'stunning'. If you really did, you would have been able to answer the clearly expressed criticisms on this thread. You haven't, therefore I assume you can't, so I'm afraid I can't take your statements seriously. Whether you believe it or not (and I accept you might), I honestly believe you are simply spouting whatever is the latest anti-Java hype you encounter. This is illustrated by the fact that you are prepared to quote articles promoting .NET in one situation, and then articles rubbishing aspects of .NET in another, simply to put support your latest anti-Java rant.

Debating with you is a waste of time, as you refuse to accept or understand evidence or argument.

That the Java camp reacted in so grumpy and parsimonious "not invented here" way is better proof that anything that the Java world has fallen totally into backwater, take my word for it.

You're obviously confused again -- you'd never have heard of RoR except for the fact that so many in the Java community are interested in it. Dion Almaer, Bruce Tate, most of Thoughtworks, Brian McAllister and many others have made quite a fuss over it, culminating in RoR being discussed here (and thus you trying it out).

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

Oh no, obviously Rolf knew way, way before anybody else that RoR would hit us like a wave and that Java as doomed from the start (don't forget his crystal ball). He just waited for the proper moment to start yelling and waving hands at us, else nobody else would believe him!

Have fun,
Henrique Steckelberg

What is this nonsense about if I knew about RoR before or after it was presented in TSS?

Every week dozens of new frameworks and products are presented in TSS. By sheer coincidence, chance, luck whatever you call it, some real innovation also is presented.

Regards
Rolf Tollerud

It looks just like ASP.NET to me, so please tell us exactly how it really is "new". Personally... I's sooner use VS.NET2K3 and ASP.NET. Both use the approach to development. Or are you saying RoR is better than ASP.NET?

I've only read the articles and haven't tried it, so I'm not qualified to say with any accuracy RoR is better than ASP.NET. Since you have used ASP.NET, and you indicate you tried RoR, I'd be interested in a "detailed" comparison. By detailed comparison, I mean compare how RoR differs from VS.NET's ability to import Sql Server tables, generate a domain model and use that model in ASP.NET.

care to take the challenge?

peter

Peter I have very little time I have to go.

In the invention business, and I am not only speaking about software, we talk about a real invention when some core functionality is proven and works as expected. The rest is "ordinary engineer work". Obviously there is still a lot to do in that department.

Now we have a three-way-race, The orginal RoR, the Java Trails, and Castle for .NET. Which one will finish first or be the best? I am not willing to risk a guess.

But even if Java or .NET emerge as "winner", nobody can take away from the Ruby guys the credit - it was their invention. Also Naked objects should have part of the credit, they were on the right track but didn't follow through.

Regards
Rolf Tollerud

Peter I have very little time I have to go.In the invention business, and I am not only speaking about software, we talk about a real invention when some core functionality is proven and works as expected. The rest is "ordinary engineer work". Obviously there is still a lot to do in that department.Now we have a three-way-race, The orginal RoR, the Java Trails, and Castle for .NET. Which one will finish first or be the best? I am not willing to risk a guess.But even if Java or .NET emerge as "winner", nobody can take away from the Ruby guys the credit - it was their invention. Also Naked objects should have part of the credit, they were on the right track but didn't follow through.RegardsRolf Tollerud

I believe I gave them plenty of credit in several posts. But I would rather be honest about their achievements than blindly kiss their collective butts. You still didn't answer my question.

How is RoR "new" in comparison to VS.NET + ASP.NET. to my untrained eyes, it looks like VS.NET style of development. The screens look different obviously, and VS.NET looks much more polished as it should. MS has more resource than RoR, but RoR has managed to create something useful. I for one think it's great OSS is copying VS.NET style of development, even if I don't use that style in my day-to-day work.

peter

Peter,

I would love to do it but it is not any possible to have a serious discussion with Steve gone completely of his rockers... Some other time!

Peter, I would love to do it but it is not any possible to have a serious discussion with Steve gone completely of his rockers... Some other time!

Perhaps you would like to clarify?

I was making the point that RoR was not particularly innovative; that it was (probably unintentionally) re-inventing stuff that had been done years ago in other languages.

To prove this, I showed you a simple but powerful MVC web framework in a dynamic language (Smalltalk), and I show you an ORM system in that language (one of many that are available) that has equivalent features to ActiveRecord in RoR. Used together these frameworks are at least as powerful and full-featured as a system like Castle, and they were implemented years before RoR.

There may be certain features of Ruby you like, or you may prefer some particular aspects of the way Rails is implemented, but now there is no way you can argue that the majority of its features are anything particularly new.

But, perhaps, according to you, presenting a point of view and backing it up by actual evidence is 'off my rocker', but I suspect that is merely what you classify anyone who does not go along with your point of view. It is your last resort when you can no longer debate any other way.

We might consider how to view someone who makes hilarious statements like Ebay being 'the most expensive project in IT history', and also argues furiously against EJB 3.0, then declares Trails and Castle the way forward, which both use Hibernate!

I would consider being called 'off my rocker' by someone like that solid evidence of my robust sanity.

It is your last resort when you can no longer debate any other way.We might consider how to view someone who makes hilarious statements like Ebay being 'the most expensive project in IT history', and also argues furiously against EJB 3.0, then declares Trails and Castle the way forward, which both use Hibernate!I would consider being called 'off my rocker' by someone like that solid evidence of my robust sanity.

I find that debating with Rolf you have to remember his experience is very limited. If he thinks Ebay is the most expensive IT project, he needs to look at what the US military and government spends on IT. It makes EBay look tremendously efficient. One can measure EBay's IT budgets in the millions. Military and government IT budgets range in the billions with a big fat "B". Just look at the FBI fiasco reported last month.

Building software in large institutions for really large global systems is so different that Rolf has no clue how it works. It's not his fault though, if I didn't see it for myself, or work with people who have built those systems, it would be very hard to comprehend. Between 1995 and 2005, CSC has been the recipient of over 200Billion dollars worth of IT contracts. It ranges from the mundane like installing and managing the email system, to complex real-time systems like building command control system. The techniques which Rolf loves so much for "small-ish" projects do not work in these cases, because the requirements are completely different. Not only that, the process of ordering hardware and software often take 8-12 months. Making a purchase often requires filling out 20 different forms. If the vendor drops their price, the order most likely won't go through. Which means you have to fill out the paper work again and ask the vendor to charge the quoted price, regardless of whether or not the price has been reduced.

When Rolf makes personal attacks, just take it as a compliment. It means you've really frustrated him :)

peter

The techniques which Rolf loves so much for "small-ish" projects do not work in these cases, because the requirements are completely different.

Indeed. I have personally seen even smallish projects collapse messily under the weight of load and complexity when others have used Rolf's type of approach!

When Rolf makes personal attacks, just take it as a compliment. It means you've really frustrated him :)peter

Thank you, Peter. I had assumed this was the case. I expect you are now probably in Rolf's firing line after your accurate analysis... !

The techniques which Rolf loves so much for "small-ish" projects do not work in these cases, because the requirements are completely different.

Indeed. I have personally seen even smallish projects collapse messily under the weight of load and complexity when others have used Rolf's type of approach!

When Rolf makes personal attacks, just take it as a compliment. It means you've really frustrated him :)peter

Thank you, Peter. I had assumed this was the case. I expect you are now probably in Rolf's firing line after your accurate analysis... !

he criticizes me often, so it's all good. It's fun to challenge Rolf with real technical questions. I've yet to see him really respond with solid technical answers. I don't know why he takes his position on certain issues, but it's rather comical. Usually, when he is defeated with facts, he leaves for a while. Then eventually, he comes back and starts the same game again. My own area of focus is very narrow, but I atleast realize my limitations. Rolf isn't really bad, he's just a bit eager to be "right".

peter

I've yet to see him really respond with solid technical answers.

He does tend to respond with links and quotes and blog entries that can seem solid at first sight, and I can imagine some novice developer or non-IT-literate manager browsing his posts and seeing some report on the growth of Windows server sales, or a comment about the state of J2EE, and not realise that the former may have been only for some small region of the world, and the latter may have been from 5 years ago. I have personally seen managers and developers with a certain agenda selectively quote FUD like this, so I am motivated to try and counteract it.

I don't know why he takes his position on certain issues, but it's rather comical.

I'm sure Rolf can speak for himself, but I have encountered others with a similar attitude and in those cases it has been because they did not want to face the realities of some types of development - that it can't all be done with quick scripts and Visual Studio. Sometimes you need heavy engineering and 'big elephant servers'(?) to handle the load. I have seen people with this attitude do really dumb things, like replace large corporate mainframes with Windows servers, and when, inevitably, the system started to break they discovered what 'scalability' really meant when simply adding more Windows boxes to the system had no effect. I fully expect people like this to insist that large corporate websites should be re-written with RoR.

Usually, when he is defeated with facts, he leaves for a while. Then eventually, he comes back and starts the same game again.

Perhaps a sufficient back-catalogue of quotes and statements is building up so that when the game starts to be played again, anyone who wants to can provide a rapid rebuttal to the FUD.

My own area of focus is very narrow, but I atleast realize my limitations. Rolf isn't really bad, he's just a bit eager to be "right".peter

Well, that is common; I would admit to suffering from that to a degree. I guess what matters is when (or if?) someone is prepared to change their mind in the face of evidence.

"In the work of the greatest of geniuses humble beginnings will reveal themselves somewhere--but one cannot trace the slightest sign of them in Shakespeare"
Sir Charles Chaplin in his Autobiography (1964)

Well it was lucky for him, Shakespeare - not Chaplin, that it was not Steve that was the one to comment on him!

Regards
Rolf Tollerud

"In the work of the greatest of geniuses humble beginnings will reveal themselves somewhere--but one cannot trace the slightest sign of them in Shakespeare"Sir Charles Chaplin in his Autobiography (1964)Well it was lucky for him, Shakespeare - not Chaplin, that it was not Steve that was the one to comment on him!RegardsRolf Tollerud

Yes, because I never studied English literature. I would certainly list an inability to critically judge Shakespeare (or 'Shaksper' as he is more authentically named) as one of my many flaws. However, this is probably a good thing, as there was probably not much employment in IT in those days.

Incidentally, did you know that COBOL is still eating away at VB.NET, percent by percent?

offres.monster.fr:

VB.NET: 32 (+0%)
COBOL: 59 (+3.5%)

<7>"The techniques which Rolf loves so much for "small-ish" projects do not work in these cases, because the requirements are completely different"

You mean:

Rich Clients that handles the state at the client and at the server "a mix of dual or quad processor servers running Windows Server 2003 advanced edition with 4 GB RAM and 64bit CPU supporting a cluster of databases",

..that can handle anything that The Big Java Server can, without the 70-80% failure rate and ridiculous uptime.

One of the reasons for that being that the .NET CLR doesn't have a lots of holes in it, like the Java VM.

Sorry.

I am saving my Java vs C# numbers until next month, the 9th in every month remember? Don't forget to save your COBOL vss VB.NET numbers every month so we can compare!

Best regards
Rolf Tollerud

<7>"The techniques which Rolf loves so much for "small-ish" projects do not work in these cases, because the requirements are completely different"You mean:Rich Clients that handles the state at the client and at the server "a mix of dual or quad processor servers running Windows Server 2003 advanced edition with 4 GB RAM and 64bit CPU supporting a cluster of databases", ..that can handle anything that The Big Java Server can, without the 70-80% failure rate and ridiculous uptime. One of the reasons for that being that the .NET CLR doesn't have a lots of holes in it, like the Java VM.

We have reached the dizzy heights of Rolf's 3rd stage of argument.

Stage 1. Shows links that look reasonable but turn out to be statistically or logically invalid.
Stage 2. Change the subject and show links which have nothing to do with the argument.
Stage 3. Just quote personal opinion and no evidence.
Stage 4. Personal insults.

Sorry.I am saving my Java vs C# numbers until next month, the 9th in every month remember? Don't forget to save your COBOL vss VB.NET numbers every month so we can compare!Best regardsRolf Tollerud

Oh dear. I'll let you into a secret. The COBOL figures were intended to indicate the nonsense of such comparisons. You are misunderstanding statistics again; specifically the matter of correlation vs. causuality. Unless you can show direct evidence that part of the change in the use of product A is causually related to a change in the use of product B, a comparison cannot be made.

Let's look at why.

Firstly, you have to demonstrate that the total numbers of A+B are are some way constrained so that a change in A or B must to some extent be at the expense of the other. You also have to determine the degree to which A and B overlap in use. If there are uses to which A can be put that B can't, or vice versa, there is yet another unknown mathematical factor which can invalidate comparisons. Finally, you have to show that a changes in A or B are not forced by other factors other than competitiveness with each other.

If, for example, we say that A is .NET and B is J2EE, these conditions do not apply:

Firstly, A is constrained by price and OS, B is not to the same extent. It is not an either/or choice, so both A and B can grow without all or part of that growth being at the expense of the other. Actually there is one type of growth that goes against this - an increase in deployments of server applications on non-MS platforms, as MS .NET is not available there.

Secondly, there is a degree of lack of overlap of use. Different uses of Java have different labels: J2EE, J2SE, J2ME. In a decision of marketing genius, Microsoft labels all uses of their technology as .NET. This means that some .NET use appears to be competing with J2EE, but it isn't because it is client-side. The true comparison is between .NET and Java as a whole, not .NET and J2EE.

Thirdly, there is a forcing factor in .NET use, at least client side, which is the retirement of VB6.

Even if you are comparing more appropriate things, such as .NET vs Java, and all the above requirements where met, using figures of growth alone don't show anything quantitative, as in order to show how much one is 'eating away' at another, you would have to have hard evidence of what the figures of one would have been without the other. You need, as we call it in statistics, the 'control'. Unless you have the control estimates you can't even have any idea of what you are really comparing; you are making a statement that is as vague as: 'one thing happened, and something else happened, therefore I conclude...'

The only way any sense of what is really happening could be obtained would be to regularly interview a statistically correct sample of thousands of developers (not just Australians, for example) and question them in detail about their technology choice, and the motives for it, then follow the results over a period of a year or two.

Anything else is "full of sound and fury, signifying nothing" (Shaksper).

Now do you understand? Did you really believe that COBOL and VB.NET were actually competing? (Actually, they might be, but how can we tell?)

(And even then, why would all this matter? Since when has popularity been a measure of quality? If you want to use .NET or J2EE, use them)

Steve!

I am sure that your statistical explanation also would have been accepted at the conference! Why don't you send it in?

You were so gracious. Many things were explained to me that I didn't know before!

Thank you
Rolf Tollerud

Steve!I am sure that your statistical explanation also would have been accepted at the conference! Why don't you send it in?You were so gracious. Many things were explained to me that I didn't know before!Thank youRolf Tollerud

Bother, I missed a stage:

Stage 1. Shows links that look reasonable but turn out to be statistically or logically invalid.
Stage 2. Change the subject and show links which have nothing to do with the argument.
Stage 3. Just quote personal opinion and no evidence.
Stage 3a. Sarcasm.
Stage 4. Personal insults.

Of course, I am not trying to teach you anything. I am trying to help you make your point by indicating the evidence that you might want to include to help put your case more effectively.

I'm sure you do have this evidence. I'm sure you would not just post comments like '.NET is eating away at Java' unless you had a solid statistical basis for doing so, which you can explain to us all.

(If you can't, don't worry, it's not just you - invalid extrapolation and drawing conclusions drawn insufficient evidence is common practice).

"If you can't, don't worry, it's not just you - invalid extrapolation and drawing conclusions drawn insufficient evidence is common practice)"

Ok, I am willing to buy anything you say. The only thing is I want to know.

For over 2 years now, every months another shift, always in the same direction. And though the total nr of jobs can change very much, (any month there can be 1000 jobs more or less than previously month), the percent relationship between Java and C# always stays the same (except for the little shift). What does it mean?.

So I am willing to accept any theory except that it is a coincidence, that one I don't buy. Otherwise I listen to anything with an open mind.

And by the way, the reason I did not choose monster.com was:
1) For the first Yann’s result was from the British site and,
2) At monster.com they have this rule that they don’t show more that 1000 hits.

Regards
Rolf Tollerud

For over 2 years now, every months another shift, always in the same direction. And though the total nr of jobs can change very much, (any month there can be 1000 jobs more or less than previously month), the percent relationship between Java and C# always stays the same (except for the little shift). What does it mean?

If the percent relationship stays true, this probably indicates a largely pure multiplicative relationship without any additions or subtractions. If Java was directly eating away at C# jobs, or vice versa, you could not have a constant ratio (unless you invoke another coincidence - that Java and C# are subtracting from each other at exactly the right proportions each time).

However, what do we mean by 'relationship'?

One possible suggestion of what might be happening is that for each project, all developers are making a choice between Java and C#, and the same fraction choose one technology each time. However, this can't work, as Java and C# don't fully overlap in use: Java is more used server side (and runs on more platforms there), and C# is more used client side. The range uses are too complex for a single constant choice ratio to be maintained.
 
The most likely interpretation, I would suggest, is the most boring one - there is not a significant amount of interaction. People who are going to use Microsoft products generally keep using Microsoft products, and tend not to be converted. Developers who don't use Microsoft products stay not using them and also aren't likely to change their minds, and both C# and Java are experiencing independent growth in expanding markets. Interestingly, this explanation works best if both are still in the uptake phase, with both growth and replacement of older technologies being important - neither C# or Java are anywhere near being 'legacy'.

Rolf, you forgot to quote someone famous in your previous post.

<7>"The techniques which Rolf loves so much for "small-ish" projects do not work in these cases, because the requirements are completely different"
You mean:

Rich Clients that handles the state at the client and at the server "a mix of dual or quad processor servers running Windows Server 2003 advanced edition with 4 GB RAM and 64bit CPU supporting a cluster of databases", ..

that can handle anything that The Big Java Server can, without the 70-80% failure rate and ridiculous uptime. One of the reasons for that being that the .NET CLR doesn't have a lots of holes in it, like the Java VM. Sorry.
I am saving my Java vs C# numbers until next month, the 9th in every month remember? Don't forget to save your COBOL vss VB.NET numbers every month so we can compare!
Best regards
Rolf Tollerud

How are you going to handle real-time data for a military command control system? In a rich client? That's a rather simplistic explanation for something very complex. Do you have any clue the amount of data command control systems handle and how quickly the data changes. Data streams come from numerous radars, satellites and other monitoring devices.

So with the system above, how are you going to handle 10K real-times message per second and make sure several thousand servers and client systems get the data in a timely manner? No one in their right mind would make such a bold statement. Windows 2K3 server has nothing to do with it. The OS is the least of your worries. 4GB of RAM is nothing for these kinds of system. Many large systems have in-memory cache ranging from 10-30Gb. The data is constantly changing and managing those changes requires completely different techniques.

The UI is one tiny piece of the puzzle. Keep on believing what you want. I challenge you to setup a win2K3 server with 4GB of ram and handle a constant stream of 50-60Kb message at a rate of 500 per second 24/7. In fact, go ask microsoft if that is possible with a quad CPU server.

Do you even know what kind of storage is needed to handle this tiny case? Now scale it up 10x and tell me the same techniques still work.

peter

Please Peter,

Let us stop this nonsense and put matters into perspective! I am not interested in the destruction of human lives so as it is. Come down to earth.

To tell the truth I am envious of salesforce.com and think I can do better.

If we can say that the real matter boils down to: "What is the best way to build a hosted CRM system"?

Some of the things we have to take into account is:

1) The application is way off more complicated than the normal Java J2EE app.
2) Life and death depends on the user interface.
3) We don't need military performance but still, it needs to support thousands of simultaneously users

If we can keep to these stipulations, then we have some more meat on the bones so to speak. And IMO, the best Price/Performance way to do it is:

Rich Clients that handles the state at the client and at the server "a mix of dual or quad processor servers running Windows Server 2003 advanced edition with 4 GB RAM and 64bit CPU supporting a cluster of databases".

As I said.

Regards
Rolf Tollerud

Please Peter, Let us stop this nonsense and put matters into perspective! I am not interested in the destruction of human lives so as it is. Come down to earth.To tell the truth I am envious of salesforce.com and think I can do better. If we can say that the real matter boils down to: "What is the best way to build a hosted CRM system"? Some of the things we have to take into account is:1) The application is way off more complicated than the normal Java J2EE app.2) Life and death depends on the user interface.3) We don't need military performance but still, it needs to support thousands of simultaneously users If we can keep to these stipulations, then we have some more meat on the bones so to speak. And IMO, the best Price/Performance way to do it is:

Rich Clients that handles the state at the client and at the server "a mix of dual or quad processor servers running Windows Server 2003 advanced edition with 4 GB RAM and 64bit CPU supporting a cluster of databases".

As I said.
Regards
Rolf Tollerud

So what you're saying here is all of your arguments are based on CRM. Is that really the case. Do you really believe that everything works like a CRM? Salesforce is cool and all, but they are hardley the end of the world for IT development. CRM doesn't even cover things like inventory management, accounting systems, and dozens of other types of applications. CRM is just one very narrow topic in the world of information technology. I've build simple CRM tools for tracking support incidents, generating reports and tracking open issues. CRM can get very complex very quickly, but it does not represent the majority of what programmers are working on.

Have you ever setup a cluster of partitioned databases and had to replicate data? Do you know the pros/cons of each replication mode Sql Server offers. I doubt you've ever had to write a sql query that connected to a remote database from one sql server to another server. Feel free to prove me wrong by providing real details. I've spent a lot of time learning these techniques and figuring out how to apply them. Reading someone's blog or PR material doesn't mean you know heads from tails about how database clustering works.

peter

CRM is just one very narrow topic in the world of information technology. I've build simple CRM tools for tracking support incidents, generating reports and tracking open issues. CRM can get very complex very quickly, but it does not represent the majority of what programmers are working on.

I hope you don't mind me joining in, Peter, as also I have personal experience of developing both CRM and public websites. CRM is usually a fundamentally different environment, where you can precisely control aspects such as the workstation environment, the network topology and traffic etc. For this situation, rich clients are a reasonable solution, although I prefer web-based interfaces (trainees who might get nervous with a stand-alone app always seem immediately comfortable when presented with a web page, and it also solves deployment issues).

Rich clients are hopelessly innapropriate for public websites, with the wide range of browser capabilities, versions, and network speeds.

Yet again, one of Rolf's quick-fix 'everything is easy' strategies proves to be lacking...

CRM is just one very narrow topic in the world of information technology. I've build simple CRM tools for tracking support incidents, generating reports and tracking open issues. CRM can get very complex very quickly, but it does not represent the majority of what programmers are working on.

I hope you don't mind me joining in, Peter, as also I have personal experience of developing both CRM and public websites. CRM is usually a fundamentally different environment, where you can precisely control aspects such as the workstation environment, the network topology and traffic etc. For this situation, rich clients are a reasonable solution, although I prefer web-based interfaces (trainees who might get nervous with a stand-alone app always seem immediately comfortable when presented with a web page, and it also solves deployment issues). Rich clients are hopelessly innapropriate for public websites, with the wide range of browser capabilities, versions, and network speeds. Yet again, one of Rolf's quick-fix 'everything is easy' strategies proves to be lacking...

feels like a three person conversation, kinda fun. it draws out little bits and details about exactly what Rolf does work on. the more bits he reveals shows how little he actually knows. The people I know with 20-25 years of experience have 100x more knowledge and expertise than Rolf. I don't mean to be spiteful or mean, but after 20 years of programming experience, I would think a programmer would know much more and be able to answer technical questions easily. I keep asking Rolf simple questions that a decent senior developer would know and yet he still can't answer them. either he feels it's beneath him to answer the question, or he doesn't know the answer. We'll never know which case it is.

peter

What do you think you win by question my competence? We are discussing Java vs .NET, nothing else. If you believe I feel intimidated think again! I am an ordinary software developer with 20 year’s experience, as such not a star - but above average or so I like to believe.

"The people I know with 20-25 years of experience have 100x more knowledge and expertise than Rolf"

Only 100x more knowledge and expertise you say?

However I do shine in one area! I have the best first-class bullshit filter! But after the last posts from you and Steve it overloaded and almost burned out! That has not happened since I read the first EJB specification. (the one that Cameron says was done by aliens from other space..).

Please wait a few days and read everything again. Anything more lacking in orderly, continuity, arrangement or relevance I have yet to see. Inconsistent, no clarity, no intelligibility, totally incomprehensible, etc etc

If my bullshit filter is broke I am going to charge you!

Best Regards
Rolf Tollerud

I do shine in one area! I have the best first-class bullshit filter! But after the last posts from you and Steve it overloaded and almost burned out!

A nice combination of:

Stage 3. Just quote personal opinion and no evidence.
and
Stage 4. Personal insults.

But Steve,

What do you think would happen if I put together your little statistics-treatise on a a4 paper and passed it around?

No big deal, it happens "in the heat of the battle". Please show a little humor and self-irony!