Hibernate vs. Rails: The Persistence Showdown

Home

News: Hibernate vs. Rails: The Persistence Showdown

  1. Ruby on Rails is a web framework but also integrates its own ORM, ActiveRecrod. Hibernate Quickly co-author Patrick Peak has written a hands-on comparison between Hibernate and Rails Active Record, concluding that while Rails is well suited for pure CRUD / smaller projects, it's ORM layer lacks a number of essential features required for larger projects.

    Specifically, Patrick looks to answer the following questions:
    • Basic Architecture Patterns - Hibernate and Rails each use each use completely different patterns of ORMs. What does that imply?
    • Explicitness - Hibernate and Rails define mappings differently, Hibernate explicitly and Rails implicitly. What does that mean, and how important is it?
    • Associations - Each supports associations, what do they look like for each of them?
    • Transitive Persistence Models - How does each tool deal with persisting objects?
    • Query Languages - How do you find objects?
    • Performance Tuning - What options do I have to tune them?
    Read Hibernate vs. Rails: The Persistence Showdown

    Threaded Messages (109)

  2. RoR is Mostly Hype[ Go to top ]

    I think everyone can agree that Ruby on Rails is still a toy...
  3. One thing to remember and I think is glossed over is that Active Record is based on the pattern of the same name and Hibernate is based on several patterns including UnitofWork.

    I do believe if Mr. Fowler would have thought that they were the same or would have had the same advantages and features, he would have pointed that out and made them the same pattern. He did not and for good reason. His book that includes them differenciates them on purpose and when we look at there being used, we need to keep that in mind.

    Rails and Active Record specifically is geared towards the simpilest thing that will possibly work. It's the 80/20 rule.

    As the article points out it does provide for doing "down to the metal" SQL code and returning the resulting values in run-time customized objects. This is painted in a bad light in the article when it mentions you may have to have a "custom view" for that result set, but this just shows the flexibility of the system.

    The example is also flawed in it's comparison about the SQL queries. Here's why...

    The Rails version:
    # Like find all, but need complete SQL
    @minersWithSqA = Miner.find_by_sql [
            "SELECT m.*, g.square_area FROM gold_claims g, miners m " +
            " WHERE g.square_area = ? and m.gold_claim_id = g.id", 1000]

    The Hibernate version:

    // Similar to join query above, but no need to manually join
    Query q = session.createQuery(
       "from Miner m where m.goldClaim.squareArea = :area");
    List minersWithSqA = q.setParameter("area", new Integer(1000)).list();

    The Hibernate version does the comparison of the objects square area, but only returns miner objects. They don't have the goldClaim or square area in them. You must travers to get them. (In this case the references to them are not loaded at query time but only on lazely) The rails query on the other hand does pull back the gold area into the resultant object even though it doesn't have too. It too could just return miner objects while letting the where clause check the gold area.

    Having pointed that out, notice that the Rails version does have the power to do this without some custom result class. The object is still a "Miner" in type, but now has a custom on the fly attribute that I can (if I want too) use in the view I display it in. This Miner object can still be used anywhere where a Miner can be. Can Java add an instance variable on the fly. I think not without some very wierd trickery.

    There are lots of pluses and minuses that could be derived from both approaches for different situations, but as I mentioned at the top of this reply, the patterns that the OR layers are based on help dictate there pluses and weakenesses and add to that the languages and there different powers and usages and you get different approaches and solutions.
  4. The example is also flawed in it's comparison about the SQL queries. Here's why...The Rails version:# Like find all, but need complete SQL@minersWithSqA = Miner.find_by_sql [        "SELECT m.*, g.square_area FROM gold_claims g, miners m " +        " WHERE g.square_area = ? and m.gold_claim_id = g.id", 1000]The Hibernate version:// Similar to join query above, but no need to manually joinQuery q = session.createQuery(   "from Miner m where m.goldClaim.squareArea = :area");List minersWithSqA = q.setParameter("area", new Integer(1000)).list();
    There is no "manual" joins in SQL, you can use "NATURAL" join in SQL without predicates too. Not all of queries are trivial and theta joins are usefull too.
  5. No Manual joins in SQL[ Go to top ]

    The original article referred to the joins as manual in the code comments. I copied it verbatium, so your point about manual queries is to be taken up with the author of the article.

    Your point about queries and things is true regardless of which framework you use.

    What I pointed out was the the test comparison was not congruent and thus was flawed as a basis for comparison until they do the same things.

    I also pointed out that Java/Hibernate can not do some of the things that the Ruby version did without lots of extra trickery at the meta level in Java where as the Ruby version just did it due to the language supporting it.
  6. They should really do a comparison between Hibernate and well written JDBC/vendor specific SQL.

    JDBC would beat it easily. (mass updates anyone???)

    Many companies have standardized on a single DB vendor. Programming all these abstraction layers because they 'might' someday change is stupid.
  7. JDBC would beat it easily. (mass updates anyone???)

    Um, you mean like HQL 3.0 update queries?


    >> Many companies have standardized on a single DB vendor. Programming all these abstraction layers because they 'might' someday change is stupid.

    If you've ever bothered to read anything we say about Hibernate, you'll realize that we *never* proffer DB independence as a compelling advantage of ORM compared to direct SQL/JDBC (though, for certain people, it is indeed useful). So this is a strawman.
  8. I work for a fortune 25 company and we opted not to go with Hibernate on our last project for the the reasons of having a standardized, legacy DB and leveraging the performance of straight JDBC->POJO.

    Now with Hibernate 3 and its SQL Query capabilities (only to name one), I've been using its Session as the core of our persistence layer on our newest project.

    Everyone writes the DAO facades anyways, and now I can more quickly build functionality off of the DB in our app, while at the same time, know that I can always go straight JDBC within my DAO methods if need be. With some of our more complex DB schemas... H3 and JDBC are about half and half within the DAO, but the JDBC connection used is provided by the Session.
  9. >> JDBC would beat it easily. (mass updates anyone???)Um, you mean like HQL 3.0 update queries?>>

    You mean those queries that get executed through the glorious "Query.executeUpate" method (no, that wasn't a typo on my side) in the production-ready Hibernate 3.0 RC1? The ones which are not even mentioned in the reference docs (which, BTW, say "Hibernate 3.0 beta4" in their title), at least not in an obvious fashion?

    I think that the point regarding mass updates is still valid: if that's the cornerstone of your processing, O/R mapping doesn't really fit in the first place.

    Juergen
  10. That's a one-dimensional view of things.

    If raw performance is what you imply, then yes JDBC will win. But even then ORMs provide value-adds like: Collecting multiple updates to a row in the same transaction and issue a single consolidated update. Things like these can be hand-coded, but with an ORM its already there.

    More fundamentally ORMs are about isolating developers (NOT hiding) from having to do mundane tasks like tracking dirty fields, add/remove of relationships and propagating this to DB and concentrate on important things like implementing biz logic.
  11. They should really do a comparison between Hibernate and well written JDBC/vendor specific SQL.JDBC would beat it easily. (mass updates anyone???)Many companies have standardized on a single DB vendor. Programming all these abstraction layers because they 'might' someday change is stupid.

    -You can still use SQL for your mass updates!

    -You can standardize all you want, but if you are a vendor who builds DB software, you can not predict which DB your customer uses. There are probably many other examples where your DB standardization argument does not work.

    -If you base your software on objects, sooner or later your data ends up in them. If you prefer to do this crud work by hand, then fine. There can be productivity gains if you use ORM. This becomes more evident when your DB schema is large.

    -Not everyone of us is an SQL wizard. Hibernate can probably do a better job with little knowledge from your part.

    -I have a real-life example where I have a template database and then some custom ones that are 'extended' from the template. Hibernate saves the day because I can now build a base library of DAOs and DB objects which I only need to extend when necessary for each custom database - a dramatic gain in reuse and productivity.

    I could continue but it is clear that there are uses for plain SQL/JDBC and ORM, all alike.
  12. They should really do a comparison between Hibernate and well written JDBC/vendor specific SQL.JDBC would beat it easily. (mass updates anyone???).

    I see no reasons to compare connectivity API to mapping (transformation) framework. It doe's not look consistent but probably it makes sence to use both ways in the same application, I see nothing wrong to use many programming languages in the same system too. I do not think mass update is a good example, there are better ways than ORM and JDBC for ETL stuff. I see no reasons to use ORM or JDBC for reports and "business intelegence" stuff too. There are many good technologies to work with data and you do not need any programming to use some of them.
    Many companies have standardized on a single DB vendor. Programming all these abstraction layers because they 'might' someday change is stupid.
    JDBC is an abstraction layer itself, it is API for "transparent" connectivity and it is not a DB vendor specific, there are JDBC implementations for exotic data access including OODBMS too.
  13. They should really do a comparison between Hibernate and well written JDBC/vendor specific SQL...
    Why not JDBC/standardized SQL? You do not have to use an ORM to keep your application database independent. There is a SQL standard that you should follow.
  14. They should really do a comparison between Hibernate and well written JDBC/vendor specific SQL...
    Why not JDBC/standardized SQL? You do not have to use an ORM to keep your application database independent. There is a SQL standard that you should follow.

    As I understand JDBC follows ODBC specification, it standardized on SQL 92

    " public abstract boolean jdbcCompliant()

    Report whether the Driver is a genuine JDBC COMPLIANT (tm) driver. A driver may only report "true" here if it passes the JDBC compliance tests, otherwise it is required to return false. JDBC compliance requires full support for the JDBC API and full support for SQL 92 Entry Level."
  15. As I understand JDBC follows ODBC specification, it standardized on SQL 92" public abstract boolean jdbcCompliant()Report whether the Driver is a genuine JDBC COMPLIANT (tm) driver. A driver may only report "true" here if it passes the JDBC compliance tests, otherwise it is required to return false. JDBC compliance requires full support for the JDBC API and full support for SQL 92 Entry Level."

    This limits your choice of database, and what you can do with the databases you can use. It has been demonstrated in other TSS threads that good ORM products will, with no intervention required by the developer, make use of vendor-specific features in order to optimise database use. So, you can either use only the databases with SQL 92 compliance, and then stick to only SQL 92 features, or you can use a good ORM so having a wider choice of databases and making better use of the database.
  16. I use good ORM products myself, but I can not demonstrate this magical portability. This problem doe's not effect my users, most of code is generated anyway. It is not a shame for me to call a stored procedure or JDBC API if I have a better reason than "transparience". I am trieng to think more about end user than about "easy-of-use" or "do not need to learn SQL".
  17. I use good ORM products myself, but I can not demonstrate this magical portability. This problem doe's not effect my users, most of code is generated anyway. It is not a shame for me to call a stored procedure or JDBC API if I have a better reason than "transparience". I am trieng to think more about end user than about "easy-of-use" or "do not need to learn SQL".

    There is nothing magical about portability. Portability is not an all-or-nothing thing. It should be something to be aimed at where possible. Keeping things portable, and keeping development easy where possible actually benefits the end user, as it can (if appropriate) allow them the possibility of choosing the deployment database, and allows you to help maintain code.

    It is a myth that using ORM means you don't need to learn SQL. There will be occasions when SQL will be needed. No technology is perfect and right for all situations.
  18. I use good ORM products myself, but I can not demonstrate this magical portability.

    Well, I can. We had a product that we had DB2 (UDB) personal on the Desktop and Sybase on the Dev/Test/Prod servers. After going to production we had some issues with Sybase. The decision was made that we go to DB2 mainframe (not UDB) for Dev/Test/Prod servers. As part of the process were able to generate the base DDL for other databases (ie MySQL) to test with to find the issues. There are differences (especially if you use sequence IDs). Even between the MF DB2 and UDB. To top it off, when we moved from Sybase to DB2 MF they changed table and field names cause their naming conventions were different. It took < an hour to do all but one query. That took a little extra trouble shooting but then we figured out that db2 mainframe was "back level".
  19. I use good ORM products myself, but I can not demonstrate this magical portability.
    Well, I can. We had a product that we had DB2 (UDB) personal on the Desktop and Sybase on the Dev/Test/Prod servers. After going to production we had some issues with Sybase. The decision was made that we go to DB2 mainframe (not UDB) for Dev/Test/Prod servers. As part of the process were able to generate the base DDL for other databases (ie MySQL) to test with to find the issues. There are differences (especially if you use sequence IDs). Even between the MF DB2 and UDB. To top it off, when we moved from Sybase to DB2 MF they changed table and field names cause their naming conventions were different. It took < an hour to do all but one query. That took a little extra trouble shooting but then we figured out that db2 mainframe was "back level".
    Is it magic ? All persistent stores must be equal for "portable" application (like "compile once ...") without any changes and tunnig.
  20. They should really do a comparison between Hibernate and well written JDBC/vendor specific SQL.JDBC would beat it easily. (mass updates anyone???)Many companies have standardized on a single DB vendor. Programming all these abstraction layers because they 'might' someday change is stupid.

    The primary advantage of ORM is not portability - it is being able to handle information and describe business logic purely in terms of an object model.

    However, my view is that anyone who does not at least allow the option for changing any aspect of the IT systems is very unwise. I have seen too many projects and systems grind slowly to a halt over years due to 'standardization' on one DB, OS, or language vendor. A good ORM product allows the use of vendor specific SQL where it is felt necessary, while allowing portability through the rest of the code.
  21. "portability" stuff is more usefull for ORM vendor to get more customers than for user. I see nothing wrong to use vendor specific features (including ORM vendor specific features). Users "standardize" on database and have reasons to pay for avanced features ("the right tool for a job"). Rename "specific" to "advanced" and it will be fine.
  22. "portability" stuff is more usefull for ORM vendor to get more customers than for user. I see nothing wrong to use vendor specific features (including ORM vendor specific features). Users "standardize" on database and have reasons to pay for avanced features ("the right tool for a job"). Rename "specific" to "advanced" and it will be fine.

    I can't agree that there is 'nothing wrong' in using vendor-specific features. Barriers to portability are always a disadvantage, because tying code in to a closed-source and proprietary product prevents the ability to review use of the product and competitively tender for alternatives. There are clear business disadvantages for such a strategy. What has to be done is to weigh those disadvantages against the benefits.

    As for "the right tool for a job" - well I consider that to be the one of the most overused phrases in IT. It assumes developers are going to neglect existing codebases and skills and re-tool for each new project. A better strategy is to find the right general-purpose tool and use it wherever possible. I believe one such tool is Java, and another is a good ORM API or implementation, such as Hibernate.
  23. I can't agree that there is 'nothing wrong' in using vendor-specific features. Barriers to portability are always a disadvantage, because tying code in to a closed-source and proprietary product prevents the ability to review use of the product and competitively tender for alternatives. There are clear business disadvantages for such a strategy. What has to be done is to weigh those disadvantages against the benefits.As for "the right tool for a job" - well I consider that to be the one of the most overused phrases in IT. It assumes developers are going to neglect existing codebases and skills and re-tool for each new project. A better strategy is to find the right general-purpose tool and use it wherever possible. I believe one such tool is Java, and another is a good ORM API or implementation, such as Hibernate.
    I think "Portable" strategy is very popular for simple reason: Decission maker is not responsable for decision.
  24. ... Barriers to portability are always a disadvantage, because tying code in to a closed-source and proprietary product prevents the ability to review use of the product and competitively tender for alternatives. There are clear business disadvantages for such a strategy...
    I think "Portable" strategy is very popular for simple reason: Decission maker is not responsable for decision.

    I am sorry, but I don't understand this response. How does it relate to the matter of the ability to review product use and competitively tender, and customer choice of deployment?
  25. I am sorry, but I don't understand this response. How does it relate to the matter of the ability to review product use and competitively tender, and customer choice of deployment?

    Customer just needs the "best" deployment, somebody must take this responsability and to decide. I think BS about choice is just a way to avoid responsability. Databases are not equal, but I do not have any portability problems, advanced features (clusters,partitions,index types) are transparent for application anyway, views help to develop portable application. So portability problem doe's not exist in RDBMS and I do not need adapter feature from ORM.
    I hope you will not start discussion about some bug in JDBC driver or some lame RDBMS implementation.
  26. So portability problem doe's not exist in RDBMS

    Can I quote you on that? As someone who has been dealing with porting between RDMBSes for years, I consider that to be one of the least correct statements ever posted on a technical forum!
  27. So portability problem doe's not exist in RDBMS
    Can I quote you on that? As someone who has been dealing with porting between RDMBSes for years, I consider that to be one of the least correct statements ever posted on a technical forum!

    Ditto. Try moving something from DB2 8 to Oracle8i to SQL Server 2000 sometime!!
  28. So portability problem doe's not exist in RDBMS
    Can I quote you on that? As someone who has been dealing with porting between RDMBSes for years, I consider that to be one of the least correct statements ever posted on a technical forum!
    Ditto. Try moving something from DB2 8 to Oracle8i to SQL Server 2000 sometime!!
    Try moving from JDO 2 to JDO 1 first.
  29. So portability problem doe's not exist in RDBMS
    Can I quote you on that? As someone who has been dealing with porting between RDMBSes for years, I consider that to be one of the least correct statements ever posted on a technical forum!
    Can you explain your problems ? Probably I will help.
  30. So portability problem doe's not exist in RDBMS
    Can I quote you on that? As someone who has been dealing with porting between RDMBSes for years, I consider that to be one of the least correct statements ever posted on a technical forum!
    Can you explain your problems ? Probably I will help.

    Very generous, but years too late. I don't have those problems now because I use an ORM.
  31. So portability problem doe's not exist in RDBMS
    Can I quote you on that? As someone who has been dealing with porting between RDMBSes for years, I consider that to be one of the least correct statements ever posted on a technical forum!
    Can you explain your problems ? Probably I will help.
    Very generous, but years too late. I don't have those problems now because I use an ORM.

    So we both do not have any problems with RDBMS.
  32. So portability problem doe's not exist in RDBMS
    Can I quote you on that? As someone who has been dealing with porting between RDMBSes for years, I consider that to be one of the least correct statements ever posted on a technical forum!
    Can you explain your problems ? Probably I will help.
    BTW why do you think it is a technical forum ? I think any A vs. B form is crap.
  33. "portability" stuff is more usefull for ORM vendor to get more customers than for user. I see nothing wrong to use vendor specific features (including ORM vendor specific features). Users "standardize" on database and have reasons to pay for avanced features ("the right tool for a job"). Rename "specific" to "advanced" and it will be fine.
    I can't agree that there is 'nothing wrong' in using vendor-specific features. Barriers to portability are always a disadvantage, because tying code in to a closed-source and proprietary product prevents the ability to review use of the product and competitively tender for alternatives. There are clear business disadvantages for such a strategy. What has to be done is to weigh those disadvantages against the benefits.As for "the right tool for a job" - well I consider that to be the one of the most overused phrases in IT. It assumes developers are going to neglect existing codebases and skills and re-tool for each new project. A better strategy is to find the right general-purpose tool and use it wherever possible. I believe one such tool is Java, and another is a good ORM API or implementation, such as Hibernate.

    ...or JDO! :-)
  34. I believe one such tool is Java, and another is a good ORM API or implementation, such as Hibernate.
    ...or JDO! :-)

    Well, of course - it's what I use - but, after all, this is a Hibernate thread!
  35. They should really do a comparison between Hibernate and well written JDBC/vendor specific SQL.JDBC would beat it easily. (mass updates anyone???)Many companies have standardized on a single DB vendor. Programming all these abstraction layers because they 'might' someday change is stupid.
    The primary advantage of ORM is not portability - it is being able to handle information and describe business logic purely in terms of an object model.However, my view is that anyone who does not at least allow the option for changing any aspect of the IT systems is very unwise. I have seen too many projects and systems grind slowly to a halt over years due to 'standardization' on one DB, OS, or language vendor. A good ORM product allows the use of vendor specific SQL where it is felt necessary, while allowing portability through the rest of the code.

    We had a project that used Hibernate and Oracle. An entirely different customer wanted to use the same code, but on a SQL Server 2000 database.

    Who saw that coming? Who could have predicted that the one project, tailored very specifically to the first customer, just happened to be exactly what the second needed?

    The port was 85% achieved by changing the dialect. The remaining 15% was code that used features specific to Oracle and had to be rewritten for SQL Server.

    While you shouldn't worry about the unlikely like wholesale shifts in databases, if a particular tool gives you this as a feature, with little work on your part, and gets you out of the persistence business, it is foolish NOT to use it.

    Now, instead of digging up out of date documentation of whatever proprietary jdbc, web presentation, or frameworky code we have lying around(I mean really, how many developers REALLY maintain documentation?), I just hand people the Struts, Hibernate, and Spring book(Pro Spring), and explain how WE use these things.

    Utilize the tools.
  36. They should really do a comparison between Hibernate and well written JDBC/vendor specific SQL.JDBC would beat it easily. (mass updates anyone???)Many companies have standardized on a single DB vendor. Programming all these abstraction layers because they 'might' someday change is stupid.


    CodeFutures supports multiple data persistence technologies - JDBC, JDO, EJB CMP, Hibernate - and are often asked which is best.

    Our focus is providing best design practice - DAOs - and we're technology neutral.

    We often recommend JDBC to customers:

    See here for a comparison of the different persistence technologies:

    http://www.codefutures.com/weblog/corporate/archives/2005/02/data_persistenc.html


    PJ Murray
    CodeFutures Software
    Java Code Generation for Data Persistence
    http://www.codefutures.com
  37. Persistence Showdown is over[ Go to top ]

    "The only strong opinion offer by CodeFutures regarding data persistence technology choice is that if have a tight deadline, the lowest risk choice is JDBC DAOs."

    "-JDBC DAOs - Data Access Objects are a core J2EE design pattern - so it's a sound approach (provided you're not hand-writing the DAOs!)."

    "In terms of popularity among CodeFutures' customers, JDBC DAOs are clearly the most popular."

    "This is good news - it means that developers are going for the simplest and most mature technology.
    "
    Thank you!

    Of course I knew all that already, but you put it so much more eloquently.

    Regards
    Rolf Tollerud
    BTW, when will you have code-generation for iBATIS?
  38. Persistence Showdown is over[ Go to top ]

    "The only strong opinion offer by CodeFutures regarding data persistence technology choice is that if have a tight deadline, the lowest risk choice is JDBC DAOs.""-JDBC DAOs - Data Access Objects are a core J2EE design pattern - so it's a sound approach (provided you're not hand-writing the DAOs!)." "In terms of popularity among CodeFutures' customers, JDBC DAOs are clearly the most popular." "This is good news - it means that developers are going for the simplest and most mature technology.
    "Thank you! Of course I knew all that already, but you put it so much more eloquently.RegardsRolf TollerudBTW, when will you have code-generation for iBATIS?

    We currently have code generation for JDBC DAOs, EJB CMP, JDO, and Hibernate.

    Next on the list are Spring and iBATIS.

    With all these options, we're neutral, but we still often recommend JDBC DAOs due to factors such as technology maturity and stability, skills availability for the specific project, longer term maintenance issues, etc.



    PJ Murray

    CodeFutures Software

    Java Code Generation for Data Persistence
  39. From the blog.
    Data Access Objects are a core J2EE design pattern - so it's a sound approach
    Yeah. Right.

    From Sun's Examples
    public CloudscapeCustomerDAO() {
        // initialization
      }
    ...
    public int insertCustomer(...) {
        // Implement insert customer here.
        // Return newly created customer number
        // or a -1 on error
      ...

    Anyone wanna comment on the insertCustomer method signature? I wouldn't want myself or any of my or my fellow developers coding like this. At least not in Java (or C#, ...).
  40. From the blog.
    Data Access Objects are a core J2EE design pattern - so it's a sound approach
    Yeah. Right.From Sun's Examples
    public CloudscapeCustomerDAO() {&nbsp;&nbsp;&nbsp;&nbsp;// initialization &nbsp;&nbsp;}...public int insertCustomer(...) {&nbsp;&nbsp;&nbsp;&nbsp;// Implement insert customer here.&nbsp;&nbsp;&nbsp;&nbsp;// Return newly created customer number&nbsp;&nbsp;&nbsp;&nbsp;// or a -1 on error&nbsp;&nbsp;...
    Anyone wanna comment on the insertCustomer method signature? I wouldn't want myself or any of my or my fellow developers coding like this. At least not in Java (or C#, ...).

    Well, thats one approach to DAO ... CodeFutures generated DAO interfaces look more like this:
    interface CustomerDao {
    &nbsp;&nbsp;public CustomerPK insert(Customer customer);
    &nbsp;&nbsp;public CustomerPK update(CustomerPK pk, Customer customer);
    &nbsp;&nbsp;public CustomerPK delete(CustomerPK pk);
    &nbsp;&nbsp;public Customer findByPrimaryKey(CustomerPK pk);
    &nbsp;&nbsp;public Customer[] findByName(String name);
    &nbsp;&nbsp;public Customer[] findByCity(String city);
    }
  41. I might be wrong here but ...
    /**
     * @hibernate.many-to-one column="gold_claim_id"
     * cascade="save"
     */
    public GoldClaim getGoldClaim() { return goldClaim; }
    Miner miner = new Miner();
    miner.setGoldClaim(new GoldClaim());
    session.save(miner); // Saves Miner and GoldClaim objects.
    session.delete(miner); // Deletes both of them.

    The glodClaim is 'save' cascaded, therefore deleting the miner will only delete the miner but not the glodClaim. I think goldClaim will need to be deleted then the miner to avoid violating the foreign key constraint in this case.

    regards
    tmjee
  42. I usually like Hibernate when the object model and schema are relatively close. This is also precisely where Rails shines. In this case, you'd end up specifying or generating a property six times in Hibernate mapping/model/schema versus one time in Rails.

    Rails is no toy. It's got a narrower sweet spot, but it's much more productive for those cases. The loc comparison for my latest rails app is more than 4 to 1...more if you count configuration. The rails code is cleaner; the code/test cycle is shorter by a factor of 10 or more. And since active record doesn't have the overhead of full ORM, Rails is very fast.

    As it stands, it all depends on differences between the schema and model. If they're the same or close to, I prefer rails.
  43. I'm curious - how is the code/test cycle shorter by a factor or 10 or more, with Rails? I admit when I hear that I get skeptical, given how I and others build Java-powered apps today in agile/TDD/fail-fast fashion.

    Keith
  44. Keith, I'm curious... what exactly do you mean by fail-fast in the context of a web application?
  45. I develop in isolation using JUnit unit and integration tests, coding the tests as (even before I write the code) - I run the tests, see them fail, fix, run the tests again, see them fail differently, fix, run/fail/fix, run/fail/fix... until run/pass/green bar/cheers-all-around. The failures execute quickly (fast) so development is very agile. I typically don't deploy to the container once until I know the meat of my app is working.
  46. And since active record doesn't have the overhead of full ORM, Rails is very fast.As it stands, it all depends on differences between the schema and model.

    On feature by feature basis, what overhead does an ORM have compared to active record? You mentioned 'fast', so I presume you mean performance?
  47. Apples and Oranges[ Go to top ]

    I think we have to remember that we are comparing Apples and Oranges here.

    Both frameworks have pro's and con's, and different reasons for use. Hibernate is a solid, mature ORM that makes sense in the Java world.

    ActiveRecord is a simple ORM that makes sense in the Ruby world. It is also a lot newer than Hibernate, and definitely has room to grow. However, it is very concise and simple.

    Both are good in their own way.

    Dion
  48. Apples and Oranges[ Go to top ]

    It is also a lot newer than Hibernate, and definitely has room to grow.

    Patrick's main point is that fundamental architectural differences between ActiveRecord and Hibernate define their use cases.

    Unlike Hibernate, ActiveRecord has a simpler, easy to understand mapping model. This not only limits it to simpler problems, it keeps it from adequately addressing the association and performance issues Patrick identified.

    Unless ActiveRecord fundamentally changes its architecture, no amount of growth and maturity will make it suitable for the types of problems at which Hibernate excels.
  49. In other news...[ Go to top ]

    PHP is good for small web projects but j2ee is more suitable for large -> enterprise projects.

    come on, this is an article for the sake of having something to write. If ruby on rails came out as being better than Hibernate then it would be damning on the latter rather than a plus on the former.

    Oh, and the earth revolves around the Sun.
  50. In other news...[ Go to top ]

    Oh, and the earth revolves around the Sun.

    Have you ever heard Eclipse?
  51. Informative article[ Go to top ]

    Thanks for this informative article. I didn't know much about Hibernate, this project seems very interesting. BTW, have a look at my own ORM library for Ruby called Og (ObjectGraph). You can find a small tutorial at: www.rubygarden.com. (Please note that the tutorial refers to an older version though). I would love to hear your opinion on Og.
  52. One thing that really struck me about the article is that there is no information in the Ruby code as to which fields are in the database.

    As someone who uses IDEA, it's great to be able to type the object name in, press ctrl+space, and get a list of all the properties I can access on the object. When rolling on to a large new project with a significant codebase, this is absolutely invaluable and saves me masses of time.

    I think there really is a sense in which a large Rails project with many developers (NB this caveat would-be flamers) would actually see a productivity *decrease* compared to a Hibernate-based project.
  53. One thing that really struck me about the article is that there is no information in the Ruby code as to which fields are in the database.As someone who uses IDEA, it's great to be able to type the object name in, press ctrl+space, and get a list of all the properties I can access on the object.

    Welcome to the world of dynamically typed languages...

    In my opinion, this is the main reason why dynamically typed languages can't get a foothold in enterprise development. All other problems (performance, existing user base, tools...) pale in comparison. Static type information is code documentation. Often, it is also the only documentation you get...
  54. We just had a conversation in the office about this. Apparently you *could* have IDE support for this kind of thing in Smalltalk because the IDE is embedded in the runtime (and has access to the image), and hence can see fields and methods that are generated at runtime. So it's not about dynamically typed languages per se.

    But analogously to the way that Eclipse can't 'see' the results of bytecode manipulation, Ruby IDEs don't have access to the runtime image. Hence unless this is changed there will never be the kind of IDE support that is available in Java.

    As you point out, this is a big problem when working on long projects with many developers, and seems to me to be a major stumbling block to Rails being adopted in the enterprise.
  55. Apparently you *could* have IDE support for this kind of thing in Smalltalk because the IDE is embedded in the runtime (and has access to the image), and hence can see fields and methods that are generated at runtime.

    Ah, but how would IDE know all objects that will be assigned to the to the variable? Sure, the IDE can know *some* methods if you run in "debugger mode" - run the program, then stop the execution at some point. Then IDE can offer you valid methods - it just examines the object currently assigned to the variable. But what about objects that were will be assigned to the variable? Some can be inferred by (static, aka non-runtime) code analysis. Most cases cannot be.

    For example, with Rails ORM, the type of the object depends on the SQL query used to fetch it. See this post for illustration.

    This shows the tradeoffs between static (lots of code needed to express types, lots of help from compiler and IDE) and dynamic typing (no code needed to express types, little help from compiler or IDE).
  56. Grr, forgot to proof read. First paragraph should end with:

    But what about objects that were or will be assigned to the variable? Some can be inferred by (static, aka non-runtime) code analysis. But in most cases they cannot be.
  57. One thing that really struck me about the article is that there is no information in the Ruby code as to which fields are in the database.As someone who uses IDEA, it's great to be able to type the object name in, press ctrl+space, and get a list of all the properties I can access on the object.

    As I said in an earlier post, there is an alternative ORM library for Ruby that provides the functionality you describe, ie the fields are described in the code. Checkout the tutorial at www.rubygarden.com to read more about Og.
  58. One thing that really struck me about the article is that there is no information in the Ruby code as to which fields are in the database.As someone who uses IDEA, it's great to be able to type the object name in, press ctrl+space, and get a list of all the properties I can access on the object.
    As I said in an earlier post, there is an alternative ORM library for Ruby that provides the functionality you describe, ie the fields are described in the code. Checkout the tutorial at www.rubygarden.com to read more about Og.
    Thanks for that! Looks like an elegant solution. I'll give it a whirl.
  59. One thing that really struck me about the article is that there is no information in the Ruby code as to which fields are in the database.

    If this is really an issue for you, then you can write you ActiveRecord class as:

    class Model < ActiveRecord::Base
      def property
        read_attribute("property")
      end
    end


    This doesn't address the auto-complete problem. But I would disagree that auto-complete will give you enough of a productivity increase to trump all the other benefits of Ruby.
  60. This is offset by the fact that you can easily use alter table statements (manually or like me, from a nice GUI) to change your data model, and not only do you not have to change your model but you haven't lost your data. In the Hibernate scenario, I believe I'm stuck doing the changes at least twice and regenerating my map, or doing them once in the code/Xdoclet tag and then regenerating everything, which will drop my tables and lose my data.

    Bottom line: data model changes will inevitably mean that I repeat myself in Hibernate, but never will in Rails. Don't Repeat Yourself (DRY) is what RoR is all about.

    You can say data models shouldn't change that much and eventually thats true but if changes are cheap early in the project I will, do and have seen significant productivity gains not to mention end up with a better data model - although in RoR I can't really argue better data model, can you say surrogate keys? :)

    The designer of ActiveRecord is fully conscious of the design trade-offs he has made, and has optimized this framework for a fairly limited (although extremely common) type of development project.
  61. The designer of ActiveRecord is fully conscious of the design trade-offs he has made, and has optimized this framework for a fairly limited (although extremely common) type of development project.

    This is fair enough, but it seems inevitable that some over-zealous Ruby developers will attempt to use such a framework for more than this type limited type of project, or (as in my personal experience) initially limited projects eventually grow beyond the designed capabilities of the framework. We have already seen declarations that RoR is effectively a J2EE replacement!
  62. The designer of ActiveRecord is fully conscious of the design trade-offs he has made, and has optimized this framework for a fairly limited (although extremely common) type of development project.
    This is fair enough, but it seems inevitable that some over-zealous Ruby developers will attempt to use such a framework for more than this type limited type of project, or (as in my personal experience) initially limited projects eventually grow beyond the designed capabilities of the framework. We have already seen declarations that RoR is effectively a J2EE replacement!

    I'm sorry, but just because ignorant programmers misapply tools does not mean that the tools are bad. There are many project failures in the J2EE world due to poor design - many of them because people tried to do something stupid like follow Sun's original blueprints and use Entity beans with remote interfaces, or use BMP, etc.

    Yeah people are excited about Rails, but its not for enterprise development. Its for building websites like Basecamp. I hope to god it never has a transaction manager or connector architecture or many of the other features of Java required for true enterprise development.

    Now, a lot of Java developers (I might even go out on a limb and say most) are building relatively simple software for departmental web applications using enterprise tools, and they could probably have an easier life with Rails, but I don't expect it to happen. In big corporations it seems one size must fit all.
  63. Now, a lot of Java developers (I might even go out on a limb and say most) are building relatively simple software for departmental web applications using enterprise tools, and they could probably have an easier life with Rails, but I don't expect it to happen. In big corporations it seems one size must fit all.

    This is the wrong way round. Big corporations have more time and money for playing around with the 'next cool language' to see if it is worth using for some projects. Small corporations and development teams have to be more economical, and the 'one size fits all' strategy is more appropriate. The advantage of Java is that it is a reasonably simple language, so it is a pretty good fit for most situations.

    There is always the significant problem of lack of code and skill re-use if you don't use the 'one size fits all' strategy, which is why I like the idea of having different languages integrated with each other on the JVM: A really useful place for Ruby is as a language integrated with Java - JRuby. This will allow Ruby to seamlessly use Java class libraries, and Java to use Ruby classes. This way code can re-used no matter what language is chosen. And, of course, if Ruby is compiled to Java byte codes, it gets the high performance of the Java VM. I think this is an exciting possibility, and a better strategy than Ruby developers attempting to re-invent the wheel with their own VM (there are existing open source JVMs with reasonable performance!).
  64. I used to think like you, and I did had a deeper look at JPython ( even bought Richard Hightower's book :-)
    And after a few experimentations, I came to a definitive conclusion : that kind of two-headed beast is not usable for more than 100 lines of not critical code.

    Seamlessly integration is not possible, what you have is a scary spaghetti soup of Python and Java code.
    It does success only at being unnatural both to Python and Java programmers. Also there are a lot of gotchas, because Python is missing interfaces for example, or because of nameclashes. Some thing are not working as expected on the Python side. And the worst is that you end up using Java without the help of modern IDEs which is a real pain ( and I wish good luck to the guys who would consider implementing autocompletion for such a beast).

    And JRuby will be just the same. Wether you do plain Ruby programming, or plain Java programming, but doing both in the same place is a maintenance nightmare promise.
    I would rather consider using something like RPC and split my application ...
  65. Seamlessly integration is not possible, what you have is a scary spaghetti soup of Python and Java code.

    Seamless integration is not only possible, but very easy:
    http://www.jython.org/docs/usejava.html
    It does success only at being unnatural both to Python and Java programmers.

    Again, I don't understand. It is possible to write pure, normal Java classes and use those in Jython. How can this be unnatural to Java programmers?
    And the worst is that you end up using Java without the help of modern IDEs which is a real pain ( and I wish good luck to the guys who would consider implementing autocompletion for such a beast).

    I don't understand. I can use Java + Jython within NetBeans, which is a modern IDE. I have autocompletion for my Java parts. What is the problem?
    And JRuby will be just the same. Wether you do plain Ruby programming, or plain Java programming, but doing both in the same place is a maintenance nightmare promise.I would rather consider using something like RPC and split my application ...

    I am not talking doing both in the same place. I am talking about a Ruby developer being able to develop in a Ruby dialect, with most or all of the advantages, yet running on a very fast VM and having access to all the Java classes and libraries. How can this possibly be a maintenance nightmare, or any worse that RPC?
  66. Seamless integration is not only possible, but very easy:http://www.jython.org/docs/usejava.html

    hum, but this is the advertisement ;-)
    For such simple access, I do agree this is seamless. But have a look at this code ( extract from Python Programming with the Java class libraries Addison Wesley)

    from jarray import array, zeros
    seq = (1,0,1,0,1,0)
    booleanArray = array(seq, 'z')

    This is much less straightforward, isn't it ? It's just to build an array compatible with Java.

    another example :

    from javax.swing import JFrame, JButton
    from java.awt.event import ActionListener
    class hello(ActionListener):
    def actionPerformed(self, event):
    print "Hello"
    f = JFrame()
    b = JButton("Hello from Java events");
    hi = hello()
    b.addActionListener(hi)
    f.getContentPane().add(b)
    f.pack()
    f.visible = 1

    But who tells you, Python programmer, that you have to implement an interface ?
    Answer : nobody, not even the computer.

    And there are many "little" things like this. Let's have a look at this interactive session :

    jython
    Jython 2.1 on java1.5.0_01 (JIT: null)
    Type "copyright", "credits" or "license" for more information.
    >>> from java.util import Date
    >>> Date(2005,4,2)
    Tue May 02 00:00:00 CEST 3905

    Yes, this constructor is deprecated. Again nobody tells you ...
    Would you have programmed in pure Python, you would have a warning for using a deprecated Python API, the same for pure Java. But not with Jython.

    While I do agree that it is possible to write pure Java classes and keep all the features of your IDEs, when you come to use it in Jython it's not true anymore. You have to type the code, and know very well the Java API.

    I think of at least one excellent usage for Jython : scientific computing. This is ideal because you can rely on Java speed and huge libraries to build yourself a toolkit, and then use this toolkit in Python. And this will work well because scientific libraries are much more about computation, which means basically functions to call with parameters and results to get. They do not interfere with the caller. Ideally you would prototype the toolkit using Jython, and rewrite the most CPU intensive maths in plain Java, and then keep only the Jython wrapper call routine.

    But if you think of something like using a Java XSLT transformer with Jython, then looking at the JFrame simplistic example, you can imagine the mess it will rapidly be. So this is why I can't imagine this approach will work with a framework, which basically is tightly coupled with your code. There woul be too much flip-flop between Java/Python for a team to implement this in a consistent manner.
    I am not talking doing both in the same place. I am talking about a Ruby developer being able to develop in a Ruby dialect, with most or all of the advantages, yet running on a very fast VM and having access to all the Java classes and libraries. How can this possibly be a maintenance nightmare, or any worse that RPC?

    Well, if it's just about to compile Ruby code into bytecode, I think this would be great. But I certainly do not trust using a lot of Java libraries with Jruby. But maybe I'm wrong on this, since I do not had a real look at Jruby. Maybe Jruby doesn't suffer the same problems as Jython.
  67. So this is why I can't imagine this approach will work with a framework, which basically is tightly coupled with your code. There woul be too much flip-flop between Java/Python for a team to implement this in a consistent manner.

    I agree. I was not advocating a mixed language approach in any single project. My idea was that, in principle, someone could decide that Ruby or Python was the appropriate language for a project, and then develop that project using JRuby or Jython. Such a project could well result in a large amount of code. With a little work, and perhaps some wrapper classes, parts of that code could be re-used in subsequent Java projects. The same with Java, and re-use in other languages. I was not suggesting that on any individual project you would have developers working to produce Java and Ruby/Python classes at a fine-grained level and then try to combine them. Unless you have a language specifically designed for this (such as BeanShell or Groovy), it is not going to look very pretty.
    While I do agree that it is possible to write pure Java classes and keep all the features of your IDEs, when you come to use it in Jython it's not true anymore. You have to type the code, and know very well the Java API.

    A good IDE plugin should allow Java API lookups, even in the context of scripting languages that use Java. If not, all you need to do is have another IDE window open, so you can enter test Java code to do lookups of classes and methods.
    I think of at least one excellent usage for Jython : scientific computing. This is ideal because you can rely on Java speed and huge libraries to build yourself a toolkit, and then use this toolkit in Python.

    Yes, this is a neat idea.
    Well, if it's just about to compile Ruby code into bytecode, I think this would be great. But I certainly do not trust using a lot of Java libraries with Jruby. But maybe I'm wrong on this, since I do not had a real look at Jruby. Maybe Jruby doesn't suffer the same problems as Jython.

    Perhaps, but even the problems you mention don't look too awkward, and I would suggest that they could probably be abstracted away with some wrapper code? This should still be a lot easier and more flexible than having to compile and maintain and deploy than exernal C code.
  68. I think we're missing the point[ Go to top ]

    I’m not sure what this sort comparison is going to accomplish besides pointing out the obvious- that Hibernate is a much more mature and robust framework than ActiveRecord.

    What we really learn from Ruby on Rails (and other frameworks) is that simplicity can be a good thing. What it comes down to is a good programmer delivers good code on time. It doesn’t have to be more robust than the problem demands. Writing code in Java with our (albeit spiffy) frameworks doesn’t make a difference so long as the end application works as it should. Given this, you can write your web app in PHP, Perl, Cold Fusion, Ruby, Java, or sweet Jesus help us, even ASP.

    The point is you need to get the thing done and working. Now a lot of this Ruby stuff sounds like hype, but the Java community needs to take a serious look at this. As it stands, there are a lot of enterprise apps that are well suited to the Java platform. At the very high end where remoting and distributed transactions are key, EJB makes sense. For simpler apps, we’re finding that lightweight containers and frameworks make more sense because of their simplicity and ease of development. Similarly, when applications are small or relatively simple, containerless scripting languages are more than capable of delivering.

    What makes Ruby and RoR attractive is it’s pushing the upper bound of what apps are feasible for scripting languages. While it’s not nearly as mature as the wide variety of Java frameworks, it does succeed in delivering a great deal of functionality and very well integrated layers. Furthermore, Ruby affords a higher level of abstraction so the framework grows the language toward the problem domain. Java just can’t do this yet.

    Maybe the answer is that the Java community should cede projects to other languages and techniques. The other option is we should learn from other languages and see how we can make development in Java better. In either case, this kind of comparison does help. What we need is an article on why Ruby on Rails is great.
  69. You're totally right![ Go to top ]

    Seems to me that the Java folks almost always miss the point when talking about RoR.

    Comparing a mature framework like Hibernate with the new kid of the block is just an easy way to cheer up the crowd and sing all together : "my projects is bigger than yours, it's actually so big, so complex and so serious it will never fit your toy framework".

    Don't worry guys, RoR is not going to take over the "enterprise" anytime soon, you'll keep on using all the technologies you painfully learned for years, keep scribbling XML configurations files, adding magic comments and annotations, generating getters and setters, using typecasts in every loop... enjoy it to the last drop, enjoy it until your company is bought by a start-up run by a couple of guys who've built their stuff with Rails! ;)
  70. You're totally right![ Go to top ]

    enjoy it to the last drop, enjoy it until your company is bought by a start-up run by a couple of guys who've built their stuff with Rails! ;)

    A significant part of my job is salvaging projects that have been developed using the 'latest cool development thing', and which have grown beyond the capabilities of the development tool and language. One of the lessons I have learned in my career is to never assume that any project is going to stay small and limited!
  71. feature creeeep doesn't exist[ Go to top ]

    enjoy it to the last drop, enjoy it until your company is bought by a start-up run by a couple of guys who've built their stuff with Rails! ;)
    A significant part of my job is salvaging projects that have been developed using the 'latest cool development thing', and which have grown beyond the capabilities of the development tool and language. One of the lessons I have learned in my career is to never assume that any project is going to stay small and limited!

    You make it sound like software products tack on more and more features for the sake of looking cool, only to go down the path to junk. That never happens :)

    on a less silly note. people shouldn't be surprised this is the normal way software develops. Repairing bad code supports the IT industry, so be glad it generates more work. heck a lot of the work I've done was repairing bad stuff, so it's provided abundant opportunity to learn how things go bad. I don't think ROR is any worse in that respect. Bad programmers will do what they do best, screw things up. Those who make a living fixing broken software would have less work if everyone did things the right way the first time.

    peter
  72. feature creeeep doesn't exist[ Go to top ]

    You make it sound like software products tack on more and more features for the sake of looking cool, only to go down the path to junk. That never happens :)

    Of course not :)
    on a less silly note. people shouldn't be surprised this is the normal way software develops. Repairing bad code supports the IT industry, so be glad it generates more work. heck a lot of the work I've done was repairing bad stuff, so it's provided abundant opportunity to learn how things go bad. I don't think ROR is any worse in that respect. Bad programmers will do what they do best, screw things up. Those who make a living fixing broken software would have less work if everyone did things the right way the first time.peter

    I guess I share David's point of view:
    Why should the small ones be written using PHP, Perl, or Ruby when the java solutions scales down, the the scaling up of the other solutions are questionable at best.

    I just don't find the arguments about scripting being quicker to write or requiring fewer lines that compelling. With current IDEs and tools Java coding can be fast.
  73. You're totally right![ Go to top ]

    Seems to me that the Java folks almost always miss the point when talking about RoR.Comparing a mature framework like Hibernate with the new kid of the block is just an easy way to cheer up the crowd and sing all together : "my projects is bigger than yours, it's actually so big, so complex and so serious it will never fit your toy framework".Don't worry guys, RoR is not going to take over the "enterprise" anytime soon, you'll keep on using all the technologies you painfully learned for years, keep scribbling XML configurations files, adding magic comments and annotations, generating getters and setters, using typecasts in every loop... enjoy it to the last drop, enjoy it until your company is bought by a start-up run by a couple of guys who've built their stuff with Rails! ;)

    Well, with the attitude, I know I'll never be out of work. I've had to work on projects that had to be rewritten because somebody tossed out a proof of concept that inevitably became a production system and ran into all manner of maintainence and production problems and needed to be rewritten.

    The more things change...
  74. I think we're missing the point[ Go to top ]

    domain. Java just can’t do this yet. Maybe the answer is that the Java community should cede projects to other languages and techniques. The other option is we should learn from other languages and see how we can make development in Java better. In either case, this kind of comparison does help. What we need is an article on why Ruby on Rails is great.

    I simply don't agree with this. At my current company, we have projects that range from small one to three page modules, to fairly large serveside applications.

    Why should the small ones be written using PHP, Perl, or Ruby when the java solutions scales down, the the scaling up of the other solutions are questionable at best.

    We have a mature enough solution that we can roll out small solutions very quickly using the Struts/Spring/Hibernate(SSH) stack on containers ranging from Tomcat to JRun4 to Oracle9iAS all using the same framework.

    One guy recently left and his knowlege dump to me was basically, here is the test box and production box and here is the database. Here are the passwords. The application itself was pretty straigtforward, but the real benefit was that is uses the same SSH stack as its bigger brother.

    We were able to move a very bright, but relatively inexperienced person from one project to another because the frameworks and structures were nearly identical. There was no, let me ramp up on PHP for this or Ruby for that.

    This is why I've said before that I just don't find the scripting solutions, in general, uncompelling. We seem to have a solution that can prototype quickly, scale up or down, and is flexible enough to withstand the impact of change. And we can move anyone to pretty much anything using very well acceptable technology.
  75. I think we're missing the point[ Go to top ]

    I don’t doubt that you and your team can crank out apps using Java and any number of frameworks. And frankly if your experience is with Java and not some other language, you should do projects in Java. Each new tech you add to the mix is just going to hurt your delivery time.

    That said, this is not a question of whether or not Java scales down or is capable of developing a particular app. It’s also not about technical superiority. Yes java apps are more portable and could definitely run faster than a scripted application. But so what?

    We have to acknowledge the business reality here is that people are delivering great apps right now in scripting languages and that these languages in many cases shorten delivery time. That doesn’t mean that every implementation will scale through the roof or is easily portable, but it doesn’t have to be. Most businesses would rather have an application now that can be modified later than an application later that is robust beyond what’s required. No application is going to be ported or expanded unless it already solves some problem well.

    From a personal perspective, you can decide to learn Ruby or PHP, that’s up to you. From a business perspective, these simple, agile languages are eating Java’s lunch on the low end, and Ruby is poised to eat up even more of it. We can either learn from this or ignore it. Hell maybe the best answer is to put Ruby in the toolbox and call it a day.
  76. I think we're missing the point[ Go to top ]

    I don’t doubt that you and your team can crank out apps using Java and any number of frameworks. And frankly if your experience is with Java and not some other language, you should do projects in Java. Each new tech you add to the mix is just going to hurt your delivery time. That said, this is not a question of whether or not Java scales down or is capable of developing a particular app. It’s also not about technical superiority. Yes java apps are more portable and could definitely run faster than a scripted application. But so what?We have to acknowledge the business reality here is that people are delivering great apps right now in scripting languages and that these languages in many cases shorten delivery time. That doesn’t mean that every implementation will scale through the roof or is easily portable, but it doesn’t have to be. Most businesses would rather have an application now that can be modified later than an application later that is robust beyond what’s required. No application is going to be ported or expanded unless it already solves some problem well.From a personal perspective, you can decide to learn Ruby or PHP, that’s up to you. From a business perspective, these simple, agile languages are eating Java’s lunch on the low end, and Ruby is poised to eat up even more of it. We can either learn from this or ignore it. Hell maybe the best answer is to put Ruby in the toolbox and call it a day.

    "Eating Java's lunch"? Says you. Ultimately, this is the same old argument. Scripting languages have been competing with compiled languages for years. A scripting language didn't knock off C. C++ did. A scripting language didn't knock off C++. Java did. And I'll wager that another compiled language will knock off Java.

    You guys try to make it seem like those who don't find scripting languages compelling are somehow afraid of the thing.

    Don't make me laugh :-). After years of learning different langugages, different tools, different databases, different operating systems, different problem domains, all with different users, after all this, there is nothing frightening in the least about the latest scripting fad.

    I don't think anyone here is married to Java anymore than they were married to whatever they used before java.

    The fact is that currently Java offers, IMO, the best out of the box solution for the low and upper-end and to be frank only a nut with no life(no offense the no-life nuts) would add another tool for the sole purpose that a tiny handful of people in think its cool.

    I have no problem learning new tools, but I've been doing this enough to know that there is only a finite number of hours in the day and so much one can reasonably master. Therefore, I am careful to pick and choose where I expend my time and energy on and choose not to toss a lasso around every single thing that comes along.

    From a business perspective, you say what most business want something now. Fine. Here's a solution that CAN give you the application today. I've seen enough prototypes become production to know that when people see a prototype, its always "if you just add these things, we're done."

    It is never that simple. So why not have something that can prototype, then scale up? And by scaling, not just performance, but in size and complexity and still be performant and maintainable.

    It seems to me that if I have a solution, that is well documented, well understood, well supported that can deliver, quickly, a small solution and still be used in a larger solution without expending maintainance time and cost on ramping up on multiple languages, then I have a superior solution.

    The day that solution is eclipsed by a better one, I'll gladly use it. That day just isn't today, IMO.
  77. I think we're missing the point[ Go to top ]

    Don't make me laugh :-). After years of learning different langugages, different tools, different databases, different operating systems, different problem domains, all with different users, after all this, there is nothing frightening in the least about the latest scripting fad.I don't think anyone here is married to Java anymore than they were married to whatever they used before java.The fact is that currently Java offers, IMO, the best out of the box solution for the low and upper-end and to be frank only a nut with no life(no offense the no-life nuts) would add another tool for the sole purpose that a tiny handful of people in think its cool.

    Now you're just getting defensive. I'm not saying anyone has to adopt a particular language. What I am saying is that languages and frameworks grow and change. If you take a look at Ruby, there's things that are just easier at the language level than writing Java. That doesn't suggest that it's in any way technically superior to Java, but it does work out to it being easier. The promise of Rails is that easy things can be just as good as hard things for certain problems. Spring (and other lightweight containers) did the same thing to EJB containers. Would you want to use EJB for every problem jsut because it can solve a problem?

    Ruby or PHP aren't goign to knock Java out of it's high perch, but they could very well in the future. If we want Java to keep getting better, we ought to recognize where progress is being made and not just dismiss it. Also, take a look out there. People are in fact making great apps in Perl, PHP, Python, and lots of other languages which we'd feel comfortable saying are just underpowered scripting languages. Java took a big chunk out of C/C++, but you have to remember when Java was considered too slow and just a toy. VM? Who needs that? C runs on the machine for real. :)
  78. I think we're missing the point[ Go to top ]

    Don't make me laugh :-). After years of learning different langugages, different tools, different databases, different operating systems, different problem domains, all with different users, after all this, there is nothing frightening in the least about the latest scripting fad.I don't think anyone here is married to Java anymore than they were married to whatever they used before java.The fact is that currently Java offers, IMO, the best out of the box solution for the low and upper-end and to be frank only a nut with no life(no offense the no-life nuts) would add another tool for the sole purpose that a tiny handful of people in think its cool.
    Now you're just getting defensive. I'm not saying anyone has to adopt a particular language. What I am saying is that languages and frameworks grow and change. If you take a look at Ruby, there's things that are just easier at the language level than writing Java. That doesn't suggest that it's in any way technically superior to Java, but it does work out to it being easier. The promise of Rails is that easy things can be just as good as hard things for certain problems. Spring (and other lightweight containers) did the same thing to EJB containers. Would you want to use EJB for every problem jsut because it can solve a problem? Ruby or PHP aren't goign to knock Java out of it's high perch, but they could very well in the future. If we want Java to keep getting better, we ought to recognize where progress is being made and not just dismiss it. Also, take a look out there. People are in fact making great apps in Perl, PHP, Python, and lots of other languages which we'd feel comfortable saying are just underpowered scripting languages. Java took a big chunk out of C/C++, but you have to remember when Java was considered too slow and just a toy. VM? Who needs that? C runs on the machine for real. :)

    I'm not being defensive. I put the smiley there to make sure my tone wasn't misinterpreted! All I'm saying is that it is nonsense to argue that people who use java are somehow afraid of or worried about Ruby.

    Also, Spring is not just about the EJB container, but the entire J2EE stack, but that is another thread.

    I'm not saying that people don't make great apps in the scripting languages, but there are concerns that with scripting languages. The non-scaling, hard to maintain, slow rep didn't come from the Java Illuminati looking to maintain a strangle hold on enterprise programming. :-)

    You seemed read up to that excerpt and stop. I directly addressed Java and its place relative to C++. I also said that I wouldn't hesitate to move too another more compeling solution, but I just don't think Ruby or other scripting languages are compelling. To me. That's why I don't buy the toolkit argument. I feel that it is my job to make sure that the software I write survives me and my whims. For example, I job I left sometime ago hired a guy who started writing apps using java, C, and bash. Guess what happened when he left? Chaos.

    When I leave my company, I don't want them poring over stuff cursing my name because I wanted to indulge my myself by using five different scriping languages across five different applications when a single solution works.

    Oh, and it is the same solution on both big and small apps.

    For me, there has to be clear benefits to using something like Ruby. Not just "rapid prototyping" or solving "certain problems." If Java can solve Ruby problems and the non-Ruby problems, and do them both well(and quickly), then I just don't see the need for Ruby. For me.

    To answer your EJB question, no. I no longer use EJBs for the same reason I don't use Ruby. I have one solution that can do both. I have a solution that can handle Ruby-sized problems and scale up to EJB-sized problems.

    Struts/Spring/Hibernate(SSH).
  79. I think we're missing the point[ Go to top ]

    I feel that it is my job to make sure that the software I write survives me and my whims. For example, I job I left sometime ago hired a guy who started writing apps using java, C, and bash. Guess what happened when he left? Chaos.
    Do you remember this thread ?
    http://theserverside.com/news/thread.tss?thread_id=29114
  80. I think we're missing the point[ Go to top ]

    From a business perspective, these simple, agile languages are eating Java’s lunch on the low end, and Ruby is poised to eat up even more of it. We can either learn from this or ignore it. Hell maybe the best answer is to put Ruby in the toolbox and call it a day.

    Maybe it is only about allowing scripting languages to run on the VM. Get the best of both worlds: seamless intergration with Java and scripting productivity for suitable tasks.
  81. What about Trails?[ Go to top ]

    What about Trails? (trails.dev.java.net/) It is the Java version of Rails and uses Hibernate.

    It seems the best of both worlds.

    What do you think? Has someone had some experience?

    Vicent Palasi
  82. From one of the many Steve Zara post :
    I just don't find the arguments about scripting being quicker to write or requiring fewer lines that compelling. With current IDEs and tools Java coding can be fast.

    You are right Java coding is fast as ever with any modern IDEs and tools like XDoclet : you can get a lot of code *generated* for you quickly.
    In fact, I tend to think that these days, coding in Java is certainly faster than coding in Ruby.

    But that's not the point.

    Because, code, even if it is generated by the machine, is still code that you have to read someday. Think of this : you are spending more time *reading* the code you wrote, that actually *writing* it. And also you will read it several times.
    One could point out the fact that much of this generated code is not important and that you could safely ignore it (e.g. getters/setters), but still this is *visual pollution* that spread in your mind.
    I think there is a certain limit to the LOC you can put in your brain and keep a good overview of what this code is doing.
    This is the whole idea behind very high level dynamic languages such as Python or Ruby : keeping you away from being distracted by the tons of boilerplate code that adds nothing to the *meaning* of the program.
    Ruby is a very expressive language by itself, and what RoR is trying to do is to emphasis this expressiveness.
    When you have a look at the samples from the article, no one could deny that the Ruby version is always more expressive that the Java one.
    RoR is hiding all the boilerplate code from you, and let you concentrate on the *business rules*. Of course you have to learn "scaffold", "activerecord" and friends to understand the codebase, but you have to do this only once !

    Java was promising us WORM, Ruby and RoR is just the promise of something like LORE : Learn Once Reuse Everywhere
    ;-)

    And this is exactly why I find writing for RoR more exciting and appealing than writing for any J2EE stack ( which I do everyday ...). RoR is still in its infancy, but do you remember the days where Java was this little language to do *scripting applets* ? Nobody then would have admit that Java was nothing but a toy to add animations to your webpages, and not a mainstream system language like C/C++.
    All *serious enterprise* code had to be done in C these days :-)


    Cheers.
  83. Why less LOC is interesting[ Go to top ]

    <blockquoye>From one of the many Steve Zara post
    Perhaps too many in one day...!
    .But that's not the point.Because, code, even if it is generated by the machine, is still code that you have to read someday. Think of this : you are spending more time *reading* the code you wrote, that actually *writing* it. And also you will read it several times.One could point out the fact that much of this generated code is not important and that you could safely ignore it (e.g. getters/setters), but still this is *visual pollution* that spread in your mind.I think there is a certain limit to the LOC you can put in your brain and keep a good overview of what this code is doing.

    I used to agree with this, but don't any more. I find that I can work easily with different sized functional code units in different languages. I used to be a Smalltalk developer, and I would code loops like this:

    1 to: 1000 do: [:index| .... ]

    Now I use Java, and I write:

    for (int index = 1; index < 1000; index++) { ... }

    One is shorter than the other, but I don't find one or the other any less easy to follow or write: I can see that both are loop statements, and use both as easily.
    RoR is hiding all the boilerplate code from you, and let you concentrate on the *business rules*.

    I do tend to agree with this, which is why I am looking into the possibility of using Groovy to express business within my Java code.
    Ruby and RoR is just the promise of something like LORE : Learn Once Reuse Everywhere;-)

    No, it really does not. It is Learn Once, Reuse Only In Projects That Are Suited To Be Coded Entirely In A Scripting Language (LOROIPTASTBCEIASL?). This 'use everywhere' attitude is what will cause problems for Ruby.
    And this is exactly why I find writing for RoR more exciting and appealing than writing for any J2EE stack ( which I do everyday ...). RoR is still in its infancy, but do you remember the days where Java was this little language to do *scripting applets* ? Nobody then would have admit that Java was nothing but a toy to add animations to your webpages, and not a mainstream system language like C/C++. All *serious enterprise* code had to be done in C these days :-)Cheers.

    This again is mistaken. Ruby nearly as old as Java. In that time Java has gained full-featured IDEs and high performance. Ruby was, and is still, a scripting language. A powerful one, but designed for quick coding of smallish tasks.
  84. Why less LOC is interesting[ Go to top ]

    <blockquoye>From one of the many Steve Zara post
    Perhaps too many in one day...!
    .But that's not the point.Because, code, even if it is generated by the machine, is still code that you have to read someday. Think of this : you are spending more time *reading* the code you wrote, that actually *writing* it. And also you will read it several times.One could point out the fact that much of this generated code is not important and that you could safely ignore it (e.g. getters/setters), but still this is *visual pollution* that spread in your mind.I think there is a certain limit to the LOC you can put in your brain and keep a good overview of what this code is doing.
    I used to agree with this, but don't any more. I find that I can work easily with different sized functional code units in different languages. I used to be a Smalltalk developer, and I would code loops like this:1 to: 1000 do: [:index| .... ]Now I use Java, and I write:for (int index = 1; index < 1000; index++) { ... }One is shorter than the other, but I don't find one or the other any less easy to follow or write: I can see that both are loop statements, and use both as easily.
    This is clearly not the best example. But I won't start another "snippets comparison contest" on this thread: there are already plenty here and everywhere on the web. That's not the point.

    Sometimes you will find Java is not more verbose that Ruby, but most of the time it is. And it's a fact that cannot be discussed ( "Facts are obstinate" as Lenine said ).

    So this is how I think : less code is less bugs, less bugs is less maintenance. And less code is easier to maintain, because you have less to read and understand.

    RoR is hiding all the boilerplate code from you, and let you concentrate on the *business rules*.
    I do tend to agree with this, which is why I am looking into the possibility of using Groovy to express business within my Java code.
    Ruby and RoR is just the promise of something like LORE : Learn Once Reuse Everywhere;-)
    No, it really does not. It is Learn Once, Reuse Only In Projects That Are Suited To Be Coded Entirely In A Scripting Language (LOROIPTASTBCEIASL?). This 'use everywhere' attitude is what will cause problems for Ruby.

    I did not make myself clear : when I said "reuse everywhere", I wanted to say reuse everywhere in every RoR project. Not the reuse everywhere, meaning RoR is usable *everywhere* for everything. I do not think it is suitable for anything else that small web development ... for now.
    But let it grow, and we'll see.

    And this is exactly why I find writing for RoR more exciting and appealing than writing for any J2EE stack ( which I do everyday ...). RoR is still in its infancy, but do you remember the days where Java was this little language to do *scripting applets* ? Nobody then would have admit that Java was nothing but a toy to add animations to your webpages, and not a mainstream system language like C/C++. All *serious enterprise* code had to be done in C these days :-)Cheers.
    This again is mistaken. Ruby nearly as old as Java. In that time Java has gained full-featured IDEs and high performance. Ruby was, and is still, a scripting language. A powerful one, but designed for quick coding of smallish tasks.

    First, I do not think Ruby is a scripting language. I know the official website is stating that, but it's not really important what it states (the picking axe book I bought defines it as simply an "object oriented lanquage") .

    What is really important is what Ruby does, or does not have to be a complete language. I can't see anything missing : Ruby have all Java have, plus some extra. You just can trash away all the useless strong typing. When you say to me "scripting language", I think of Bash or Javascript. So if you think Ruby is a scripting language, just put me under the nose what it's missing in Ruby to be a real language.

    Second, languages do evolve, and Ruby had a lot since its infancy. So maybe it was build to be a versatile tool language, but it is now much more a plain object oriented language with a usefull bunch of core libraries. So saying that Ruby is "designed for quick coding of smallish tasks" is simply unfair.

    Python was designed also this way, but time and enthousiast people proved that kind of statements is wrong. They proved it is definitly possible to write things like a complete database or a web server, or an evolved CMS in pure Python.

    Remember that " Java started as a part of a larger project to develop advanced software for consumer electronics." ( exerpt from sun's docs ) and that it was expressively designed for use on internet. Ages ago the all Java thing was about Applets. And then people proved it was possible to write a database or a web server or a CMS in pure Java. And Java gained its title of "system language" and is now thought as a replacement for C/C++.

    I think Ruby does not have all Java have (or Python) simply because it is not widespread like Java. It took years for Python to gain a large enough user base to see projects like Zope or Gadfly emerge. Ruby is in the same process as Python was 4-5 years ago : gaining users and libraries. But what surprises me is the speed at which it is catching up Python and Java on this. You would be surprised by the number of ruby projects starting these days. There is for example a complete reimplementation of Hivemind (it's called copland BTW). And I am sure there will be others "ports" from Java land.

    Ruby learned alot and still learns from Java, it's sad to see that the Java people seems not to learn from Ruby ( yet some people do )

    Cheers.

    And try to *relax* a little bit :-) It's just code ... (yes it pays my bills too but that's no reason)
  85. Why less LOC is interesting[ Go to top ]

    First, I do not think Ruby is a scripting language. I know the official website is stating that, but it's not really important what it states (the picking axe book I bought defines it as simply an "object oriented lanquage") .

    It is highly important what the website states, as the website is presumably written by the developers who help maintain Ruby. It does not make sense to try and insist that Ruby is more than the main language website says!
    What is really important is what Ruby does, or does not have to be a complete language. I can't see anything missing : Ruby have all Java have, plus some extra.

    Ah. Like speed, security, and high-quality IDEs and debuggers, such as NetBeans or Eclipse.
    You just can trash away all the useless strong typing.

    It isn't useless. Sometimes it is very useful for compile-time testing. I like to have the choice of using it or not.
    When you say to me "scripting language", I think of Bash or Javascript. So if you think Ruby is a scripting language, just put me under the nose what it's missing in Ruby to be a real language.

    Nothing. It is a real language. A real language designed for scripting and interpreted use.
    Second, languages do evolve, and Ruby had a lot since its infancy. So maybe it was build to be a versatile tool language, but it is now much more a plain object oriented language with a usefull bunch of core libraries.

    How has it changed? Has it gained speed, or security features?
    So saying that Ruby is "designed for quick coding of smallish tasks" is simply unfair.

    Well, if you want to code large tasks with out a full-featured IDE with features such as debugging and refactoring and code completion, I wish you luck!
    Python was designed also this way, but time and enthousiast people proved that kind of statements is wrong. They proved it is definitly possible to write things like a complete database or a web server, or an evolved CMS in pure Python.

    Of course this is possible (although I would be interested to know of a 'complete database' written in Python). You can write almost anything in almost any language. The question is whether it is really sensible to do this.
    Remember that " Java started as a part of a larger project to develop advanced software for consumer electronics." ( exerpt from sun's docs ) and that it was expressively designed for use on internet. Ages ago the all Java thing was about Applets. And then people proved it was possible to write a database or a web server or a CMS in pure Java. And Java gained its title of "system language" and is now thought as a replacement for C/C++.

    Yes, but Java has, unlike Ruby, actually evolved. It has gained substantial new APIs and it has progressed from a slow interpreted language to a really high-performance language.
    I think Ruby does not have all Java have (or Python) simply because it is not widespread like Java.

    You are contradicting yourself. Earlier you said:
    Ruby have all Java have, plus some extra
    it's sad to see that the Java people seems not to learn from Ruby ( yet some people do )Cheers.And try to *relax* a little bit :-) It's just code ... (yes it pays my bills too but that's no reason)

    Its not just code - its the potential for large number of failed and abandoned projects, potentially wasting lots of time and money, because of developers being fooled by hype into trying to develop large systems with languages that weren't designed for this.

    You can't make Ruby more than it is just by wishful thinking and hope - developers will be more successful if they accept its limitations, and use it for what it does well, and not by assuming it is general purpose.
  86. Why less LOC is interesting[ Go to top ]

    Its not just code - its the potential for large number of failed and abandoned projects, potentially wasting lots of time and money, because of developers being fooled by hype into trying to develop large systems with languages that weren't designed for this.
    This topic really isn't that new. The same thing happened/applies to COBOL and QuickJob/Easytrieve/... .
  87. Why less LOC is interesting[ Go to top ]

    Its not just code - its the potential for large number of failed and abandoned projects, potentially wasting lots of time and money, because of developers being fooled by hype into trying to develop large systems with languages that weren't designed for this.
    This topic really isn't that new. The same thing happened/applies to COBOL and QuickJob/Easytrieve/... .

    Reminds me of the fashion for '4th generation languages' in the 80s.
  88. Why less LOC is interesting[ Go to top ]

    Its not just code - its the potential for large number of failed and abandoned projects, potentially wasting lots of time and money, because of developers being fooled by hype into trying to develop large systems with languages that weren't designed for this.
    This topic really isn't that new. The same thing happened/applies to COBOL and QuickJob/Easytrieve/... .
    Reminds me of the fashion for '4th generation languages' in the 80s.
    Exactly. I had to do the same thing then. Rip out the 4GL code and do COBOL. Should have never made it to production. At least they named QuickJob well.
  89. Why less LOC is interesting[ Go to top ]

    just read this blog -http://www.jroller.com/page/thuss/20050401#fed_up_with_java_switching
  90. Why less LOC is interesting[ Go to top ]

    just read this blog -http://www.jroller.com/page/thuss/20050401#fed_up_with_java_switching

    Nice one!

    What is so amusing about all this RoR stuff is I have seen it all before so many times. I remember when PERL was going to take over the world, then it was Tcl/Tk, then Python, now Ruby. I wonder what the next overhyped scripting language will be?
  91. Why less LOC is interesting[ Go to top ]

    It is highly important what the website states, as the website is presumably written by the developers who help maintain Ruby. It does not make sense to try and insist that Ruby is more than the main language website says!

    But the reference book from Dave Thomas does not says the same : so who should we trust ? Our mind or some statements ?
    If I ask the webmaster of ruby-lang to remove this word, and he does agree, would all your belief vanish ? I do not think so, so please, stop with this kind of FUD.

    Ah. Like speed, security, and high-quality IDEs and debuggers, such as NetBeans or Eclipse.

    You are again deviating some unprecise statement I made : I was of course speaking of the language alone ( but isn't it obvious ? ). Ruby have control statements, loops, exceptions, objects, etc ... Just like Java does. But Ruby also got closures and - more important I think - a powerful and beautiful mixins mecanism. Whereas in Java you have to learn how to use an AOP toolkit to do mixins. This is the kind of plus I was thinking of.

    Nothing. It is a real language. A real language designed for scripting and interpreted use.

    Can't you see the comparison I made with Java ? Sometimes even the creator(s) of a language does not see all the possibilities offered by the language, until the users proves it's possible to do something that was not intented to be made at first.
    Java *was not* designed to be a system language, but today it is proven you can do system developement in Java.
    How has it changed? Has it gained speed, or security features?

    Yes it has, it is, and it will, definitly. The new VM is on its way, and will be faster. The standard API is very good and intuitive, and growing with every release. And like Python it has security. It does also have unit testing integrated.
    Well, if you want to code large tasks with out a full-featured IDE with features such as debugging and refactoring and code completion, I wish you luck!

    The need for more and more complex tools cames mainly from the fact that J2EE projects are bloated with complexity and boilerplate code/configuration files.
    And refactoring is painful because of strong typing.
    I do appreciate refactoring with Eclipse, but what I'd appreciate more would be *not* having to refactor.
    Of course this is possible (although I would be interested to know of a 'complete database' written in Python).

    There is Gadfly, but I know what you will say : it's not complete, it does not have *enterprise* features. Well, I'm not selling Gadfly for enterprise use, but everybody on this planet does not need enterprise features.
    You can write almost anything in almost any language.


    NO, you can't ...
    The question is whether it is really sensible to do this.

    Sometime it is, sometime it isn't. With this thinking of yours we would never had database in plain Java, nor webservers because there is already a lot of good, proven, rocksolid ones written in C. But at some point it was sensible to have a tomcat or a hsqldb.
    The same is true for Ruby : it's not sensible to reimplement everything where you can do some interfaces/drivers. But at some point it will be sensible to rewrite things. For example there is already an XML parser in plain Ruby ( ReXML ) and if you have a look at the API and code samples, you will understand rapidly why it was a good thing to rewrite that stuff ( even if there was already a wrapper to libxml ): better integration and more natural syntax, close to Ruby's one.
    Yes, but Java has, unlike Ruby, actually evolved. It has gained substantial new APIs and it has progressed from a slow interpreted language to a really high-performance language.

    How do you know Ruby doesn't have evolved ? From where do you got this opinion ? It actually *have* evolved, and in the same way Java had : optimizing speed, and gaining APIs. Moreover you don't need a 3 years JCP to add a feature to the language.
    You are contradicting yourself. Earlier you said:
    Ruby have all Java have, plus some extra

    No I'm not. Ruby have more core language features, less tools/IDEs/libs than Java, that's it.

    Its not just code - its the potential for large number of failed and abandoned projects, potentially wasting lots of time and money, because of developers being fooled by hype into trying to develop large systems with languages that weren't designed for this.You can't make Ruby more than it is just by wishful thinking and hope - developers will be more successful if they accept its limitations, and use it for what it does well, and not by assuming it is general purpose.

    Well, I could take this statement, and replace the word Ruby by Java. There already have been a lot of waste/failures with, for instance, EJB. There had also lost money on hype technologies in the Java world.

    This is not the language/framework the problem, but the people using it.

    Anyway, what I could use for now, and that would ease my everyday's job, is to have some of the nice aspects of Ruby or RoR incorporated in some way to Java. But sadly, I doubt it will happen someday.

    cheers.
  92. Why less LOC is interesting[ Go to top ]

    It is highly important what the website states, as the website is presumably written by the developers who help maintain Ruby. It does not make sense to try and insist that Ruby is more than the main language website says!
    But the reference book from Dave Thomas does not says the same : so who should we trust ? Our mind or some statements ? If I ask the webmaster of ruby-lang to remove this word, and he does agree, would all your belief vanish ? I do not think so, so please, stop with this kind of FUD.

    How can quoting the description of a language from the designers of the language possibily be called FUD? I would call ignoring the main language website and inventing your own description of a language you have not written much more like FUD, or at least not being realistic.
    Ah. Like speed, security, and high-quality IDEs and debuggers, such as NetBeans or Eclipse.
    You are again deviating some unprecise statement I made : I was of course speaking of the language alone ( but isn't it obvious ? ). Ruby have control statements, loops, exceptions, objects, etc ... Just like Java does. But Ruby also got closures and - more important I think - a powerful and beautiful mixins mecanism. Whereas in Java you have to learn how to use an AOP toolkit to do mixins. This is the kind of plus I was thinking of.

    Great, but it is of little use without performance and other practical features. There are some great languages out there that have amazing features, but without guaranteed performance and robustness and security, it is not sensible to use them for substantial projects.
    Nothing. It is a real language. A real language designed for scripting and interpreted use.
    Can't you see the comparison I made with Java ? Sometimes even the creator(s) of a language does not see all the possibilities offered by the language, until the users proves it's possible to do something that was not intented to be made at first.Java *was not* designed to be a system language, but today it is proven you can do system developement in Java.

    Yes, but show me the Java website that still says 'this language is intended for Applet use'!
    How has it changed? Has it gained speed, or security features?
    Yes it has, it is, and it will, definitly.

    Show me benchmarks that demonstrate a significant improvement in ruby performance in the past few years.

    The new VM is on its way, and will be faster. The standard API is very good and intuitive, and growing with every release. And like Python it has security. It does also have unit testing integrated.

    I can't write fast apps now based on the promise that a new VM might improve speed.
    Well, if you want to code large tasks with out a full-featured IDE with features such as debugging and refactoring and code completion, I wish you luck!
    The need for more and more complex tools cames mainly from the fact that J2EE projects are bloated with complexity and boilerplate code/configuration files.And refactoring is painful because of strong typing.I do appreciate refactoring with Eclipse, but what I'd appreciate more would be *not* having to refactor.

    This is nonsense. Refactoring and other features have been used for years even in simple languages like Smalltalk (which is dynamically typed). They are now considered to be important tools for any major project. Not refactoring to test and examine your object model is now considered to be poor development technique.
     
    Of course this is possible (although I would be interested to know of a 'complete database' written in Python).
    There is Gadfly, but I know what you will say : it's not complete, it does not have *enterprise* features. Well, I'm not selling Gadfly for enterprise use, but everybody on this planet does not need enterprise features.

    Actually, I'm impressed that someone has written it. I have looked it up, and unlike databases written in Java, it doesn't match widely used databases in terms of performance or stability. Which kind of makes my point, doesn't it?
    You can write almost anything in almost any language.
    NO, you can't ...

    YES you can! There are mathematical proofs of this.
    With this thinking of yours we would never had database in plain Java, nor webservers because there is already a lot of good, proven, rocksolid ones written in C. But at some point it was sensible to have a tomcat or a hsqldb.

    That is not what I am saying at all! Of course languages evolve and change, and new languages will appear. What has happened with Java database and webservers and other applications is that they have recently become very useful because Java now has the speed of C++.

    Let me know when Ruby has the speed of C++.
    For example there is already an XML parser in plain Ruby ( ReXML ) and if you have a look at the API and code samples, you will understand rapidly why it was a good thing to rewrite that stuff

    Yes, and it is very slow compared to Java's libraries.
    It actually *have* evolved, and in the same way Java had : optimizing speed, and gaining APIs. Moreover you don't need a 3 years JCP to add a feature to the language.

    Well, I'll await benchmark evidence that the speed has improved significantly. It is funny you are talking about adding features to Java via the JCP on a thread about Hibernate! There are many libraries and tools for Java that have not been anywhere near the JCP.
    Well, I could take this statement, and replace the word Ruby by Java. There already have been a lot of waste/failures with, for instance, EJB. There had also lost money on hype technologies in the Java world.

    This is true of any language. However, look at the vast range of Java successes in all areas from mobile devices to large enterprise applications.
    This is not the language/framework the problem, but the people using it.

    Not true. Some languages are just not practical for certain purposes. I would not write high-performance math in Smalltalk. I would not attempt to write device drivers in Java. I would not write substantial enterprise code in Ruby.
  93. Why less LOC is interesting[ Go to top ]

    How can quoting the description of a language from the designers of the language possibily be called FUD? I would call ignoring the main language website and inventing your own description of a language you have not written much more like FUD, or at least not being realistic.

    Simply because you try to make the people flee from RoR & Ruby with some *unprecise* statements. This is instilling Fear, preaching Doubt and spreading Uncertainty.
    And I don't feel like lying or luring people here. Honest ! I feel moderate on this debate.
    I would feel more comfortable if you would stop bashing Ruby constantly, without giving any other reasons than this statement. I am amused to note that you do not have showed me yet a core language defect. For example, would we have spoken of PHP, I would have agreed that the lack of exceptions handling is a sufficient reason to avoid doing any substantial enterprise code with it.
    Great, but it is of little use without performance and other practical features. There are some great languages out there that have amazing features, but without guaranteed performance and robustness and security, it is not sensible to use them for substantial projects.

    Yes, and I'm not advocating using RoR or Ruby for *any* projects. I am just trying to tell you that there are things of interests elsewhere than in the Java world ( which I like very much indeed ) and that *sometimes* it would be sensible to copycat some of the best things we see. Because some of the things I see are harmless and simpler.
    Why do we still have to write/generate such piece of crap like getFoo/setFoo in every single bean like-class we write ? Ask Sun and the JCP ...
    Why do we still not having a simple Domain Language like the one that is crafted in Active Record ? Ask who you want, but I don't think it is possible to have this in Java without pain.

    And for the speed ... it's been a while I've learned that hardware is cheaper than manpower. Sometimes slower is fast enough for the task you want to do.
    Yes, but show me the Java website that still says 'this language is intended for Applet use'!

    Of course I can't ! And you know that, but it was not true some years ago. Sun's position on Java shifted many times, and I am pretty sure it will again in the future. And you don't give a little chance to let Ruby mainteners change their position on what the language is intented for ?
    This is nonsense. Refactoring and other features have been used for years even in simple languages like Smalltalk (which is dynamically typed). They are now considered to be important tools for any major project. Not refactoring to test and examine your object model is now considered to be poor development technique.&nbsp;

    Generaly speaking I do agree with you, but it depends on why you have to refactor ...
    But still, I think it is better to encourage coding techniques that avoid refactoring : that's one of the key selling arguments for AOP. Using layers and loosely coupled component can avoid refactoring, where using traditional patterns do not.
    Of course this is possible (although I would be interested to know of a 'complete database' written in Python).
    There is Gadfly, but I know what you will say : it's not complete, it does not have *enterprise* features. Well, I'm not selling Gadfly for enterprise use, but everybody on this planet does not need enterprise features.
    Actually, I'm impressed that someone has written it. I have looked it up, and unlike databases written in Java, it doesn't match widely used databases in terms of performance or stability. Which kind of makes my point, doesn't it?
    Yes and no ... Actually RDBM systems is not where Python shines, and I do not think it is appropriate to extend more Gadfly ( I don't know if it's even possible to do it ). Gadfly is fine as a little embedded DB in your application. If your project grows, you better switch later to a real database, and because you have used a subset of standard SQL, it will be made easy.
    But Python got Zope and Twisted, which are two robust and popular enterprise applications ( BTW Zope uses its own database called ZODB ). It also have an alternative VM called Stackless Python ( which basically allows for microthread and coroutines).
    And you know what ? Actually, this experimental *scripting* language implementation is used to run a massive online game called Eve Online. A real life business application, with a lot of complexity. And as far as I remember they got something like 8k clients on one single server, and more than 100k per world ( on a cluster farm).
    It's funny to see what smart and innovative people can do with a toy language ...
    You can write almost anything in almost any language.
    NO, you can't ...
    YES you can! There are mathematical proofs of this.
    Hooo, you must be kidding me ! You *know* that it's not true : theory is not practice. You surely can prove to me it's possible to write a full J2EE server in x86 assembly from scratch. But just give me a call when you're done ... if I'm not bones and ashes.
  94. Why less LOC is interesting[ Go to top ]

    And you don't give a little chance to let Ruby mainteners change their position on what the language is intented for ?

    Of course I will let THEM change their position! Let me know when they do! I will accept that Ruby has changed and is fast and powerful when they and a mass of developers demonstrate this (as happened with Java).

    However YOU simply repeatedly stating that the Ruby website is wrong in calling Ruby a scripting language is not going to convince me that Ruby is capable of general purpose use. A quick Google search reveals that it isn't - there are a many developers who are coming across serious performance problems.
    You surely can prove to me it's possible to write a full J2EE server in x86 assembly from scratch. But just give me a call when you're done ... if I'm not bones and ashes.

    This exactly my point! You can write an XML parser in Ruby (like the one you mentioned). Just give me a call when it is as fast as Java XML parsers and not (as I last read) about 50x slower, and suffering from memory problems.

    Performance is important. I used to use Smalltalk, and I loved it. However, in the end I had no choice but to move to Java. I got tired of endless promises of future speed and statements that performance did not matter, as long as the language was cool and dynamic and fun. I'm not prepared to go back to using languages where the developers have to keep making excuses for the poor performance and lack of scalability. Been there, done that, had enough of it.
  95. Why less LOC is interesting[ Go to top ]

    Of course I will let THEM change their position! Let me know when they do! I will accept that Ruby has changed and is fast and powerful when they and a mass of developers demonstrate this (as happened with Java).However YOU simply repeatedly stating that the Ruby website is wrong in calling Ruby a scripting language is not going to convince me that Ruby is capable of general purpose use. A quick Google search reveals that it isn't - there are a many developers who are coming across serious performance problems.

    Ok, fair enough !

    This exactly my point! You can write an XML parser in Ruby (like the one you mentioned). Just give me a call when it is as fast as Java XML parsers and not (as I last read) about 50x slower, and suffering from memory problems.Performance is important. I used to use Smalltalk, and I loved it. However, in the end I had no choice but to move to Java. I got tired of endless promises of future speed and statements that performance did not matter, as long as the language was cool and dynamic and fun. I'm not prepared to go back to using languages where the developers have to keep making excuses for the poor performance and lack of scalability. Been there, done that, had enough of it.

    Productivity maintanability are also important. There is always a tradeoff.
    In my job, productivity is more important than brute speed, so this is why I do think a framework like RoR may be interesting in a near future.

    And I will definitly invest some time on it personally.
  96. Why less LOC is interesting[ Go to top ]

    Productivity maintanability are also important. There is always a tradeoff.In my job, productivity is more important than brute speed, so this is why I do think a framework like RoR may be interesting in a near future.And I will definitly invest some time on it personally.

    I agree with you about this, which is why I think that hybrid systems, such as Java + Ruby (and Java + Python, and Groovy), will give huge benefits to the developer. You have the benefits of both, and it is not an either Java or scripting language situation. There is not so much of a tradeoff. Perhaps RoR is possible with JRuby?
  97. Based on my experience on projects, I prefer to see all that mappings/columns while i´m creating my POJO classes. The way that Rails work is IMHO very improductive, because looking to the class I CANNOT see what fields are in the database, and with this aproach the intellisense feature of the IDEs for example, simply was gone, to see what properties I have on an object i have to look to the DB model.
    Tell me for example wat heapens to my project if they are very large and I need for example change the name of one table column?? My code will be broken, I will need to change every call to that filed on the hole system. With the Hibernate mappings I only have to change the column name on the mapping XML to map my get/set property to another column of the database, WITHOUT changing the code on the hole project that uses the referenced get/set property.
    To me it´s one point that have to be considered before adoting a solution like ActiveRecord.
  98. Readability[ Go to top ]

    After working with Hibernate for the last six months, I can see the advantages of Hibernate and Rails. I am big fan of readable and refactored code. Hence I still think Hibernate is the better choice when the database is large and complicated and various developers touch each other's code. As the article had stated, if the database is simple then Rails is the better product since code is less, most of the code is generated and readability isn't a factor.

    Great Article.
  99. RoR is a toy?[ Go to top ]

    I keep hearing the same types of arguments that RoR is a toy. But in the end, it's all about economics. I've no doubt that a Keith Donald or Rod Johnson or Howard Lewis Ship can crank in the Java environment.

    It's the lesser developers, and new Java developers who will have trouble with it. This industry has long needed something between Java for the enterprise, and Visual Basic for toy projects. There's a whole intermediate space that's going unnoticed. Right now, too many people are trying to cram that square Java peg into that round hole. I don't think it fits. In the end, something like RoR will pop, and we'll be glad it did. Java developers will keep on cranking, but we'll be writing apps where you really do need full ORM (and where wrapping a database model is not enough.)

    And we won't try to write applications, which really should be written in a scripting language, in Java. We won't have to struggle with the extra code and brain power to grock it because we'll have a more expressive language.

    If you're building a start up where productivity is king, if you're writing a web user interface to babysit a relational database, and if you're building small tools or little apps then use the right tool for the job. The rapid code/test cycle, the dynamic and weaker typing, the improved metaprogramming capabilities and the pureness of the language have opened my eyes to Ruby. Now, I have three tools in the box, as far as languages are concerned...really, 2 since I've not coded C++ in a very long time now.

    There are still more reasons to use Java than Ruby for most applications, but that's changing pretty quickly.
  100. RoR is a toy?[ Go to top ]

    So you agree that RoR is a toy that only lesser developers would use. That puts that argument to rest.

    Also, its hard to predict but it seems much more likely the future of web development will involve declarative programming languages with xml, xaml and such things. So back to lisp and s-expressions we go. Soon fat will be in again too no doubt.
  101. no toy[ Go to top ]

    So you agree that RoR is a toy that only lesser developers would use. That puts that argument to rest.
    No and yes. Not a toy, but accessible to lesser developers (at least, in a systems-programming sense; not in an application programming sense.) I think that tools like RoR are just accessible to a wider audience. It's not that Ruby is too basic; it's that Java is too hard. I just said that the Java stack that we're using is just too hard for many of the developers who are trying to use it. And I think that line-of-business developers, who spend a good amount of time understanding the business domain, would be well-served using some kind of intermediate language, like Ruby, and a higher level abstraction, like Rails. Right now, PHP is making good headway in that slot, but it's ultimately not the right answer for apps with significant domain logic.
  102. Enough Ruby FUD[ Go to top ]

    I am a C# programmer so I'm not just defending Java here.

    "But at some point it will be sensible to rewrite things. For example there is already an XML parser in plain Ruby ( ReXML ) and if you have a look at the API and code samples, you will understand rapidly why it was a good thing to rewrite that stuff ( even if there was already a wrapper to libxml ): better integration and more natural syntax, close to Ruby's one."

    Problem #1 is that ruby is a really, really slow language. It scores near the bottom of the language shootout benchmark (http://shootout.alioth.debian.org/sandbox/index.php?sort=fullcpu). Now I know that benchmarks should be taken with a grain of salt, but clearly there are some performance issues. I was using Ruby's YAML library and found that it was slow and not thread-safe. Well I talked to the author and he said it was written in Ruby but he was re-writing it in C so it would be fast enough to be usable. Clearly this is indicative of Ruby's interperative nature, but even among other scripting languages Ruby is dog-slow.

    Also another problem with the libraries is that they lack breadth and quality compared to Java. Even if you are lucky enough to find the library you are looking for, chances are it will have been written by a programmer over the weekend, and is barely alpha quality.

    Finally, Ruby has many quirks of its own. Check out these "features" (source: wikipedia):

        "* Local variable names may not begin with a capital letter, otherwise they are treated as constants.
        * 0, "" and [] are true: In C, the expression 0 ? 1 : 0 is evaluated as 0. In Ruby, however, it yields 1. Reasoning: In Ruby, many expressions (e.g., regular expression tests) return either a numeric value, string or array, or "nil". When such a return value is evaluated in a boolean context, only "nil" is evaluated as "false": every numeric (string or array) value, including zero (0, empty string, "", or array, []) is considered "true". Coincidently, as in Java, C- and Perl-style automatic conversion from numerics, strings and arrays to boolean "false" does not work.
        * To indicate floating point numbers, it is insufficient to append a dot (99.). Because numbers are susceptible to method syntax, one must follow with a zero digit (99.0) or an explicit conversion (99.to_f).
        * There is no character (char) data type. This may cause surprises when slicing strings: "abc"[0] yields 97 (an integer, representing the ASCII code of the first character in the string); use "abc"[0,1] to obtain "a" (a substring of length 1)."

    Just little things like the method "to_f" are really annoying. To save a couple keystrokes you sacrifice so much readability. What the heck is f? Why not spell out float? This is not APL is it?
  103. Enough Ruby FUD[ Go to top ]

    I am a C# programmer so I'm not just defending Java here. "But at some point it will be sensible to rewrite things. For example there is already an XML parser in plain Ruby ( ReXML ) and if you have a look at the API and code samples, you will understand rapidly why it was a good thing to rewrite that stuff ( even if there was already a wrapper to libxml ): better integration and more natural syntax, close to Ruby's one."Problem #1 is that ruby is a really, really slow language. It scores near the bottom of the language shootout benchmark. Now I know that benchmarks should be taken with a grain of salt, but clearly there are some performance issues. I was using Ruby's YAML library and found that it was slow and not thread-safe. Well I talked to the author and he said it was written in Ruby but he was re-writing it in C so it would be fast enough to be usable. Clearly this is indicative of Ruby's interperative nature, but even among other scripting languages Ruby is dog-slow.
     
    Sometimes speed doesn't matter that much. It is often better to have to job done on time and slower, than to have it done late and optimised for 100k ops/sec. If you are concerned with speed though, there is a wrapper to libxml2, which is written in C. I don't had a look at any benchmarks, but it is said to be faster.
    And like I said earlier, Ruby have a lot of room to improve its speed (just like Java had on its time).

     
    Also another problem with the libraries is that they lack breadth and quality compared to Java. Even if you are lucky enough to find the library you are looking for, chances are it will have been written by a programmer over the weekend, and is barely alpha quality.
     
     Sure, I do admit that previously. If you do rely on a lot of libraries, it's not wise to start with Ruby. But if you have to code pure business logic, it may be smart to use Ruby (or RoR).
     
     
    Finally, Ruby has many quirks of its own.
     
     C'mon ! No language is perfect. Speaking of quirks, I am using Java 5 since 1 year now, and I do now know what a quirk is ...
     Ever heard of Stringformat ? Variable arguments functions ? Annotations ? Autoboxing ?
     These are so lame additions it would be laughable if some of them were not encouraging bad coding practices ( and bugs ...).
  104. Enough Ruby FUD[ Go to top ]

    "Sometimes speed doesn't matter that much."

    Sometimes it does though. Fact. And it has to be reliable too.

    For instance when you have this great web framework you want to promote, but you can't keep the website running because RoR (err, this great web framework I mean) is such a slow pig that it doesn't run reliably on a shared server so you have to move it to a dedicated server.

    Then of course you blame it on the MySql because it couldn't possibly be that slow pig of a framework killing the system.

    Good luck with that RoR there. If the author can't keep the simpliest of web sites (a wiki and marketing pages) running smoothly then what chance do all those "lesser" developers have.

    "C'mon ! No language is perfect."

    Exactly and Ruby is far from it. Face facts. Want a better OO language than Ruby? Check out Eiffel. It's focus is not just conciseness, but rather reusability, extendibility, reliability, efficiency, openness and portability. It has the speed of C++, but much better readability than Ruby. Check out that Shootout link and see for yourself.
  105. Enough Ruby FUD[ Go to top ]

    "Sometimes speed doesn't matter that much."Sometimes it does though. Fact. And it has to be reliable too.For instance when you have this great web framework you want to promote, but you can't keep the website running because RoR (err, this great web framework I mean) is such a slow pig that it doesn't run reliably on a shared server so you have to move it to a dedicated server.Then of course you blame it on the MySql because it couldn't possibly be that slow pig of a framework killing the system.Good luck with that RoR there. If the author can't keep the simpliest of web sites (a wiki and marketing pages) running smoothly then what chance do all those "lesser" developers have.

    Remember that this framework is still young .... It does not have yet passed the 1.0 release point. So chances are the framework itself is not optimized, and the blame is not to be put on Ruby only.
    "C'mon ! No language is perfect."Exactly and Ruby is far from it. Face facts. Want a better OO language than Ruby? Check out Eiffel. It's focus is not just conciseness, but rather reusability, extendibility, reliability, efficiency, openness and portability. It has the speed of C++, but much better readability than Ruby. Check out that Shootout link and see for yourself.

    I do not want the best OO language on earth, it's pointless. I checked Effeil once, and I found the syntax very ugly. It is also far from C/C++ which is not an advantage these days. So from my point of view, it is not more readable than Ruby.

    I found Ruby being balanced, and good enough.

    And I do not think that "programming by contract" is very suited to web development ...
    Just done some googling to find a library, and I think you would agree that this is not the way you want to do form processing ....

    BTW, about speed, Ruby is close to PHP in you shootout ...
  106. Enough Ruby FUD[ Go to top ]

    "I checked Effeil once, and I found the syntax very ugly. It is also far from C/C++ which is not an advantage these days. So from my point of view, it is not more readable than Ruby."

    Let's look at some code. A word frequency program that reads text and calculate how often each word occurs.

    Which one of these examples is more readable?

    The Eiffel version:

    class WORDFREQ

    creation make

    feature

        make is

            local
    count, highlevel: INTEGER;
    c: CHARACTER;
    dictionary: DICTIONARY[INTEGER, STRING];
    outcol: ARRAY[STRING];
    sorter: REVERSE_COLLECTION_SORTER[STRING];
    word, temp: STRING;
    iter: ITERATOR[STRING];
    do
    count := 0
    from
    !!dictionary.with_capacity(60000)
    !!word.make(40)
    io.read_character
    until
    io.end_of_input
    loop
    c := io.last_character.to_lower
    if not c.is_letter then
    -- insert word into dictionary
    if not word.is_empty then
    if not dictionary.has(word) then
    dictionary.add(1, clone(word))
    else
    count := dictionary.at(word);
    count := count + 1;
    dictionary.put(count,word)
    if highlevel < count then
    highlevel := count
    end
    end
    end
    word.clear
    else
    -- append to constructing word
    word.add_last(c)
    end
    io.read_character
    end;

    !!outcol.with_capacity(dictionary.count, 0)

    from
    iter := dictionary.get_new_iterator_on_keys
    iter.start
    until
    iter.is_off
    loop
    temp := dictionary.at(iter.item).to_string
    temp.precede_to_count(' ', 7)
    temp.extend(' ')
    temp.append(iter.item)

    outcol.add_first(temp)
    iter.next
    end

    sorter.sort(outcol)

    from
    iter := outcol.get_new_iterator
    iter.start
    until
    iter.is_off
    loop
    std_output.put_string(iter.item + "%N")
    iter.next
    end
    end
        end


    The Ruby version:

        1 #!/usr/bin/ruby
        2 # -*- mode: ruby -*-
        3 # $Id: wordfreq-ruby.code,v 1.4 2004/11/13 07:43:36 bfulgham Exp $
        4 # http://shootout.alioth.debian.org/
        5
        6 freq = Hash.new(0)
        7 loop {
        8 data = (STDIN.read(4095) or break) << (STDIN.gets || "")
        9 for word in data.downcase.tr_s('^A-Za-z',' ').split(' ')
       10 freq[word] += 1
       11 end
       12 }
       13 freq.delete("")
       14
       15 lines = Array.new
       16 freq.each{|w,c| lines << sprintf("%7d %s\n", c, w) }
       17 print lines.sort.reverse


    To me the Eiffel version almost looks like pseudo-code. It is very clear and expressive. The Ruby version is concise but has crap that reminds me of perl in it. Don't you agree?

    The kicker is that the Eiffel version is nearly 5 times faster than the Ruby version.
  107. Enough Ruby FUD[ Go to top ]

    Wow this forum just butchered the spacing of that text. No tabs I guess. This should be better. Where is the preview option?


    class WORDFREQ

    creation make

    feature

        make is

            local
                count, highlevel: INTEGER;
                c: CHARACTER;
                dictionary: DICTIONARY[INTEGER, STRING];
                outcol: ARRAY[STRING];
                sorter: REVERSE_COLLECTION_SORTER[STRING];
                word, temp: STRING;
                iter: ITERATOR[STRING];
            do
                count := 0
                from
                    !!dictionary.with_capacity(60000)
                    !!word.make(40)
                    io.read_character
                until
                    io.end_of_input
                loop
                    c := io.last_character.to_lower
                    if not c.is_letter then
                        -- insert word into dictionary
                        if not word.is_empty then
                            if not dictionary.has(word) then
                                dictionary.add(1, clone(word))
                            else
                                count := dictionary.at(word);
                                count := count + 1;
                                dictionary.put(count,word)
                                if highlevel < count then
                                    highlevel := count
                                end
                            end
                        end
                        word.clear
                    else
                        -- append to constructing word
                        word.add_last(c)
                    end
                    io.read_character
                end;

                !!outcol.with_capacity(dictionary.count, 0)

                from
                    iter := dictionary.get_new_iterator_on_keys
                    iter.start
                until
                    iter.is_off
                loop
                    temp := dictionary.at(iter.item).to_string
                    temp.precede_to_count(' ', 7)
                    temp.extend(' ')
                    temp.append(iter.item)

                    outcol.add_first(temp)
                    iter.next
                end

                sorter.sort(outcol)

                from
                    iter := outcol.get_new_iterator
                    iter.start
                until
                    iter.is_off
                loop
                    std_output.put_string(iter.item + "%N")
                    iter.next
                end
            end
        end
  108. Enough Ruby FUD[ Go to top ]

    To me the Eiffel version almost looks like pseudo-code. It is very clear and expressive. The Ruby version is concise but has crap that reminds me of perl in it. Don't you agree? The kicker is that the Eiffel version is nearly 5 times faster than the Ruby version.

    Well it depends on your backgrounds and habits I assume.
    To me the Eiffel version is very hard to read (even with correct tabulations). The code disposition is very vertical, which forces me to scroll down my eyes often, while I am much more inclined to read from left to right. And because I had to scroll down a lot, I had also to have a look back to match the end constructs with their beginning. I find it distractive.
    On the contrary the Ruby version is so concise that I can grasp the intent behind the code in a single look. I do agree there are some perlish crap in this snippet, and I do not like that. But the good point is that this kind of perlisms tends to be deprecated, and the Ruby purists are moving away from them ( some of the perlism legacy is catched by running the interpreter with warnings enabled).
    Also, what I really like is this kind of construct :

    print lines.sort.reverse

    This is so much expressive and intuitive, just like plain english. It's just like a mix between Shell pipes ( cat words | uniq | sort -v ) and Java doted notation.

    But don't get me wrong, Eiffel is certainly a well designed language - and I do have a lot of respect for its creator - it's just that I've never wrote in Eiffel ...

    As for speed, again, I don't advocate Ruby for its speed ... If you need speed or libraries, or whatever Ruby hasn't yet, stick with your usual toolbox.
  109. Enough Ruby FUD[ Go to top ]

    Fair enough Olivier.

    You seem a reasonable, openminded fellow.

    Good luck to you on your trail to programming nirvana. I know I have not quite found what I'm looking for either.
  110. What about iBATIS!!?!??![ Go to top ]

    While Hibernate and Rails are getting hyped, a very nice persistance framework is iBATIS - which is in the Apache Incubator.