YARJC: Yet another Rails vs. Java Comparison

Home

News: YARJC: Yet another Rails vs. Java Comparison

  1. 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.

    Threaded Messages (331)

  2. Why is this here?[ Go to top ]

    I'm starting to wonder if that April fools day article was a joke, or a prediction?
  3. +1
  4. Domain Specific Frameworks[ Go to top ]

    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.
  5. One thing this proves...[ Go to top ]

    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]
  6. re: One thing this proves...[ Go to top ]

    getters and setters are a serious overhead that is
    > killing our projects

    Do you really mean this? 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.

    If lines of code is the new my balls are bigger metric then i would rather be a woman.
  7. re: One thing this proves...[ Go to top ]

    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.
  8. What about using a good IDE?[ Go to top ]

    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!
  9. re: One thing this proves...[ Go to top ]

    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.
  10. number of dead brain cells[ Go to top ]

    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>
  11. number of dead brain cells[ Go to top ]

    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.
  12. number of dead brain cells[ Go to top ]

    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).
  13. 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
  14. 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.
  15. That's a really nice quote. I'll have to remember that.
  16. Isn't Justin Gehtland suspicious?[ Go to top ]

    Bought by Microsoft I say!
  17. 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.
  18. 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
  19. Ruby is a good language[ Go to top ]

    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
  20. Ruby is a good language[ Go to top ]

    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.
  21. ... 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.
  22. 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.
  23. right[ Go to top ]

    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.
  24. "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
  25. the urban myth department, again[ Go to top ]

    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.
  26. "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.
  27. the urban myth department, again[ Go to top ]

    "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 ...]
  28. "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
  29. the urban myth department, again[ Go to top ]

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

    Isn't that how they make sausages ?

    Kit
  30. Contradicting yourself[ Go to top ]

    "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 ....
  31. choice is what matters to me[ Go to top ]

    "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
  32. 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.
  33. Ruby is a good language[ Go to top ]

    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. :)
  34. 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.
  35. 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."
  36. 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.
  37. 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.
  38. 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.
  39. 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?
  40. 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?
  41. 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.
  42. 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.
  43. 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."
  44. 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.
  45. 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.
  46.  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. :-)
  47. 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.
  48. 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).
  49. 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!
  50. great points[ Go to top ]

    .. 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.
  51. beautiful done[ Go to top ]

    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
  52. beautiful done[ Go to top ]

    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
  53. beautiful done[ Go to top ]

    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!)
  54. beautiful done[ Go to top ]

    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?!?
  55. beautiful done[ Go to top ]

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

    Ah, yes, I should read more carefully... ;)
  56. 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.
  57. 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
  58. 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? ;)
  59. https://trails.dev.java.net
  60. 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)
  61. 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.
  62. 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)
  63. 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! :-)
  64. What is wrong with that? I didn't see any handwaving :-)
    ... which proves it worked.

    --
    Cedric
  65. 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
  66. 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.
  67. 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
  68. 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.
  69. 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.
  70. ...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.
  71. 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.
  72. So when does a framework stop being lightweight? 123k? 503k?

    By god Cedric you do have a fetish for 3 right there.
  73. 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.
  74. 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.
  75. 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.
  76. 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.
  77. 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?
  78. 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.
  79. 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.
  80. 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.
  81. 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.
  82. 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.
  83. 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">
  84. <ww:property value="#item.some.nested.property" />
  85. </ww:iterator>

    Rails:
    <% for item in @collection do %>
  86. <%= item.some.nested.property %>
  87. <% 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)
  88. 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">
  89. <ww:property value="#item.some.nested.property" />
  90. </ww:iterator>Rails:<% for item in @collection do %>
  91. <%= item.some.nested.property %>
  92. <% 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.
  93. 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.
  94. I said. show me a EJB case[ Go to top ]

    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
  95. I said. show me a EJB case[ Go to top ]

    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.
  96. blah blah blah[ Go to top ]

    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
  97. Scalability and RAS, blah blah blah[ Go to top ]

    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?
  98. dy[ Go to top ]

    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'!
  99. I said. show me a EJB case[ Go to top ]

    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.
  100. I said. show me a EJB case[ Go to top ]

    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.
  101. It is not a java thing[ Go to top ]

    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
  102. It is not a java thing[ Go to top ]

    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.
  103. we are halfway there[ Go to top ]

    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
  104. we are halfway there[ Go to top ]

    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
  105. my work is done[ Go to top ]

    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
  106. we are halfway there[ Go to top ]

    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.
  107. 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
  108. 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.
  109. 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.
  110. 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
  111. 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.
  112. 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.
  113. 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.
  114. exactly what VS.NET does[ Go to top ]

    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
  115. exactly what VS.NET does[ Go to top ]

    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.
  116. 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.
  117. 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.
  118. you never cease to be amazed[ Go to top ]

    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
  119. you never cease to be amazed[ Go to top ]

    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.
  120. 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
  121. Yet more promises[ Go to top ]

    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.
  122. 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
  123. 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.
  124. Steve, you are hopeless[ Go to top ]

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

    Madre Mia
    Rolf Tollerud
  125. Steve, you are hopeless[ Go to top ]

    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.
  126. Steve, you are hopeless[ Go to top ]

    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.
  127. "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
  128. P.S.[ Go to top ]

    Tomorrow we shall se how RoR handle AJAX!
  129. P.S.[ Go to top ]

    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.
  130. listen to the opposition[ Go to top ]

    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
  131. more envy from Python country[ Go to top ]

    "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
  132. more envy from Python country[ Go to top ]

    "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.
  133. listen to the opposition[ Go to top ]

    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.
  134. listen to the opposition[ Go to top ]

    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.
  135. Can it get any worse?[ Go to top ]

    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?
  136. "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.
  137. I'll be back![ Go to top ]

    "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) ?
  138. I'll be back![ Go to top ]

    "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?
  139. Steve, you are confused[ Go to top ]

    "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
  140. P.S.[ Go to top ]

    The whole setup which you describe is a mess.
  141. Rolf, you are repetetive.[ Go to top ]

    "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").
  142. 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
  143. not invented by us[ Go to top ]

    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
  144. not invented by us[ Go to top ]

    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
  145. not invented by us[ Go to top ]

    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?
  146. 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")
  147. the best of all![ Go to top ]

    An open, friendly community with nice and easygoing people.

    Not like the Java world.
  148. the best of all![ Go to top ]

    An open, friendly community with nice and easygoing people.Not like the Java world.
    Are they Ninjas too? I love ninjas!
  149. 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?
  150. "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
  151. Wrong so many times[ Go to top ]

    "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!
  152. Which parser you talking about?[ Go to top ]

    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
  153. flexing out muscles[ Go to top ]

    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
  154. Sorry, just wanted to improve the title!
  155. am I suppose to read your mind[ Go to top ]

    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
  156. am I suppose to read your mind[ Go to top ]

    "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
  157. you're too funny[ Go to top ]

    "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
  158. you're too funny[ Go to top ]

    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.
  159. thank god others aren't as lazy as me[ Go to top ]

    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
  160. thank god others aren't as lazy as me[ Go to top ]

    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!
  161. here are the votes from the Sweden[ Go to top ]

    (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
  162. P.S[ Go to top ]

    It is not enough to program in C++, you have to be good at it too..
  163. here are the votes from the Sweden[ Go to top ]

    (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.
  164. can't download the file[ Go to top ]

    (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
  165. can't download the file[ Go to top ]

    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.
  166. (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.
  167. 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
  168. 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
  169. Which orignal 4meg file, but with start time moved

    java
    562
    578
    578
    578
    579
    562

    C#
    578
    578
    578
    578
    578
    578
  170. 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
  171. 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
  172. 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."
  173. some perspective[ Go to top ]

    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
  174. some perspective[ Go to top ]

    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 :)
  175. C++ rules, Java move too slowly[ Go to top ]

    "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
  176. correction[ Go to top ]

    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
  177. ?[ Go to top ]

    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
  178. COBOL is King, Ruby is dead[ Go to top ]

    "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!
  179. ?[ Go to top ]

    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.
  180. hey, I never claimed to be coherent[ Go to top ]

    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
  181. COBOL R00LZ[ Go to top ]

    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.
  182. 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
  183. "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?
  184. P.S. correction[ Go to top ]

    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?
  185. I'm a COBOL believer![ Go to top ]

    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!
  186. COBOL R00LZ[ Go to top ]

    (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)
  187. 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
  188. C++ rules, Java move too slowly[ Go to top ]

    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.
  189. 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
  190. Rolf won't believe you[ Go to top ]

    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
  191. poor me![ Go to top ]

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

    Never do I get any sympathy!
  192. isn't that what crazy people say?[ Go to top ]

    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.
  193. poor me![ Go to top ]

    Never do I get any sympathy!
    Ok. I am sorry you are crazy. Can we recommend a psychiatrist?
  194. poor me![ Go to top ]

    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).
  195. Doh![ Go to top ]

    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
  196. Castle On Rails[ Go to top ]

    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
  197. Castle On Rails[ Go to top ]

    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.
  198. Castle NOT On Rails[ Go to top ]

    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'!
  199. the "not invented here" syndrom[ Go to top ]

    "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
  200. P.S.[ Go to top ]

    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".
  201. P.S.[ Go to top ]

    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
  202. Henrique?[ Go to top ]

    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.
  203. Rolf supports EJB 3.0[ Go to top ]

    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?
  204. the "not invented here" syndrom[ Go to top ]

    "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.
  205. the "not invented here" syndrom[ Go to top ]

    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!
  206. 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
  207. 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
  208. seriously, how is it new?[ Go to top ]

    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
  209. 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
  210. 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
  211. 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!
  212. 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.
  213. limited experience[ Go to top ]

    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
  214. limited experience[ Go to top ]

    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... !
  215. yeah, but I don't mind[ Go to top ]

    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
  216. yeah, but I don't mind[ Go to top ]

    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.
  217. Steve the critic..[ Go to top ]

    "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
  218. yeah, but I don't mind[ Go to top ]

    "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%)
  219. <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
  220. The coup de grace[ Go to top ]

    <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)
  221. now I know all about statistics[ Go to top ]

    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
  222. now I know all about statistics[ Go to top ]

    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).
  223. "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
  224. 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'.
  225. Rolf, you forgot to quote someone famous in your previous post.
  226. Not quite[ Go to top ]

    <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
  227. Not quite[ Go to top ]

    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
  228. So basically[ Go to top ]

    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
  229. So basically[ Go to top ]

    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...
  230. human nature[ Go to top ]

    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
  231. I do have one secret weapon, though[ Go to top ]

    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
  232. 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.
  233. good entertainment[ Go to top ]

    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!
  234. Go ahead[ Go to top ]

    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!

    Please go ahead. I have posted it already on a public forum. If you can't come up with counter-arguments, you are welcome to ask others to help you. If you still don't understand about sampling and taking different factors into account, I can recommend some good books.
  235. No one said EJB, duh![ Go to top ]

    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 years 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 etcIf my bullshit filter is broke I am going to charge you!
    Best Regards
    Rolf Tollerud

    give me a break, I'm not trying to intimidate you. that would be a pointless exercize. I don't expect you to answer with real facts or techniques. You'd have to answer the challenge directly for it to be intimidation.

    I didn't bring up EJB, nor did I claim it has to be done with EJB. The blunt truth is. the people I know with 20-25 yrs of experience are way out of my realm and yours. It's purely luck that I've had a chance to work with these individuals. I don't understand your illogical hatred of EJB. It's a tool, if you don't like, use another tool. but not all tools are appropriate for all jobs.

    I'll be happily surpised the day you answer direct technical questions with solid facts.

    enjoy

    peter
  236. what is interesting and what is not[ Go to top ]

    "I'll be happily surpised the day you answer direct technical questions with solid facts."

    The only technical questions you are concerned with are how to set up the server to take as big load as possible.

    If I keep state at the client and the server is "stateless" I don't need to concern me about the server at all. The only thing I need to do is to lift the phone and order it. The server configuration and setup has nothing to do with my application. Of course I am careful to tax the server a little, I carefully plan my cache-policy, but otherwise I don't regard server configuration and setup as belonging to the area of programming at all, it is another type of knowledge - an area that does not interest me.

    If you ask me about software development that's a other thing - something that is interesting!

    Regards
    Rolf Tollerud
  237. If I keep state at the client and the server is "stateless" I don't need to concern me about the server at all.

    How do you keep the state at the client if you have guarantee of what the client is?

    Please describe how you would do this with the following range of browsers:

    Mozilla 6, IE 6, IE 5 (as on MacOS), Opera and IE4 (on older, but still used, Windows versions).

    This client-side state also has to work without cookies, Javascript, on low-bandwidth connections, and it has to be back-button safe.
  238. I doubt Rolf can answer[ Go to top ]

    If I keep state at the client and the server is "stateless" I don't need to concern me about the server at all.
    How do you keep the state at the client if you have guarantee of what the client is?Please describe how you would do this with the following range of browsers:Mozilla 6, IE 6, IE 5 (as on MacOS), Opera and IE4 (on older, but still used, Windows versions).This client-side state also has to work without cookies, Javascript, on low-bandwidth connections, and it has to be back-button safe.

    Based on what I've read of Rolf's response, he isn't dealing with large or medium datasets. If the data is less than 100K rows of data, than sure, load up the data in a Rich client. It's not a big deal. Heck, you can even go as high as 500K rows if you make sure all the workstations running the Rich client have 1-2Gb of ram. Also, if that data doesn't change and no one needs to be notified of changes, I see no problems with loading all the data in a Rich client.

    Once the dataset is over 500K and changes need to propogate to all active sessions, Rolf's approach breaks horribly. At that point, you have to completely rewrite the application and throw 80% of the code away. But I'm sure Rolf will have a magic bullet for making the "heavy client" approach work for these types of usecase, regardless of the mountain of evidence showing the opposite.

    peter
  239. I have no problem with getting my customers to accept that the applications demands IE or Firefox only. In fact most of them they couldn't care less about Firefox, I usually just include it as a whim. I have worked with business-apps all my life - never public websites, which is another area that does not interest me.
    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. It's a long way from GE, Microsoft, and Walmart to A1-Plumbing but there's a huge commercial middle ground and it's several orders of magnitude larger than the "enterprise" market.
     Mike Foody

    And in those 5.5 million companies there are thousands of challenging and interesting vertical market business applications that is not yet "webified" That is a lot of nice juicy steaks!

    "he isn't dealing with large or medium datasets"

    Please Peter, be serious, have you learnt nothing from Google's applications?

    Regards
    Rolf Tollerud
  240. I have no problem with getting my customers to accept that the applications demands IE or Firefox only. In fact most of them they couldn't care less about Firefox, I usually just include it as a whim. I have worked with business-apps all my life - never public websites, which is another area that does not interest me.
    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. It's a long way from GE, Microsoft, and Walmart to A1-Plumbing but there's a huge commercial middle ground and it's several orders of magnitude larger than the "enterprise" market. &nbsp;Mike Foody
    And in those 5.5 million companies there are thousands of challenging and interesting vertical market business applications that is not yet "webified" That is a lot of nice juicy steaks!"he isn't dealing with large or medium datasets"Please Peter, be serious, have you learnt nothing from Google's applications?
    Regards
    Rolf Tollerud

    here's a simple direct question. How big is the database your typical application deals with? By you, I mean the application you have worked on first hand. the second question is, how much data can you keep in your rich client before it bogs down the system?

    I already know the answer to these questions and have done quite a bit of testing with 10 different use cases using .NET, IE and .NET controls.

    peter
  241. Peter,

    For the last time.

    You just restrain the searches to "what shall we say?" 200 rows for example. If the user can not get the information she want then, she have to refine her search. In that way the database can even be in terabyte size.

    That said our databases usually is around 50000 to 500000 rows, but sometimes in the beginning it can contain only a few hundreds posts. The thing is, the user doesn't notice or care at the difference from 500 rows to 500000 rows, neither would she if it was 250 mill rows. The database silently and effectively picks up the first 200 as fast from 250 mill rows as from 500. That is our database magic.

    Whatever the size of the database the users never see more than 200 posts at the time, (of course configurable)

    (I am really ashamed to have to explain this to you!)

    Regards
    Rolf Tollerud
  242. haha[ Go to top ]

    Peter, For the last time. You just restrain the searches to "what shall we say?" 200 rows for example. If the user can not get the information she want then, she have to refine her search. In that way the database can even be in terabyte size.That said our databases usually is around 50000 to 500000 rows, but sometimes in the beginning it can contain only a few hundreds posts. The thing is, the user doesn't notice or care at the difference from 500 rows to 500000 rows, neither would she if it was 250 mill rows. The database silently and effectively picks up the first 200 as fast from 250 mill rows as from 500. That is our database magic.Whatever the size of the database the users never see more than 200 posts at the time, (of course configurable)(I am really ashamed to have to explain this to you!)
    Regards

    Rolf Tollerud

    I wasn't asking about using cursors to page duh. That's obvious if you paging is acceptable. I'm talking about cases where you really need a large percentage of the data in a table. How you going to handle those cases in your Rich client approach? What happens if your customer says, I want to run a report of all the posts in the database and graph it in the GUI by topic, subtopic, thread and post count. Then the customer says, "from there I want to be able to drill down to the posts."

    peter
  243. internal CRM != Salesforce.com CRM[ Go to top ]

    I find it funny you think an internal CRM application is technically the same as Salesforce.com. The requirements are different enough that the techniques used for an internal CRM are completely inappropriate for something that is designed to handle millions of accounts with thousands of concurrent users. The first thing is this, something like Salesforce has to keep track of the usage, which means aggressive logging at all levels. This is necessary for planning and maintenance. The second, an internal application on a LAN does not have to deal with the latencies salesforce.com has to deal with. Third, something like salesforce.com has to utilize SSL/HTTPS. Do you have any experience handling 400 concurrent SSL requests in a cluster? Some food for thought.

    peter
  244. no more please[ Go to top ]

    Peter,

    For your information, salesforce.com uses exact the same technique I am talking about. (all though I think I can do it better :) Reports is another area we can take it after the weekend can we?, this kids stuff is getting boring.
  245. you should win an oscar[ Go to top ]

    Peter,

    For your information, salesforce.com uses exact the same technique I am talking about. (all though I think I can do it better :) Reports is another area we can take it after the weekend can we?, this kids stuff is getting boring.

    since when did you start working at salesforce.com? Just becaue the GUI looks similar, doesn't mean the plumbing and business logic is the same. that would be like saying a motorcycle is just like a formula one race car.

    enjoy your weekend

    peter
  246. I have no problem with getting my customers to accept that the applications demands IE or Firefox only. In fact most of them they couldn't care less about Firefox, I usually just include it as a whim. I have worked with business-apps all my life - never public websites, which is another area that does not interest me.

    It may not interest you, but it is a crucial area for most businesses.

    You are welcome to say all you like about your ideas for the limited area in which you work, but the problem is you insist on extrapolating into areas you have (as you said) never worked with. You seem to be assuming that the way you work in your area applies generally.

    I have written custom business apps and websites - it is fun and productive as you can take all kinds of shortcuts and make all kinds of assumptions.

    However many of us also have deal with the world outside of the safe and cosy situation of internal development. We aren't in a position to tell our customers what they can and can't use (if only we could!). In those situations (which are extremely common) your approaches won't work; we can't reliably save state on the client, yet we often need to deal with high load from a range of browsers that is awesome.

    When your site has reached its millionth user, you soon realise that browser portability and scalability are vital. If you don't bother to support a browser that has 1% of the user base, and if only 10% of those users complain (and they do!), that results in a lot of trouble. Believe me, I have seen it!
  247. An easier question[ Go to top ]

    After I sent the last response I realized it was way too hard for you, so here is a much easier scenario. Build a system which must meet the following requirements.

    1. return a query within 50ms for 90% of the queries
    2. handle a database with 250million rows of data
    3. log every single query, so that a detailed report can be done each night
    4. provide fault tolerance and redundancy
    5. if the design uses multiple servers, it must fail-over gracefully to another server
    6. hardware failure under no circumstance should bring down the cluster
    7. the design must be able to handle monthly updates, which ranges from 1-20million rows
    8. the cluster needs to handle an average of 50 concurrent queries at peak times
    9. if the concurrent jumps 4x, the cluster must not go down

    There's only 2-3 ways to build this kind of system. I'm sure there are plenty of TSS readers who have worked on these kinds of systems and know the answer.

    peter
  248. No innovation here - move along[ Go to top ]

    .But even if Java or .NET emerge as "winner"
    Wow! Rolf admits that a Java framework might 'win'!
    nobody can take away from the Ruby guys the credit - it was their invention.

    To see how backward and primitive RoR is, take a look at Seaside for Smalltalk http://www.seaside.st/ and GLORP http://glorp.org/ - a easy-to-use MVC web framework and a lightweight ORM. Like RoR, these are open source and work with a dynamic language. Unlike RoR, they can be used in a decent refactoring IDE with some of the best testing and debugging tools ever written.

    Of course, these aren't new. They have been used for years. So much for the 'innovation' of RoR, and the
    'it was their invention' hype.
  249. 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 ..

    .. in which case you'd look at DataPower: http://www.datapower.com/

    (A lot of XML hype, yes, but some really bright guys with actual working technology and a good CEO. :-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  250. xml middleware[ Go to top ]

    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 ..
    .. in which case you'd look at DataPower: http://www.datapower.com/(A lot of XML hype, yes, but some really bright guys with actual working technology and a good CEO. :-)Peace,Cameron PurdyTangosol, Inc.Coherence: Cluster your POJOs!

    having worked with sarvega on a previous benchmark I did with tomcat and a simple webapp using XML, hardware acceleration works well. I don't doubt datapower's hardware acceleration works :)

    the idea of an XML middleware application sounds very appealing to me for cases where really huge XML files over 50Mb are being sent over the wire. The old benchmark numbers I have are posted on tomcat's resource page also.

    peter
  251. Somewhat ironic, a presentation from the creator of Ruby

    http://www.rubyist.net/~matz/slides/rc2003/mgp00003.html
  252. As for Ruby being the next big thing - I wonder what the next over-hyped bandwagon you will jump on, Rolf?
    Well, our friend Rolf Quixote de la Mancha is on a perpetual righteous quest to utterly destroy Java and its followers, simply because he hates technical people who prefer science and choice-making instead of martial arts and spoon-feeding. So everytime something pops up which could make a dent at Java's market, he'll be on it. Take .Net, C#, Avalon, RoR, AJAX, Name Calling, Dubious Martial Arts, Spurious Statistics, Blog Quotes and just about anything that may challenge Java directly for its position or put it into a bad light, and we will surely see Rolf backing it fiercely and absurdly. That's just the nature of a troll, and as long as we keep feeding him, he'll be here entertaining some of us and boring the rest.

    Regards,
    Henrique Steckelberg

    PS: "never been wrong yet" -> Famous Last Words :)
  253. That's just the nature of a troll, and as long as we keep feeding him, he'll be here entertaining some of us and boring the rest.Regards,Henrique SteckelbergPS: "never been wrong yet" -> Famous Last Words :)

    Well, as I have said before elsewhere, I personally find Rolf useful, because while I know he is wrong, I get useful material through the process of proving him wrong. By motivating me to do this research, he is being very helpful to me in the promotion of Java and other technologies.

    I may be naive, but I'm not entirely sure he is a true Troll, because I think he might actually believe some of what he says. Not that this makes him any less entertaining, or boring.
  254. about plain superstition[ Go to top ]

    "because he hates technical people who prefer science"

    But Henrique nobody loves Science, art and science, more than I. What I hate is pseudo-science and "high-priests" that talk like pompous asses! If you were a little older you wouldn’t be so easily fooled and know that people that talk like that are always fakes. Why not go back and read some of Cameron's old posts 2-3 years ago? (please be careful so you don't throw up). How come Yukihiro Matsumoto - a bona fide genius - doesn’t talk like that?

    Real science implies experiments in a controlled environment that can be repeated elsewhere, by others.

    Great God
    Rolf Tollerud
  255. about plain superstition[ Go to top ]

    <blockquoteWhat I hate is pseudo-science and "high-priests" that talk like pompous asses! Don't you see that is what YOU are? The first sign is someone who uses big words and psuedo-relevant literary quotes.
  256. about plain superstition[ Go to top ]

    Forgot a bracket.
    What I hate is pseudo-science and "high-priests" that talk like pompous asses!
    Don't you see that is what YOU are? The first sign is someone who uses big words and psuedo-relevant literary quotes.
  257. the benefit of an classic education[ Go to top ]

    "Don't you see that is what YOU are? The first sign is someone who uses big words and psuedo-relevant literary quotes"

    Having an classic education and interested in everything from Aristoteles and Livius to Korean film and Irish science fiction is an good background for, as Churchill put it, requiring a sense of proportions.
    A sense of proportions means, "to understand what that is important and what that is not important".

    What your words amounts to is that you think that I am a fake. It is duly noted and registered.

    As to what Peter says "Calling RoR new and claiming.."

    Nothing is entirely new. But apparently sufficient is new with RoR that is has caused a unprecedented sensation on net with 3 Slashdot threads the last two weeks..

    Regards
    Rolf Tollerud
  258. that's harley a credible argument[ Go to top ]

    "Calling RoR new and claiming.."Nothing is entirely new. But apparently sufficient is new with RoR that is has caused a unprecedented sensation on net with 3 Slashdot threads the last two weeks..Regards Rolf Tollerud

    just because there's flame wars does not prove it is new. it's all about using hype to generate interest. it's all good. as long as after the flame dies down people remember the facts. I'm sure if someone decides to be cute and port RoR to cobol, they would also start a huge flame war, but who cares.

    it's really just entertainment for geeks.
  259. the benefit of an classic education[ Go to top ]

    "Don't you see that is what YOU are? The first sign is someone who uses big words and psuedo-relevant literary quotes"Having an classic education and interested in everything from Aristoteles and Livius to Korean film and Irish science fiction is an good background for, as Churchill put it, requiring a sense of proportions. A sense of proportions means, "to understand what that is important and what that is not important".What your words amounts to is that you think that I am a fake. It is duly noted and registered.

    I am not down playing your education and interests. Yes, having this is GOOD. But it is HOW and WHERE you use it. It has to make sense contextually and it has to be understandable to your audience. Otherwise you come off sounding less intelligent then you are desiring to be and like the pompous asses you so despise.
  260. Ok, maybe I am a pompous ass sometimes. But at least not all the time!

    Try to see the positive..
  261. But apparently sufficient is new with RoR that is has caused a unprecedented sensation on net with 3 Slashdot threads the last two weeks..RegardsRolf Tollerud

    No serious IT manager or developer bases any decision on the number or volume of threads on Slashdot, or their contents. Slashdot has a clear agenda: it is largely populated by young and inexperienced enthusiasts who think that all the problems of IT can be solved by products that are labelled 'open source', no matter how unstable or untested those products are. There is also a highly backward-thinking attitude that does not consider portability important (if it runs on MySQL, who cares?) and things that any kind of OOP is way too slow and complex.

    It was only a short while ago that there was such an 'unprecedented sensation' on Slashdot when it was claimed that LAMP (Linux/Apache/MySQL/PHP,Perl etc) could be a complete replacement for J2EE. This sensation soon died down and was replaced with realism. This months 'sensation' is RoR. However, realism is already appearing, as the long-recognised faults in Ruby are being publicised:
    http://creativekarma.com/ee.php/weblog/legacy/ruby_better_than_perl_but_what_isnt

    The truth is that professional development can be really dull. It requires good solid architectures and processes. It can't be done with a few quick scripts and emacs!

    If RoR ever gets to be a serious development tool, it will look like all the others: It will need high-performance VMs and libraries with high-quality multithreading, refactoring IDEs, a proper database interface or ORM, which will require configuration files (in XML, or yet more Ruby scripts). There will need to be major language changes to remove current Ruby faults. It will end up big like Java or .NET, because the features of those systems are necessary for robust professional development. You need things like clustering, message queues, management tools. But then, Ruby will have become boring, and the Slashdot crowd will be raving about something else.
  262. destroying the fun[ Go to top ]

    Well, for your case I hope that you never get any invitation to some party!

    But seriously if you are trying to compare the RoR uproar with that tiny modest suggestion that PHP maybe, just maybe could be viable for just a trace bigger projects than former believed?

    Where is your sense of proportions?

    Regards
    Rolf Tollerud
  263. this is a push push business[ Go to top ]

    Currently are there 7 (seven) new projects to create a VM for Ruby of which one is sponsored by the Japanese government
  264. this is a push push business[ Go to top ]

    Currently are there 7 (seven) new projects to create a VM for Ruby of which one is sponsored by the Japanese government

    A new project doth not a product make. Having a VM does not make a language better; it does not improve its syntax or remove its side-effect flaws. Also, many of those projects have been dormant for a long time. It has got so bad that one of the projects is called, jokingly 'YARV' - Yet Another Ruby VM. One of the VM implementations is so bad, it is actually slower than the normal interpreter!

    But, just a minute - weren't you talking about 'true compiling'? Not quite the same as a VM, is it?

    Again, please let me have your time machine so I can currently develop and benchmark these future VMs.
  265. Currently are there 7 (seven) new projects to create a VM for Ruby of which one is sponsored by the Japanese government

    Remember circa 1990 when the Japanese government sank countless yen on a crusade to make parallel ProLog the premier language? Meanwhile Uncle Scam was trying to do the same with Ada. And now the Japanese government is back at it with Ruby?!

    Did it ever occur to these wonks that Keynesian economics is a poor kind of selective pressure? I mean look at the ongoing spat between Mike and Richard over Groovy elsewhere on TSS. If those two geniuses can't agree on language design criteria, how the heck could detached bureaucrats possibly do so?! I can only hope the Japanese have the only democracy still foolish enough to continue funding language implementation.
  266. destroying the fun[ Go to top ]

    Well, for your case I hope that you never get any invitation to some party!But seriously if you are trying to compare the RoR uproar with that tiny modest suggestion that PHP maybe, just maybe could be viable for just a trace bigger projects than former believed?Where is your sense of proportions?RegardsRolf Tollerud

    Perhaps you should actually read what I posted. It was not a 'tiny modest suggestion that PHP maybe, just maybe could be viable for just a trace bigger projects than former believed' it was titled, and I quote: "LAMP Grid Application Server, No More J2EE". I don't think anyone could call that a 'tiny modest suggestion'!

    As I described, it has been done again, and again over the years. This is nothing new. I mentioned Smalltalk. They did all this a long time ago with packages like GLORP and Seaside. PERL has all this stuff, as does TCL.

    Watch the Ruby crowd re-discover the wheel and then think they invented is both sad and funny.
  267. show a little style please[ Go to top ]

    "LAMP Grid Application Server, No More J2EE"

    I do not know if that was a claim or not, but it doesn't matter. If it was a claim, you should just have disregarded it. Common sense is not forbidden. To even hint that this was meant literally or seriously put you in the same category as Cameron. I suggest you try to watch the British parliament, and then you see that you can have a heated discussion without assuming your opponent is an idiot. What do you think would have happened if you in that assembly had vented your opinion "So you mean that PHP shall replace all J2EE"? Nobody would have said anything; you would just have been frozen out. The good old "silent treatment".

    So I repeat, the gist of the former PHP discussion was that perhaps PHP was a little underused, no more. That has nothing to do with the sensation around Ruby and RoR that can be compared to a tsunami.

    Regards
    Rolf Tollerud
  268. show a little style please[ Go to top ]

    "LAMP Grid Application Server, No More J2EE"I do not know if that was a claim or not, but it doesn't matter. If it was a claim, you should just have disregarded it.

    Rolf, it was the actual title of the article! How much clearer could it be?
    Common sense is not forbidden.

    It obviously is for you, saying things like:
    the sensation around Ruby and RoR that can be compared to a tsunami

    Which is not only a crazy exaggeration, but, I have to add, in very poor taste.
    To even hint that this was meant literally or seriously put you in the same category as Cameron.

    I'm not hinting anything. I'm quoting from the article. However, I consider categorising with Cameron to be high praise, even though I have neither his wit, or style, not his fluency with the word 'ninjas'.
    "So you mean that PHP shall replace all J2EE"? Nobody would have said anything; you would just have been frozen out. The good old "silent treatment".So I repeat, the gist of the former PHP discussion was that perhaps PHP was a little underused, no more.

    Wrong. Let me quote:

    "it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE"

    No statement about PHP being underused, no qualifications, no conditions; just a declaration that it is 'much better suited .. than J2EE'.
  269. no style here..[ Go to top ]

    "Wrong. Let me quote:

    "it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE"

    No statement about PHP being underused, no qualifications, no conditions; just a declaration that it is 'much better suited .. than J2EE'."


    Ok, you persist in the Cameron hypocrisy dishonest fashion. Very well, you will get the same treatment as you would have got in the British parlament!
  270. it was just a question if which one[ Go to top ]

    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?

    Well, let's face it. Dynamic scripting languages have a long history of knocking off static ones. Look at Fortran, that was taken by...nope, that was C. But C, it was knocked off by...no wait, that was C++. Well, C++ was taken out by...hmmm, that would be Java.

    Never mind.

    Well, sure C#(not a scripting language, but go with it) will knock of Java. Oops, runs only on Windows.

    Really, never mind.
  271. Best regards Rolf Tollerud("never been wrong yet")

    "Never been wrong yet?"

    Oh dear! Do I have to remind you about J2EE/EJB and EBay, about 'Nasdaq running on .NET technology', and many others?

    Please can we have just a little honesty?
  272. It's not new[ Go to top ]

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

    Rolf Tollerud

    Ok, looking at some of the docs, I would say it's hardley new. In fact, I would say it's a good copy of VS.NET + ASP. I'm gonna have to give MS credit here and say that VS.NET does this style of (wizard + templates + generated code) development better. By better I mean more flexible and full featured. In my bias opinion, it's great that Ruby On Rails is copying this approach and making simple projects easier. Whether this approach will work for larger and more complex applications still needs to be tested. 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 and shows what OSS can do with very little time.

    enjoy

    peter
  273. Questions[ Go to top ]

    I think one of the biggest things some people never get is what the word Enterprise means.

    I have a few Rails (not Ruby) questions.

    Why should a framework dictate my data?

    Will Rails work my our weird naming standard e.g table PCVM.CVMB40B columns: CVMB40B_NOVEH, CVMB40B_AMVAL, CVMB40B_NODAYS, CVMB40B_.........

    Can rails work with anything besides surrogate keys?

    Can rails work with composite keys?

    Can rails work with the famous legacy smart keys/columns?

    Can rails access other EIS systems besides relational databases? LDAP hierarchical databases?

    Can rails do 2PC transactions?

    Can rails access a MQ?

    Will rails ever be supported major company?

    Do I really have to change the order my columns in a database for a html view?

    How can I unit test rails, not integration testing.

    Why should I learn Rails/Ruby when I can only use it in about 2% of the development I do?

    These would be Enterprise concerns. Existing data and other applications interact with that data. Along with standards and the other political BS.

    Is rails ready for prime time?
  274. BTW, Ruby On Rails is quite stable, Basecamp is a commercial site that is ISPing a RoR application.

    Weird, usually when I say that RIFE is in development for 4 years and in production for over 3 years in the biggest Belgian mobile phone company and a whole collection of public sites and open-source products are made in it, people usually say that it's too young and not used enough and thus not stable. Surely that single production application that was written for Rails (and vice-versa) is definite proof that Rails is stable!
  275. All heavy-load mission critical Java sites in the world ..

    What?!? You're finally admitting that there are actually web sites that are running on Java? Are you feeling OK? What did I miss?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  276. enlightening[ Go to top ]

    All heavy-load mission critical Java sites in the world ..
    What?!? You're finally admitting that there are actually web sites that are running on Java? Are you feeling OK? What did I miss?Peace,Cameron PurdyTangosol, Inc.Coherence: Cluster your POJOs!
    Not to mention the word "mission critical"
    Urban truth

    Regards
    Sayan
  277. RoR and XP[ Go to top ]

    and XP forbids implementing future requirements.

    Actually, XP doesn't forbid anything! XP is an 'approach' that 'encourages' things. It may discourage planning for future requirements, but it certainly does not discourage re-use of existing code.

    Allow me to state another XP principle: Decide things as late as possible. Designs should be flexible. There should be no 'Big Design Up Front' (to quote from Wikipedia). Because there is no mapping layer between database structure and classes in RoR - it's more direct, your code is based on the initial design of a database, and it could be painful to continuously track changes in data design, or modify database and object model independently. This is hardly conforming to XP.
  278. I was talking about templates - projects with most of the 'boilerplate' code already written.
    You seem to be acknowledging that boilerplate is an issue with Spring/Hibernate, a point I've tried to make.
    and XP forbids implementing future requirements.
    One of the siller aspects of XP, I have always thought.
    XP's obsession with urgent requirements is its appeal. "Is it ready yet?" is typically how my employers say Hi. I usually don't work for a big company with a big project, big team, and long schedule. Corporate Amerika feels like a 'Borg collective to me. I have an affinity for small shops and quickie projects. That's why Spring/Hibernate's sourcebase tripling is so scary to me.
    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...
    I actually like table oriented development. I prefer an ER diagram instead of a UML class diagram.
  279. I was talking about templates - projects with most of the 'boilerplate' code already written.
    You seem to be acknowledging that boilerplate is an issue with Spring/Hibernate, a point I've tried to make.

    The issue was not about boilerplate, it was about lines of code for a new project. If the boilerplate is already written, the lines of code for a new project are small.
    XP's obsession with urgent requirements is its appeal. "Is it ready yet?" is typically how my employers say Hi.

    That is why XP is good. Which is why RoR's poor support for rapid change is bad. The employers say "Is it ready yet", you reply "No, because I have to adapt my code to your changed schema".
    I usually don't work for a big company with a big project, big team, and long schedule.

    The most use of Spring and Hibernate is on the smaller projects.
    That's why Spring/Hibernate's sourcebase tripling is so scary to me.

    It is not tripling if you use template projects, and tools to generate code, and you can't take one person's anecdote about one project as a serious 'case study'.

    (Anyway, the whole 'tripling' argument is bogus. Much of my Java code is generated by my IDE, with things like bean property management controls.)
    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...
    I actually like table oriented development. I prefer an ER diagram instead of a UML class diagram.

    Fine, but this still does not solve the problem of the Ruby code having to be modified to match potential changes in the ER diagram. With Java/Hibernate/JDO you have a mapping which can be edited, and there are refactoring tools.

    Again, if you are really after pure speed of development, why not use something like Studio Creator - you could do many smaller projects almost entirely visually, and with very few lines of code. I can't see the advantage of RoR over this approach.

    I don't use Studio Creator, as in my experience the time actually spent writing lines of code is a very small fraction of total development time.
  280. One of the jobs we have in the IT department I work for is to take "write-and-forget", "one-off", quickly-developed-by-non-technical-people departamental systems and turn them into corporate systems. Someday one realizes that their small database has grown out of control in both size and scope, and find out that there are other similar systems spread thoughout the company nationwide, and who's got to come to the rescue? We get to analize these systems and give them a solution in order to turn them into corporate systems. 90% of the time there must be a complete rewrite of it all, both of database structure and code. Every week we see one of these "small systems" pop up asking for help. Now, whenever I see these small one-offs round, I get this feeling that I'll probably run into them again in the future, and be with them for a loong time...

    Regards,
    Henrique Steckelberg
  281. You seem to have a major hard-on for a project you've never used, Brian?

    Why the angst? I mean, people are contradicting you with direct experience, yet you seemed to be bent on putting software, that as far as I know, hasn't done a thing to you, in a bad light.

    Let's face it, there is nothing that is being said about Rails that wasn't said about PHP and Perl before that. Yet, java for small, medium, and large applications keeps chugging along.

    I can say, based on DIRECT experience, experience you seem to lack that Spring/Hibernate has resulted in less code, less mantainance, and less headache.

    Why is it that you embrace this single blog as if God himself endorsed Rails as the offical script of the righteous, but are so quick to disregard Steve's multi-project success with skepticism.

    I mean, his is real-world, isn't it? And now you say that "lightweight" is misunderstood because people don't agree with YOU. What exactly makes you so enlightened that the entire J2EE community is so fearful and uninformed, but you are so prolific?
  282. .Less handcode is what the study's metrics are about. Worrying about reusability distracts from writing lean code.

    BTW, do you even understand the inherent contradiction in these two statements. You simultaneous batter reuse and having many lines of code.
  283. All this alarm is alarming[ Go to top ]

    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.

    There was no "study". A guy wrote a very small app in Java, and several months later rewrote it in Ruby on Rails, with a claim that 80% of the functionality was done in 4 days. The public at large can't see either code base. The author himself has disclaimed most of his own claims saying that any comparison is kind of meaningless.

    What this means, pretty plainly, is that no one can draw any useful conclusions at all about any of this. None. About all you can say is that it's weird that a guy spends half of his blog entries making claims and then dedicates the other half of his entries with disclaimers saying that it's all meaningless anyway :-)

    Spring and/or Hibernate could be the most featherweight frameworks on the planet, or they could exceed the density of neutronium. Or possibly fall somewhere in between. But there is _no_ way to tell from this application. None. Zip. Zero.
  284. "Sparse like a Japanese tea room, as functional as a Zen studio".

    There is at least something that is certain, never will you experience such pleasant ride, such comfortable feeling of driving a luxury car as when you work in Rails. True MVC in practice, not only theory.

    A perfect example of the devise:
    "Build a better mousetrap and the world will beat a path to your door.
    Henry David Thoreau in Walden in 1854.

    Regards
    Rolf Tollerud
  285. All this alarm is alarming[ Go to top ]

    There was no "study". A guy wrote a very small app in Java, and several months later rewrote it in Ruby on Rails, with a claim that 80% of the functionality was done in 4 days. The public at large can't see either code base. The author himself has disclaimed most of his own claims saying that any comparison is kind of meaningless.What this means, pretty plainly, is that no one can draw any useful conclusions at all about any of this. None. About all you can say is that it's weird that a guy spends half of his blog entries making claims and then dedicates the other half of his entries with disclaimers saying that it's all meaningless anyway :-)

    ...which makes you think about the motives of posting something like that in the first place.

    The fact that he posts some claims and then disgredits most of them himself, leaves nothing but one or two mildly interesting bits of information on the table, which he can not prove either. So what's the point? From all the attention it got, you can only conclude that it was meant to do exactly that - get attention.
  286. 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.

    Well, then just don't use Spring + Hibernate. A number of Spring + Hibernate users are telling you "don't worry", but you don't seem to care. Lines of code are not a very good metric, in my opinion: a lot of those lines are generated in a fraction of second by IDEA.

    Anyway: "lightweight" is a very generic term, you should declinate it in the context which seems to interest you the most: "lightweight with respect to lines of code".
  287. Gave it a chance...and...[ Go to top ]

    Hi

    I'll always give a new technology a chance. I checked
    out ROR for the first time today. I like the way it attempts to overcome the the O/R mapping problem and
    some of the other things it gives you.

    I'm working on BeanPlanet (yep, another framework),
    led by Gary Watson, that is not *just* tied to Object -> RDBMS mapping but attempts, with its Universal Navigation Language (UNL), to automatically map Objects via their relationships in any domain. For example, Java POJOs to: RDBMS tables, XML documents, BeanPlanet BeanStore configuration (yep, XML is the default configuration method in BeanPlanet too), other Java POJOs and vice-versa.
    It does this via EL and scripting; thereby adding much
    that ROR boasts - but to POJOs.

    Unfortunately, like most of the BeanPlanet team, we found
    the language pretty off-putting. Sorry guys.

    I agree that Java has its issues: configuration, property
    getter/setter, attributes and lack of scripting, as
    detailed in several previous threads.

    Java: Here today, still here tomorrow I think.

    Rob,
    BeanPlanet.org
  288. Is it scalable?

    Can it handle high volumn of transactions?

    How about security?
  289. Is it scalable?Can it handle high volumn of transactions?How about security?

    +1
  290. 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.

    Just to be clear, his finding was that Rails was 2000% as fast as Java. I think that makes .NET only 30% faster than Rails.

    It's good to know that he thinks that Java is up to the task of simple web apps though.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  291. no need to worry[ Go to top ]

    EJB 3.0 will fix all problems!
  292. Just to be clear, his finding was that Rails was 2000% as fast as Java.
    Wow, that is much too fast. Beware of the train deRailing at that speed.
  293. Yeah ROR might be better than Java. However, let us not forget what really counts is the market. If I’d spend some time on learning anything other than J2EE, I would go with .NET. No matter how hard you bash Java, it takes a huge share of the delicious pie. A while back, I heard that “PHP could do anything”. That is funny. We ought to learn a lot from Mr. Bill Gates. The market is the only thing that decides what technologies stay and what must leave.
  294. At the Milwaukee No Fluff Just Stuff conference, I was invovled in a lunchtime conversation with Justin and [Pragmatic] Dave Thomas about this subject, just days after Justin completed the first version of the Ruby code.

    The concensus at that point: it probably wasn't a difference in *execution* speed, but smarter data retreval strategies used by Rails persistance layer. While Hibernate has excellent support for lazy loading, both developers thought that Rails was being *lazier*.

    Justin's new numbers point to the faster caching in RoR: while both applications performed about equally without pre-cached data, RoR performed 20x better than the Java stack with cached data [both versions using similar caching strategies].

    He also points out a *significant* decrease in Lines of Code[Java:3293 RoR:1164] and Lines of Configuration [Java:1161 RoR:113]. While LoC is not an accurate gauge of effort (as he *and* many here have observed), it is another point in Ruby's favor, and can be considered an indicator of decreased complexity.

    There's also been an uproar over his testing methodology; I don't think Justin set out to prove or disprove anything regarding Ruby/RoR v. Java's speed, just enough to verify his initial assessment after four days of RoR development: "Rails is actually faster." And, for those still complaining, he is working on some updated comparisions, running under Resin, and on a Windows box instead of his Powerbook, with a better methodology.

    Reading the posts [both on Slashdot and here], it seems like a lot of people feel threatened by these results in some way. Attacks on methodology, attacks on the languages, attacks on Justin and his implementation skills... Why the difficulty in accepting that Ruby/RoR *could* be faster than Java in some cases, with a smaller codebase, and easier implementation?
  295. Scott,
    "Why the difficulty in accepting that Ruby/RoR *could* be faster than Java in some cases, with a smaller codebase, and easier implementation?"
    What an absolutly charmimng innocent remark!

    You do not challenge the Java/J2EE establishment unpunished..

    Regards
    Rolf Tollerud
  296. Hibernate and Laziness[ Go to top ]

    To clarify Hibernate's being less lazy than rails. In Hibernate 2.0, by default, no assocation is lazy. You have to explicitly mark them as lazy. This can lead to excessive SQL calls if you don't know what its doing (or you haven't turned hibernate.show_sql on). Hibernate 3.0 has switched that default for collections, which are very chatty in both Rails and Hibernate. (The N+1 problem).

    Rails on the other hand is ALWAYS lazy (you have no choice), which is only good if you don't need the data. Hibernate has a lot smarter ways to get the data if you need it, like outer join fetching.
  297. Getters/Setters Sarcasm[ Go to top ]

    Just in case there was any doubt, I was definately kidding about the 'threat' posed by getters/setters. My point was they are really trivial and usually passively generated, but they signficantly up the line count in comparisons like this, and folks who favor Rails keep showing examples like...


    class GoldClaim < ActiveRecord::Base
    end


    And saying "Look at that! No Code! Isn't it great! That means it can't have bugs!"

    Never mind that you can't tell what fields it has unless you look at the database.
  298. Getters/Setters Sarcasm[ Go to top ]

    folks who favor Rails keep showing examples like...

    class GoldClaim < ActiveRecord::Base
    end

    And saying "Look at that! No Code! Isn't it great! That means it can't have bugs!"
    Never mind that you can't tell what fields it has unless you look at the database.

    Worse: if the database schema undergoes variations, all client code that uses the class becomes broken, which means either:

    a) you cannot change the database (tell the customer and see his reaction)

    b) you have to rewrite thousands of junior-programmer-written lines of codes, spread across hundreds of classes, to change the reference to the variated table

    It's an old story: the scripting language is definitely faster and more convenient where re-engineering does not matter, but larger applications need added complexity to avoid a (much more expensive) unability to adapt to changing requirements. Just manage to avoid using Spring for a 1k-lines-of-code application. I'd rather use ASP/VB for this...
  299. RE: Hibernate and Laziness[ Go to top ]

    To clarify Hibernate's being less lazy than rails. In Hibernate 2.0, by default, no assocation is lazy. You have to explicitly mark them as lazy. This can lead to excessive SQL calls if you don't know what its doing...

    Patrick,
    That was my initial thought when we discussed it. Then I remembered that Justin was presenting Advanced Hiberate later that day at the conference :)

    I also confirmed lazy loading was enabled during the discussion; hence the speculation about RoR being more efficiently lazy.
    --Scott
    Session #21: Advanced Hibernate by Justin Gehtland
    Hibernate is easy to get started with, but can sometimes be hard to make efficient or secure. In fact, the default settings for Hibernate create
    applications that will run slowly, cause unwanted round trips to the database, and may be more restrictive and/or permissive from a security standpoint
    than you would otherwise want. This session will show advanced techniques for tuning performance, including:
    • advanced collection mapping strategies
    • lazy loading
    • cascading update management
    • lifecycle management
    • Hibernate's interceptor layer
    In addition, we'll examine the security considerations when using Hibernate. Often, single-credential data access isn't enough for sensitive data. We'll
    walk through using per-user credentials for data access, logging security information about and through Hibernate, and accessing data sources through
    secure application servers.
  300. Spoke to Justin about this...[ Go to top ]

    I think a number of things are clear from this test:

     - The lines of code for Java or RoR were so low that no meaningful conclusions could be reached. It was a very small application - some might say tiny. Justin said most of the Ruby code was written in a few days. Can people wake up and realize that you can't read too much into 1 guy working a few days and pumping out (drum roll please) just over 1,000 lines of code.

     - Based on everything written about this "test", it seems clear that most of the time almost no Ruby code was ever executed - what was executed was a very, very short path which served up an entire cached page.

    Seriously now folks - a guy wrote a _whole thousand lines of code_ and Ruby people are jumping up and down in a frenzy. Get a grip. Go write a real application in Ruby of some _meaningful_ size with an actual team size >1 and perhaps the results might then be worthwhile.
  301. Grrr... I'm grumpy tonight...[ Go to top ]

    I think a number of things are clear from this test:&nbsp;- The lines of code for Java or RoR were so low that no meaningful conclusions could be reached.

    I think 4 days initial effort and ~1k lines of code, possibly better (or at least acceptable) performance, and having a good time doing it is a meaningful conclusion in my book.

    Also ~3k lines of Spring/Hibernate code can be pretty dense with logic, considering the functionality that stack provides. As for ~1k lines of RoR, have you seen what the language can do? It may not be a terribly complex app, but judging complexity based on LoC is just silly.
    with an actual team size >1
    OK, you've got me there. I would love to hear implementation effort notes from someone who's used RoR on a team project. Anybody?
  302. Also ~3k(3293) lines of Spring/Hibernate code can be pretty dense with logic, considering the functionality that stack provides.
    Of course. But if you rewrites it to 30000 LOC they will say that too is too small and so on, until they will reach the system for the worlds largest Financial Provider.

    Also, I never saw so complete and professional website(s) for any new language/framework before, including documentation, tutorials, etc, even hands-on video lessons.

    Now we are only waiting for Microsoft and Rod & Juergen to present their versions!

    Rolf Tollerud
  303. Grrr... I'm grumpy tonight...[ Go to top ]

    I think 4 days initial effort and ~1k lines of code, possibly better (or at least acceptable) performance, and having a good time doing it is a meaningful conclusion in my book.

    You think lessons learned from 4 days on a trivial app really mean very much? Dear lord - why?
     It may not be a terribly complex app, but judging complexity based on LoC is just silly.

    Comparing 3K lines of code to 1K is silly, I agree :-)

    However - you can't stop at that statement. Lines of code _do_matter, at least in terms of orders of magnitude. I think even the biggest idiot among us can recognize that a 10 line app is trivial, and that a 500,000 line app is not trivial. If you can agree to that Scott, then it means that lines of code is not meaningless - it just means that it's got a rather low accuracy as a metric.

    You can argue that this particular 3K lines of Java and 1K lines of RoR "can be pretty dense with logic" - but now you're just guessing. Let's not strain ourselves too hard and just think in terms of averages. On average - is your typical 3K line application very complex? Sorry, no - it's not.

    Now let's look at some other bits of information. The author says he re-wrote 80% of the Java bit in RoR in about 4 days and the end result is ~1K lines. There are two general possibilities here (plus a combination of the two):

    One, RoR is so amazingly powerful and easy that it enabled him to achieve this amazing feat.

    Or Two, the application was so trivial that almost didn't matter what language/framework he wrote it in.

    Or some combination of the two. Based on everything I've heard, I think 90% of the positive success the author has seen is due to the fact that he's got a very simple app that just happens to fit very easily into a RoR model. And if he had picked perl, or python, or any number of other languages he probably could've banged something out in equivalent time. Pretty much any language that has decent reflection
    would do - including Java :-)

    However - a success on something this small really doesn't say anything about its general applicability. Sorry, it doesn't. Think about some apps you've worked on that are, shall we say, slightly larger than 1K/3K :-) And think about the tiny wonders you've banged out in a week. Do the lessons learned in the one-offs that you've written in a week _really_ apply all that much to the larger projects?
  304. Grrr... I'm grumpy tonight...[ Go to top ]

    a 10 line app is trivial, and that a 500,000 line app is not trivial

    Don't mean to be nitpicking, but 500,000 lines of print statements one after the other is trivial. The the line-count on its own is silly, you have to consider the actual content and code too.
  305. Grrr... I'm grumpy tonight...[ Go to top ]

    Don't mean to be nitpicking, but 500,000 lines of print statements one after the other is trivial. The the line-count on its own is silly, you have to consider the actual content and code too.

    Ah, the German Philosopher approach :-) How many angels can dance on the head of a pin, is the cat alive or dead, is a 500,000 line app complex more complex than a 10 line one.

    Sometimes you have to stop nitpicking and apply a bit of common sense. Yes, you can compare 2 wholly different applications each of which has 500,000 lines of code and find that they are ...wholly different applications with very different levels of complexity.

    However - I think a reasonable human being who isn't attempting a Thought Experiment can make some reasonably shrewd guesses and draw some very general conclusions (emphasis on general) when speaking about an average 3K line program vs. an average 500K line program.

    Let's be pragmatic for a moment. If you were a bettin' man, which application would you bet was more complex?

    If you were a bettin' man, would you say 1 person wrote that 500,000 line program? Do ya think he wrote it in 4 days?

    If your answer is "no" and "no" - do you think the lessons learned from 1 guy re-writing an app in 4 days really apply to, say, a 500,000 line program developed over the course of a few years by one or two dozen people?

    You can pick data points - different program sizes, different team sizes - but the point remains that in software development the very, very small (1 guy, 1K lines of code, 4 days) rarely says very much about the medium (3-4 guys, 40K lines of code, several months) or about large (30 guys, 1MM lines of code, several years).
  306. Grrr... I'm grumpy tonight...[ Go to top ]

    I'm sorry Mike, but I don't totally agree. What measures complexity? We have for instance a 60,000 line modularized web suite that we use for a large number of projects, however that suite is imported as a binary jar. The applications themselves are 1,000 lines or less, not counting the templates.

    So if I evaluate the complexity of the web suite against the complexity of the applications themselves by line count alone, any sensible person would think that the 60,000 lines one is moderately complex and the 1,000 lines one very trivial. The applications themselves however largely do the same thing and if there are problems or bugs we often do have to trace them through the 60,000 lines. I thus still don't think that LoC alone say anything at all.
  307. Grrr... I'm grumpy tonight...[ Go to top ]

    I thus still don't think that LoC alone say anything at all.

    You can of course manufacture any number of scenarios to prove this point for a specific case. If we were to play your game we'd factor in the lines of code in the operating system, language compilers, and of all the software tools used by the chip designers who designed the hardware your stuff is running on :-)

    Using that measure when I write "System.out.println (50)" the program is _enormously, monumnetally_ complex because millions of lines of code are involved (perhaps billions). Reading this you may even say that this proves your point.

    But mneanwhile, those with common sense will be able to glance at it and tell you how complex it is. And, if the source were available, I strongly suspect that if we looked at the author's application and Ruby code we would rapidly be able to come to a conclusion as to just how complex it is. Is it a case of having to juggle in how 60K lines of framework code are used and using our German Philosopher hat? Or is it a case of looking at a few pages of code a single guy banged out in a 4 days?
  308. flawed benchmark[ Go to top ]

    Let's get something straight. Justin's benchmark consisted mainly of lighttpd static page vs full Java stack measurements. He was able to enable static caching that doesn't even touch Rails because his specific application did not generate personalized pages that vary for each user. When he ran the Rails benchmark with "caching initially disabled" it meant that for the first request Rails generated the static html version of the page and this was served by lighttpd (a web server) for all the remaining 99 requests. Meanwhile the Java app executed the full stack.

    This is why I think this bechmark is flawed. My own measurements indicate that the Rails stack is significantly slower than the Java stack.
  309. flawed benchmark[ Go to top ]

    When he ran the Rails benchmark with "caching initially disabled" it meant that for the first request Rails generated the static html version of the page and this was served by lighttpd (a web server) for all the remaining 99 requests. Meanwhile the Java app executed the full stack.

    That's stupid, unless I'm missing something. How did you even reach that conclusion ? Does RoR perform automatic, no-user-intervention required caching of requests to static pages ? Cause I've never seen such a wonder with server-side dynamic pages with "caching initially disabled". But then again maybe you know something about RoR that the rest of us (dare I say) don't. And if you do not, then please refrain from spreading bullshit thank you very much.
  310. flawed benchmark[ Go to top ]

    When he ran the Rails benchmark with "caching initially disabled" it meant that for the first request Rails generated the static html version of the page and this was served by lighttpd (a web server) for all the remaining 99 requests. Meanwhile the Java app executed the full stack.
    That's stupid, unless I'm missing something. How did you even reach that conclusion ? Does RoR perform automatic, no-user-intervention required caching of requests to static pages ? Cause I've never seen such a wonder with server-side dynamic pages with "caching initially disabled". But then again maybe you know something about RoR that the rest of us (dare I say) don't. And if you do not, then please refrain from spreading bullshit thank you very much.

    **** TSS's lack of "preview" and "edit".
    OBVIOUSLY it reads: "no-user-intervention required caching of requests to dynamic pages".
  311. flawed benchmark[ Go to top ]

    When he ran the Rails benchmark with "caching initially disabled" it meant that for the first request Rails generated the static html version of the page and this was served by lighttpd (a web server) for all the remaining 99 requests. Meanwhile the Java app executed the full stack.
    That's stupid, unless I'm missing something. How did you even reach that conclusion ? Does RoR perform automatic, no-user-intervention required caching of requests to static pages ? Cause I've never seen such a wonder with server-side dynamic pages with "caching initially disabled". But then again maybe you know something about RoR that the rest of us (dare I say) don't. And if you do not, then please refrain from spreading bullshit thank you very much.

    You ARE missing something. Rails page caching works like this:

    When you navigate to the url /test/page a rewrite rule in the web server checks for a /test/page.html static file, if it exists then it serves it without even invoking the Ruby process. If it doesn't exists (in the case of all the cached html files cleared, thus "caching initially disabled" in Justin's words) Rails processes the request and generates the /test/page.html that is served to subsequent requests by the web server.


    Please read Justin's comments in his own blog before you question anything.
  312. Too small[ Go to top ]

    Mike
    Can people wake up and realize that you can't read too much into 1 guy working a few days and pumping out (drum roll please) just over 1,000 lines of code.
    Amen. Trying to extrapolate to the large (or even medium size) from the very small is dangerous.

    Rgds
    Rod
  313. Too small[ Go to top ]

    Mike
    Can people wake up and realize that you can't read too much into 1 guy working a few days and pumping out (drum roll please) just over 1,000 lines of code.
    Amen. Trying to extrapolate to the large (or even medium size) from the very small is dangerous. RgdsRod
    Yeah. That is Rolf's modus operandi.
  314. people do really are conservative[ Go to top ]

    I can not see why a RoR project with "a mix of dual or quad processor servers, with lots of RAM and 64bit CPU supporting a cluster of databases", modern cache policy, stateless as far as possible could not scale equal to the largest Java projects?

    Are we talking about maintenance? Don't you think Spring-like, iBATIS-like and Tapestry-like frameworks soon will pop up around Ruby precisely as they have done around Java? Soon to be a dime a dozen?

    Regards
    Rolf Tollerud
  315. people do really are conservative[ Go to top ]

    I can not see why a RoR project with "a mix of dual or quad processor servers, with lots of RAM and 64bit CPU supporting a cluster of databases", modern cache policy, stateless as far as possible could not scale equal to the largest Java projects?
    Did anyone here think he would be able to see why?
     Are we talking about maintenance? Don't you think Spring-like, iBATIS-like and Tapestry-like frameworks soon will pop up around Ruby precisely as they have done around Java? Soon to be a dime a dozen
    Why need them? Rails is easy and fast.

    Of course they could pop up. And for that matter this thing with Michael Jackson could be just one big misunderstanding. :) Like "Ohhhhh. You said you like peanuts. Not p.... . Our bad. Here is your train, monkey and giraffe back."
  316. Getters/Setters Sarcasm[ Go to top ]

    Never mind that you can't tell what fields it has unless >you look at the database.

    Logically, thats where I would prefer the fields to be defined. Why have hundrends of "brain-dead" get/set methods in the class.
  317. Getters/Setters Sarcasm[ Go to top ]

    >Never mind that you can't tell what fields it has unless >you look at the database. Logically, thats where I would prefer the fields to be defined. Why have hundrends of "brain-dead" get/set methods in the class.

    A class, even a DTO, should not have its attributes mandatorily mapped 1-to-1 to the fields in the database. It may be easier to handle at first glance, but when something changes in the DB the dumbly-mapped class propagates the changes everywhere and creates a mess.

    This has nothing to do with where the DB fields are declared, which is obviously in a DDL script. The problem is that the schema must not mandate what the name of the class attribute is. Doing this is a desing error, i.e. forced tight coupling between presentation layer and the DB, not present in EJB Persistence or in Hibernate. If RoR's ActiveRecord (which I do not know well) forces the developer to map names 1-to-1, then using it in an enterprise application is unadvisable.
  318. Getters/Setters Sarcasm[ Go to top ]

    I don't think RoR forces you into a 1-1 mapping. Its just the default that can (or should be overriden). i.e. if there is a special case, implement it. Otherwise don't cloud code with statements for the sake of it.
  319. Getters/Setters Sarcasm[ Go to top ]

    I don't think RoR forces you into a 1-1 mapping. Its just the default that can (or should be overriden). i.e. if there is a special case, implement it. Otherwise don't cloud code with statements for the sake of it.

    Well, this makes more sense to me than saying "Mapping configuration is evil".
  320. Getters/Setters Sarcasm[ Go to top ]

    Never mind that you can't tell what fields it has unless you look at the database.

    Logically, thats where I would prefer the fields to be defined. Why have hundrends of "brain-dead" get/set methods in the class.

    There are a couple of different issues here. The first has to do with the coupling points between the database and the application, and the second has to do with the use of accessor and mutator methods to implement the concept of a property. If the application is sprinkled with coupling points to the database, and in the absence of very good refactoring tools, then changes to the database will be catastrophic to the application. In reality, some applications use databases that never change, and there are very good refactoring tools for Java so there will be (some day) very good refactoring tools for Ruby, so maybe it's not as dramatic a problem as it sounds.

    Regarding a property being implemented with an accessor and mutator method, I have personally found it to work very well, although it is verbose (as is Java). One of the things that we do as part of our code review process is evaluate after the fact how various design and coding decisions worked out. Quite often we have found that we've regretted NOT making something into a virtual property (a field accessible by and accessed only through its virtual methods), but we have never regretted making something into a virtual property instead of accessing it directly as a field. YMMV.

    BTW The main benefit of the DTO concept is that the application logic binds to the DTOs and not directly to the database. For simple "read and POST" web apps it is almost always going to be overkill. On the other hand, for larger applications being built by more than one developer, it is an effect tool to use in the "separation of concerns".

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  321. Spoke to Justin about this...[ Go to top ]

    What uproar? 30 posts? C'mon. A very small application, utilizing, the latest scripting flavor of the month, generating a few dozen posts does not equal uproar.

    Why is it when people are not interested, this gets converted to "threatened"?
  322. RE: What uproar?[ Go to top ]

    Did you miss the Slashdot discussion [99 3+ comments out of 546]? Or the countless other discussion forms and mailing lists this has popped up on? Or the chatter when Justin made his first blog post about it in March?
  323. Bruce Tate posted in Dion's blog in March:
    I can fill in some of the holes for you. Let me point out that the current Java version was also a rewrite of another Java version. The company is based in Austin, and I'm acting CTO. The compelling reasons to move are clear. The feedback cycle in Java takes too long, and you need to write three or four times the lines of code to do meaningful work. We'd guess that the productivity gains on Rails are probably a factor of five or ten...very significant.

    In the past, Java had always trumped more productive languages based on the community and the strength of frameworks. Now? I'm not so sure. Rails is going to make a dent.

    I'm not ready to do Rails for everything, yet. But it's a compelling language for this application, and there are many like it. We believe it will perform, and scale. The application, indeed, feels much, much faster. I'll bet that the numbers will bear that out.

    And I'm in the process of writing a book on the experience. I'll release details soon. Better, faster, lighter...er...indeed.

    I had to laugh reading the last paragraph; I've joked before about a sequel to "Better, Faster, Lighter Java", focusing on alternative languages/tools, titled "Betterer, Fasterer, Lighterer". Now, it seems like we might actually see it, written by the original authors.
  324. Missing the point[ Go to top ]

    Don't make this into Rails versus Spring. It isn't.

    I've worked with Justin on this project (I worked as interm CTO, and on the data model end). In fact, the customer told me to make the call of Rails vs. Java. Here, you've got a couple of guys who have pushed Spring pretty hard--Justin's not attacking it in any way. In fact, he's got a book (with me) that just hit the press called Spring: A Developer's Notebook. At the conference in Boston, I'll teach 3 Spring sessions, and Justin will teach 2 Hibernate classes. Rod Johnson did the forward to our book, knowing that I'm working with rails.

    We're not Spring bashers, but for this application, Rails was absolutely the right tool for the job. We're moving much faster, in the user interface and in the persistent model. We were able to tune it quicker. There's less to maintain. Like most Rails apps, this one makes sense because we control the schema and model, 100%, so Hibernate didn't give us as much bang for the buck. We have not used Spring 2 or Hibernate 3...they weren't out when we started.

    Listen, I still do way more than Java than Rails, because there are things that Java can do that Rails, and even Ruby, can't. Many of my customers are not, and should not, be comfortable with ruby. But there's a growing chunk of them that stand to gain a whole lot by adopting a higher level language with a more productive set of tools. For me, it's pure economics. If I choose the problem well, I know that I can be more productive with Ruby, scale it better, and ramp my customers up quicker. It's all in the business problem. Java should not be promoted as one size fits all.

    Spring is right smack in the middle of my tool box. There's nothing more important, including Rails. It's popular and valuable because it gets me closer to the dynamic languages (simulating code blocks in the JDBC model and other places; simulating mix ins with the AOP injection, and simplifying my testing to the level of dynamic languages because of dependency injection.

    But Rails is going to take a place in my tool box, too. For a certain class of problems (building a web front end to babysit a database that I control), Rails is more productive. It's a limited sweet spot, but a very important one.
  325. Missing the point[ Go to top ]

    Don't make this into Rails versus Spring.

    Well, in fact I find the hype about ROR pretty interesting: what I was complaining about was the statement "Spring + Hib is heavyweight, and EJB3 will relieve all of that"! ;)
  326. Oops, Rails and Java are both dead. Oh, wait, who is this new winner? ASP.NET - oh me gosh!!!

    I built a Lexus and a Corolla. Both are cars. But man, the Corolla is so much cheaper and smaller and lighter. It MUST be the better car.

    When fools (technologists) start understanding business (the reason for their existence and their clients), such debates will vaporize. That day will not come any time soon.
  327. is anyone surprised[ Go to top ]

    Making bold claims drives up traffic and gets a lot of people to try out a tool. Call it publicity through flame wars. Otherwise, most people would just ignore Ror and think nothing of it. my cynical perspective on the whole Ruby vs Java debate.
  328. Just to see what the actual speed of Java could be in a stack, environment and application that I know well, I performed some benchmarks myself. Maybe someone might find it interesting( although I mainly did it for myself): http://rifers.org/blogs/gbevin/2005/4/8/myth_java_cant_scale_down
  329. http://rifers.org/blogs/gbevin/2005/4/8/myth_java_cant_scale_down

    No one in this thread said that Java can't scale down. I said I was disappointed that the enterprise Java vanguard choose to ignore downward scalability.

    Also, I see that your winning Java implementation doesn't use Spring or Hibernate, which further supports my reaction to the feature RoR study.
  330. No one in this thread said that Java can't scale down.

    As I said in my post, this is just a remark I've seen several times during the last weeks of discussion on various web sites / blogs / news sites / .... and I thought I'd verify it. It wasn't directed at you in particular.
    Also, I see that your winning Java implementation doesn't use Spring or Hibernate, which further supports my reaction to the feature RoR study.

    There are soooo many Java solutions and frameworks. Spring and HIbernate are just one of them and are not the best choice in every situation, of course. There's nothing groundbreaking about that, that's why there's choice and alternatives. RoR doesn't have many groundbreaking features that aren't found elsewhere, the initial focus is just different and for certain type of apps you get to write lesser lines of code. That's just for certain type of apps with certain features. An excellent example of this in a micro form is that when I criticized Ta-da List for having a security problem due to one of the features (continuous editing after session timeout), they didn't actually implement the feature correctly. Instead, they fixed the security hole and removed the feature. So yeah, they were quickly able to do that and probably not in many lines of codes, but it was apparently too difficult to actually preserve the feature.
    I can start enumerating a whole collection of features that are pretty common in my day-to-day 'small' web applications that would simply blow the RoR LoC out of proportion. For some features you have to pay a small price in initial architecture, but it's a small price to pay since, honestly, how many 600 lines applications to you sell?
  331. No one in this thread said that Java can't scale down.
    As I said in my post, this is just a remark I've seen several times during the last weeks of discussion on various web sites / blogs / news sites...
    Your claim in bold seems innacurate. Please give a cite.
    There are soooo many Java solutions and frameworks. Spring and HIbernate are just one of them and are not the best choice in every situation, of course. There's nothing groundbreaking about that, that's why there's choice and alternatives.
    Then why did Steve earlier try to evangelize Spring as a nearly universal solution? :
    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.

    <blcokquote>RoR doesn't have many groundbreaking features that aren't found elsewhere...Do you consider less source as "groundbreaking"? I do. Back in the Objective-C days of Steve Jobs, there was a rivalry to see for which system an application needed the least code. Less was considered elegant.
  332. Please give a cite.
    I'm sorry, I'm not going to read over the hundreds of comments / blog posts / list archives / ... again
    Then why did Steve earlier try to evangelize Spring as a nearly universal solution?
    Because it evidently is for him, just as RIFE is universal for me, but I don't start saying it's revolutionary and the rest sucks.
    Do you consider less source as "groundbreaking"? I do.
    I'm sorry I don't. I think it's a very stupid metric and only one part of a very large picture.
  333. http://rifers.org/blogs/gbevin/2005/4/8/myth_java_cant_scale_down
    No one in this thread said that Java can't scale down.
    As I said in my post, this is just a remark I've seen several times during the last weeks of discussion on various web sites / blogs / news sites...
    Your claim in bold seems innacurate. Please give a cite.
    I'm sorry, I'm not going to read over the hundreds of comments / blog posts / list archives / ... again

    Surely someone in this thread would also have seen one of the "several" occurences you saw. Can anyone support Geert's point by giving a cite? Anyone?
  334. Surely someone in this thread would also have seen one of the "several" occurences you saw. Can anyone support Geert's point by giving a cite? Anyone?
    Did a 2 minute google search and found this: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/134136

    I never read this particular post before, but it's one of those typical statements:
    People have just managed to fit Rails into 64MB virtual servers. I
    doubt you could do the same with a Java app.


    And please stop being pedantic, you know that people constantly bash on Java being a memory hog.
  335. Surely someone in this thread would also have seen one of the "several" occurences you saw. Can anyone support Geert's point by giving a cite? Anyone?
    Did a 2 minute google search and found this: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/134136I never read this particular post before, but it's one of those typical statements:People have just managed to fit Rails into 64MB virtual servers. I doubt you could do the same with a Java app.And please stop being pedantic, you know that people constantly bash on Java being a memory hog.

    The default maximum memory of JVMs used to be 64MB! I used to develop with NetBeans within this limit. Java apps which don't use large libraries such as Swing can easily fit within far less memory. A simple 'hello world' printing app in Java can fit within only a few MB, which includes JVM, JIT, classloaders, security, and basic libraries. I think the memory hog myth arose because JVMs probably freely allocated memory up to the maximum setting, rather than working to keep memory low.
  336. http://www.sitharus.com/blog/archives/2005/04/more_rails_and_1.html

    One thing I'll say about Java, it may scale up well, but it doesn't really scale down. JVMs are huge, Ruby interpreters aren't. My home server with 256MB of RAM, or my main server with 64MB of RAM, just don't cut the Java mustard.

    ... another one
  337. Then why did Steve earlier try to evangelize Spring as a nearly universal solution?

    I didn't. I said it was useful for certain things. I did not call it a 'universal solution'.
    RoR doesn't have many groundbreaking features that aren't found elsewhere...
    Do you consider less source as "groundbreaking"? I do. Back in the Objective-C days of Steve Jobs, there was a rivalry to see for which system an application needed the least code. Less was considered elegant.

    Firstly, the lessons of that period were learned long ago. Brief code is not always the most maintainable - consider the horrors of some small C++ programs, where a few operators can hide vast amounts of confusing code. RoR mistakes brevity (e.g. not specifying field names in classes that map to database tables) for clarity.

    Secondly, as I keep asking... If you really want less source, why not use some sort of visual tool, such as Studio Creator? Why do you insist on writing all those unnecessary lines lines of Ruby for your small projects?
  338. http://www.cnn.com/2005/TECH/science/04/14/mit.prank.reut/index.html
  339. http://www.cnn.com/2005/TECH/science/04/14/mit.prank.reut/index.html
    So you can be replaced by a computer program! Are are you just that as others have claimed?
  340. http://www.cnn.com/2005/TECH/science/04/14/mit.prank.reut/index.html

    Ah. Rolf stage 2:

    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.