Re: Object-relational impedence

David Cressey wrote:
> "topmind" <topmind_at_technologist.com> wrote in message
> news:79dc34f4-be5e-4adc-9b26-0b394a5d4173_at_s37g2000prg.googlegroups.com...
> On Mar 16, 7:55 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
> > I'm trying to figure out how the OO mind ticks. It's like trying to
> > figure out the psychology of Go To defenders. (I never met one, they
> > retired just before I got there.)
>
> I never met a GO TO defender either. In 1962, when I took my first
> programming course, everybody I knew used GO TO freely. About ten years
> later, I taught myself to program without GO TOs. It was difficult at
> first, but later it was easier then with GO TO.
>
> I recollect that people who wanted to use GO TO simply were following force
> of habit, with no elaborate rationalization.
>
> Like you, I am trying to understand what the OO people are thinking. I
> would suggest that many OO thinkers would compare people who program
> procedurally (like myself) to the GO TO die hards. And just as abandoning
> GO TO was only the beginning of adopting the structured programming
> discipline, so likewise learning inheritance, encapsulation, and
> polymorphism is just the beginning of learning to conceive of a system as a
> collaboration among objects.
>
> Unlike some people in the c.d.t. newsgroup, I am not quick to dismiss OO
> people as total fools. If OO were total foolishness, the industry would
> have gotten over it by now. The same is true of SQL, by the way.

The industry has "gotten over it" for the most part. Most custom app code actually written is generally procedures in OO clothing. OO is something that people just give lip service to for the most part. Developers are made to feel guilty if they use procedural techniques, and thus force-wrap lots of stuff into classes and methods. It creates a lot of mundane busy-work, but hey, they get paid still.

For larger projects, OO allows architects to "herd" programmers by using encapsulation to restrict the damage caused by unmotivated mediocre programmers. The architect will say, "you can only touch Employee info via these accessors and ONLY these accessors". It creates bloated buerocratic code, but as Paul Graham says, such large companies are going to have bloated buerocratic code no matter what, even if they used more relational. OO is not simplifying software in such settings, but merely controlling the mob. If a jillion accessors have to be changed, so be it: they spend the millions. It's not the only way to control the mob, but it has the most support and tools from vendors. OO is the QWERTY keyboard of mob control: sub-standard but too established to change.

>
> So far, I've managed in all these discussions to boil the OO vs RM impasse
> down to one single assertion of some of the OO people: that messages are
> not data.

Data and behavior are generally interchangeable viewpoints. To an interpreter/compiler, program code is data, for example. To a CPU, machine code is data. R fans shift the view toward a data-centric view and OO fans shift stuff to a behavior-centric view (and that's why all the set/get's in their code). I just find the data-centric view more mathable, studyable, and siftable. Set theory and collection-oriented- programming doesn't seem to gell well with behavior-centric techniques. BC techniques seem to always lead to navigational (one- -at-a-time) thinking for some reason.

>
> I remain firmly convinced, arguments to the contrary notwithstanding, that
> messages are data, regardless of whether or not messages are used to convey
> behavior. And I think that it's the failure to recognize that messages are
> data, and that message structuring is data structuring, that has held OO
> aloof from data management for all these years.
>
> In keeping with this thought, I think that an "Object Oriented Database"
> should not store "persistent objects", but rather "persistent messages".
> These messages are directed "To whom it may concern" like a message in a
> bottle. This is quite different from sending a message to a particular
> object. But it's messaging nonetheless.
>
> In order to concretize my thinking, I would have to learn not only OO, but
> OOP as well. I'm not sure I have the mental stamina to become procifient in
> OOP.
-T- Received on Mon Mar 17 2008 - 16:58:29 CET