Re: Whose Fish?


Jordan Marr wrote:
This sounds like yet another "you hate OO because you don't get OO"
insult. To me, OO is a *lower* level of abstraction than p/r because
it uses objects pointing to objects instead of relational rigor to
define most of the relationships between things. OO is like the Go To
of modeling: a wad of pointers. Good p/r also tends to meta-tize
things that OO'ers like to hard-wire into code. I've demonstrated this
already with my Payroll code example versus R. Martin's. How is hard-
wiring a higher abstraction? OO has no definable, dissectable,
analyzable rigor. If there is a genius to it, nobody has been able to
isolate it in a western-reductionalist style, instead sounding like a
bad episode of Kung fOO. (I am not saying traditional Eastern
thinking is necessarily bad, just that it is harder to dissect and
test in a reproducable, measurable, and scientific way. Maybe fuzzy
Zen thinking works better, but it eludes dissection.)

This thread is about the Whose Fish riddle, and you're going off on
your typical BS. As usual, because it's the only thing you have to
say. I don't care to argue the same points you've been arguing on
every other thread on this NG. And now this thread looks just like
any other, regardless of its potential.

If your justification for the example looks like any other reply then
of course my answer will also. It is not my fault that all roads lead
to Rome.


You still haven't demonstrated with code that OO automatically leads
to more reuse or better biz frameworks.

Ugh, Whose Fish would have been so much more interesting than business
apps, which you are stuck on.

Perhaps. But practicality should trump mental masturbation unless we
are entering "American Paradigm Idol".

Have a good look at Lhotka's CSLA reusable business framework.

Awk! He's selling a book. At least the Payroll example is free. He
also mentioned "distributed environment". This usually means a RDBMS
hater, so my yellow flag is up. I already spent gobs on OO books
recommended by others.


It is all in how you percieve the problem domain and how you choose to
model it.

So we *are* modeling our view of the world instead of modeling the
world? That can lead to a lot of bias because people will give a
better score to techniques that better model their internal world, not
necessarily those that are objectively better.

Yes, the author obviously models their own view of the world. So?
And some models will function better than others.

Beyond "correct output", "better" is probably also in the eye of the
beholder. My wife's method of organizing (wooden) desk doodads is
different than mine. Is one or the other "wrong"?


"IMO", that's the problem. You have to SHOW, not TELL.

Right. I don't have to do jack. Pearls before swine as far as I'm
concerned.
If I replied to all of your replies I envision this thread never
ending. You have your mind made up already.

It is not. If you show me OOP kicking P/R's bootie in a clear
objective way, and I'll reconsider.

If I posted any examples
you would go into them with the intent to rip it apart to find
problems because your mind is already made up. It is a waste of
time.

Now, if this was actually a forum of OO enthusiasts, I can see posting
the code of this puzzle for everyone to enjoy. However, in the
current context, I don't think it is.

On a slightly different topic, I think most people are actually more
middle ground than you imagine them to be. You say OO has taken over
the industry, but every job I've ever worked was a bunch of datasets
and PR code. It's just easier to do.

In practice they are indeed middle ground. However, OO has become kind
of elistist, and is comparable to "eat your vegitibles". People are
made to feel guilty if they are not doing OO.


The projects that do incorporate OO still use a relational DB as
opposed to loading the entire DB into objects.

They still do a lot of DB mirroring. In-App composition & aggregation,
common OO techniques, is a form of mirroring. One generally does not
do this in P/R because one uses queries to "flatten" the view to fit
the particular task at hand.

I just don't see the
industry as biased toward pure OO as you seem to say it is. Most
people are willing to incorporate the best of both worlds, instead of
your world of pure case statements.

Lots of similar case statements can often be factored to tables, I
would note.


You have to
show how OO better fits the actual real world. And what about things
based on intellectual property or capital, like money? They are not
physical. Yes, you can model money transactions as a bunch of
mechanical hands moving coins around, but most would agree that is a
clumsy way to go about it. Sometimes the real world is F'd such that
we *don't* want to recreate it. Few miss library card catalogs, and
you would get fired if you emulated them if charged with building an
online book search. The purpose of biz computers is to make business
more efficient, not necessarily copy physical versions of the
activities.

I don't think you have to model it the same as reality... IOW, you
could come up with a better model and write it that way.

Sets and relational seem to work pretty well most of the time for biz
apps. OO thinking seems to ignore them. Whether sets and relational
fit the "real world" better, I don't know. They just make it easier
for the developer (at least this one) to design, manage, trace, grok,
and study the design. OO looks like Goto's uglier brother to me. At
the least, sets/R are a more "useful lie" to me than OO.

If you can documenet the pyschology for properly grokking navigational
structures (wrapped in set/gets now), please do. Some of us just don't
see the appeal, similar to the complaints Dr. Codd had against them in
the late 60's. 30+ years and nobody has answered the Doctor's issues.


Jordan

-T-

.