Re: One Ring to Bind Them

Yes, you're right on all counts.

It seems that at some point in the history of computing, software developers decided to traipse down the path of implementation, rather than the other fork: declarative logic. Somehow thinking like a processor, juggling long procedures and registers (objects), is deemed better than writing engines / JVMs / compilers that take declarative statements and generate the necessary procedures.

"Laconic2" <laconic2_at_comcast.net> wrote in message news:c9GdnW9YiKJkSlDd4p2dnA_at_comcast.com...
> Was: In an RDBMS, what does "Data" mean?
>
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:wekzc.25516$Dh6.9215_at_newssvr31.news.prodigy.com...
>
> > 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.
>
> 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.
>
> 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.
Received on Mon Jun 14 2004 - 22:01:14 CEST