Re: One Ring to Bind Them
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Tue, 15 Jun 2004 03:08:43 +0200
Message-ID: <40ce4c14$0$559$e4fe514c_at_news.xs4all.nl>
>
> Although then "they" (or is that "we"?) start spec'ing things as parms,
> perhaps pulled into the OO code by way of xml documents. You can send
> inputs to pre-existing functions and expect outputs (declarative) and/or
> write functions along with the inputs and outputs (procedural). Any way you
> cut it, there are functions that get executed. Those can be written by the
> Oracle corporation so that if you decouple your assets from the products of
> that company you have less than an entire solution, or you can write the
> functions in a language that doesn't give you quite the same ties to a
> single corporation (such as Java -- and of course we could then argue the
> merits of the Java approach, which doesn't interest me so much as discussing
> the merits of the Oracle approach). You we could store rules/constraints
> as data in the database -- declarative -- and then write functions for that
> part of the application rather than having the database provide those --
> procedural.
>
>
> yup, definitely
>
>
> So, how should we fix the situation or is
> declarative vs procedural a matter
> of taste? --dawn
Date: Tue, 15 Jun 2004 03:08:43 +0200
Message-ID: <40ce4c14$0$559$e4fe514c_at_news.xs4all.nl>
Dawn M. Wolthuis wrote:
> Laconic2 wrote:
>>Eric Kaun wrote: >>>This is, more than anything, the philosophical divide >>>between relational and Pick folks. The more rules, >>>the more they should be kept OUT of the >>>application code. "Application" means just that: >>>a judicious application. >>>Of what? Rules. Application != definition, >>>just as implementation != specification. >> >>It isn't just the Pick folks. The OO folks >>also feel that the business rules belong encapsulated >>inside the objects that "really know what's going on", >>as opposed to formalized as metadata and shared >>the same way data is shared.
>
> Although then "they" (or is that "we"?) start spec'ing things as parms,
> perhaps pulled into the OO code by way of xml documents. You can send
> inputs to pre-existing functions and expect outputs (declarative) and/or
> write functions along with the inputs and outputs (procedural). Any way you
> cut it, there are functions that get executed. Those can be written by the
> Oracle corporation so that if you decouple your assets from the products of
> that company you have less than an entire solution, or you can write the
> functions in a language that doesn't give you quite the same ties to a
> single corporation (such as Java -- and of course we could then argue the
> merits of the Java approach, which doesn't interest me so much as discussing
> the merits of the Oracle approach). You we could store rules/constraints
> as data in the database -- declarative -- and then write functions for that
> part of the application rather than having the database provide those --
> procedural.
>
>>In the days when databases were being spread to the old >>COBOL and files gang, this divide was called the >>difference between "process centric" and >>"data centric" views of the world. >>I think it's really the same divide, over and over again.
>
> yup, definitely
>
>>It even happens within the RDBMS vendors. >>I've been watching SQL gradually evolve from >>a bad answer to the requirement for a "universal data >>sublanguange" into a bad programming language, in its own right.
>
> So, how should we fix the situation or is
> declarative vs procedural a matter
> of taste? --dawn
Anybody running an operation with a large shared databank, in practice, has had to bridge this gap. I haven't seen it done in theory yet, though.
Can we fix it? (in theory, that is) -- I am positive we can.
But it will take a lot of unlearning.
"They" and "We" does not help.
Received on Tue Jun 15 2004 - 03:08:43 CEST