Re: Date's "First Great Blunder"

Eric Kaun wrote:
> "mAsterdam" wrote:
>>Dawn M. Wolthuis wrote:
>>>C. J. Date has written about what he calls "The First Great
>>> Blunder" related to this question: What concept is it
>>>in the relational world that is the counterpart to the
>>> concept of object class in the object world?
>>
>>Let's sketch those worlds:
>>
>>At some time, ISO chose to define an object as a
>>"model of an entity, characterised by behaviour and state." and entity
>>being "a thing of interest".
>>
>>The dynamics here are very important. Does a relational model
>>charactarise behaviour? It surely limits behaviour by means of
>>constraints. Maybe it is somehow possible to completely capture
>>behaviour in constraints on valid states and valid transitions -
>>it is not what it is meant to do.
>
> Why not?

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?

>Characterizing (modeling) behavior is inherently difficult to
> model. Many specification languages (Z, Alloy, others) have pre- and post-
> values (e.g. X vs. X', the post-state) that work fairly well.
>
> A specification language meant for dynamic behavior might be Hoare's
> Communicating Sequential Processes (CSP), but I guarantee such things aren't
> in the heads of most OO programmers and language designers. Nor are
> state-transition tools.

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. But some of them *do* get it right. Does OO programming suck because there are many bad programmers using OO tools? No.

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

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.

>>It needs to
>>prepare for reincarnation, as it were. Well, just dump (serialize)
>>the system image, and restore it the next time the (now different)
>>program is run.
>>This is exactly what Smalltalk systems used to do (still? I don't know).
>>
>>As soon as we want to the object to *share* data with objects in
>>different programs, this scheme breaks down.
>
> It also holds the objects accountable to nothing at all - nothing
> declarative. The constraints in relational are important, for
> self-documentation, understanding, firewalling problems, etc.
> We're trying to manage great complexity
> (and OO apps are very complex, not least because
> of the value/variable hybrid mutation), and need to give our small heads
> tools to do so. Computers can check and enforce constraints. Constraints are
> shorter than code, and when that code is limited to a single method in a
> single object, a constraint can be spread across multiple objects and
> methods, making it exponentially (?) harder than a constraint, precondition,
> postcondition, etc.

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

>>To get back to where I left off:
>>What concept is it in the object world
>>that is the counterpart to the concept
>>of relation in the relational world?

>>A vampire's coffin, or something similar. Shared reincarnation
>>(not persistence, which disregards the sharing aspect) is
>>beyond the scope of looking at data as objects.
>>
>>The relational model looks at data as shared pieces of information.
>>Structured and with meaning, but passive. Until some outside chain
>>of events triggers an update, "nothing ever happens" (- Talking heads).
>>
>>Autonomous behaviour is beyond the scope of lookin at data as relations.
>
>
> Perhaps, but:
> 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. 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.

2). Ever tried to select a usable combination for a major project?
3). We are so used to them that we don't view them as tools.
4). Sure. Necessarily so.
5). As long as

1. the lasting results of the behaviour fits in the structure and
2. the structure provides support for the required behaviour, all is well.

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

Are you sure? :-) Received on Thu Apr 15 2004 - 00:31:28 CEST