Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Fri Jul 08 2005 12:24 pm 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. > ...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. > 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. (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). >> 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. 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? > 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. > 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 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. >> 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. 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. I can do this, because biz apps are simple enough that the tools can anticipate many of my needs. >>> 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.) >> 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. * Implementing various toolkits (e.g. JavaBeans concept). -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .