Re: Whose Fish?


Jordan Marr wrote:
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.

Rome may be connected to the road system, but that doesn't mean you
have to keep going there.

Maybe I should give my arguments numbers, and just say, "Oh yeah
smarty pants, well #635!".


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

Why is "mental masturbation"? Because it wasn't a paying project?
Neither was your customer / invoice program. You wrote that
completely for completely intellectual / educational purposes too.

Yes, but it is a degree or two closer to projects people actually
encounter. Just because we cannot acheive the perfect example does
not mean we shouldn't do any. A "C+" example is better than a "D"
example.

Same as what I did. You just don't don't like the Whose Fish puzzle
because it's harder, so you're trying to degrade it by writing it off
as something below you.

So you claim. It does not resemble the majority of biz projects I have
worked on. I state that with full honesty. If your experience is
different, the so be it. We can agree to disagree on that point. The
reader can apply whichever branch best fits their experience.

I would point out that there is a whole subfield of "optimization"
problems in biz, somewhat related to the Traveling Salesman problem,
perhaps something FedEx faces when deciding how to load and move their
trucks. Maybe those are better in objects, I don't know. I haven't
done much of those so don't dwell on them.


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.

Lhotka's very robust reusable business framework is available for
free, and it's completely documented in code. There are also example
projects demonstrating how to use it. You don't have to buy the
book.

I would suggest you provide more detailed links next time, rather than
"Joe Smith at LSFU made something". If you want to encourage people to
take a look at something specific, then refer them to something
specific.


And there is nothing RDBMS hater about it. It works very much hand in
hand with the RDB.

Once again, I throw something out and you dismiss it immediately.
Let's face it: OO can (and does) write the same apps with the same
functionality (CRUD, business database apps, etc), AND it can handle
all the stuff that PR doesn't do well at (drivers, CAD, frameworks,
etc). You don't prefer it.. I do.

And I don't buy your implications that "OO" means loading the entire
contents of the database into an in memory OO DB of composition and
hierarchies. Most database are size prohibitive for that anyway.

Where did I ever say "entire"? I even gave an example of what OO tends
to do to reduce such confusion.



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

Better, to me, means the assurance that a change won't indirectly
cause other bugs. That means that the code has to be organized in an
intuitive way, as it is with a good object model,

If "intuitive" is our metric, then sets and relational are far more
intuitive to me than OOP's navigational structures. This is partly
because they are more *sift-able* than OO code: I can bring together
and alter my view of factors much more easily. I don't want to see
things how Bill Gates codes them, I want to see them how *I* want to
see them, and making factors query-able acheives that better than any
known technology. It provides a more flexible way of seeing stuff.
Your OO code will stay OO code in one way in one form. (OO code
browsers are clunky navigational query systems.)

My view of how I query info may be different than even what ANOTHER
relational weenie wants to see. I am not stuck with his/her view
either. You can't say this about OOP code.

It is the Frank Sanatra paradigm: I WANNA SEE IT *MY* WAY!

This, and more consistency across shops are the two main features of
relational.

Again, I don't dispute that OO may fit your head. But to extrapolate
your head to everyone else is a mistake.

and the logic is
encapsulated inside those models in an intuitive place. Then it is
easy to see what will be affected by changes.

Better yet if you can do it by querying, or that a non-programmer can
do it by using query tools (such as Query-By-Example) such that the
programmer does not have to be a glorified product clerk.

If you could provide a specific change example along with code impact
and how you think about it, that may be helpful. I cannot read your
mind.


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.

You just said that better is in the eye of the beholder, and you
already behold your way as better.

Everybody has their fav techniques.


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.

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.

I hate elitism but I like OO. The industry has been so dataset
oriented lately that I feel more persecuted as an OO fan than not.

Most programming language frameworks are OO, so it behooves most
programmers to be grounded in OO programming concepts.

True, but that is kind of a QWERTY Keyboard argument: we use it
because everyone else uses it, not because it is better.


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.

Whatever, most of the apps that I've ever worked on only load the data
that is necessary for the current use case. So the data is still
flattened, but it's in objects instead of table structures. At that
point, why does it matter if they are composed? The composition
collection is already flattened.. it just needs databound into a
control most of the time anyway. There is no need to traverse
anything.

This sounds contradictory. May I request some psuedocode?


Although I will say that the next version of C# will have an
integrated query language for querying in memory collections. (yay!)

I also enjoy languages/tools that offer "local queries". They fell out
of favor, but are slowly creeping back, fortunately.


Sets and relational seem to work pretty well most of the time for biz
apps. OO thinking seems to ignore them.

No, it just skins them in objects with related behavior. And for
maintenance, I know if I change the behavior of an object, I'm not
going to inadvertently affect the behavior of other objects in the
code.

Again, you have not shown how OO acheives this better than
alternatives (outside of shapes, animals, and device drivers).

-T-

.

Relevant Pages

  • Re: Whose Fish?
    ... OO can write the same apps with the same ... You just said that better is in the eye of the beholder, ... Most programming language frameworks are OO, ... In-App composition & aggregation, ...
    (comp.object)
  • Re: mfc pitfalls
    ... In most MFC apps, you are writing code in that kind ... virtual methods usually work better than callbacks for most ... no syntax in the design for function pointers. ... programming in OO environment requires new ...
    (microsoft.public.vc.mfc)
  • Re: WWW/Internet 2009: 2nd CFP until 21 September x
    ... If you can decompose the table into multiple tables each of which has no nulls, what you discover is that a null in the combined table corresponds to an absent row in one of the decomposed tables. ... If I knew then what I know now, I would have refused the whole business and gone into a sensible line of work. ... At one time, maybe it was when Dijkstra was active and 'The Psychology of Computer Programming' was a current book, this culture was evident amond C programmers. ... I have some sympathy for Walt's comments on the grounds that I thought more than half of the apps I saw wouldn't have been needed in those businesses if I had been signing the cheques, let alone most of the requirements. ...
    (comp.databases.theory)
  • Re: Whose Fish?
    ... That would be much more in line with your Table Oriented Programming ... currently programming) non CRUD business apps. ... intuitive way, as it is with a good object model, ... I might load CustomerInfo with read only ID ...
    (comp.object)
  • Re: How do I select the oldest/newest record in Access query?
    ... it may be possible that the query [BX Apps B] lists the field PolID ...
    (microsoft.public.access.queries)