Re: OO versus RDB




Dmitry A. Kazakov wrote:
On 17 Jun 2006 19:51:27 -0700, David Barrett-Lennard wrote:

I find it difficult to respond! Despite all that youv'e said I don't
really understand your concerns with my original post. There seems to
be a lot of generic statements using ill defined terms. ie a lot of
hand waving! I can neither agree nor diasagree with what you are
saying. Rather I keep on asking myself: what point are you trying to
make? Can you please say something more specific - perhaps using a
real example?

Hmm, how could it come to any example when a methodology [of comparison] is
in question?

What methodology?


Your point was: RM has simple transparent semantics? [Is it right?]

Yes


My objection/question was: so what? What makes this [any] semantics good
for solving problems? [hint: you have to show correspondence of semantics]

(There are many semantically simple things, toothpaste, for example.)

I'm neither saying OO is always best nor RM is always best. My
original post proposes a criterion for when to prefer one paradigm over
the other. I only like RM for storing "factual" knowledge about
external entities. In this limited domain, RM seems ideally suited.
It is impressively simple to understand, powerful and flexible. Every
record of every table can be understood in isolation. OO enjoys no
such simple semantics. Please tell me which statements in this
paragraph you disagree with.

I made these claims using the example of representing large amounts of
knowledge about humans. If you disagree with me, why not use the same
example, and point out some advantages of OO?


---------
Yet real examples were given in my previous post and in a plethora of
earlier discussions on this silly topic. I can provide you with a long list
of cases where RM does not suit, as a paradigm of software construction. In
the areas of my interest it fails ignominiously:

1. Compiler construction
2. Pattern recognition
3. Image processing
4. Machine learning
5. Middleware technology
6. Distributed / concurrent systems
7. Real-time / embedded systems
8. Operating systems
9. Reusable components

Nobody would even try...

Yes, in these areas RM is rather lacking. At best it may contribute
rather minor aspects of a complete solution. Perhaps a larger
contribution for machine learning.

My criterion is : OO should limit itself to things that "are what they
are". That doesn't stop OO from working well in all the above areas.

Please comment on my criterion. If it is flawed then there exists a
counter example. I challenge you to find one!


Cheers,
David Barrett-Lennard

.



Relevant Pages

  • Re: OO versus RDB
    ... really understand your concerns with my original post. ... be a lot of generic statements using ill defined terms. ... how could it come to any example when a methodology is ... you have to show correspondence of semantics] ...
    (comp.object)
  • Re: OO versus RDB
    ... really understand your concerns with my original post. ... how could it come to any example when a methodology is ... you have to show correspondence of semantics] ... I'm neither saying OO is always best nor RM is always best. ...
    (comp.object)
  • Re: OO versus RDB
    ... really understand your concerns with my original post. ... RM has simple transparent semantics? ... for solving problems? ... of cases where RM does not suit, as a paradigm of software construction. ...
    (comp.object)
  • Re: OO versus RDB
    ... really understand your concerns with my original post. ... be a lot of generic statements using ill defined terms. ... embedded software for controlling elevators. ...
    (comp.object)
  • Re: One under
    ... >The original post was a thoughtful contribution about an upsetting ... and all the respondents seem able to do is bitch about ... >semantics, when the meaning was perfectly clear all along ...
    (uk.transport.london)