Prev: Abstraction (Was: Mixing P/R philosophy with OO)
Next: Anecdote Wall (Was: Mixing P/R philosophy with OO)
From: topmind on 11 Apr 2007 11:36

Patrick May wrote:
> "Harry" <simonsharry(a)gmail.com> writes:
> > On Apr 10, 5:32 am, Patrick May <p...(a)spe.com> wrote:
> >> >> > My current understanding is that the RDBMS is a layer [
> >> >> > . . . ] providing me a very valuable, a very significant
> >> >> > service in terms of something (set theory) that I'm well
> >> >> > familar with since my pre-college days. In absence of any
> >> >> > multi-vendor-RDBMS support requirement, I'd very much like my
> >> >> > solution to be closest to this layer.
> >>
> >> >> Why?
> >>
> >> > Why?? What do you mean! If you had a good, very useful (let's
> >> > say: an OO) layer (say, X) that was abstracting away something
> >> > ugly (say, Y) and providing you a useful service, why would you
> >> > want to build a few more layers on top of it and code against
> >> > them instead of X.
> >>
> >> And how, exactly, does this demonstrate the value of
> >> relational algebra to real world problem domains?
> >
> > Relational/procedural style predates OO. The burden of proving the
> > inadequacy of relational/procedural in "real-world problem domains"
> > lies on you, not me.
>
> The burden of proof is on the person making the claim. You are
> claiming that mapping the solution to an RDBMS and SQL provides value,
> so it's your burden to prove it.

Actually, paradigm benefits should be considered EQUAL or UNKNOWN
until proven otherwise, regardless of which newsgroup a thread is in.

>
> Attempting to shift the burden of proof is one of [topmind's]
> traits. Admit it: You're a sock puppet.

I never claimed my favorite techniques are *objectively* better. Thus,
you are lumping all your enemies into an oversimplistic group so that
you can beat the same strawman with your lame nerf weapons. I've only
pointed out there is no evidence that they are objectively worse. That
is NOT the same as claiming something objectively better.

If someone else wants to claim that relational is objectively
superior, I do *not* necessarily agree. I cannot prove relational
objectively superior. I think it results in more consistent designs,
but I have yet to formulate a way to measure consistency. A similar
argument has been used for blocks versus Go To's. Nobody can yet
objectively prove blocks are better than Go To's for that matter.
Consistency has yet to be formalized, and "visual indendation cues" is
mostly a psychological argument. It may not apply to an alien race.

>
> >> > The Facade pattern and its motivations don't apply to the above
> >> > case because I (for one) am comfortable with the SQL interface,
> >> > find it elegant enough, and would thus want to use, nay exploit,
> >> > its full power.
> >>
> >> What power are you talking about, exactly?
> >
> > The ability to *very* easily relate/join, at runtime, two or more
> > arbitrary tables (provided, of course, it makes sense) is what I
> > believe is the single biggest powerful feature of SQL/relational.
>
> How, exactly, does this translate into value in real world
> problem domains (aside from those with an explicit need to join
> arbitrary tables)? I'm trying to understand why you believe that all
> problem domains are best addressed by mapping the solution to the
> relational model.

Perhaps I am mistaking, but I don't recall anybody claiming "all".

> > I'm not saying we all become doofuses and not exercise our gray
> > matter, or that procedural does not require any thinking at
> > all... but that, IMO, it does not typically involve that much of
> > head-scratching. A first-semester programmer, IMO, can very
> > quickly, almost overnight, become an expert in identifying and
> > writing procedures. Procedural is mainly action oriented (or,
> > procedural). To carry out an action, there are steps... step 1, step
> > 2, 3, 4... If there's a step 3.5 here and a step 2.23 there to be
> > introduced, it is very easy and straightforward to do so. If you
> > need to add a new field to a C-struct, boom, you go ahead and add
> > it.
>
> And then you have to recompile and relink every module that uses
> it. Then you have to retest everything you just changed.

Use a dynamic language and/or associative arrays. C is not the
pinnicle of procedural.

>
> > In OO however, you must also pay attention to nontrivial design
> > aspects such as types, their roles, and their relationships.
>
> You have to pay attention to detail to produce quality software
> using any set of techniques. OO gives you more tools in your virtual
> toolbox. That's a good thing.

Not if it is common collection-oriented idioms that can and should be
rolled into a (semi) standardized package (AKA database) so that they
are not reinvented from scratch.


> > OO is about modeling reality.
>
> No, it is not. The best short summary of the purpose of OO that
> I've heard is that "OO is about dependency management." I'm not sure
> I buy that 100%, but it's a good first (and second) approximation to
> reality.

"Dependency management" is not clearly and consensusly defined.
Actually, relational should weigh well on this because if you manage
your dependencies via a databases, then you don't have to hard-wire
dependencies into code and can view, search, cross-reference, and
display them how you please (similar to the "visual cues" in the GOTO
issue above). App code is hard to do this with.

For example, R. Martin's payroll system hard-wires concepts such as
Union Dues into code. In my design it is merely a table entry with
appropropriate attributes and formula(s). My code does not have a
"dependency" on Union domain issues. If a new kind of tax or fee
appears, little or no new code is needed. R. Martin worries about the
wrong dependencies and weighs them poorly in my opinion. He is so
obsessed with wrapping away the database that he has ended up using
classes as data records. It traded one dependency for another, the
wrong one. (I hope to release my version of the payroll example within
a few weeks. I'm in no hurry.)

>
> Sincerely,
>
> Patrick
>

-T-

From: Patrick Thrapp on 11 Apr 2007 13:31
"topmind" wrote in message...
>
> I never claimed my favorite techniques are *objectively* better. Thus,
> you are lumping all your enemies into an oversimplistic group so that
> you can beat the same strawman with your lame nerf weapons.

Now that was good. I saved the above in my virtual quiver.


From: Kreeg on 11 Apr 2007 13:46
It's also a major case of the Pot calling the Kettle black :-)

Patrick Thrapp wrote:
> "topmind" wrote in message...
>> I never claimed my favorite techniques are *objectively* better. Thus,
>> you are lumping all your enemies into an oversimplistic group so that
>> you can beat the same strawman with your lame nerf weapons.
>
> Now that was good. I saved the above in my virtual quiver.
>
>
From: topmind on 11 Apr 2007 15:39

Kreeg wrote:
> It's also a major case of the Pot calling the Kettle black :-)

Well, now that there are more Relational Weenies here than there used
to be, the OO side is perhaps finding out how hard it is to keep track
of who believes what about P/R. (Assuming the lumpage is not
intentional, but in this case he accused somebody of mirroring me,
implying some kind of active mental accounting of who holds what
opinion. I don't think I've ever accused anybody of such, other than
mirroring OO textbooks.)

>
> Patrick Thrapp wrote:
> > "topmind" wrote in message...
> >> I never claimed my favorite techniques are *objectively* better. Thus,
> >> you are lumping all your enemies into an oversimplistic group so that
> >> you can beat the same strawman with your lame nerf weapons.
> >
> > Now that was good. I saved the above in my virtual quiver.
> >
> >

-T-

From: Universe on 12 Apr 2007 20:43
On Apr 11, 11:36 am, "topmind" <topm...(a)technologist.com> wrote:

> Patrick May wrote:

> > "Harry" <simonsha...(a)gmail.com> writes:

> > > OO is about modeling reality.

> > No, it is not. The best short summary of the purpose of OO that
> > I've heard is that "OO is about dependency management." I'm not sure
> > I buy that 100%, but it's a good first (and second) approximation to
> > reality.

OO is first about relevant, realistic modelling of the programming
domain in order to reduce the coding complexity. To pararphrase the
founders of OO Krysten Nyggard and Ole Dahle, "the purpose of of OO is
to simulate or model reality as a machine in order to reduce
complexity." (A single software system may involve multple domains,
e.g. the business domain and the low graphic driver support code
domain.)

Dependency management (reducing code coupling & hence code change
ripple effects) is generally handled in a better way using OO
modelling, but that does always mean one achieves superior reduction
of code coupling using OO for a given coding task compared to a
solution in another programming style, like for example Structured
Programming (SP), or Functional Programming (FP).

Elliott
---
* Global Plans with Iterative & Incremental Implementation *
* Theory Leads, Practice Verifies *

 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Abstraction (Was: Mixing P/R philosophy with OO)
Next: Anecdote Wall (Was: Mixing P/R philosophy with OO)