Common sense, above all else, is usually the essential ingredient in being good at anything.

– Tim Rogers

That Object-Relational-Mapping is a difficult Problem is not news.

The usual criticisms are all valid, but what occured to me, after thinking a while about this, is that all approaches I’ve seen so far seem oriented to the object-oriented modeling, trying to map the OO-models to database relations.

What about tackling the problem from the other side? Relations can have huge benefits over object graphs, why not leverage their strengths and, instead of mapping OO to relations, just try to use OO to make dealing with relations easier and more natural in OO languages?

Relational logic is powerful and relatively easy to understand. There are just a few annoyances that should be addressed:

• Validation
• Mapping relations to forms
• Keeping track of associations

This wasn’t in any way thought through by me, it just came to my mind. Maybe there are already some solutions that go this route, maybe someone even proved this to be impractical. The approach seems worth investigating.

…as soon as I find the time :(

Ola Bini manages to express my feelings about the difference between Ruby and Python:

So what’s the point? Well, the point is Ruby. In fact, Ruby has almost all of the flexibility of Perl to do things in different ways. But at the end of the day, none of the Perl problems tend to show up. Why is this? And why do I feel so comfortable in Ruby’s “There is more than one way to do it” philosophy, while the Perl one scares me?

I think it comes down to language design. The Python approach is impossible for the simple reason that what the language designer chooses is going to be the “one way”, by fiat. Some people will agree, and some will not. But what I’m seeing in Ruby is that the many ways have been transformed into idioms and guidelines. There are no hard rules, but the community have evolutionary evolved idioms that work and found out many of the ways that doesn’t work. This seems to be the right way - if you do the choice as a language designer, you have actually chosen the people that will use your language: that’s going to be the persons who doesn’t dislike the language designers choices. But if you leave it open enough for evolutionary community design to happen you can actually get the best of both world: both a best way to do things, and something that works for a much larger percentage of the programmer world.

– http://ola-bini.blogspot.com/2008/02/language-design-philosophy-more-than.html

I like constraints, they can be liberating, but I also want to be treated as a grownup when it comes to breaking them. So Ruby’s socially suggested guidelines are much more comfortable to work with than Python’s enforced style.

One school is that everything is fully deterministic in practice (“Theory D”). If development appears, from the outside, to be probabilistic, it is only because we haven’t discovered the “hidden variables” that fully determine the outcome of software development projects. And, since we are talking about development in practice, it is practical to measure the variables that determine the outcome such that we can predict that outcome in advance.

The other school of thought is that development is fully probabilistic in practice (“Theory P”), that there are no hidden variables that could be used to predict with certainty the outcome of a software development project. Theory P states that the time and effort required to measure all of the variables influencing a software development project precisely enough to predict the outcome with certainty and in advance exceeds the time and effort required develop the software.

…

To date, Theory P is the clear winner on the evidence, and it’s not even close. Like any reasonable theory, it explains what we have observed to date and makes predictions that are tested empirically every day.

Theory D, on the other hand, is the overwhelming winner in the marketplace, and again it’s not even close. The vast majority of software development projects are managed according to Theory D, with large, heavyweight investments in design and planning in advance, very little tolerance for deviation from the plan, and a belief that good planning can make up for poor execution by contributors.

Does Theory D reflect reality? From the perspective of effective software development, I do not believe so. However, from the perspective of organizational culture, theory D is reality, and you ignore it at your peril.

– http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html

Last night Zed Shaws Rails is a Ghetto Shitstorm was brought to my attention. Zeds rant provides enough meat for a post of its own but it’s not what I want to write about today. Following some comments on Zed article on Technorati I stumbled (again) into one of those evenings full of great discoveries.