Re: Relational-to-OOP Tax

"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
Patrick May wrote:
No, I agreed that using a database for simple create, read,
update, and delete operations, all directly supported by
straightforward SQL, made sense. The same clear overlap does not
exist between complex business requirements and database
functionality.

Well, either way, you have not presented evidence of the DB getting
in the way for typical biz apps; simple, CRUD, or complex. There is
no "getting in the way" evidence so far.

Your squirming is getting repetitive (and old). You made the
claim that "If you embraced the DB instead of spend all your code
wrapping it, the app would be noticably simpler." Let's see your
proof.

You made the claim that using the database features will
simplify the design relative to using OO techniques, without
restricting the context of that claim. You therefore have the
burden of proof to support that claim in the context of behavior
more complex than simple CRUD.

I have no idea how you are measuring "complex".

Do you have no experience with anything other than CRUD systems?

CRUD screens can often be complex because the rules for what, when,
how, and where to display stuff can be sticky and involve a lot of
nitty gritty biz rules.

It sounds like you need to learn some patterns for decoupling
your presentation and business rules. Look up MVC and some more
recent enhancements. Careful, though, that might be getting
dangerously close to the "OO Paradigm" for your taste.

If CRUD was truly simple, then it would be packaged in easy
libraries or tools such that they could be wipped out in half-a-day.

Many can. The basic functionality of CRUD was among the first
automated tools available.

However, good interface design is often difficult and requires trial
and error, and lots of nitty gritty rules and exceptions to the
rules if you want to give the customer a good product.

Amazing, an entire sentence in which you've made a valid point.
Yes, good interface design is difficult. Yes, a good UI designer is
worth his weight in pizza. However, the complexity involved in
creating good UIs and reports has more to do with the tools available
and the more artistic nature of the work than with any software
development issues. Considering only business UIs (games being a
different matter entirely), the programming challenges are limited to
tweaking and fiddling. The real complexity lies in the design of the
user experience, most of which is outside the realm of code.

In any case, this is a tangent that has nothing to do with your
still unsupported claim.

Accusing your opponent of your own faults is known as
projection. You do nothing but play word games, making bold
claims, squirming, and finally refusing to meet the demands of
intellectual integrity by either retracting or supporting your
assertions.

Prove your claim regarding simplification or retract it.

Freeb already gave one.

I've seen no such thing. It's very easy for you to claim it, but
without a reference to a specific section in a specific post, it's no
more supported than any of your other claims.

Wrapping is objectively more code for single- use SQL than
in-line. And similarly, an IF or case statement connected to a
database attribute is objectively less code than a single-use
polymorphic dispatch on the same attribute.

You agreed earlier in this thread that lines of code is not the
only measure of simplicity. In order to support your claim, you need
to demonstrate a solution that "embrace[s] the DB" and is simpler by
some well-defined metric while still providing the same functionality
and benefits of the implementation you are critiquing.

Do you honestly believe that having fewer tools available
leads to higher quality software than having more tools?

Having more *by itself* does not automatically improve it, you would
probably agree.

"Lisp is worth learning for a different reason — the profound
enlightenment experience you will have when you finally get
it. That experience will make you a better programmer for the
rest of your days, even if you never actually use Lisp itself a
lot."
-- Eric Raymond

The same is true for most other languages and techniques,
although obviously to a lesser degree.

Having fewer tools cannot result in higher quality software than
having more tools and *knowing how to use them*.

As far as whether it *can* improve it if done right, it is hard to
say. It cost brain power and training to switch back and forth
between paradigms

It's not at all hard to say. Better developers manage to work
with multiple paradigms simultaneously, choosing the techniques best
for the problem at hand. Anyone who can't learn how to use at least
one each of a procedural, object oriented, declarative, and functional
language with a reasonable level of competence isn't anyone I'd hire.

and changing code from one paradigm to another is costly when domain
requirements take away a given paradigm's advantage for a given spot
of code.

You're still hung up on the idea of "paradigms". Let it go.
It's obscuring your view of a the more cohesive, integrated reality
beyond your self-limiting categories.

There is probably a point of diminishing returns such that the skill
to know and read multiple paradigms becomes more of a drag than
having more options adds. If programmers lived 500 years and were
not pressured to leave the profession after 42, the situation might
be different.

If you find that task of learning new techniques and approaches
particularly onerous, perhaps you aren't in the right industry for
your talents. Have you considered a career in food service?

Sincerely,

Patrick

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

Relevant Pages

  • [PATCH] Documentation cleanup: trivial misspelling, punctuation, and grammar corrections.
    ... Different DMA engines may support different number of domains. ... +- API for paravirt ops for abstracting functionality for VMM folks. ... Read/Write attribute file that controls memory scrubbing. ... + Further information can be found in the interfaces section below for ...
    (Linux-Kernel)
  • [PATCH] Documentation cleanup: trivial misspelling, punctuation, and grammar corrections.
    ... Different DMA engines may support different number of domains. ... +- API for paravirt ops for abstracting functionality for VMM folks. ... Read/Write attribute file that controls memory scrubbing. ... + Further information can be found in the interfaces section below for ...
    (Linux-Kernel)
  • Re: Relational-to-OOP Tax
    ... burden of proof to support that claim in the context of behavior ... your presentation and business rules. ... good interface design is difficult. ... with multiple paradigms simultaneously, choosing the techniques best ...
    (comp.object)
  • Re: Why is OO Popular?
    ... You're saying OO has no better support for components than ... > inheritance) are the foundation of distributed systems. ... >> of growth in the computing industry, which brings in many more people ... > A design should be as simple as possible, ...
    (comp.object)
  • Re: Important Correction (Ray Martinez)
    ... Natural selection is only one factor in producing the appearance of design, ... What is a "lie" about the above, ... Behe has not been able to demonstrate that any anthropologists are wrong. ... not support the "truth" as they know it. ...
    (talk.origins)