Re: Mixing OO and DB

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 16 Feb 2008 22:05:54 +0100
Message-ID: <47b74f60$0$14347$e4fe514c_at_news.xs4all.nl>


Dmitry A. Kazakov wrote:
> (I don't think that types inference is a good idea,
> but that is a rant for another day. (:-))

Don't forget to xpost it :-)

>>>>>>> ... And, equivalently, you cannot describe
>>>>>>> recording in terms of either data or facts.
>>>>>> Yep, that's the fate of primitives and semi-primitives.
>>>>> In other words being recorded / data is incomputable.
>>>> Being recorded - maybe, but data - why not?
>>> For data are [incomputably] recorded [incomputable] facts...
>> So we can't record facts containing computed data.
>> Where did this go wrong?

>
> That things we can compute need not to be recorded. It is here, computed.
> If you can spell a fact in the formal system you can forget about its
> meaning. We write Pi and leave the meaning of to the reader. It is a heavy
> burden for him, but a great relief for us, an abstraction in short.
>
>>>>> Anyway it would be not "I want data, else there is no
>>>>> common ground." It would be about the structure of the formal system which
>>>>> you wished deploy for what you call data. (Maybe, I could to do it as well,
>>>>> but for something having a different name.)
>>>> If that what it takes to get rid of the scarequotes, I have no
>>>> problem with you calling it something else if there are enough
>>>> common associations and isomorphisms - and no blocks.
>>>> Do you have a name in mind? Blurk sucks.
>>> Inputs?
>> No, that won't work. Inputs do not need to be meaningful (have 
>> values/symbols associated with informal denotations) in order to be 
>> acceptable to processes. Good enough for IPO, not for IDO.

>
> But why do you insist of meaningfulness? Even informally we deal with a lot
> of conditionals, uncertain and contradictory facts. Can't you live with
> "let the input X be meaningful"?

It is to coarse.

Many bugs are due to subtle (and sometimes not so subtle) differences in interpretation. The denotation should be explicit. IMO common understanding of ("township approved"?) external predicates leads to better software. If the system designers do not share understanding of the data - who is going to understand at all?

Still, protection of the data is another matter. Rejection of inconsistencies: bug or feature?

As a bug:
Anything goes - but I would not call that data-centric (IDO).

As a feature (i.e. data as an asset, as in most ventures): How about "let the input X be meaningful and consistent with current data"? The consistency part can be delegated to the DBMS as far as we can give it rules about what to consider consistent: constraints in the schema.

A dedicated datacapture process needs to be aware of the schema, and eventually of the current data. Rendering also benefits from schema awareness.

>>>>>>>>> Yes, we cannot reason about meaning while staying 
>>>>>>>>> within the same formal system. Because you seem 
>>>>>>>>> to bind data with a meaning (as I do), that immediately
>>>>>>>>> kicks the notion of data out of the formal system. 

(retry) Indeed. However, we can have a shared, formal proxy to meaning. Date's external predicates are a good starting point for that.

>>>>>>>>> So data do not exist
>>>>>>>>> there. Which is all my point! No data, nothing to worry about.
>>>>>>>> And the result is a hermetic system as useful as solipsism.
>>>>>>>> Have some fun there! I'm out waiting until you are bored of it.
>>>>>>> OK, I am back on vacation. How are you going to formalize something which
>>>>>>> cannot be formalized? (:-))
>>>>>> Hey, I am not the one eager to formalize without
>>>>>> a proper, shared, informal understanding.
>>>>> Neither I am. 
>>>> It sure looks that way, even in your post I am replying to now.
>>> I don't insist on formalizing it right now, but I do on that we should keep
>>> in mind necessity of doing it in order to be able to sort the mess out. I
>>> thought that your remark was about rather temporal aspect. Or do you reject
>>> any need of formalization even after certain level of informal
>>> understanding?
>> No, the informal understanding is to prune useless formalisms as early 
>> as possible (but even 'certain level' is suspect here as it suggests 
>> measurability).
>>
>> Reality check, if you will - not marketing.

>
> (:-)) Unfortunately, in our discipline marketing is the reality.

Yep, there is enough noise to hinder common understanding.

> I agree that there exist a lot of close to practically useless formal
> theories, starting from lambda calculus and ending with formal grammars.
> Yet I would not dismiss them.

Watch your tongue - there are some Lispers here ;-) Received on Sat Feb 16 2008 - 22:05:54 CET

Original text of this message