Re: TRM - Morbidity has set in, or not?

David Cressey wrote:
> "Marshall" <marshall.spight_at_gmail.com> wrote in message
> news:1147886349.702914.222780_at_38g2000cwa.googlegroups.com...
>
> > To achieve the big wins, though, we need a programming language that
> > uses the RM at its core, and that has support for physical
> > independence.
> > I am afraid that at this time this is just a wish.
>
> I have a different take on this, slightly.
>
> We need a programming language that has a data model as its core, and has
> support for physical data independence.
> The desired data model would incorporate all the benefits of the present
> RDM, at the least. such a data model would probably have to incorporate the
> RDM as a sub model.

I'm not sure it would "have to" (depending on dbms's used) but it certainly could have such a sub model. If such a programming language has RDM as only one of several ways of modeling and working with data in large shared data banks, then the RDM loses the exclusivity it seems to demand, however. So, is the RDM sub model you mention one that is still the only way to view persisted data, or simply one way? For example, could XQuery (or similar) and SQL (or a better implementation of the RDM) function side by side in a language that works with large shared data banks without violating the RDM? (recognizing this could be considered as not supporting physical data independence, a term that perhaps we could find specific functional requirements for and ensure they are met)

> The programming language also needs a highly developed process model at its
> core. The object oriented process model provides a good starting place.

Agreed.

> Here's where I would start:
>
> Since the time OOP became popular, the design and construction of objects
> has been revolutionized. But OOP depends on two fundamental concepts, not
> just one. In an object oriented world, there are objects, and there are
> messages. The messaging scheme of languages ranging from Smalltalk to Java
> is woefully inadequate. There has been almost no fundamental advance here
> in 30 years.

I have no doubt you are right about this, but am curious what, other than generally-employed efficient standards, you find to be amiss in this area with languages such as Java.

> In order to build on the successes that OOP has acheived, the messaging
> scheme is going to have to go through a profound shift. When people get
> around to building a better messaging scheme, they will discover that the
> fundamental question is: how can objects share data coherently?

Will that question be addressed separately from how we can share procedures/functions? With Java Remote Method Invocation (RMI) or JERI from the Jini libraries you ask questions of a service using the language (methods) of the service (e.g. getFirstName()), however you must first agree on Java as the programming language (a rather significant downside). With SOA, you also agree on a means of invoking functions (along with schema for xml data exchange, e.g.).

Don't languages typically have an adequate means of handling messaging, even for high availability, high performance in a distributed environment (e.g. using Jini) until you are mixing languages? In the case of .NET (where I am woefully ignorant), the barrier might be in the requirement for a specific run-time vm rather than a specific language.

> This turns out to be the same question that database theory began working
> on, back in 1970, when Codd published. It's in a different guise, but it's
> the same question.

In the 1970 ACM paper he says

"The simplicity of the array representation which becomes feasible when all relations are cast in normal form is not only an advantage for storage purposes but also for communication of bulk data between systems which use widely different representations of data."

XML and JSON are indications that we might have moved beyond the simplest of forms for communication of bulk data between systems, however, as there is no need to put data in what-was-once-called-1NF for data exchange (and no one suggests otherwise, as best I can tell). With more richness in the current RDM, are there any folks using it for data exchange, employing set processing commands for data and constraints, for example?

Cheers! --dawn Received on Thu May 18 2006 - 16:21:50 CEST