Re: Databases as objects

Marshall wrote:
...
> My message should be read as an explanation of the evolution of
> my thoughts on OOP. There was a time when I thought "inheritance,
> encapsulation, polymorphism" was a tremendous achievement.
> Nowadays I see better abstractions. Fortran is a big step up from
> assembly, and that fact doesn't change when we introduce SML
> and observe that SML is a big step up from Fortran. If one is
> interested in programming language theory (PLT) then it behooves
> one to understand exactly what Fortran brought to the table, so
> that even though one does not wish to use Fortran any longer,
> one does not accidently discard some of its benefits when one
> is moving on to the next higher level.
> ...

Many people agreed with the comment about Fortran. Still, there were some things that assembly could do that Fortran couldn't. Seems true of most abstractions I'm aware of which I guess is necessarily a result of the very definition of abstraction which narrows one's view. This is a great advantage for focussing on problems rather than machines. But I wonder if things get out of control, eg., go too far when languages like Java start try to model the very machines they run on, eg., IO classes.   Today, practically no one chooses a machine based on its instruction set. I wonder if a machine that had relational operators might change this (I'm not very familiar with the failed 'database machines' of twenty years ago).

Now I will go to the Alphora site mentioned today and try to find out how it applies relational ideas to display interfaces. Like Gene, maybe, I have never understood why a mundane commercial application can't present the database using relational operators. In fact the ordinary single-user, single database situation is a better target for discussion of how two databases ought to cooperate than distributed ones. I'd go so far as to call it a canonical case. That's because I think there are logically two machines even if the system happens to have only one. Many users know this even if many developers forget it.

Apologies if I've mentioned this story before - when I was helping a well-known airline go bankrupt, I was asked to make an interface from a somewhat relational flight cargo system to process control machines that ran big robotic machines in an automated warehouse. The pc machine software required about a dozen messages, all to do with various flight states, eg., departed, landed and so forth, but these were full of holes, such as not being able to recognize that a flight had been re-directed after takeoff. Each time I brought up one of these cases, the robot vendor responded by adding a new message type. After much head-banging, I finally got them to acknowledge that pc machines used some Dec db software or other. I proposed that both systems ought to communicate with only three kinds of messages, Insert, Replace and Delete since the logical interface was the table/view data both db's unwittingly shared. This is one of many technical arguments I've seen that was nixed for political reasons. I suspect that many Java developments have gone astray from original intent for similar reasons.

p Received on Sat Dec 23 2006 - 03:15:20 CET