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



Chris Sonnack wrote:
> topmind writes:
>
> >> 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.
>
> You don't appear to have the experience to make a valid comparison.
> Why don't you describe the most complex business situation you've
> encountered, and we'll see how it compares to some situations we've
> encountered.


It would take to long to describe the situations. However, an
interesting excercise is the "payroll example" at:

http://www.geocities.com/tablizer/struc.htm


>
> > ...but interrelationships between things can get very tangly, defying
> > rational abstraction.
>
> The inter-relationships between things in quantum physics and various
> mathematical constructs is *beyond* our understanding today.  No matter
> how "tangly" business relationships are, they're a walk in the park by
> comparison.

Apparently you've never worked with the marketing department. Similar
to quantum physics, it is hard to find rational, or at least "natural",
patterns to their requests.

>
> > Many of the domains you list below are based more or less on
> > fixed algorithms or the laws of physics.
>
> "Fixed algorithms"?  In many of these fields, the algorithms have to
> be invented as they go along.

How is that different from a biz app, such as finding algorithms for
compensating sales people or regional managers in a "fair" manner?

>
> (True story: during production of the animated film, THE INCREDIBLES,
> they were having a heck of a time designing the software that did the
> simulation of Violet's long hair (the outtakes are hysterical).  At
> one point the chief software designer told the Producer that, "Hey,
> long hair is *theoretical*!"  "What do you mean, theoretical", replied
> the Producer.  "We open in nine months!"  If you've seen the film,
> you know they did solve it, but they had to *invent* it from scratch.)
>
> In *most* new feature animated films, the software is *invented* to
> meet the needs and is vastly more complex than any business software.
> For instance, each new Pixar film adds a new trick.  TOY STORY was
> one of the first good 3D animated films.  TOY STORY 2 added a much
> better shading ability.  MONSTERS, INC added hair and fur.  FINDING
> NEMO added water simulation and the ability to simulate many more
> objects in a scene.  These are all "ground breaking" applications
> that were researched and developed.  That just doesn't happen very
> often in biz apps--existing tools, technologies and understandings
> meet the need *most* of the time.
>
> There is a difference between "convoluted" (which biz apps can be)
> and "complex" (which very few biz apps are).

Well, I still don't have a clear definition of the difference between
the two. I suppose "convoluted" could mean that it is unnecessarily
complex; in other words, ruined by sloppy humans. But, maybe there are
simpler algorithms for the 3D movie software, its just that nobody has
discovered it yet.

Note that I majored in "graphics/CAD" and wrote 3D scene generation
software in Pascal as a student assignment. A good portion of the code
was merely cross-referencing and looking up stuff such as "which other
polygons intersect me". A lot of it could be reduced to mere database
operations.

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


A lot of compiler work is also merely cross-referencing stuff. Once it
is parsed and in data structures, the rest is mostly just
collectioned-oriented operations of symbol tables, precidence tables,
assembler/machine-code snippet lookups, etc. Hell, even much of the
Yacc/Lex compiler kits are data-driven (via text files containing
attributes).

> >
> > This are not necessarily more "complex", it is just that it
> > takes longer study of the domain to understand them.
>
> ROFL.  And why do you think that is?  You don't suppose it might be
> that the field is more complex than any business application?


Again, I have not seen any clear metric to measure "complex". The
number of lines of code in a payroll or tax system is not necessarily
less than in a 3D movie generator. So far they are just different
flavors of complexity, NOT different "levels".


>
> > If you have been writing 3D movie software all your life, then you
> > understand the domain and related math and it is second-hand.
>
> Don't take my word for it, seek out a long time professional in that
> field and ask them.

Everybody thinks their field is the most complex. Human ego usually
gets in the way of good answers.

>
> > I will agree that the general concept of a given biz app is usually
> > easier to understand than the things you listed,...
>
> No kidding!

But that is not necessarily related to "complexity". What I meant was
that it takes less training to understand the general concepts of a
given business. That does NOT mean the business is simple.

>
> > ...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.
>
> That's true to a great extent.  But this bit was about the relative
> complexity of biz apps, not about change management.  You were protesting
> that biz apps were just as complex...I hope we've cleared that up now.
>

Nope.

>
> >> 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.
>
> Sometimes.  But also sometimes they do the really hard bits so you
> don't have to.  The *reason* they can do this is that biz apps are
> simple and tend to be fairly similar in a given domain.  Thus a
> framework can make assumptions about the nature of the business
> and stand a good chance of being right.

I don't know about that. Companies have found a hard time
making generic business applications software. Things like
SAP take boatloads of SAP experts to tune the sucker, almost
more staff than building it from scratch.

Also, I won't necessarily dispute that polymorphism might
be great for making a spreadsheet (Excel clone) from
scratch, but that is not what those in my domain
do for a living (although I once made a FoxPro app
that executed formulas stored in tables, which is
sort of a hand-rolled spreadsheet.)

>
> Example: in about ten minutes, I can design a query for a remote DB
> and embed that query in Excel.  I can create charts based on that
> query and then link to those charts in a PowerPoint presentation.
> The end result is a presentation I can give a manager that merely
> opening refreshes so s/he is viewing current production data in a
> nice set of charts.

Until you need complex cross-referencing or other fancy calculations
that bring the Excel to it's knees. Excel has a Turing-Complete
language in it; thus it can implement ANY defined algorithm, even 3D
movies graphics (if you wait long enough for the output). So, I am not
sure
you have made a point.

>
> I can do this, because biz apps are simple enough that the tools
> can anticipate many of my needs.

No, because it has a TC language built in.

>
>
> >>> Can I at least get you to admit that? An admission that
> >>> polymorphism is NOT a universal, general-purpose technique
> >>> is an important revelation.
>
> (Perhaps it is to you, but not to anyone who understands it.)

I guess I am just dumb.

>
> >> 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.
>
> Any time the system can be designed to use an abstraction with a
> generic interface is a place where polymorphism is useful.
>
> * Handing input and output objects to functions.
> * Handing a processing "callback" object to a function.
> * Processing similar but different messages or objects.

This I disagree with. The real-world patterns of
variations on a theme do NOT fit poly in general.
Classification philosophers have studied such far
more carefully than you and I and generally
agree with me on this.

> * Implementing various toolkits (e.g. JavaBeans concept).

Kind of vague. What is not a "concept"? (JavaBeans suck BTW)

> 
> 

-T-

.