Re: ID field as logical address

David BL wrote:
...
> Any instruction to update the database state is imperative by
> definition. What else do you think imperative means?
> ...

When it comes to people who prefer imperative programs because they can see no other way, it ends up meaning religious.

In order to truly follow their chosen faith, they really need to ask themselves what is the advantage of some definition or other as well as ask what complications it introduces. Date calls the lack of assignment in functional languages a "cheat ... in effect they perform come kind of assignment ... even though assignment as such isn't part of the logic or functional programming style". I'm not saying at all that Date is a religious nut, but some of his followers are. I would defend his right to think that given his aim, even though I think the massive integration of concepts he's after is beyond what most people can assimilate, nor do they need to. Personally, I have no problem with a logical view that assumes all relations are persistent and that some can be referred to by name.

The "dictatorship of reason" as Ralston Saul puts it, has become its own parody, like most religion which exists to solve the problems it has created.

Assigning a name in the context of a program is not the same thing as assigning to a pointer to a value. One trouble many imperative programmers have is that they don't have a useful notion of program in the first place, in fact the arrangement of statements they will call a program practically always stands for several dozen programs. The particular arrangement is nearly always dictated by the devices they prefer, such as repetitive assignment and not by the logical application's purpose but SICP says this better than I can.

> [snip]
>

>> Just because db values vary
>> doesn't mean one must implement variables and assignment.

I can't claim all the credit, the seemingly endless supply of pedants here helps enormouslly. Received on Wed Jun 03 2009 - 21:11:28 CEST