Re: Mixing P/R philosophy with OO (within J2EE).

"Harry" <simonsharry> writes:
> On Apr 8, 7:27 pm, Patrick May <p...@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?

> 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?

To give you an idea of where I'm coming from, the systems I build
have behavior. They read data feeds, run Monte Carlo simulations,
compute risk, and feed the results to trading systems. They provision
telco network elements. They manage workflows that integrate
disparate COTS systems running over WANs. They broadcast video via
satellite. I want to implement these systems in a language that
matches the problem domain, not in SQL.

>> Bryce Jacobs (posting here and elsewhere under the pseudonym
>> Topmind) has admitted in this very newsgroup that he has very
>> limited practical experience with OO techniques. Your breathless
>> near-sycophancy strongly suggests to me that you are his sock
>> puppet.
>
> And, breathless sycophancy to R. Martin et al would be OK I guess.

Of course not. You have, however, quoted two completely bogus,
unfounded assertions from Bryce Jacobs' site. First, that OO is a
rehash of the network database model. Second, that OO is unsuitable
for dynamic scenarios. No one with any experience with OO techniques
would make either claim.

> Bryce Jacobs is welcome to do a 180° on his stance on OO; it won't
> change my current impressions on OO.
>
> My research + experience + insight = My world view.

You should use your own words, then.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

Lew wrote:
> Lew writes:
> >>> Kung fu that steals ideas and techniques from all styles is more
> >>> powerful than any single style.
>
> topmind wrote:
> > But takes 2 lifetimes to learn and transfer to the new batch of
> > hirees. Kungfooer's only have to win. Software developers have to
> > share their work. Analogy deflection.
>
> Are you saying you missed my point?
>
> No analogy will be perfect in all points; if it were it wouldn't be an
> analogy, it'd be the thing itself. The question is whether the analogy served
> the purpose in illustrating the message that one should use the best of all
> available techniques.
>
> If you want to share your work, this is even more important. It actually
> intensifies the point I was making.
>
> The notion that "kungfooers [sic] only have to win" betrays a complete lack of
> understanding of the principles of kung fu. Kung fu is about self-mastery and
> the graceful accomplishment of perfection. It has absolutely nothing to do
> with winning.

Well, I guess the analogy ends yet again.

We've already had a big debate on the value of "paradigm pot-purri"
roughly about 7 weeks ago. I don't wish to repeat it today.

> Analogy deflection completely missed its mark.
>
> The point in all kung fu is to teach the next generation of warriors, not to
> hold the knowledge to oneself. Analogy back on track.
>
> --
> Lew

-T-

Patrick May wrote:

>
> > 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?
>
> To give you an idea of where I'm coming from, the systems I build
> have behavior. They read data feeds, run Monte Carlo simulations,
> compute risk, and feed the results to trading systems. They provision
> telco network elements. They manage workflows that integrate
> disparate COTS systems running over WANs. They broadcast video via
> satellite. I want to implement these systems in a language that
> matches the problem domain, not in SQL.

For puke's sake again, show us an example of OO kicking P/R's ass in
these domains. Kill P/R dead with CODE & SCENARIOS, not braggings and
anecdotes.

Don't let your ego write checks that your keyboard can't cash.

> Sincerely,
>
> Patrick
>

-T-

> > 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?

I think that have been demonstrated over and over again in all these
sucessful business applications using relational algebra.

> > 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?

I think he is talking about the power of predicate logic and set
theory.

> To give you an idea of where I'm coming from, the systems I build
> have behavior. They read data feeds,

Relational algebra is used for data management, it is not used for
communication (or presentation).

> run Monte Carlo simulations,

Doesn't your Monte Carlo simulatons operate on data? Isn't relations a
suitable way of organizing data in this case? Wouldn't relational
algebra be helpful for doing parts of the calculations?

> compute risk,

Yet again, relational algebra would probably be a very helpful tools
for computing risk.

> and feed the results to trading systems.

Communication tasks is outside the realm of relational algebra.

> They provision telco network elements. They manage workflows that integrate
> disparate COTS systems running over WANs.

Relations would be a perfect tools for modelling workfolows. The
communication part is another issue. You seem to be mixing concerns in
you task descriptions.

> They broadcast video via satellite.

Communication...

> I want to implement these systems in a language that
> matches the problem domain, not in SQL.

If the problem domain is data management, SQL matches it.

> > And, breathless sycophancy to R. Martin et al would be OK I guess.
>
> Of course not. You have, however, quoted two completely bogus,
> unfounded assertions from Bryce Jacobs' site. First, that OO is a
> rehash of the network database model. Second, that OO is unsuitable
> for dynamic scenarios. No one with any experience with OO techniques
> would make either claim.

OO doesn't rehash the network model? I think there are almost a
consensus at comp.object that OO implements the network model. OO is
more than a data model, but it do uses the network data model. Can you
point out the differences?

/Fredrik

On Apr 10, 5:32 am, Patrick May <p...@spe.com> wrote:
> "Harry" <simonsha...> writes:
> > On Apr 8, 7:27 pm, Patrick May <p...@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. Once you're done designing the schema for your
real-world problem, you need to be coming up with a sound, convincing
justification for what *exactly* is lacking at the RDBMS/sql level and
in procedural style that would necessitate invocation of OO.

> > 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. In
OOP, far more thinking and keystrokes (some of which could be avoided,
see below) would typically be involved in accomplishing the same,
'practical' end-result.

> To give you an idea of where I'm coming from, the systems I build
> have behavior. They read data feeds, run Monte Carlo simulations,
> compute risk, and feed the results to trading systems. They provision
> telco network elements. They manage workflows that integrate
> disparate COTS systems running over WANs. They broadcast video via
> satellite. I want to implement these systems in a language that
> matches the problem domain, not in SQL.

And you truly believe P/R can't do any of those things? Each of the
names you've dropped above can be handled outside of OO just as
elegantly, provided you're unbiased and open enough to see elegance in
things other than OO.

> >> Bryce Jacobs (posting here and elsewhere under the pseudonym
> >> Topmind) has admitted in this very newsgroup that he has very
> >> limited practical experience with OO techniques. Your breathless
> >> near-sycophancy strongly suggests to me that you are his sock
> >> puppet.
>
> > And, breathless sycophancy to R. Martin et al would be OK I guess.
>
> Of course not. You have, however, quoted two completely bogus,
> unfounded assertions from Bryce Jacobs' site. First, that OO is a
> rehash of the network database model. Second, that OO is unsuitable
> for dynamic scenarios. No one with any experience with OO techniques
> would make either claim.

There's something in OO 'filosofy' itself (I think!) that tends to
slow you down by encouraging (forcing?) you think hard / 'consciously'
about issues which could otherwise be pragmatically ignored or which
wouldn't normally surface or could be handled in alternate ways in the
procedural world. 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. In OO however,
you must also pay attention to nontrivial design aspects such as
types, their roles, and their relationships. All this requires an
insight which simply cannot be gained overnight; infact, in most cases
it will take years and years of exposure to not only 'good' but also
'not-so-good' and 'bad' real-world OO designs.

If each type were to truly stand in isolation of and independent from
other types in the system, a major plus of OO (is-a / polymorphism)
will be lost, and the situation would get more or less akin to C-
structs... with may be a bunch of member functions attached (making it
lesser of a namespace pollution). (Note that trying to force an is-a
into a has-a is not only unnatural / unintuitive in some OO
situations, it also involves more (delegation-related) keystrokes.)

And, if an effort *is* made to 'really look around' in the system, in
the problem space... for commonalities, then it becomes a question of
how much thorough / serious / sincere / pedantic / filosofical you
want to get. For example, should I go for pure interfaces or abstract
classes? Traits/aspects? Should I follow the pimpl idiom thruout my
system? Should I forgo the use of new operator in favor of the Factory
pattern? To how much extent should I go in making my classes suitable
for extension/derivation? Is my class final enough to be designated as
such (in Java)? If no, what can I do to make it so? Should I even
worry about the finality of my classes? Should I go for MI (which C++
supports and also exemplifies via the iostream hierarchy), or should I
not go for MI (for, if a successful OO language such as Java and the
bright OO folks at Sun chose to not even support the feature, may be I
too should stay away from MI (within C++))? What should be my Vehical
hierarchy? Should TwoWheeler and FourWheeler be derived from Vehicle?
Or, should Vehicle support a method 'int getNumberOfWheels()'? Or
both? When introducing a Task type (that is capable of running in
parallel with the primary thread of the system)... now, IS Task A
Thread? Or, does Task HAVE A Thread within it? Should I derive it off
of a new GenericTask (an abstract class or an interface)? Hmm... my
system can in near future have sequential (non-parallel) tasks as
well, so let me give this thing some more thought...! If I'm
introducing GenericTask as an afterthought... is my existing class
hierarchy robust enough to handle it... or is it fragile (let me
double check this...)? Etc. Etc. Etc.

OO is about modeling reality. The problem is that we can never truly
and fully understand what reality is, as reality gets revealed (via
our experiments) in stages. The good news, however, is that this
generally is a very slow process in nature... spanning decades if not
centuries. Dare I say, it's slow enough to be stably captured by even
the most ordinary of OO taxonomists. If I model Earth as a planet and
Mars too a planet, it is very unlikely that every few weeks our
scientists would be altering either their status or the definition of
what constiutes a planet! Similary, the blue whale is going to remain
a mammal for a long time (I think). As astutely noted by TopMind (no
sock puppeting here), things don't happen this way in the most if not
all of biz situations... "CatDog's are a real possibility."

In modeling of reality in software, we naturally superimpose *our*
perception of these relationships on our class model. Which is a
*lot* of additional work (compared to p/r where all we're saying is
that this 'object' has this, this, and this attribute and that object
similarly has these other bunch of attributes, and here... here are
the loosely coupled operations you could invoke on them). So, if all
this additional work is in need of frequent re-work, than I fail to
understand what the whole point is!


> > My research + experience + insight = My world view.
>
> You should use your own words, then.
>

Ultimately, there's no such thing! Even the language we're using
right right now is a borrowed one... our parents and teachers sock
puppetted us into speaking a particular way and we continue it to this
day. Originality, some say, is remembering things while forgetting
their source! :-)

Now, sir, with your permission and blessings, I'd like to close this
exchange and get back to my work... a great deal of which (you'd be
pleased to know) is OO- and not P/R-based!

Regards,
Harry.

Harry wrote:
> <snip>
>
> Relational/procedural style predates OO.
Yes, and spaghetti predated procedural, and COBOL before it, and
assembly before it, and machine language before it. There were other DB
structures before relational, too. It doesn't make them better or
worse. It only makes them older.
> The burden of proving the
> inadequacy of relational/procedural in "real-world problem domains"
> lies on you, not me. Once you're done designing the schema for your
> real-world problem, you need to be coming up with a sound, convincing
> justification for what *exactly* is lacking at the RDBMS/sql level and
> in procedural style that would necessitate invocation of OO.
>
You're shifting the burden of proof. Both c.o and c.l.j.d being
OO-related newsgroups suggests they already accept the value of OO
languages and concepts. The burden of proof lies with those asserting
OO is inadequate. It is not c.o's responsibility to prove anything
about P/R, or even to have a position on P/R at all.
>
> <snip>
>
> OO is about modeling reality.
It is not. Programmers often mistake an OO model's similarity to
real-world objects as inspirational rather than coincidental. OO is
more about roles, responsibilities, and messaging, even than it is about
hierarchies.

As you seem to realize, attempting to model the real world is nearly
futile, even for The Architect from The Matrix.

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

Thomas Gagne wrote:

> > The burden of proving the
> > inadequacy of relational/procedural in "real-world problem domains"
> > lies on you, not me. Once you're done designing the schema for your
> > real-world problem, you need to be coming up with a sound, convincing
> > justification for what *exactly* is lacking at the RDBMS/sql level and
> > in procedural style that would necessitate invocation of OO.
> >
> You're shifting the burden of proof. Both c.o and c.l.j.d being
> OO-related newsgroups suggests they already accept the value of OO
> languages and concepts. The burden of proof lies with those asserting
> OO is inadequate. It is not c.o's responsibility to prove anything
> about P/R, or even to have a position on P/R at all.

By what debate reasoning do you conclude this? It is NOT
comp.object.evangalism or the like. It is *about* objects, not
necessarily PRO-objects. Being about a topic and being pro-topic are
different animals. Many technical topics in wikipedia rightfully have
a "Criticism" section.

> >
> > <snip>
> >
> > OO is about modeling reality.
> >
> It is not. Programmers often mistake an OO model's similarity to
> real-world objects as inspirational rather than coincidental. OO is
> more about roles, responsibilities, and messaging, even than it is about
> hierarchies.

Note that the "reality" comment is not mine. However, NOBODY AGREES ON
WHAT OOP IS and some OO'ers do claim it is about 'reality'. There is
no consensus. Thus, saying what OO is or is not is going to be sticky
either way. That being said, "roles, responsibilities, and messaging"
is a bit nebulous, especially "messaging". Everything is a message
just about. A query is message, so is HTTP requests and email. What is
different about OO messages?

>
> As you seem to realize, attempting to model the real world is nearly
> futile, even for The Architect from The Matrix.

Note that some OO'ers *do* claim OO is about reflecting the "real
world". I would roughly estimate it to be about 30% of OO fans based
on past debates.

>
> --
> Visit <http://blogs.instreamfinancial.com/anything.php>
> to read my rants on technology and the finance industry.

-T-

topmind wrote:
> Thomas Gagne wrote:
>
>
> <snip>
>
>>> <snip>
>>>
>>> OO is about modeling reality.
>>>
>> It is not. Programmers often mistake an OO model's similarity to
>> real-world objects as inspirational rather than coincidental. OO is
>> more about roles, responsibilities, and messaging, even than it is about
>> hierarchies.
>>
>
> Note that the "reality" comment is not mine. However, NOBODY AGREES ON
> WHAT OOP IS and some OO'ers do claim it is about 'reality'.
That's why it is sometimes helpful to read what OO pioneers have said
and written about the subject they helped invent.
> There is
> no consensus. Thus, saying what OO is or is not is going to be sticky
> either way. That being said, "roles, responsibilities, and messaging"
> is a bit nebulous, especially "messaging". Everything is a message
> just about. A query is message, so is HTTP requests and email. What is
> different about OO messages?
>
Alan Kay, Smalltalk's inventor, considered messages Smalltalk's bigger
concept than even "objects."
>
>> As you seem to realize, attempting to model the real world is nearly
>> futile, even for The Architect from The Matrix.
>>
>
> Note that some OO'ers *do* claim OO is about reflecting the "real
> world". I would roughly estimate it to be about 30% of OO fans based
> on past debates.
>
That's fine. I used to think that, too.

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

Thomas Gagne wrote:
> topmind wrote:
> > Thomas Gagne wrote:
> >
> >
> > <snip>
> >
> >>> <snip>
> >>>
> >>> OO is about modeling reality.
> >>>
> >> It is not. Programmers often mistake an OO model's similarity to
> >> real-world objects as inspirational rather than coincidental. OO is
> >> more about roles, responsibilities, and messaging, even than it is about
> >> hierarchies.
> >>
> >
> > Note that the "reality" comment is not mine. However, NOBODY AGREES ON
> > WHAT OOP IS and some OO'ers do claim it is about 'reality'.
>
> That's why it is sometimes helpful to read what OO pioneers have said
> and written about the subject they helped invent.

Which pioneer? Simula was interested in physical simulation (tugboats
and loading docks), while Alan Kay seemed to not emphasize the
physical issues so much.

>
> > There is
> > no consensus. Thus, saying what OO is or is not is going to be sticky
> > either way. That being said, "roles, responsibilities, and messaging"
> > is a bit nebulous, especially "messaging". Everything is a message
> > just about. A query is message, so is HTTP requests and email. What is
> > different about OO messages?
> >
> Alan Kay, Smalltalk's inventor, considered messages Smalltalk's bigger
> concept than even "objects."

That may technically be true quote-wise, but it still does not provide
a clear definition of "message", nor OO.

> >
> >> As you seem to realize, attempting to model the real world is nearly
> >> futile, even for The Architect from The Matrix.
> >>
> >
> > Note that some OO'ers *do* claim OO is about reflecting the "real
> > world". I would roughly estimate it to be about 30% of OO fans based
> > on past debates.
> >
> That's fine. I used to think that, too.

So are those people doing bad OO code until they "get it'?

>
> --

-T-

On Apr 10, 7:44 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
> Harry wrote:
> > <snip>
>
> > Relational/procedural style predates OO.
>
> Yes, and spaghetti predated procedural, and COBOL before it, and
> assembly before it, and machine language before it. There were other DB
> structures before relational, too. It doesn't make them better or
> worse. It only makes them older.

No comments on Cobol. Never used it.
Spaghetti is out of consideration here as it is trivially and
universally accepted to be a 'bad thing.'
In enterprise class systems of today, I've never heard anybody going
below the level of C, so assembly and machine languages are out of
consideration as well.
Enterprise class systems of today do, however, have the RDBMS as one
of the their components. Again, am not aware of any other DBMSs other
than Relational ones in use.

Thus, what I wanted to say was: in enterprise class systems of today,
if the RDBMS component is very much in the picture, *and* if it is
providing a nontrivial service with such solid mathematical
foundations as set theory and predicate calculus, *why* would anybody
want to ignore it and proceed to architect additional layer(s) on top
of it?

> > The burden of proving the
> > inadequacy of relational/procedural in "real-world problem domains"
> > lies on you, not me. Once you're done designing the schema for your
> > real-world problem, you need to be coming up with a sound, convincing
> > justification for what *exactly* is lacking at the RDBMS/sql level and
> > in procedural style that would necessitate invocation of OO.
>
> You're shifting the burden of proof. Both c.o and c.l.j.d being
> OO-related newsgroups suggests they already accept the value of OO
> languages and concepts.

c.o Description: Object-oriented programming and languages.
c.l.j.d Description: Databases, java.sql, JDBC, ODBC.
I don't see anything in these descriptions that suggests "they
already accept the value of OO and languages and concepts!"

> The burden of proof lies with those asserting
> OO is inadequate. It is not c.o's responsibility to prove anything
> about P/R, or even to have a position on P/R at all.

My point of view, again, is that if the layer below (the RDBMS) is
providing me with a very rich and valuable service, *and* if the
procedural style is already available, why on earth would I want to
write another set of abstraction layers if I'm perfectly happy and
comfortable with the former's interface?

>
> > OO is about modeling reality.
>
> It is not. Programmers often mistake an OO model's similarity to
> real-world objects as inspirational rather than coincidental. OO is
> more about roles, responsibilities, and messaging, even than it is about
> hierarchies.
>
> As you seem to realize, attempting to model the real world is nearly
> futile, even for The Architect from The Matrix.
>

Now that's a revelation to me! OO devoid of its somewhat
anthropomorphic style of visualizing entities, I think, would leave
big room for design errors. I'll never be absolutely sure if my
concrete classes are correctly pointing to concrete or vague/abstract
concepts.