[Grace-core] Grace feedback

[Dan Grossman]

Hi guys,

Thanks for the thoughtful replies.  In return:

* yes, please add me to the lower-traffic "announce list" and inform
me when significant content goes up on the website, though I suspect
the latter will be subsumed by the former.

* sure, I'd be happy to send Marty a message once there's more content
up and convince him that this is something he should be interested in.

* then there's the issue of my integer_set ADT example.  I think all
your replies were in the right ballpark of what I was getting at.  I'm
not worried about whether one writes s1.intersection(s2) or
intersection(s1,s2).  I do want the implementation of intersection to
know the underlying implementation of s2 (and s1).  I'd lean toward
allowing direct access to the fields of s2, but I could settle for
having access to methods beyond those "publicly" available as part of
an integer_set.  (My choice of integers was just to separate any issue
of generics.)

Yes, this is less OO, but it is a more direct example of hiding an
implementation behind an abstraction.  I want to teach equivalent
implementations with different "performance" trade-offs.  For example,
set union is slower if you remove duplicates, but results in faster
lookup operations (especially those that fail).

MYTYPE, if it works out in Grace, may well be the right technical
device to get to a good place.  As another example, I'd like the
language to have a sane way to write an equals method.  One of my
indictments of Java for novices is pages 193-196 of Core Java, Volume
1 -- 4 pages on how to write a frickin equals method.  (Available from
Amazon's search-inside-the book, just search for "The equals method".)
 This aligns with Kim's view that inheritance should come later.

--Dan

On Thu, Nov 4, 2010 at 8:13 PM, Andrew P. Black <black at cs.pdx.edu> wrote:
> I though that Dan's point is that he wants to teach ADTs, not objects at all, because ADTs are simpler.
> What ADTs give up — being able to substitute a new implementation on a per-instance basis — is something that most novices won't ever do.
>
> Is that right, Dan?    Being object bigots, we may not agree, but I would like to at least understand your point.
>
>        Andrew
>
>
>
> On 4 Nov 2010, at 15:46, Dan Grossman wrote:
>
>> At SPLASH, I gave you guys some oral feedback / first impressions on
>> your Grace initiative and promised to follow-up in writing so you'd
>> have it written down somewhere.  I'm finally getting around to that.
>> This advice is quite likely worth what you paid for it -- and
>> naturally it's much easier to throw spitballs from the back of the
>> room than to actually do something.
>>
>> In no particular order:
>>
>> ...
>
>> * The place where I feel most OO languages fall down for lower-level
>> pedagogy is basic abstract interfaces.  The technical reasons have to
>> do with binary methods blah blah blah, but the point is to avoid all
>> that.  I want to be able to define an abstract type and operations on
>> it:
>>     type set_of_integers;
>>     function new_set : () -> set_of_integers
>>     function add_to_set : (int) -> set_of_integers
>>     function intersection : (set_of_integers, set_of_integers) ->
>> set_of_integers
>> I don't care about the syntax.  I do care that I can change the
>> implementation without affecting clients.  And I shouldn't have to
>> jump through OO hoops -- the implementation should be able to assume
>> the concrete representation.  I called this "Clu-style" though of
>> course many other languages get this right (ML, Racket, ...).
>>  ...
>
>