Re: Date's "First Great Blunder"

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Thu, 15 Apr 2004 20:12:21 GMT
Message-ID: <F0Cfc.2$Ba6.0_at_newssvr16.news.prodigy.com>


"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:407dbbc2$0$571$e4fe514c_at_news.xs4all.nl...
> The relational model is designed for large shared databanks.
> Is it useful, practical for something else? Nice!
> Go ahead, use it, abuse it. No screwdriver around?
> A hammer will do. But we *have* screwdrivers.
>
> There are several models for dynamics,
> some obsolete, some still in use. Now most of those models
> can be translated into relations, for instance a STN (State
> Transiton Network). But why bother if we have tools to
> describe specialized STN's more directly, without the
> overhead which is in the relational model to cope with
> large, shared amounts of data, in casu states?

True, but this doesn't address objects per se, and most developers don't use those STN tools either. Your implication was that objects somehow improve modeling dynamic behavior, which I'd argue is false. They're static as well.

> Is 'meaning' and 'getting the predicates right' in the head of most
> database designers? No. So we are stuck with overly detailed structures
> in data we don't even know the meaning of.

True enough, although the relational model is at least derived from and implies the importance of predicates. I'm still unsure what exactly objects are derived from, and what they imply. More to the point, they're muddled combinations of things.

> But some of them *do* get it
> right. Does OO programming suck because there are many bad programmers
> using OO tools? No.

True enough - it sucks for other reasons. Granted that bad programmers can mess up anything.

> >>Why throw a sledgehammer at screws?
> >>
> >>Think of an object as a possibly active thing (actor) in the context
> >>of a running program. This context has a severe limitation. When the
> >>program stops, the object dies. In order to preserve whatever state
> >>beyond the running time of the program, the object needs to preserve all
> >>the data that is necessary to revive at a later time.
> >
> > And all that assumes that the object is the lexus of meaning, which
isn't
> > necessarily true.
> >
> Please clarify this for a non-native speaker. I read the devils's
> dictionary entry and it doesn't help me understand your sentence.

hahahahahahaha

I see that I wrote "lexus" rather than "nexus". My apologies. I don't even drive one. :-)

I just mean that using an object (poorly defined and overly complex) as the basis of your programming model is flawed. "Everything is an object" is limiting at best and untrue at worst.

> I'll just give some keywords:
>
> OO: behaviour, limited scope, effective, specialized, isolated.
> RM: meaning, wide context, lasting, general, shared.
>
> Very useful, both. We need both worlds. We need to communicate across
> their boundaries. Auch.

I disagree that OO is any better at modeling behavior than simple functions, and would further state that shoving every bit of behavior into objects is brittle and limiting.

"Limited scope" is a convention of use, easily broken by a mediocre OO developer.

Effective?

Specialized? Not really - not if the language only understands objects. Then they're overly general.

Isolated? Most apps involve a nice network of objects, which I'd hardly say is indicative of isolated / firewalled behavior.

When objects are treated as types, all is well. When the entire system structure is shoved into objects, you get pathological coupling and aliasing problems - Ye Olde value/variable confusion. And some class/type mismatches as well.

> Constraints are core to modelling (both static and dynamic),
> datamanagement, and programming. I think we agree on that.

Yup.

> > 1) those are concerns that SHOULD be separated
> > 2) there are tools for looking at each separately
> > 3) as a collective, we don't use those tools anyway
> > 4) objects merge both data and function
> > 5) behavior is required to obey structure (else the structural rules
mean
> > nothing)
>
> 1). Only if we need to separate it. The separation is costly.

The coupling is more costly, and harder to do "right".

> a. Simple administrative applications:
> A database with a simple form-painter tool will do. No specialized
> programming language required.
> b. A guestbook web-application: Any programming language wil do.
> No database required.

Nothing is required but bits, if the job to be done is simple enough. Scaling is another matter entirely.

> 2). Ever tried to select a usable combination for a major project?

I'm not sure what you're getting at. I favor a best-of-breed approach over a "one magic IDE" approach, but typically I'm not making those decisions.

> 3). We are so used to them that we don't view them as tools.

Used to what? The models and concepts? Doubtful. Most programmers think in terms of the language they use (human nature), which is why the languages must improve.

> 4). Sure. Necessarily so.

No, not necessarily unless "object" is your goal, rather than something like "good design" and "separation of concerns."

> 5). As long as
> a) the lasting results of the behaviour fits in the structure
> and
> b) the structure provides support for the required behaviour,
> all is well.

True... motherhood and apple pie.

> > etc. etc.
> >
> > In short: I don't understand what you're getting at, but I disagree with
you
> > anyway. :-)
>
> Are you sure? :-)

I'm certain that I either agree or disagree with you, in whole or in part.

  • erk
Received on Thu Apr 15 2004 - 22:12:21 CEST

Original text of this message