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<http://awelonblue.wordpress.com/2012/05/20/abandoning-commitment-in-hci/>. 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<http://awelonblue.wordpress.com/2011/06/15/data-model-independence/>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 <[email protected]> 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 <[email protected]> > *To:* Fundamentals of New Computing <[email protected]> > *Sent:* Wednesday, April 17, 2013 6:13 PM > *Subject:* Re: [fonc] 90% glue code > > Sounds like you want stone soup > programming<http://awelonblue.wordpress.com/2012/09/12/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 <[email protected]> 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" <[email protected]>: > > 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 <[email protected] <mailto: > [email protected]>> 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 > <[email protected] <mailto:[email protected]>> wrote: > > > On Mon, Apr 15, 2013 at 11:57 AM, David Barbour > <[email protected] <mailto:[email protected]>> wrote: > > > On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David > <[email protected] <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > > http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> > > > > ______________________________**_________________ > fonc mailing list > [email protected] <mailto:[email protected]> > > http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> > > > > > ______________________________**_________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/**listinfo/fonc<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 > [email protected] > http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
