[fonc] Report Card

[Casey Ransberger]

I wanted to send this message out after the final status report, but since 
that's indefinitely delayed (keep going!) I'm just going to do it now. 

Easy question: has keeping this dialogue open been useful to the folks at VPRI, 
or has it been more of a burden than anything else?

I can definitely say that it's been very good for me, in that I learned a hell 
of a lot reading all of the lovely papers posters cited. It's also been a lot 
of fun meeting people who were interested in a lot of the same things that I 
was. 

I'm not so happy about my own contribution though. Did I do anything at all to 
advance the state of the art? Well, no. I mostly just flapped my lips. It's 
asymmetrical, I learned way more than I taught. The best I could do was play 
sounding board for some of Ian's ideas while dinking around with Maru's guts.

BTW if you haven't looked at it, Maru is way cool. 

VPRI has done something pretty awesome and weird here, in that the dialogue was 
wide open the whole time. As I gather, it was in the spirit of ARPA. We've had 
our share of trolls, long-winded posters (raises hand) and just general chaos. 

I really enjoyed the guy who called us all a bunch of Alan Kay fanboys the 
other day by the way. That was just priceless. Like we can't think for 
ourselves!

(Alan if I can get an autograph after this I think I'll be set.)

So seriously, has this been worthwhile? I'm not just asking VPRI folks, though 
I'm DEFINITELY asking VPRI folks, I'm also asking everyone else on the list. 

I learned a lot, huge win for me, and we talked in circles a bunch, some of 
that was fun. 

I can also think of a few parts where I felt pretty strongly that it *was* 
worthwhile. To throw out an example, remember when Dale Schumacher asked pretty 
poignantly whether or not the original idea behind objects/messages was similar 
to the actor model? That was like a blockbuster for nerds it was so awesome. 
That totally rocked. 

That's me. Okay now talk amongst yourselves go!

?
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Separating computation from the machine

[Tristan Slominski]

I don't think that's what the introduction implies. I'm going on a limb
here and assume that I your conclusion stems from the author's claim of
inability to separate meaning from mechanism, or even further, that
computation is not a special thing worth having a theory about?

Consider the author's hints that computation is about meaning and
mechanism. Further, consider author's analysis and criticism of claims of
universal computation. The author allows a mechanism to be paired with a
program, and seems to acknowledge that one can find a combination of a
different mechanism paired with a different program that would be
equivalent to the first pair.

That alone seems to me to dismiss the concern that mind uploading would not
be possible (despite that I think it's a wrong and a horrible idea
personally :D)

The author's point of view seems, to me, to resemble the "Thunderstorm
Choreographers" point of view of Brian Foote (
http://www.youtube.com/watch?v=h6Y9aJhqO78&t=21m31s)

It's too bad that the "Age of Significance" project seems to no longer be
active. I'm curious what happened to it.


On Wed, Apr 17, 2013 at 12:06 PM, Loup Vaillant-David 
wrote:

> On Sat, Apr 13, 2013 at 09:25:19PM +0200, John Nilsson wrote:
> > This discussion reminds me of
> > http://www.ageofsignificance.org/
> >
> > It's a philosophical analysis of what computation means and how, or if,
> it
> > can be separated from the machine implementing it. The author argues that
> > it cannot.
>
> If I got it correctly, I hope the author is mistaken: if he's right,
> then that's one less path to both immortality and ascension.  (I'm
> talking about mind uploading.)
>
> Loup.
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] 90% glue code

[Simon Forman]

On 4/19/13, Simon Forman  wrote:
> Shroup, http://www.lawsofform.org/


Ooops!  That should be Shoup, not "Shroup".



"The history of mankind for the last four centuries is rather like that of
an imprisoned sleeper, stirring clumsily and uneasily while the prison that
restrains and shelters him catches fire, not waking but incorporating the
crackling and warmth of the fire with ancient and incongruous dreams, than
like that of a man consciously awake to danger and opportunity."
--H. P. Wells, "A Short History of the World"
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] 90% glue code

[Simon Forman]

This might be of interest. Over the last century a small group of
people, working largely independently and in isolation, have
discovered and refined an Universal Language.

This is a logic-symbolic notation, not a spoken language (i.e. not
like Esperanto), that captures and expresses the essence of logical
reasoning in a direct and unmistakable way.

The rules of logical reasoning (and Set Theory, etc.) expressed in the
Universal Language admit of a decision procedure that is of
unprecedented simplicity and power.

I think of it as the alphabet of thought.

I'm still gathering threads and learning but I've compiled a few links
and a bit of history:

C. S. Pierce, Existential Graphs, circa 1890

Spencer-Brown, "Laws of Form"

Bricken, http://iconicmath.com/

Shroup, http://www.lawsofform.org/

Burnett-Stuart, http://www.markability.net/


One example that should indicate why I am excited about it:  Logical
statements that are equivalent under De Morgan's are identical in the
notation.  De Morgan's "laws" are, in effect, a kind of side effect of
notational encumbrance.

Also, "modus ponens" and "modus tellens" have identical expression.
Also, any expression in the notation is a schematic for a logic gate
circuit that computes the logical value of the expression.

It goes on and on.

Warm regards,
~Simon


"The history of mankind for the last four centuries is rather like that of
an imprisoned sleeper, stirring clumsily and uneasily while the prison that
restrains and shelters him catches fire, not waking but incorporating the
crackling and warmth of the fire with ancient and incongruous dreams, than
like that of a man consciously awake to danger and opportunity."
--H. P. Wells, "A Short History of the World"
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] 90% glue code

[Rat Xue]

So who cares about functionality we need to mechanically refactor the glue.

On 19 April 2013 17:32, David Barbour  wrote:
> But in this case you've got a square law in play (i.e. N^2 edges for N
> components). So the Pareto distribution becomes 96%-4%.
>
>
> On Fri, Apr 19, 2013 at 1:45 AM, Casey Ransberger 
> wrote:
>>
>> WRT the 90% guess, I usually go for 80% on stuff like that when I make a
>> SWAG where it smells like a Pareto distribution.
>>
>> http://en.wikipedia.org/wiki/Pareto_principle
>>
>> http://en.wikipedia.org/wiki/Pareto_distribution
>>
>>
>>
>> On Tue, Apr 16, 2013 at 7:52 PM, David Barbour 
>> wrote:
>>>
>>>
>>> On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart  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 
 wrote:
>
>
> On Mon, Apr 15, 2013 at 11:57 AM, David Barbour 
> wrote:
>>
>>
>> On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David
>>  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
> 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
>>>
>>
>>
>>
>> --
>> Casey Ransberger
>>
>> ___
>> 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

Re: [fonc] 90% glue code

[David Barbour]

But in this case you've got a square law in play (i.e. N^2 edges for N
components). So the Pareto distribution becomes 96%-4%.


On Fri, Apr 19, 2013 at 1:45 AM, Casey Ransberger
wrote:

> WRT the 90% guess, I usually go for 80% on stuff like that when I make a
> SWAG where it smells like a Pareto distribution.
>
> http://en.wikipedia.org/wiki/Pareto_principle
>
> http://en.wikipedia.org/wiki/Pareto_distribution
>
>
>
> On Tue, Apr 16, 2013 at 7:52 PM, David Barbour wrote:
>
>>
>> On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart  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 wrote:
>>>

 On Mon, Apr 15, 2013 at 11:57 AM, David Barbour wrote:

>
> On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David <
> 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
 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
>>
>>
>
>
> --
> Casey Ransberger
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] 90% glue code

[Casey Ransberger]

It's on the reading list now. Thank you!

On Apr 19, 2013, at 5:56 AM, Alan Kay  wrote:

> Wow, automatic spelling correctors suck, especially early in the morning 
> 
> The only really good -- and reasonably accurate -- book about the history of 
> Lick, ARPA-IPTO (no "D", that is when things went bad), and Xerox PARC is 
> "Dream Machines" by Mitchell Waldrop.
> 
> Cheers,
> 
> Alan
> 
> From: Alan Kay 
> To: Fundamentals of New Computing  
> Sent: Friday, April 19, 2013 5:53 AM
> Subject: Re: [fonc] 90% glue code
> 
> The only really good -- and reasonable accurate -- book about the history of 
> Lick, ARPA-IPTO (no "D", that is went things went bad), and Xerox PARC is 
> "Dream Machines" by Mitchel Waldrop.
> 
> Cheers,
> 
> Alan
> 
> From: Miles Fidelman 
> To: Fundamentals of New Computing  
> Sent: Friday, April 19, 2013 5:45 AM
> Subject: Re: [fonc] 90% glue code
> 
> Casey Ransberger wrote:
> > This Licklider guy is interesting. CS + psych = cool.
> 
> A lot more than cool.  Lick was the guy who:
> - MIT Professor
> - pioneered timesharing (bought the first production PDP-1 for BBN) and AI 
> work at BBN
> - served as the initial Program Manager at DARPA/IPTO (the folks who funded 
> the ARPANET)
> - Director of Project MAC at MIT for a while
> - wrote some really seminal papers - "Man-Computer Symbiosis"is write up 
> there with Vannevar Bush's "As We May Think"
> 
> /It seems reasonable to envision, for a time 10 or 15 years hence, a 
> 'thinking center' that will incorporate the functions of present-day 
> libraries together with anticipated advances in information storage and 
> retrieval./
> 
> /The picture readily enlarges itself into a network of such centers, 
> connected to one another by wide-band communication lines and to individual 
> users by leased-wire services. In such a system, the speed of the computers 
> would be balanced, and the cost of the gigantic memories and the 
> sophisticated programs would be divided by the number of users./
> 
> -  J.C.R. Licklider, Man-Computer Symbiosis 
> , 1960.
> 
> - perhaps the earliest conception of the Internet:
> In a 1963 memo to "Members and Affiliates of the Intergalactic Computer 
> Network," Licklider theorized that a computer network could help researchers 
> share information and even enable people with common interests to interact 
> online.
> (http://web.archive.org/web/20071224090235/http://www.today.ucla.edu/1999/990928looking.html)
> 
> Outside the community he kept a very low profile. One of the greats.
> 
> Miles Fidelman
> 
> -- 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

Re: [fonc] 90% glue code

[Alan Kay]

Wow, automatic spelling correctors suck, especially early in the morning 

The only really good -- and reasonably accurate -- book about the history of 
Lick, ARPA-IPTO (no "D", that is when things went bad), and Xerox PARC is 
"Dream Machines" by Mitchell Waldrop.


Cheers,

Alan



>
> From: Alan Kay 
>To: Fundamentals of New Computing  
>Sent: Friday, April 19, 2013 5:53 AM
>Subject: Re: [fonc] 90% glue code
> 
>
>
>The only really good -- and reasonable accurate -- book about the history of 
>Lick, ARPA-IPTO (no "D", that is went things went bad), and Xerox PARC is 
>"Dream Machines" by Mitchel Waldrop.
>
>
>Cheers,
>
>
>Alan
>
>
>
>>
>> From: Miles Fidelman 
>>To: Fundamentals of New Computing  
>>Sent: Friday, April 19, 2013 5:45 AM
>>Subject: Re: [fonc] 90% glue code
>> 
>>
>>Casey Ransberger wrote:
>>> This Licklider guy is interesting. CS + psych = cool.
>>
>>A lot more than cool.  Lick was the guy who:
>>- MIT Professor
>>- pioneered timesharing (bought the first production PDP-1 for BBN) and AI 
>>work at BBN
>>- served as the initial Program Manager at DARPA/IPTO (the folks who funded 
>>the ARPANET)
>>- Director of Project MAC at MIT for a while
>>- wrote some really seminal papers - "Man-Computer Symbiosis"is write up 
>>there with Vannevar Bush's "As We May Think"
>>
>>/It seems reasonable to envision, for a time 10 or 15 years hence, a 
>>'thinking center' that will incorporate the functions of present-day 
>>libraries together with anticipated advances in information storage and 
>>retrieval./
>>
>>/The picture readily enlarges itself into a network of such centers, 
>>connected to one another by wide-band communication lines and to individual 
>>users by leased-wire services. In such a system, the speed of the
 computers would be balanced, and the cost of the gigantic memories and the 
sophisticated programs would be divided by the number of users./
>>
>>-  J.C.R. Licklider, Man-Computer Symbiosis 
>>, 1960.
>>
>>- perhaps the earliest conception of the Internet:
>>In a 1963 memo to "Members and Affiliates of the Intergalactic Computer 
>>Network," Licklider theorized that a computer network could help researchers 
>>share information and even enable people with common interests to interact 
>>online.
>>(http://web.archive.org/web/20071224090235/http://www.today.ucla.edu/1999/990928looking.html)
>>
>>Outside the community he kept a very low profile. One of the greats.
>>
>>Miles Fidelman
>>
>>-- 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

Re: [fonc] 90% glue code

[Alan Kay]

The only really good -- and reasonable accurate -- book about the history of 
Lick, ARPA-IPTO (no "D", that is went things went bad), and Xerox PARC is 
"Dream Machines" by Mitchel Waldrop.

Cheers,

Alan



>
> From: Miles Fidelman 
>To: Fundamentals of New Computing  
>Sent: Friday, April 19, 2013 5:45 AM
>Subject: Re: [fonc] 90% glue code
> 
>
>Casey Ransberger wrote:
>> This Licklider guy is interesting. CS + psych = cool.
>
>A lot more than cool.  Lick was the guy who:
>- MIT Professor
>- pioneered timesharing (bought the first production PDP-1 for BBN) and AI 
>work at BBN
>- served as the initial Program Manager at DARPA/IPTO (the folks who funded 
>the ARPANET)
>- Director of Project MAC at MIT for a while
>- wrote some really seminal papers - "Man-Computer Symbiosis"is write up there 
>with Vannevar Bush's "As We May Think"
>
>/It seems reasonable to envision, for a time 10 or 15 years hence, a 'thinking 
>center' that will incorporate the functions of present-day libraries together 
>with anticipated advances in information storage and retrieval./
>
>/The picture readily enlarges itself into a network of such centers, connected 
>to one another by wide-band communication lines and to individual users by 
>leased-wire services. In such a system, the speed of the computers would be 
>balanced, and the cost of the gigantic memories and the sophisticated programs 
>would be divided by the number of users./
>
>-  J.C.R. Licklider, Man-Computer Symbiosis , 
>1960.
>
>- perhaps the earliest conception of the Internet:
>In a 1963 memo to "Members and Affiliates of the Intergalactic Computer 
>Network," Licklider theorized that a computer network could help researchers 
>share information and even enable people with common interests to interact 
>online.
>(http://web.archive.org/web/20071224090235/http://www.today.ucla.edu/1999/990928looking.html)
>
>Outside the community he kept a very low profile. One of the greats.
>
>Miles Fidelman
>
>-- 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

Re: [fonc] 90% glue code

[Miles Fidelman]

Casey Ransberger wrote:

This Licklider guy is interesting. CS + psych = cool.


A lot more than cool.  Lick was the guy who:
- MIT Professor
- pioneered timesharing (bought the first production PDP-1 for BBN) and 
AI work at BBN
- served as the initial Program Manager at DARPA/IPTO (the folks who 
funded the ARPANET)

- Director of Project MAC at MIT for a while
- wrote some really seminal papers - "Man-Computer Symbiosis"is write up 
there with Vannevar Bush's "As We May Think"


/It seems reasonable to envision, for a time 10 or 15 years hence, a 
'thinking center' that will incorporate the functions of present-day 
libraries together with anticipated advances in information storage and 
retrieval./


/The picture readily enlarges itself into a network of such centers, 
connected to one another by wide-band communication lines and to 
individual users by leased-wire services. In such a system, the speed of 
the computers would be balanced, and the cost of the gigantic memories 
and the sophisticated programs would be divided by the number of users./


-  J.C.R. Licklider, Man-Computer Symbiosis 
, 1960.


- perhaps the earliest conception of the Internet:
In a 1963 memo to "Members and Affiliates of the Intergalactic Computer 
Network," Licklider theorized that a computer network could help 
researchers share information and even enable people with common 
interests to interact online.

(http://web.archive.org/web/20071224090235/http://www.today.ucla.edu/1999/990928looking.html)

Outside the community he kept a very low profile. One of the greats.

Miles Fidelman

--
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

Re: [fonc] 90% glue code

[Chris Warburton]

David Barbour  writes:

> 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.)

As well as purely statictical ML, I think John Pollock's defeasible
reasoning is an interesting model. Results are given alongside a
justification/argument for why. These justifications can be defeated
later, causing the result to be revised. This is reminiscent of
proof-carrying-code, but using non-monotonic logic.

It is also similar to "Cromwell's Rule" 'think it possible that you may
be mistaken', which current software either ignores, or handles
simplistically with exceptions. Worlds offer a better approach to this,
since the system isn't left in an inconsistent state. Delimited
continuations also look interesting for this kind of undo-able computing.

There may be interesting parallels to reversible computation as well: if
we allow computations to be undone/revised then they can't destroy any
information.

Another thing that comes to mind from this conversation is CosmicOS (
http://people.csail.mit.edu/paulfitz/cosmicos.shtml ).

Regards,
Chris
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] 90% glue code

[Casey Ransberger]

This Licklider guy is interesting. CS + psych = cool.

This conversation makes me think of things Hofstadter wrote about with
regard to isomorphism in Gödel, Escher, Bach.

I only have one or two very small things to contribute here. Esperanto
doesn't seem to have caught on, and sometimes a good idea takes a long time
to catch on :)

Mmm, and maybe McCarthy's search for a universal intermediate
representation is on-target here too.

I've wondered how Frank would deal with the problem of "language barrier,"
especially around metalanguage.


On Fri, Apr 19, 2013 at 1:45 AM, Casey Ransberger
wrote:

> WRT the 90% guess, I usually go for 80% on stuff like that when I make a
> SWAG where it smells like a Pareto distribution.
>
> http://en.wikipedia.org/wiki/Pareto_principle
>
> http://en.wikipedia.org/wiki/Pareto_distribution
>
>
>
> On Tue, Apr 16, 2013 at 7:52 PM, David Barbour wrote:
>
>>
>> On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart  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 wrote:
>>>

 On Mon, Apr 15, 2013 at 11:57 AM, David Barbour wrote:

>
> On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David <
> 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
 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
>>
>>
>
>
> --
> Casey Ransberger
>



-- 
Casey Ransberger
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] 90% glue code

[Casey Ransberger]

WRT the 90% guess, I usually go for 80% on stuff like that when I make a
SWAG where it smells like a Pareto distribution.

http://en.wikipedia.org/wiki/Pareto_principle

http://en.wikipedia.org/wiki/Pareto_distribution



On Tue, Apr 16, 2013 at 7:52 PM, David Barbour  wrote:

>
> On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart  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 wrote:
>>
>>>
>>> On Mon, Apr 15, 2013 at 11:57 AM, David Barbour wrote:
>>>

 On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David <
 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
>>> 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
>
>


-- 
Casey Ransberger
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc