Re: Whose Fish?

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.

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.
Have a good look at Lhotka's CSLA reusable business framework.

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.

"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. 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.

The projects that do incorporate OO still use a relational DB as
opposed to loading the entire DB into objects. 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.

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.

Jordan

.