Hi David
I think both of your essays are important, as is the general style of
aspiration.
The "ingredients of a soup" idea is one of the topics we were supposed to work
on in the STEPS project, but it counts as a shortfall: we wound up using our
time on other parts. We gesture at it in some of the yearly reports.
The thought was that a kind of "semantic publish and subscribe" scheme -- that
dealt in descriptions and avoided having to know names of functionalities as
much as possible -- would provide a very scalable loose coupling mechanism. We
were hoping to get beyond the pitfalls of attempts at program synthesis from
years ago that used pre-conditions and post-conditions to help matchers paste
things together.
I'm hoping that you can cast more light on this area. One of my thoughts is
that a good matcher might be more like a "dynamic discovery system" (e.g.
Lenat's "Eurisko") than a simple matcher ....
It's interesting to think of what the commonalities of such a system should be
like. A thought here was that a suitable descriptive language would be could be
should be lots smaller and simpler than a set of "standard conventions" and
"tags" for functionality....
Joe Goguen was a good friend of mine, and his early death was a real tragedy.
As you know, he spent many years trying to find sweet spots in formal semantics
that could also be used in practical ways...
Best wishes,
Alan
>________________________________
> From: David Barbour <dmbarb...@gmail.com>
>To: Alan Kay <alan.n...@yahoo.com>; Fundamentals of New Computing
><fonc@vpri.org>
>Sent: Wednesday, January 2, 2013 11:09 PM
>Subject: Re: [fonc] Current topics
>
>
>On Tue, Jan 1, 2013 at 7:53 AM, Alan Kay <alan.n...@yahoo.com> wrote:
>
>As humans, we are used to being sloppy about message creation and sending, and
>rely on negotiation and good will after the fact to deal with errors.
>
>
>You might be interested in my article on avoiding commitment in HCI, and its
>impact on programming languages. I address some issues of negotiation and
>clarification after-the-fact. I'm interested in techniques that might make
>this property more systematic and compositional, such as modeling messages or
>signals as having probabilistic meanings in context.
>
>
>
>>
>>you are much better off making -- with great care -- a few kinds of
>>relatively big modules as basic building blocks than to have zillions of
>>different modules being constructed by vanilla programmers
>
>
>Large components are probably a good idea if humans are hand-managing the glue
>between them. But what if there was another way? Instead of modules being
>rigid components that we painstakingly wire together, they can be ingredients
>of a soup - with the melding and combination process being largely automated.
>
>
>If the modules are composed automatically, they can become much smaller, more
>specialized and reusable. Large components require a lot of inefficient
>duplication of structure and computation (seen even in biology).
>
>
>
>
>>
>>Note that desires for runable specifications, etc., could be quite harmonious
>>with a viable module scheme that has great systems integrity.
>
>
>Certainly. Before his untimely departure, Joseph Goguen was doing a lot of
>work on modular, runable specifications (the BOBJ - behavioral OBJ - language,
>like a fusion of OOP and term rewriting).
>
>Regards,
>
>
>Dave
>
>
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
