Comparing coffee with gemstones

There’s a couple of posts going around about another post comparing Ta-Da with Bla-Bla Look, folks, this isn’t comparing the two languages: this is comparing different coding styles, that strangely enough value different things!


Just for completeness, here’s what the two Ruby classes would look like in Java, given a similar framework to Rails:

 // Item.java
@Validate_presence_of { content }
class Item extends ActiveRecord {

  @Transaction_required
  public void switch() {
    toggle("completed");
    if (getBoolean("completed").booleanValue()) {
      removeFromList();
      set("position", null);
    } else {
      assumeBottomPosition();
    }
  }
}

// ItemController.java
class ItemController extends ApplicationController {
  public Renderer toggle() {
    findListItems().find("id").switch();
    return Renderer.BLANK;
  }
}

Okay, the framework here is completely fictional, of course, but it _could_ exist. A class ActiveRecord could easily build a list of properties from database columns, exactly like the RubyOnRails ActiveRecord does, for example.

While some parts may be a little more verbose in one language than another, it more or less evens out.

The difference, really, comes down to coding styles. The author of Bla-Bla has used a procedural style for the ManageList/ItemController class; there’s a lot of verbosity in it that could be moved elsewhere. For example, Bla-Bla’s ManageList handles the database update, list ordering, and so forth – in TaDa, that’s on the Item object (where, IMHO, it belongs).

Using these classes to compare Java to Ruby, or RIFE to Rails (and I know very little about either), is a strawman argument of the worst kind.

Advertisements

Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 18 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 16 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.

8 thoughts on “Comparing coffee with gemstones”

  1. Isn’t this really a religious argument over the benefits of ActiveRecord over other peristence patterns?

    All the articles about RoR seem to ignore (or glaze over) the fact that it is ActiveRecord making things so easy.

    On another note, a lot of people dismiss ActiveRecord as being too simplistic, or with the N+1 query problem for large collections etc… perhaps it is thrown out more often then it should be.

    After all, modelling databases is more of a science the object modelling. Of course, I shudder to think what ActiveRecord would have looked like for some of the 4th and 5th normal form systems with 300+ tables would look like…

    Having said all that, the good RoR examples I have seen in a comparison with Java/Hibernate, the java soln weighed in at around 3 to 5k LOC, which is fairly lite regardless of what you make of LOC measurements.

  2. Um, yes and no…

    ActiveRecord is a simple mechanism for simple problems. As it turns out, for most of the TaDa list stuff, it’s a simple problem.

    However, you can use a lot of the RoR techniques without ActiveRecord and a fancier persistence model – I’ve applied them in Java quite happily. Certainly, the RoR solution from TaDa list is a “better” OO solution.

    FWIW, I feel that you can do more or less equivalent solutions between Ruby and Java, given similar frameworks (which there are). That said, the majority of Ruby programs will be more OO than the majority of Java programs. This is nothing to do with Ruby, and everything to do with the type of people who are attracted to work in new, unproven languages.

  3. Hence the original post title !

    Ruby also is a fresh start in some ways, so it appears uncluttered.

    I am sure you can do whatever you need with RoR beyond ActiveRecord, that is part of the point I gather. You take what you need from the “default” features, and plug in more complex stuff if needed. I could imagine doing the same with a java framework (you could pretty much make it look the same).

    It also doesn’t help the OO side of things for java when all the “prescribed” patterns (ie ones in the “official” sun literature) are very much non-OO from the start. So everyone who gets into J2EE really just runs with these non-OO patterns if they don’t know any better.

    Hypothetically, would you “bet your career” by using ruby for a major project with high stakes? (assuming you had complete freedom to do this, and your team would work equally well this way?). I think I just overdid the hypotheticals…

  4. Hypothetically? Yes. Assuming I’d had six months rampup time to come up to speed with Ruby, and the (max 5) other people in the team had as well.

    I wouldn’t tackle life-critical software, but that’s about the end of the constraints.

    If I’d had my druthers, though, I’d rather do it in Cincom Smalltalk. 🙂

  5. Life critical… well no one wants to really do that (hmmm… who is doing it then?).

    if (missile->status = launched) {
    ….
    }

    My theory is that the above is why ADA was invented for the US miliary. Not a good theory, though, but amusing (I am sure if it a urban myth I picked up and forgot was a myth).

    I used to do ladder logic many many many years ago for PLCs that controlled plant equipment which could hurt people badly if it went wrong. There was also an alternative to use C, but practically no one used it. Ladder was just so dumb that you had to get it right or it didn’t work.

  6. My objections to doing life-critical software is that I haven’t the right background; I’d need more than six months to pick it up. Other than that, I’d be happy to use Ruby for it (subject to a Ruby interpreter being suitably certified).

    One of my uni lecturers used to work on pacemakers. His stories make sure that I’ll stay away from life-critical stuff if I can. 🙂

  7. There was a very good point made about J2EE design patterns not being OO. This is very true. Most of the J2EE design pattern evolved out of work arounds the for problem with EJB’s abstraction of object location. The end result being very procedural programming style, i.e. ValueObject pattern, session Facade etc.

    Unfortuanely people think J2EE pattern are very good because it enforces architectural layering (which is an important OS/Networking concept), but of hardly any used in web applciation.

    regards Malcolm Edgar

  8. ValueObjects, Facade, etal can still be O/O, as can EJBs. Just because people don’t use them that way doesn’t mean they can’t be OO.

    For example: How many value object classes do you need in your application? More than one? Why?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s