Re: Mixing OO and DB
From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Sat, 16 Feb 2008 14:00:50 +0100
Message-ID: <8l1qnemjudyn$.1uq6g784vxt0k.dlg_at_40tude.net>
>
> We know that doesn't work in practise, but that may be due to the poor
> type systems (or their implementations) in use. Maybe it works in
> theory and just not yet in practise - I really don't know.
>
> Heh. Could it be?
>
> Being recorded - maybe, but data - why not?
>
> No, it merely needs to be understood. A definition is neither
> a necessary nor a sufficient conditon for understanding.
> It may sharpen it, and it may assist in formalizing the understanding.
>
>
> It is not what I meant.
> In fact I wonder how you arrived to think that is what I meant.
>
>
> Nothing finer. Coarser if anything.
> What is the raison d'être of the structure of a bridge?
> That's easy: it supports the substance of the parts of the bridge
> to interact such that the bridge can do what it is designed for: carry
> traffic without blocking what is underneath. Take away the purpose of
> the bridge, take away the substance, either way the structure is futile.
>
> 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.
>
> 1. This does not follow.
> 2. Complementary views - on what?
>
>
> Schema + external predicates come to mind.
>
> It sure looks that way, even in your post I am replying to now.
Date: Sat, 16 Feb 2008 14:00:50 +0100
Message-ID: <8l1qnemjudyn$.1uq6g784vxt0k.dlg_at_40tude.net>
On Sat, 16 Feb 2008 01:44:13 +0100, mAsterdam wrote:
>> mAsterdam wrote: >>> Dmitry A. Kazakov wrote: >>>> mAsterdam wrote: >>>>> ... Which primitive elements does your formal system have? >>>> Value, type, variable, operation. >>> That looks rich enough to get somewhere. >>> >>> Somewhat OT to this thread - just because I am curious: >>> do you have a reference to definitions/descriptions of how these act >>> together you consider worthwhile? >> >> Date's definitions were OK for values and types.
>
>> Any value has exactly one type.
> We know that doesn't work in practise, but that may be due to the poor
> type systems (or their implementations) in use. Maybe it works in
> theory and just not yet in practise - I really don't know.
It does in practice. For example, Ada's type system has this property.
> Anyway, your statement does sort of draw type into the basics
> of the common ground as well, no?
Yes, it would be difficult to analyse languages otherwise, but see below.
> For precision: I do not need to
> accept "Any value has exactly one type." in order to accept blurk.
>>>>>> Bad. It means that you have to formalize "memorize" in some quite tricky >>>>>> way. Honestly I don't know what could be the difference between "memorized >>>>>> Pi", "not-yet-memorized Pi", "once-memorized-but-forgotten-by-now Pi" and >>>>>> so on. >>>>> Are you suggesting π is data? >>>> Yes. But you can take some P(pi)=true instead. >>> Or R(P(π)) - packaging a symbol/value doesn't make it data. >>> In order to be data it should convey a fact, relevant in a >>> sense outside the formal system, i.e. an observation, or the basis >>> for a decision. >> >> Then I see no disagreement anymore. Is all that rant going on for years >> between c.d.t and c.o just about what to feed to the beast?
>
> Heh. Could it be?
>>>> 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...
>>>> But I see no disagreement in the core issue: >>>> a formal system does not operate meanings. >>> I see no agreement to the core issue: >>> A formal system needs to support meaning to be useful. >> >> "To support" needs to be defined.
>
> No, it merely needs to be understood. A definition is neither
> a necessary nor a sufficient conditon for understanding.
> It may sharpen it, and it may assist in formalizing the understanding.
>
>> If you mere mean self-consistency or Turing-completeness, then it is OK.
>
> It is not what I meant.
> In fact I wonder how you arrived to think that is what I meant.
>
>> If you mean something finer than that, you have to say what.
>
> Nothing finer. Coarser if anything.
> What is the raison d'être of the structure of a bridge?
> That's easy: it supports the substance of the parts of the bridge
> to interact such that the bridge can do what it is designed for: carry
> traffic without blocking what is underneath. Take away the purpose of
> the bridge, take away the substance, either way the structure is futile.
>> 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?
>>>> It is we who assign meanings to the inputs and outputs, and, at >>>> yet another level of understanding, judge about the formal system as a >>>> whole in terms of its usefulness, for example. >>> It is IPO vs. IDO (late 70's debate) all over: >>> >>> Input values - Process - Output values: It does not matter what the >>> input means, as long as the output is correctly processed from the input. >>> >>> Input process - Data - Output process: The input process (datacapture) >>> is to be constrained in order to prevent inconsistencies in the data. >>> The output process (rendering) should be validated not to corrrupt >>> meaning. "You have 01 vacation days left". Ouch - but just within the >>> currently acceptable range. >> >> In both cases you constrain a process. So if complementary of views was >> your point, I think it is invalid.
>
> 1. This does not follow.
> 2. Complementary views - on what?
>
>> Further if you want to deal with D in >> IDO, you need a language to describe D.
>
> Schema + external predicates come to mind.
>>>>>> 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. 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.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Sat Feb 16 2008 - 14:00:50 CET