Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?]
To   : comp.programming,comp.object
From : topmind
Date : Fri Jul 01 2005 04:55 pm

> This has nothing to do with DBSes themselves.  Databases are used in
> most trivial of applications as well as in the most complicated.  In
> and of themselves, databases say nothing about the complexity of the
> application.

Good. That is one issue out of the way.

>
>
> >>> I don't understand why you suggest that reporting systems are
> >>> inherently "less complex" than whatever you have in mind.
> >>
> >> Because it's true.  It's understandable you don't realize that, because
> >> you've lived in "China" all your professional life (it seems).
> >
> > You are wrong. Like I said elsewhere, I have worked on many kinds of
> > business applications, not just reporting, and one is not inherently
> > more simple than the other. Can you present evidence of this alleged
> > inherent simplicity?
>
> Certainly.  Business applications (and I've BEEN a corporate programmer
> for two decades and have extensively used RDBSes) are highly, if not
> 100%, deterministic.  They (biz apps) tend to involve data storage and
> retrieval and data reporting.  They tend to be based on a *relatively*
> small set of business rules with a relatively small set of permutations.

Not the ones I encounter. I agree that if things were cleaned up,
normalized, etc., things would be easier, but interrelationships
between things can get very tangly, defying rational abstraction.
Many of the domains you list below are based more or less on
fixed algorithms or the laws of physics. Thus, they tend to
be predictable along certain lines. God does not change the
laws of physics very often.

>
> For truly complex software, consider voice or image recognition, or the
> software used by physicists to delve into quantum physics, or digital
> signal processing, or advanced mathematical programming,
> of the computer generated imaging software used in the movies.
>
> For that matter, many compilers are vastly more complicated than most
> business apps.

This are not necessarily more "complex", it is just that it
takes longer study of the domain to understand them. If
you have been writing 3D movie software all your life,
then you understand the domain and related math and it
is second-hand.

I will agree that the general concept of a given biz
app is usually easier to understand than the things
you listed, but once one is past that difference,
dealing with software change is pretty much a matter
of how to organize things to be able to change them
without too much pain.

>
> How do I know this is more complex than biz apps?  Because, as I've
> said, I've been *doing* biz apps for 20 years, and at least some of the
> software fields I listed above are well beyond me.

You seem to be confusing "easy to relate to" and "easy to
organize". These can be very different things.

>
> Trust me, especially with the frameworks and tools available today,
> biz apps are easy.

No, the tools just mean one is now focusing on the sticky parts
instead of the easy but repetitous parts.
In the domains you listed above
if there are no tools for them, then one spends more time
on grunty stuff.

A carpenter with power tools still has to do as much thinking
as those before power tools, perhaps more because lapses
can result in bigger boo boo's. Automating grunt work
does not necessarily mean your job simpler, but rather
that you spend more time on less repetitious or tedius
issues.

The IT department might cut the department in half after
a grand tool comes along, and now half the people have
to do the same amount of net end product. You might
spend your day doing less grunt stuff, but you are
still doing stuff.


>
> > And even if it was true, at least you seem to agree that it is an area
> > where polymorphism does not help much.
>
> No, I never agreed with that.  I used p/m quite a lot, actually.

Then why bring up other domains?

>
> > Can I at least get you to admit
> > that? An admission that polymorphism is NOT a universal,
> > general-purpose technique is an important revelation.
>
> If you mean it's not useful in every program, of course I agree.
> Very little is useful in *every* program.
>

Well, then let's narrow down where it is useful and where it is not.

-T-

.