Re: Storing data and code in a Db with LISP-like interface

Dmitry A. Kazakov wrote:

> On Tue, 02 May 2006 17:58:44 GMT, Bob Badour wrote:
> 

> 
> Any ADT defines values (the domain set) and the operations defined on. ADT
> "Set" does it as well.

Look, pointing out that one can use sets descriptively hardly comes as a shock or surprize to those of us who suggest applying set theory and predicate logic is the appropriate way to handle data management. After all, if one could not use sets to describe just about anything, they wouldn't really work for that purpose, now would they?

However, neither classes nor objects are a direct application of either set theory or predicate logic.

>>Container libraries are for shit. Give me mathematics over some crappy
>>physical implementation.
>
> What kind of mathematics you need?

Predicate logic. Set theory. Anything else that applies to the problem at hand.

> 1. Problem space? Program objects are not mathematical ones.

But relations are. Which is why your original assertions are nonsense.

> 2. Program semantics? Correctness is a separate issue. Refer to DbC and > formal static analysis. It is a quite decent mathematical discipline.

Semantics are in your head. The fact that one can use predicate calculus in the analysis of programs comes as no surprise to me either.

> 3. Types theory? Lambda calculi? There is no agreement on it, so far. But > it definitely lets formalization.

So? The shit that the OO crowd come up with falls flat.

>>>4. Classes
>>>
>>>A class is a closure of a set of types. Isn't it about sets?
>>
>>So then, one should be able to define the set operations easily. Right?
>>A join creates an entirely new type that is not a subtype of either of
>>the things joined. A union creates something that strictly speaking
>>defines a superset of the values of the types joined, which would mean
>>it could define a supertype of the things joined but not a subtype of
>>either. Cartesian product creates a new type that is neither a supertype
>>nor a subtype of either of its operands.
>>
>>Your replies in 3 to support your assertion that set operations are
>>supported actually contradicts the assertion.
>>
>>A supertype is a superset of values

> 
> This is a common misconception. The domain set of a supertype is not a
> subset of the domain set of its subtype.

No, it is a superset. I thought I was clear on that.

>>and a subset of operations.

> 
> Not quite. To be a suprtype means to export operations to the subtype. If
> all operations are exported, then they from a proper subset.

I don't give a shit about physical implementation details. Correctness is a completely separate concern. You seem totally oblivious to this important fact. If we are applying mathematics, then quite clearly a supertype is a superset of values and a subset of operations.

>>However,
>>this observation hardly leverages the power of set algebra and the
>>equivalent predicate logic. Now does it?
>
> It does not model set theory. Why should it?

If you claim it is a direct application of set theory, then your claim is false. The relational model is a direct application of both set theory and predicate calculus. This application of mathematics provides a sound basis for dealing with the concern for correctness.

OO fails miserably in comparison.

>> Think about tables of tables and operations
>>
>>>defined on them. That would be an RM equivalent of generic programming.
>>
>>Yes, it would. However, you have failed to establish that OO is an
>>application of set theory. At best, you have suggested one can use sets
>>to describe the ad hoc shit the OO disciples promote.
>
> Which is exactly an application of.

OO is not a direct application of set theory. One can apply set theory to describe anything, which is why applying it to data management is so appropriate. Applying set theory to the task of describing some ad hoc shit doesn't make the ad hoc shit an application of anything.

  You know, set theory was invented
> solely to describe the shit around as...

Of course, I agree. Which is what makes it so appropriate for data management and why favouring some ad hoc shit over it is just plain old stupid. Received on Thu May 04 2006 - 17:12:02 CEST