Re: Relational-to-OOP Tax


Patrick May wrote:
"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.

I told you that I am working on it and will take my sweet time.


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.

MVC sucks IMO. The best GUI systems are a combination of attribute-
driven and event-driven, similar to the VB/Delphi model, perhaps minus
the unnecessary GUI config code. Indexability (findability) is what
is needed, not really "decoupling". Decoupling only makes sense if you
are likely to switch GUI systems, which is too rare to bother paying a
constant complexity tax for. (Similar issue to switching DB vendors
that OO'ers claims has to be done like every 6 months.)

Again, indirection is not free.


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.

True, but the web killed them off because if its awkward event and
response cycles. But still, the nitty details are often domain-
specific or customer-specific. With good GUI tools you spend a few
days designing the basics, but weeks or months customizing it based on
customer feedback.


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.

But I've found that the web complicates the process by adding
limitations to what can be practically accomplished. One then spends
most of their time working around web limitations to fit needs instead
of focusing on what the customer really wants/needs. It is like
trying to swim without arms. The ideal GUI for the situation and the
web version are often much further apart than with fat-desktop tools.

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.

Well, I am not in a mood to go hunt it down for you.


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.

It is one of many variables. Nobody has a consensus measure of
simplicity. I would present my design, and one could see how that at
least it is less lines of code. If readers want to claim it is more
complex for whatever reason, fine. To my mind it is simpler and
barring good objective metrics being found, *psychology* is what
matters. Code is usually simpler *to me* when it uses the database as
directly as possible. This is because there is less code spent on
converting back and forth between relational/tables and navigational
structures. I find navigational chaotic and messy in addition to the
translation costs. So did Dr. Codd for that matter, so I am not alone.
If I am a nutcase for that, than so is Dr. Codd. He won an ACM prize
BTW, you didn't.

Many of us do NOT like large-scale navigational. It does not fit our
heads. If it fits yours, good for you, but don't force it down our
throats using books that imply it is the only and best way in town.

It wastes code and developer time to translate back and forth between
navigational and relational. That is the best summary of the problem
I can give you right now. OO is inharently navigational in structure
(relationship between objects).

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.

I don't remember claiming I could objectively do so, beyond code size.


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

Perhaps off topic, but one could say the same about relational and
other collection-oriented technologies such as APL and its newer
cousins. (I've asked Lispers to show it significantly improving some
sample code, and they admitted they couldn't do it, using lame evasive
excuses.)


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

It does when you are consider staffing and learning curves.


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.

Not necessarily. You create code that can only be understood by those
schooled in multiple paradigms. This means that as long as the code
exists, multi-paradigmers have to be hired. This will delay hiring
(more time to find) and make them more expensive. Unless the benefits
of doing such are significant, they will not outweigh the staffing
drawbacks.

You seem to be viewing this from a programmer's perspective, not a
business owner's.

Further, a certain percentage of such people use multiple paradigms as
a form of Mental Masturbation. They mix techniques simply because they
are bored or perhaps as a form of job-security lock-in, not because it
results in more maintanable code. I've encountered people like this.
It may be difficult to weed these out of the hirees and they will muck
up designs. The further the technique is away from a manager's
ability to verify, the more room for monkey business.

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.

Your opinion is not the majority opinion on this.


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.

We don't have a better word for mix of approaches at this point.
'"Paradigm" is the best compromise word and everybody knows what it
means even if not perfect.


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?

You come across as such an arrogant prick, you know that?

I am at the point where people tell me I should go into management to
avoid the well-known industry-wide age discrimination of programmers.
General experience is not heavily valued in this industry, only
experience in specific technologies needed by a given company. I am
just the messenger, I didn't make it this way.

Thus, the career incentive to become a multi-paradigmer is small.


Sincerely,

Patrick


-T-

.

Relevant Pages

  • Re: So as part of the idea!
    ... An AD design should support the business model. ... want it to support and optimize applying GPOs. ...
    (microsoft.public.win2000.active_directory)
  • Re: OO Design induces an existential crisis
    ... You call yourself an experienced business applications ... that is pretty good for meeting the principles of both OO design and SOA ... If they are reading one of my articles, they are probably a developer ... a function point counter and a cost wonk, ...
    (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: How should I generate a primary key?
    ... Obviously the designer did not get all of the business rules from the ... Should the database ... A Work Order records the transaction of a truck service at a given ... This has got nothing to do with bad design, it is about the developer trying ...
    (comp.databases)
  • 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)