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.
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.
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.
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…
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. 🙂
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.
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. 🙂
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
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?