[Grace-core] Minutes of Teleconference 11-12.11.2015

[Andrew P Black]

On 12 Nov 2015, at 0:57, James Noble <kjx at ecs.vuw.ac.nz> wrote:

> * talked about definitions of inheritance
> - Tim is doing formalism aiming for “new aliasing + traits” model
> - James will focus on writing out that description first
> 
> * talked about “manifest” aka “static” aka “let”...
> 
> James

James,

Here is what I don’t like about your abstract and the outline of the paper so far.

What we can all agree on , I think, is that objects that have their own behaviour are the central idea in OO programming, and that this behaviour is “dynamically dispatched”, i.e., chosen by the object itself in response to some request or message from another object.  That’s really all there is to say, from the outside of the object.

Some languages make this much more complicated by adding in features from other programming paradigms, such as non-objects, type-based dispatch, functions, packages, pattern-matching,  … you name it, and some supposedly OO language probably has it.  For the most part, we have avoided such pitfalls (with the notable exception of patterns) because it’s not our goal to produce a universal programming tool, but rather a language for teaching the essentials of OO.

The place where OO languages differ markedly is the inside of objects: the way that objects are constructed, and in particular in their support for “differential programming”, to use Borning’s phrase, as quoted in my NOOL paper.   It might be useful to have a taxonomy based on orthogonal axes, but I’m not up for that until after breakfast.   But we know that we can make one distinction between objects that are autonomous vs. objects that depend on a “class” for their behaviour.  We can make another distinction between differential programming methods that depend on objects vs. differential programming methods that depend on classes, that is, between Self-like trait objects and Smalltalk-like trait objects, or between delegation and subclassing.  

Where I fundamentally disagree with your abstract is when you say “a language cannot ``have it all'', and that designers need to choose between several incompatible design goals”.   What I think is true is that each language makes some choice from these alternative starting points, and ends up at some inevitable finishing point — a finishing point that is different from that of the languages that started somewhere else.   It is perhaps surprising that there don’t seem to be any “crossover points” — places where we can switch from one path to another.  In other words, it is perhaps surprising that we can’t start from, say, objects, and end up with a language semantics that is identical to that of a language that starts from classes.   But that does indeed seem to be the way the “physics” of this world is constructed.

When I read your abstract, it sounds to me as if you are claiming a result like FLP impossibility: that there is some universally desired combination of stuff (like FLP’s fault tolerance, availability and consensus in distributed systems) and that we have a “proof” that we can’t have them all.  We don’t have anything like that.  There is no consensus on how differential programming, object initialization, and multiple reuse should work.  Each starting point leads, by a set of internally-consistent design decisions, to a different ending point that remains consistent with its origins, but differs from that of its cousins.

The mistake that we have been making, and continue to make, in the design of these mechanisms for Grace is to remain obstinately stuck with the idea that we have to arrive at particular destination — the “comfy chair” that we have (each) inhabited throughout our previous 20+ years of teaching.  (They are all in different places, of course.)  What we should be doing instead is listening to the design as it unfolds, and following the road where it takes us.

If we can write a paper like that, I think that it would be fascinating reading!

	Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20151112/48edc8cb/attachment.html>