I've worked with a lot of accounting data, which fits the relational DB model really well. But I can't understand why I have to use an OO model to display it on a screen as a table of rows and columns with the odd field scattered here and there. It just seems like a lot of extra complexity to me when all the users want to see is SELECT * FROM TRANSACTION.... made to look pretty.
Funny, that's what my users want, and the only object I use to give it to 'em is a CSV parser that happens to have an output method (which works really well).
Users are delighted that all they have to do is click and their Excel/SAS datasets fill up. They are dumbfounded when I show them the code and it is quite literally 4 lines long, and two of them are MIME headers.
Of course, they don't see the definition of the VIEW, but why should they? ;-)
Indeed. OO is so ill defined anyway. What is documented as OO now I am sure is not what alan kay intended it to be. New popular frameworks like rails don't help either (much) - although its oo-lite - so its not so bad.
still, I am looking forward for an excuse to crack out stuff like arc and walk away from OO for a while (I am allowed to dream).
I've been working with Smalltalk, which was Alan Kay's creation. Most implementations are not what he intended -- at one Smalltalk Solutions keynote he excoriated all of us. He said that he never intended Smalltalk to become a programming language. He wanted to create a Montessori toy for the mind. That said, I don't think that Smalltalk as a programming language is that far from what he intended. He just never intended it to stop there.
Doubtful. Object oriented models mirror the real world far more than normalized relational data.
So then ... maybe its relational dogma that is the problem. People are realizing that it is the source of the object-relational impedance mismatch, and is what needs to change.
