Hi David
We are being invaded by "stupid aliens" aka our's and other people's software.
The gods who made their spaceships are on vacation and didn't care about
intercommunication (is this a modern version of the Tower of Babel?).
Discovery can take a long time (and probably should) but might not be needed
for most subsequent communications (per Joe Becker's "Phrasal Lexicon"). Maybe
ML coupled to something more semantic (e.g. CYC) could make impressive inroads
here.
I'm guessing that even the large range of ideas -- good and bad -- in CS today
is a lot smaller (and mostly stupider) than the ones that need to be dealt with
when trying for human to human or human to alien overlap.
Cheers,
Alan
>________________________________
> From: David Barbour <dmbarb...@gmail.com>
>To: Alan Kay <alan.n...@yahoo.com>; Fundamentals of New Computing
><fonc@vpri.org>
>Sent: Thursday, April 18, 2013 9:25 AM
>Subject: Re: [fonc] 90% glue code
>
>
>
>Well, communicating with genuine aliens would probably best be solved by
>multi-modal machine-learning techniques. The ML community already has
>techniques for two machines to "teach" one another their vocabularies, and
>thus build a strong correspondence. Of course, if we have space alien
>visitors, they'll probably have a solution to the problem and already know our
>language from media.
>
>
>Natural language has a certain robustness to it, due to its probabilistic,
>contextual, and interactive natures (offering much opportunity for refinement
>and retroactive correction). If we want to support machine-learning between
>software elements, one of the best things we could do is to emulate this
>robustness end-to-end. Such things have been done before, but I'm a bit stuck
>on how to do so without big latency, efficiency, and security sacrifices.
>(There are two issues: the combinatorial explosion of possible models, and the
>modular hiding of dependencies that are inherently related through shared
>observation or influence.)
>
>
>Fortunately, there are many other issues we can address to facilitate
>communication that are peripheral to translation. Further, we could certainly
>leverage code-by-example for type translations (if they're close).
>
>
>Regards,
>
>
>Dave
>
>
>
>
>On Thu, Apr 18, 2013 at 8:06 AM, Alan Kay <alan.n...@yahoo.com> wrote:
>
>Hi David
>>
>>
>>This is an interesting slant on a 50+ year old paramount problem (and one
>>that is even more important today).
>>
>>
>>Licklider called it the "communicating with aliens problem". He said 50 years
>>ago this month that "if we succeed in constructing the 'intergalactic
>>network' then our main problem will be learning how to 'communicate with
>>aliens'. He meant not just humans to humans but software to software and
>>humans to software.
>>
>>
>>(We gave him his intergalactic network but did not solve the communicating
>>with aliens problem.)
>>
>>
>>
>>I think a key to finding better solutions is to -- as he did -- really push
>>the scale beyond our imaginations -- "intergalactic" -- and then ask "how can
>>we *still* establish workable communications of overlapping meanings?".
>>
>>
>>
>>Another way to look at this is to ask: "What kinds of prep *can* you do
>>*beforehand* to facilitate communications with alien modules?"
>>
>>
>>Cheers,
>>
>>
>>Alan
>>
>>
>>
>>
>>
>>
>>
>>>________________________________
>>> From: David Barbour <dmbarb...@gmail.com>
>>>To: Fundamentals of New Computing <fonc@vpri.org>
>>>Sent: Wednesday, April 17, 2013 6:13 PM
>>>Subject: Re: [fonc] 90% glue code
>>>
>>>
>>>
>>>Sounds like you want stone soup programming. :D
>>>
>>>
>>>In retrospect, I've been disappointed with most techniques that involve
>>>providing "information about module capabilities" to some external
>>>"configurator" (e.g. linkers as constraint solvers). Developers are asked to
>>>grok at least two very different programming models. Hand annotations or
>>>hints become common practice because many properties cannot be inferred. The
>>>resulting system isn't elegantly metacircular, i.e. you need that
>>>'configurator' in the loop and the metada with the inputs.
>>>
>>>
>>>An alternative I've been thinking about recently is to shift the link logic
>>>to the modules themselves. Instead of being passive bearers of information
>>>that some external linker glues together, the modules become active agents
>>>in a link environment that collaboratively construct the runtime behavior
>>>(which may afterwards be extracted). Developers would have some freedom to
>>>abstract and separate problem-specific link logic (including
>>>decision-making) rather than having a one-size-fits-all solution.
>>>
>>>
>>>Re: In my mind "powerful languages" thus means 98% requirements
>>>
>>>
>>>To me, "power" means something much more graduated: that I can get as much
>>>power as I need, that I can do so late in development without rewriting
>>>everything, that my language will grow with me and my projects.
>>>
>>>
>>>
>>>
>>>On Wed, Apr 17, 2013 at 2:04 PM, John Nilsson <j...@milsson.nu> wrote:
>>>
>>>Maybe not. If there is enough information about different modules'
>>>capabilities, suitability for solving various problems and requirements,
>>>such that the required "glue" can be generated or configured automatically
>>>at run time. Then what is left is the input to such a generator or
>>>configurator. At some level of abstraction the input should transition from
>>>being glue and better be described as design.
>>>>Design could be seen as kind of a gray area if thought of mainly as picking
>>>>what to glue together as it still involves a significant amount of gluing
>>>>;)
>>>>But even design should be possible to formalize enough to minimize the
>>>>amount of actual design decisions required to encode in the source and what
>>>>decisions to leave to algorithms though. So what's left is to encode the
>>>>requirements as input to the designer.
>>>>In my mind "powerful languages" thus means 98% requirements, 2% design and
>>>>0% glue.
>>>>BR
>>>>John
>>>>Den 17 apr 2013 05:04 skrev "Miles Fidelman" <mfidel...@meetinghouse.net>:
>>>>
>>>>
>>>>So let's ask the obvious question, if we have powerful languages, and/or
>>>>powerful libraries, is not an application comprised primarily of glue code
>>>>that ties all the "piece parts" together in an application-specific way?
>>>>>
>>>>>David Barbour wrote:
>>>>>
>>>>>
>>>>>>On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart <st...@wart.ca
>>>>>><mailto:st...@wart.ca>> wrote:
>>>>>>
>>>>>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich
>>>>>> > In real systems, 90% of code (conservatively) is glue code.
>>>>>>
>>>>>> What is the origin of this claim?
>>>>>>
>>>>>>
>>>>>>I claimed it from observation and experience. But I'm sure there are
>>>>>>other people who have claimed it, too. Do you doubt its veracity?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 15, 2013 at 12:15 PM, David Barbour
>>>>>> <dmbarb...@gmail.com <mailto:dmbarb...@gmail.com>> wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 15, 2013 at 11:57 AM, David Barbour
>>>>>> <dmbarb...@gmail.com <mailto:dmbarb...@gmail.com>> wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David
>>>>>> <l...@loup-vaillant.fr <mailto:l...@loup-vaillant.fr>> wrote:
>>>>>>
>>>>>> On Sun, Apr 14, 2013 at 04:17:48PM -0700, David
>>>>>> Barbour wrote:
>>>>>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich
>>>>>> > In real systems, 90% of code (conservatively) is
>>>>>> glue code.
>>>>>>
>>>>>> Does this *have* to be the case? Real systems also
>>>>>> use C++ (or
>>>>>> Java). Better languages may require less glue, (even
>>>>>> if they require
>>>>>> just as much core logic).
>>>>>>
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> The prevalence of glue code is a natural consequence of
>>>>>> combinatorial effects. E.g. there are many ways to
>>>>>> partition and summarize properties into data-structures.
>>>>>> Unless we uniformly make the same decisions - and we won't
>>>>>> (due to context-dependent variations in convenience or
>>>>>> performance) - then we will eventually have many
>>>>>> heterogeneous data models. Similarly can be said of event
>>>>>> models.
>>>>>>
>>>>>> We can't avoid this problem. At best, we can delay it a
>>>>>> little.
>>>>>>
>>>>>>
>>>>>> I should clarify: a potential answer to the glue-code issue is
>>>>>> to *infer* much more of it, i.e. auto-wiring, constraint
>>>>>> models, searches. We could automatically build pipelines that
>>>>>> convert one type to another, given smaller steps (though this
>>>>>> does risk aggregate lossiness due to intermediate summaries or
>>>>>> subtle incompatibilities). Machine-learning could be
>>>>>> leveraged to find correspondences between structures, perhaps
>>>>>> aiding humans. 90% or more of code will be glue-code, but it
>>>>>> doesn't all need to be hand-written. I am certainly pursuing
>>>>>> such techniques in my current language development.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> fonc mailing list
>>>>>> fonc@vpri.org <mailto:fonc@vpri.org>
>>>>>> http://vpri.org/mailman/listinfo/fonc
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> fonc mailing list
>>>>>> fonc@vpri.org <mailto:fonc@vpri.org>
>>>>>> http://vpri.org/mailman/listinfo/fonc
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>fonc mailing list
>>>>>>fonc@vpri.org
>>>>>>http://vpri.org/mailman/listinfo/fonc
>>>>>>
>>>>>
>>>>>--
>>>>>In theory, there is no difference between theory and practice.
>>>>>In practice, there is. .... Yogi Berra
>>>>>
>>>>>_______________________________________________
>>>>>fonc mailing list
>>>>>fonc@vpri.org
>>>>>http://vpri.org/mailman/listinfo/fonc
>>>>>
>>>>_______________________________________________
>>>>fonc mailing list
>>>>fonc@vpri.org
>>>>http://vpri.org/mailman/listinfo/fonc
>>>>
>>>>
>>>
>>>_______________________________________________
>>>fonc mailing list
>>>fonc@vpri.org
>>>http://vpri.org/mailman/listinfo/fonc
>>>
>>>
>>>
>>_______________________________________________
>>fonc mailing list
>>fonc@vpri.org
>>http://vpri.org/mailman/listinfo/fonc
>>
>>
>
>
>
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
