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 think I agree, but I'm not 100% sure I know what you mean. I observe that a programming language will need things the ability to define and invoke functions, have some mechanism for concurrency, I/O, etc.

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

Not sure what you mean by "process model." That sounds like a term for concurrency and interprocess communication, but I think maybe you mean an inter-object communication model?

> 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.

Hmmm.

First off, I must note that I dislike the Smalltalk-y term "message passing" to denote function invocation. As a term, I think it obscures, rather than illuminates. Also, since function invocation is necessarily of the synchronous-request-reply kind, it pushes out other forms of (actual) message passing from the nomenclature. And it is my belief that actual messaging is something that belongs in the language, rather than in a library.

Secondly, can you expand on what you mean by "woefully inadequate?" I'm not sure I know what you mean--do you have some specific application (ha ha) in mind?

Thirdly, I'm not sure if you're aware of what some of the more advanced functional programming languages can do. I note: closures, passing fuctions as parameters, returning functions as results, and partial application. These all seem desirable to me, and are all missing from popular OOPLs. (Unless you count, say, function pointers in C, or inner classes as closures.)

> 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?

Hmmm. If you mean read-only data, then this is something of an implementation detail. If you mean read/write data (often called "state") then I think the right answer is externalizing them from the object. The separately-manageable database is the right answer.

The problem with OOP is that it sprinkles state all through your program, like sprinkling sand into fine machinery. That state can't be managed or inspected, except with huge difficulty.

> 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.

Is it possible it has the same answer now that it did then?

Marshall Received on Thu May 18 2006 - 16:34:05 CEST