Re: Multiplicity, Change and MV

B Faux wrote:
> Bob Badour wrote:
>
> <quote>
> "The major attraction of the modern elixirs is that they relieve their
> consumers from the obligation of being precise by presenting an
> interface too fuzzy to be precise in: by suppressing the symptoms of
> impotence they create an illusion of power."
>
> In his essay, he refers to "modern elixirs" as languages purported to
> obviate the need for programmers -- a claim I have heard many times by
> Pickies.
>
> Pickies are universally intoxicated by the illusion of power to which
> Dijkstra refers.
> </>
>
> FWIW
>
> True, 'Pickies' tend to drink from the same cup -
>
> However, in most RM environments there is a definite split between a Data
> Base Administrator function and a Programmer function. The rules applicable
> to each are separate and different.

Data management and application development are different functions. Data management must manage data for all applications, which means it must reliably account for far more requirements than any single application. Application development involves the efficient expression of efficient algorithms to achieve limited results.

Both tasks are examples of applied mathematics and both require excellent communication ability.

 > The RM DB model allows/requires certain
> business logic to reside in the database - where admitedly is makes more
> sense when diverse applications will access the same data. In 'Pickdom',
> the tasks associated with Programming an application and Administering the
> database are commonly combined. This is not a requirement, but rather a
> practical extension of the need for both tasks to follow common logic
> concerning processing outcomes.

I disagree. It is a requirement forced onto application developers by Pick's absolute lack of any integrity function and exceedingly poor manipulation function.

> In most theoretical analysis, processing outcomes are not relevant.

I disagree. Theory is the method by which we identify correct outcomes.

 > The
> details of storage, retrieval, optimisation, constraints (rules), etc is of
> primary concern.

You are mixing logical and physical concepts and I don't see what you are driving at.

 > An abstract theoretical manipulaton of data within the
> confines of a file system is all that is examined, in sometimes excrutiating
> detail. Underlying operating systems, microprocessor specifications, memory
> use and allocation, rarely (if ever) enters into the discussion. The idea
> is that given a compelling prototypical design, the rest of it will be made
> to fit in any way possible to support the design.

I suggest that represents an abject abdication of both data management and application development roles as applied mathematicians. Received on Fri Apr 21 2006 - 01:29:31 CEST