Forgot your password?
typodupeerror
Programming IT Technology

Ruby On Rails Showdown with Java Spring/Hibernate 555

Posted by Hemos
from the battle-of-the-overhead dept.
Paradox writes "Java developer Justin Gehtland recently tried re-implementing one of his web applications in Ruby on Rails instead of his normal Java Spring/Hibernate setup. His analysis of overall performance and application size was startling, to say the least. The Java app's configuration alone was nearly the size of the entire Rails codebase, and Rails application was significantly (15%-30%) faster! At the same time, the Ruby community is abuzz because Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. Will Ruby on Rails become even faster as a result?"
This discussion has been archived. No new comments can be posted.

Ruby On Rails Showdown with Java Spring/Hibernate

Comments Filter:
  • by killjoe (766577) on Monday April 04, 2005 @11:50AM (#12134297)
    I think the crux of the matter is that he was not taking advantage of some of what these java containers offer. Things like queues, soap, RMI, CORBA bindings, remote invocations etc.

    The lesson here I think is that unless you plan on running on multiple containers and using asyncronous calls java is overkill.

    If you do need those things then ROR won't work at all.

    Another thing is that ROR wants you to design the database from scratch to fit it's naming rules. It's not really designed to work with existing databases. For example it can't map the ugly database field names into nice attribute names for your objects. To me that's a pretty big shortcoming.
  • Horses for courses (Score:3, Interesting)

    by 16K Ram Pack (690082) <(tim.almond) (at) (gmail.com)> on Monday April 04, 2005 @11:56AM (#12134368) Homepage
    From what I've seen so far (trying it out), RoR has its place.

    It's a little bit like using something like MS Access. If you play along with MS Access, and don't try and do things that it doesn't do particularly well, then you can actually build desktop database systems very quickly. If you try and go outside of the "Access way", it becomes a quagmire.

    There are tens of thousands of sites out there that don't need to have queues, SOAP, RMI etc. They might be someone's list of restaurant reviews or something. Maybe RoR has a good place for that.

  • Re:You are all wrong (Score:1, Interesting)

    by Anonymous Coward on Monday April 04, 2005 @11:57AM (#12134374)
    Right, except that this is all nonsense. For instance, due directly to Python's nature, Python will always be slow. Python HAS to do a lookup for variable names. This will always be slow.

    Java is slow. How much of this is due to the nature of the language, and how much due to its implementation? I dunno, I really don't know much about Java. I do know that every interactive Java program I have ever used has been hilariously, stupidly, ridiculously slow. Practically speaking, the point is, right now, if performance is a significant issue, Java is not the right choice.

    I disagree with this nonsense about "C++ is not the way to go." C is almost never the right choice. Most of the people currently writing C would be better off with a much higher level language (whether it be Python, Ruby, Lisp, whatever), and the rest would be better off with C++. Exactly what do you gain by using C rather than C++? Nothing. C has NO benefits over C++.

    (In case it wasn't clear, I do agree that performance often isn't the issue that people think it is.)
  • Re:Application (Score:1, Interesting)

    by Anonymous Coward on Monday April 04, 2005 @11:58AM (#12134385)

    For a great analysis look here: weblog [rubyonrails.com]

    You call that an analysis? You must have serious problems.

    And please tell me what the Rails version does more. I'm very interested. The Java version does more imho since it uses ordinals for every entry and keeps them always ordered, the Rails version sets the ordinals to null if the entries are done and relies on the database natural ordering.

    Screenshots like this are totally useless since they compare things that can't be compared. Rails handles lists well because it was written for Basecamp that does to-do lists (and more). So of course it's shorter since the functionality has simply been moved to the core framework (Acts -> List).

  • Re:Here we go again (Score:5, Interesting)

    by TrekCycling (468080) on Monday April 04, 2005 @12:03PM (#12134434) Homepage
    Are you serious? I would argue that if there is such a thing as a J2EE "fanboy" (to use a gaming term) then that is an individual who cares only about job security and not about being a good technologist. I'm a developer with 10 years of experience. My experience is in everything from ASP with VB/JScript to PHP to Java. I use whatever the company deems best at the time or whatever I feel is the best solution at the time. I think there is a virtue in being agile and being able to pick up new technologies. The downside is that you don't go as deep. So I don't have 5 years of J2EE on my resume. The upside is that I'm not a J2EE fanboy and if next week my company decides that Ruby is the way to go then I pick up a Ruby book, start poking through the documentation and learn Ruby.

    I think J2EE "fanboys" are either too lazy to learn something new, too philosophically rigid to allow for the possibility that there are other ways to accomplish the task at hand or don't, or they're worried that RoR becoming popular would invalidate their 5 years of J2EE experience.

    I know people that probably fit this bill in some manner. I would hope for their sake and the sake of their organizations, however, that they'd be willing to pragmatically look at the problem being presented and make a decision based on what's best for the organization, be it Java or Ruby. At the end of the day I believe being a good technologist and a good communicator, being eager to learn and willing to try new things is more valuable than just being a Java wonk. Flexibility is a virtue. I imagine most Java developers are more flexible than you give them credit for. Although I know there are exceptions.
  • Re:You are all wrong (Score:1, Interesting)

    by Anonymous Coward on Monday April 04, 2005 @12:05PM (#12134459)
    Now, what we can compare is the implementation of a particular language

    Well, I think it's pretty obvious that we're talking about the Ruby on Rails implementation of Ruby and Sun's implementation of Java here, so in effect we are comparing implementations, not the languages themselves. That's just the way programmers talk about stuff and most are easily able to make that connection without requiring explanation.

    What you said is absolutely correct and I totally agree, but it's not really applicable in this situation.
  • by ramone1234 (588375) on Monday April 04, 2005 @12:16PM (#12134549)
    I checked out the video demo at http://media.nextangle.com/rails/rails_setup.mov [nextangle.com] and I have to admit that I'm pretty impressed. This framework eliminates a lot of the tedium that goes into developing web apps... Here's my problem though... Is there any reason it has to be in Ruby? I've heard of python's equivalent 'subway' ( http://subway.python-hosting.com/ [python-hosting.com] ), and I'm wondering if Ruby has some language feature that makes it inherently more suitable than other languages (like python) for this 'rails-style' of development...

    Otherwise, I think I'd just rather stick with Python... It seems to have a bigger and more mature standard library, and I can find more web hosts to support it... I'm not trying to start a language war, I'm just looking for the practical solutions...
  • Re:Ruby is a toy (Score:3, Interesting)

    by Jerf (17166) on Monday April 04, 2005 @12:22PM (#12134614) Journal
    You should try one of these dynamic languages sometime. You'd be surprised how easily Python or Ruby lets you roll your own messaging systems, simply because they are so easy to work with. You can often roll up a custom solution that exactly matches the domain in less time than it would take to set up a Massive All-Purpose Java solution. I know, I've done it at least twice now.

    Does my custom solution do absolutely everything that the Massive All-Purpose Java solution does? No, and that's half the point. I can still add what I need faster than you'd believe.

    Normally I'm all about using libraries, but there is a cost to them as well (bending your app to the library's assumptions), and these languages make some things so easy it's not worth it anymore.
  • Re:Security (Score:3, Interesting)

    by Karma Sucks (127136) on Monday April 04, 2005 @12:28PM (#12134666)
    The first one seems to be in PHP anyway.
  • Re:Mojavi (Score:3, Interesting)

    by MAdMaxOr (834679) on Monday April 04, 2005 @12:29PM (#12134676)
    I tried Mojavi, and I liked it. However, it's not nearly as compelling as RoR, mostly because it's missing the *magic*. Mojavi is condensed best practices for PHP, and RoR is new, and borderline voodoo.
  • by fishbowl (7759) on Monday April 04, 2005 @12:35PM (#12134742)

    >Hibernate seems to be the most hyped technology for
    >webapps on java right now.

    I use Hibernate for databinding in production systems with thousands of users. I don't think of anything as "hype" when it works. Hibernate is very good at what it does, although it is a little tricky to learn how to use it effectively.

    As to the comparison of configuration lines, you have a huge amount of power in Java config, and the tradeoff for that, of course, is a little complexity.
  • by CatGrep (707480) on Monday April 04, 2005 @12:38PM (#12134777)
    You count getter setter methods? You know that they can be produced lets say in 3 seconds with any modern Java IDE..

    Good point about the getter/setter methods. To which I reply: You know they can be generated for you if you use a modern language like Ruby.

    class Foo
    attr_accessor :bar, :baz, :foo
    end

    Now the class Foo has accessor methods (getter and setter) for the instance vars bar, baz and foo.
    A total of six methods were created from that one line of code. No need for a 'modern Java IDE' - vi or emacs work fine. You want read-only access? Use attr_reader then only the getter methods will be created.

    This is probably why the method count for Ruby in the article was significantly less than for the Java version.
  • Re:Mojavi (Score:3, Interesting)

    by CatGrep (707480) on Monday April 04, 2005 @12:42PM (#12134821)
    RoR has given PHP a run for it's money.

    PHP is now very tired after that race. Please let it lie down and rest.
  • by Anonymous Coward on Monday April 04, 2005 @12:43PM (#12134835)
    Uh, but he didn't even really know Ruby well before starting. And he is an extremely experienced Java programmer. I would say those cancel each other out.
  • Re:Faster? (Score:3, Interesting)

    by Karma Sucks (127136) on Monday April 04, 2005 @12:45PM (#12134851)
    CPAN modules are never going to fit into the Ruby way of doing things, Parrot or not, unless I'm missing something?

    There are multiple sources for Ruby modules, as I'm sure you already know. So far they've worked out quite well for me.

    I agree that RubyGems is quite brain-damaged.
  • by greg_barton (5551) * <greg_barton@ya[ ].com ['hoo' in gap]> on Monday April 04, 2005 @12:49PM (#12134883) Homepage Journal
    I love Hibernate. Hibernate is not a speed demon. It's a scalability demon. It's a OR mapping demon. It's a flexibility in persistence demon in spades.

    It ain't fast. It's not dog slow, but you've got to pay the piper somewhere. If you cache out the wazoo you can get some decent performance, but then you pay in memory. (and if you're clustering, in multicast interserver network traffic)

    So get over it and use the tool for what it was meant to be used.
  • by MarkWatson (189759) on Monday April 04, 2005 @01:04PM (#12135021) Homepage
    I earn most of my living writing custom web apps using (usually just part of) the J2EE stack. I love J2EE because it is rock solid - debugged web apps seem to run forever :-)

    That said, I have been working through the fantastic second edition of "Programming Ruby" and I have been using Ruby on Rails. Another great technology for use in my consulting business!

    While I understand that it is good for developers to share their experiences as per what works for them and what does not, I think that these J2EE vs. RoR discussions are starting to loose value based on the time spent on them.

    Now, to get up to speed on J2EE probably takes several months of dedicated study and lots of experience. Ruby and specifically Ruby on Rails might take a half dozen evenings of study instead of watching TV. If you are a J2EE developer the cost of trying RoR is low. The cost of trying J2EE is much higher.

    The choice of platform does not have the impact that design choices make on the success of projects. This is obvious, but: do some up front analysis and then try to use the best tool for a job.

    BTW, I have a few open source projects in both Java and Ruby (shameless plug :-)
  • Sure. (Score:5, Interesting)

    by Some Random Username (873177) on Monday April 04, 2005 @01:07PM (#12135047) Journal
    Rails sucks because its written in ruby, which is slow (excruciatingly slow for recursion and text processing), and doesn't support OS level threads. The fake threads ruby does have can under uncertain circumstances cause the entire interpreter to block.

    Rails sucks because David thinks security is your problem, and leaves in functionality that can easily be misused to create a security problem if you haven't read the rails code thoroughly to understand what its doing underneath. Convenience trumps security in rails development.

    Rails sucks because its development is incredibly mysql centric, and doing anything beyond the basics with real databases will result in tons of bugs, and then you are told "try again in a few weeks when there's a new version, it should be fixed by then". Then the new version has different bugs instead. Continue this cycle until you decide to use mysql or stop using rails.

    That's all I've got, any other problems I've seen are personal preference issues, or things that can easily be fixed as rails matures.
  • Re:Security (Score:2, Interesting)

    by paulpach (798828) on Monday April 04, 2005 @01:08PM (#12135049)
    Not only that, but it is full of XSS vulnerabilities:

    Scaffold is vulnerable, input any data like

    <script>alert('I have been fooled')</script>

    and when you see the data it will happily execute that code.

    The bug tracking system they use is also full of XSS holes. Browse their database and you risk giving your login/password to anybody.

    Even on the tutorials, they teach people to write XSS vulnerable software. From the first tutorial [onlamp.com]:

    ...
    <input id="recipe_title" name="recipe[title]" size="30"
    type="text" value="<%= @recipe.title %>" />
    ...

    The user only has to input

    "/> <script> alert('fooled again')</script>

    for the title, and presto, he can get all other user's cookies

    All the other tutorials have the same vulnerability.

    The developers don't care about these. Some people even activelly oppose fixing them. I can only imagine what else is in there. I wouldn't touch ruby on rails with a 10 foot pole for anything where security mattered.

  • by CatGrep (707480) on Monday April 04, 2005 @01:14PM (#12135113)
    I'm not trying to start a language war,

    Oh, of course you are. Might as well just admit it.

    As far as Ruby vs. Python features go:
    1) code blocks. Ruby lets you pass code blocks around. Sounds pretty dull, eh? But in fact it's what makes it possible to create Domain Specific Languages in Ruby quite easily without needing to create a special parser. In many ways Rails can be thought of as a domain specific language built on Ruby.
    2) classes are always open in Ruby(including the Class class). By 'open' I mean you can always add new methods to a class (or even a particular object). Another feature that makes it easy to create DSLs
    3) continuations. (Not that Rails makes use of them, but some other Ruby-based web programming frameworks do)
    4) Ruby has true lambdas. AFAIK Python's lambdas are pretty limited (limited to one expression?)

    Also, can you embed Python in HTML? (seems that the whitespace issue would cause a lot of problems with doing that)

    I'm just looking for the practical solutions...

    Give RoR a try. You might just find that it'll do everything you need it to do now without needing to wait around for a Python-based clone. What could be more practical?
  • Re:Here we go again (Score:5, Interesting)

    by C10H14N2 (640033) on Monday April 04, 2005 @01:22PM (#12135222)
    In sixteen years of developing for large-cum-huge organizations, I've found that there is one overriding criterion for EVERYTHING that such companies do: stability.

    People who are "fanboys" may just be so invested in [something] that to achieve the same depth of _tested_ knowledge in [something else] would take five years. They may in fact be looking at things like Ruby, but they aren't planning on switching their production development to it until both they and it are seasoned because it would be insane to do so. It's not just THEIR level of comfort that is in question, it is the organizations ability to accept it.

    Before someone slams on corporate culture limiting your godlike creative powers, it's actually pretty reasonable. A business is a machine. You want to get some return on the machine before you rip the engine out and retool it--and that timeframe is generally ~5 years. Think of it like buying a car. YOU may be able to afford to replace yours every year or maybe you're a grease monkey who does a frame-off rebuild every spring just for kicks, but the vast majority don't want to go through the hassle and expense on an annual basis.

    So, Ruby has now reached the point where it is a serious contender. Expect it to start replacing J2EE somewhere between 2008-2010.
  • by TrekCycling (468080) on Monday April 04, 2005 @01:25PM (#12135260) Homepage
    I think there's a good chance this is part of the problem. I assume you meant universities switched from C++ to Java, right? They did locally where I live. I think that's a shame. I'd rather learn something more challenging like C++ as my first language (my first language was C) so that that way I can understand basic concepts of programming at a lower level before moving on to Java, etc.

    I think part of this also is what you pointed out, people who went into CS because that's where the money was. For my part I studied English in college. I wrote a lot. I read a large chunk of the classics of post-modern, modern and earlier literature. And then somewhere halfway through college I fell in love with computing. So I bought "Teach Yourself C on the Macintosh" (I think because it was the book in the store that came with a compiler, whereas the Pascal book didn't).

    Then when I graduated from college, being a former landscaper, I applied for a couple different jobs. One was as a landscaper. One was for $10 an hour doing HTML, JavaScript, CSS, Photoshop, etc. I got the web job first, so I became a programmer. I didn't seek it out, but rather fell into it and enjoy it enough to keep learning new things.

    I think you're right that there is a distinct difference in mindset there. I wasn't looking for a career. I was looking for a job I enjoyed. And all the same I won't fight against new technologies to cling to my newfound career. I could easily be happy doing landscaping if for some reason all the world needs is Java experts. But if they need generalists who love what they do, then I won't be planting trees again for a while.

    That's how I look at it.
  • Zope 3 (Score:4, Interesting)

    by Lodragandraoidh (639696) on Monday April 04, 2005 @01:30PM (#12135306) Journal
    I wonder how Zope 3 (python web application framework+more) compares to these?
  • by sbrown123 (229895) on Monday April 04, 2005 @02:05PM (#12135717) Homepage
    I was able to read the site but unable to post comments back to the author. I'll drop them here instead to follow up on my prior posting comments:

    -----

    A few problems with your testing that I could see:

    "So, for the sake of total specificity, the following numbers were generated on a 1.5GhZ Mac OSX (10.3.7) PowerBook with a 4200rpm hard drive and 1GB of RAM."

    The Java Virtual Machine running on Macs has always been questionable. Its not Sun's implementation and has not been as heavily updated by Apple. First I would start by running your tests on a Windows or Linux box using the Sun JRE 1.5.

    "The Java app is running on Jakarta Tomcat v 5.0.28, while the Rails app is running in Lighttp with FastCGI. The setups are standard for each application stack."

    As mentioned by a prior poster, Tomcat is only a reference implementation. Its not built for speed. The Ruby setup you used, on the other hand, is. This alone is a major oversight in your testing.

    "Number of Methods:
    Rails: 126
    Java: 549"

    Having to write 4 times as many methods is a clear indicator that you are using the wrong framworks to get the job done. There are hundreds of frameworks for building web applications between the languages. Spring with Hibernate must not be the right mix.

    "Configuration Lines
    Rails: 113
    Java: 1161"

    I am guessing you used Xerces for parsing on the Java side. This is bad since Xerces is not a very quick parser and there are plenty of Java XML parsers that are much better suited when speed is concerned. Look at using XPP or Lightning instead. With JAXP (if Hibernate and Spring support it) you will not have to change code to use these in place of Xerces. Also, any time you are comparing a XML parsed document versus and non-XML parsed document the latter will always win. Try using frameworks that do not depend on XML configuration files.

    True language performance comparisons should never be done with web applications. There are simply too many variables. I know this was not your intent (doing language performance comparisons), but that is how your article is being viewed by others. People are always itching for a battle between the languages.

    Different languages are suited for different tasks better than others. For example, I once had to translate a Perl application to Java for my work. Due to what that Perl code was doing, the finished Java application was several times larger and slower. Perl was better due to the task at hand.
  • Re:You are all wrong (Score:1, Interesting)

    by Anonymous Coward on Monday April 04, 2005 @02:11PM (#12135789)
    You'll have to tell me, since I'm unaware of any such mysteries, and I never said that purely functional langauges can't be optimized. I didn't even say that they can't be optimized to at least match the performance on non-functional languages. What I did say was that you could not do so practically (i.e. the compute resources required are disproportionate to non-purely-functional languages by orders of magnitude).
    What a bunch of crap. You don't know what you're talking about. Functional languages are *easier* to optimize, not harder. I challenge you to provide a reference. You won't be able to, because you are a poser.
  • Show me the code (Score:3, Interesting)

    by MSBob (307239) on Monday April 04, 2005 @02:19PM (#12135867)
    So.... I should make my next platform decision based on some guy's blog where he quotes some suspicious looking numbers within some unknown domain space and refuses to open the source code for public scrutiny? The Ruby trolls are really out in full force lately.
  • by CatGrep (707480) on Monday April 04, 2005 @02:20PM (#12135876)
    Well, this is just silly. I'm not a Python expert by any means, but even I know this works:

    def func():
    def my_code_block():
    print "Hello, World!"

    return my_code_block;

    f = func();
    f();


    Of course. You're basically passing around a function reference. That's not what I'm talking about.

    What Python doesn't have is nice, clean, anonymous code blocks

    That's what I'm talking about. In Python you can't do something like this:
    def my_while(cond)
    return @ret unless cond
    @ret = yield
    retry
    end

    my_while i<10 {
    puts "i: #{i}"
    j = 0
    my_while j<10 {
    puts " j: #{j}"
    j+=1
    }
    i+=1
    }
    my_while looks like a natural extension of the language. I'm sure you could duplicate this function in Python, but it wouldn't look like a natural part of the language.
  • by melted (227442) on Monday April 04, 2005 @02:24PM (#12135918) Homepage
    It does not support Unicode. No unicode strings, no unicode regexps. So if you write your apps with l10n/i18n in mind, Java is still your best choice (or .NET/C# if you're on Windows).

    Unicode is expected in v2.0, but nobody knows when it will come out.

    Plus, the IDE doesn't support code completion, and having worked with code completion for years now I'm now much less productive without it.
  • by aziegler (201013) <halostatue@gm[ ].com ['ail' in gap]> on Monday April 04, 2005 @02:31PM (#12135994) Homepage
    1. I don't believe your SOAP comment is correct. Remember, ROR doesn't provide SOAP per se; it's SOAP4R that does. ROR may provide basic SOAP4R capabilities, but that in no way means that it's using 100% of the features. The ROR team may have decided that the typical use of SOAP with a ROR site is likely to be 25% of the SOAP capabilities. You can *still* do the full SOAP support -- you just have to work a bit harder on it.

    2. Yes, but J2EE is an overblown, overladen framework to begin with. When people need queueing and remoting technologies with ROR, it will be added. In fact, the remoting technology -- at least in part -- is already there through DRb (if you haven't looked at it, you should) and Florian Groß's breakpoints code. I would strongly disagree with your assertion that the J2EE components for these are "comprehensive" and especially "unified."

    3. Again, you *can* do field name mapping, but it's a bit more work to do so. There's no reason you can't create aliases, e.g.:

    def deg_f=(fahrenheit)
    write_attribute("celsius", (fahrenheit - 32) * 9 / 5.0))
    end

    def deg_f
    (read_attribute("celsius") * 5 / 9.0) + 32
    end

    See http://ar.rubyonrails.com/classes/ActiveRecord/Bas e.html [rubyonrails.com] for more information.

    Field name mapping is easy; not as easy as simply following the Rails model, but it's *easy*. SOAP is a bit harder, and other stuff maybe a bit harder still. It's all still easier than trying to pick up all of J2EE.

    -austin
  • Code Completion (Score:3, Interesting)

    by Paradox (13555) on Monday April 04, 2005 @02:39PM (#12136087) Homepage Journal
    Ruby does not have a canonical IDE, unlike Java.

    However, most developers agree they are more productive in languages like Python, Ruby or OCaml than they are in languages that do have auto-complete environments (e.g., C++, Java, C#, etc...).

    This shouldn't be taken as a "We don't need no stinkin' code completion" comment. It's just an observation that code completion would be icing on the cake, but the cake is allready there, tasty and full of chocolate.

    If you want to try ruby with code completion, check out FreeRIDE [rubyforge.org]. It is not done yet, but it'll show you the direction things are going.

  • by computational super (740265) on Monday April 04, 2005 @03:35PM (#12136648)
    Know your latin: i.e.: "id est" or "that is" e.g.: "exempli gratia" or "for example"

    To which I'd like to add, "et cetera [reference.com]: et = and, cetera = the rest" . There is no work "eck" in the Latin language, and the phrase "Eck cetera" is nonsense. And you sound stupid if you say it. And, while I'm on the subject, there are two "s"s in the word asterisk. It's not an asterick, even if you verb it.

    The fact that bringing ignorance to the attention of the general populace is considered worse than being ignorant itself is a sure sign that we've reached a period of pure intellectual unenlightenment - the second dark ages hath begun. Well, Paradox, let me be the first to stand behind you in solidarity in the battle against stupidity and deliberate ignorance.

  • Re:You are all wrong (Score:2, Interesting)

    by Effugas (2378) * on Monday April 04, 2005 @04:07PM (#12136996) Homepage
    It you are doing advanced GUI development and prototyping, C++ is probably not the way to go ( since it is harder to write fast and correctly ).

    You are incorrect.

    It has become quite difficult to ignore the reality that for advanced GUI coding, C++ has established itself as one of the few languages that truly scales to operational use. From an operational standpoint -- meaning, roughly, that the output is actually something you want to run, only the following toolkits have responsive, shell-integrating output:

    1) MFC (C++)
    2) Qt (C++)
    3) WxWindows (C++, and something I've only recently been convinced of by NessusWx. I haven't seen anything fairly mature out of Perl/Python Wx bindings yet. There's a reason everyone's waiting for Open Source Qt4.)
    4) Delphi (Very noticably not C++, not exactly Pascal either.)
    5) VB (Also not C++, but has an entirely different set of scalability problems)

    That's pretty much it. However Swing is to code for, it's more painful to deploy and just a beast to use. (It's 2005 and, like PKI, Java on the Desktop is an expensive joke that's no longer funny.) I keep wanting to see good things from SWT, but however the system looks it's just not very responsive -- either in boot time or in actual use.

    The only thing I actually vacillate on is GTK in C. Scite and GAIM provide acceptable, even very good output. It sure doesn't look very nice to code for though.

    I reserve judgement on C#'s Windows.Forms for now.

    Ultimately, surveying the field, C++ is really doing something right, and it's time people stop repeating the Alice-In-Wonderland myth that you wouldn't want to use it for GUI development. GUI's are one of the big reasons *to* use C++...everything else can hide its performance problems on a remote server, or by the lack of need for interactivity.

    Incidentally, don't discount the problems introduced by interpreters. You know why Flash still fails as a GUI hosting platform, despite appearing to be a perfect choice? Event loop speed. Flash updates events only a couple times a second, meaning you're sitting there, waiting hundreds of milliseconds for your change to get noticed. Java has had similar problems.

  • by Anonymous Coward on Monday April 04, 2005 @04:07PM (#12137000)
    it's a frickin' framework + code generator!

    The Ruby folk go to extremes sometimes to get developers' attention: here they're presenting Ruby on Rails as something as wonderful and new,whereas every language has such code generators: Perl has Mason, MayPole and many others that do everything RoR does but without the insane premise that "everything is an object" (which Ruby is based).

    Ruby is one man's honest effort to objectify Perl. A good effort, I might add, but because it's derived from Perl and has such a small user base, Ruby will remain a niche language.

  • Re:You are all wrong (Score:3, Interesting)

    by kubalaa (47998) on Monday April 04, 2005 @04:11PM (#12137053) Homepage
    FYI: the higher level a language is, the *more* possible it is to optimize in general (though the optimizations may be difficult). It is languages like C that are "impossible to optimize", since they way overspecify, for example, the order-of-execution, and force optimizers to bend over backwards preserving semantics that the programmer doesn't even care about.
  • by FatherOfONe (515801) on Monday April 04, 2005 @05:50PM (#12138272)
    I would read the article but the site is down.

    My first issue with this is that he uses spring and hibernate and then compares speed. WTF is this about? You use an OR mapping tool that is fairly robust and you then talk about speed? Why didn't he just code all the SQL by hand and forget Hibernate. On a LOT of applications this would perform much better. Heck he could even rip Spring out and again do what he needs by hand.

    How much would that have reduced the size?

    Now for my next question. How did both applications scale? Where both speeds acceptable at the required load/user level? Heck if you are building a system that you want to maintain, and potentually switch out databases, then Hibernate ROCKS. Yes there is some overhead, but for 99% of the applications on todays hardware this will not be an issue.

  • Re:Here we go again (Score:4, Interesting)

    by hugg (22953) on Monday April 04, 2005 @06:20PM (#12138575)
    I am not a J2EE fanboy, but I depend on it for my bread and butter. As long as I work within the federal/enterprise development sphere, I will probably depend on it for quite some time. This is because big organizations in the U.S. are standardizing on J2EE, and to some extent dot-NET.

    One reason for this is because their IT departments discovered a few years ago that they have accumulated all sorts of crufty code written against multiple languages and platforms, and had no way to manage it because all the contractors who wrote it had taken the money and run. Seeing shrinking IT budgets, and new platforms (like ROR) coming out every year, they decided to make their lives easier by standardizing on the most best-of-breed (read: most resumes available) platforms. This would allow their IT folks to only have to learn one set of technologies to deploy and manage applications internally.

    IT managers like standard platforms, because they are sold on the idea that they can develop "web services" which can let apps "transparently share data" and allow for "collaborative whatchamacatchie". Most often, the reality is that these organizations still have a tremendous amount of data scattered across N databases and M organizations, and no magic dev platform is going to solve that without effort.

    I regard most of the J2EE architecture as over-engineered and overkill on most projects I've done. I prefer to use it stripped-down as I can get away with. Heck, I could probably embed a Jython interpreter in a servlet and use it on a project without anyone noticing. But for large organizations, the trend is toward less diversity.

The reason why worry kills more people than work is that more people worry than work.

Working...