Re: [fonc] 90% glue code
One approach I've been thinking about is to invert the information hiding principle. The problem with information hiding is that the interface and properties exposed by a module is determined by the module: I am a... And some line is drawn between which properties are implementation details, and which are the contract. So I was thinking, what if the roles were swapped. What if modules could not declare a public contract but instead just had to conform to any type, interface or property that a client depending on it would care to declare as a requirement. In effect changing the module description into a collection of You are a... statements. Kind of similar to how a structural type allow any module conforming to the interface without the module having to implement a particular nominal type. For one, declaring a contract for a dependency is rather easy as it is based on local reasoning: What do I do, what do I need? as compared to What do I do, what do others need? Another benefit would be that there is no arbitrary reduction of the modules full capabilities. For example a Java List only implementing Iterable couldn't be used by clients requiring an ordered and finite sequence. I would expect this to encourage module writers to declare the smallest set of properties possible to depend on so that there would be more focus on information shielding, what information to expose one self to, rather than what information not to expose to others. The problem with this approach is that the proof of conformance can't come from the module, and it's hardly productive to require each client to provide one. I guess in some sense this is partly solved by a mechanism such as type classes as done in Scala or Haskell. One problem with this scheme though is that they do this by means of a static dispatch, making it impossible to specialize implementations by runtime polymorphism. While I haven't played with it, I do believe that Clojure has solved it while preserving runtime polymorphism. BR, John On Thu, Apr 18, 2013 at 3:13 AM, David Barbour dmbarb...@gmail.com wrote: Sounds like you want stone soup programminghttp://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 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
Re: [fonc] 90% glue code [universal language]
On 4/20/13, John Carlson yottz...@gmail.com wrote: How do these handle infinite sets? :D You have to handle infinity the same way a computer does: make up a special symbol and let it use different rules. You make up a name and describe the behaviour of the thing named by logical statements that can be encoded in the notation. Several people have experimented with number notation systems inspired by or layered on top of the boundary/name-based notation, but the basic system is strictly binary logical, not numerical. I'm playing with expressions that denote circuits that compute mathematical functions, which is the obvious natural way to express numbers and do math with the notation, and of course anything a computer can be made to do (floating point, NaN, Infinity, etc) can be expressed in the notation. I'm hardly a sophisticated source for this stuff- I'm in way over my head -but there is a lot of rich and detailed information at the websites mentioned. Warm regards, ~Simon 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/ 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 [universal language]
You have to handle infinity the same way a computer does: make up a special symbol and let it use different rules. This is pretty much correct. For any concept of infinity, it should behave consistently with what it represents in terms of the operators of a given system. For example, in Euclidean space, if you multiple infinity by a number, you get infinity back. If you invert infinity in a circle, you get the center of the circle as a result and so forth. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code [universal language]
On 4/20/13, John Carlson yottz...@gmail.com wrote: Do you need one symbol for the number infinity and another for denoting that a set is inifinite? Or do you just reason about the size of the set? Is there a difference between a set that is countably infinite and one that isn't countable? I barely know Russell's paradox... you're ahead of me. Well, for what it's worth, quoting from Meguire's 2007 Boundary Algebra: A Simple Notation for Boolean Algebra and the Truth Functors: Let U be the universal set, a,b∈U, and ∅ be the null set. Then the columns headed by “Sets” show how the algebra of sets and the pa are equivalent. Table 4-2. The 10 Nontrivial Binary Connectives (Functors). NameLogic Sets BA Alternation a∨b a∪b ab Conditional a→b a⊆b (a)b Converse a←b a⊇b a(b) Conjunction a∧b a∩b ((a)(b)) ___ NOR a↓b a∪b (ab) ___ Sheffer stroke a|b a∩b (a)(b) Biconditionala↔b a⊆b⊆a (((a)b)(a(b))) -or- ((a)(b))(ab) (Apologies if the Unicode characters got mangled!) Check out http://www.markability.net/sets.htm also. I don't know much about set theory but I think the Universal set stands for the set of everything, no? Cheers, ~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 [universal language]
I think that concepts in some sense transcend the universe. Are there more digits in pi than there are atoms in the universe? I guess we are asking if there are transcendental volumes which are bigger or more complex than the universe. If the universe contains the transcendental as symbols then how many transcendental symbols are there? I think you still run into Russell's Paradox. On Apr 20, 2013 9:15 PM, Simon Forman forman.si...@gmail.com wrote: On 4/20/13, John Carlson yottz...@gmail.com wrote: Do you need one symbol for the number infinity and another for denoting that a set is inifinite? Or do you just reason about the size of the set? Is there a difference between a set that is countably infinite and one that isn't countable? I barely know Russell's paradox... you're ahead of me. Well, for what it's worth, quoting from Meguire's 2007 Boundary Algebra: A Simple Notation for Boolean Algebra and the Truth Functors: Let U be the universal set, a,b∈U, and ∅ be the null set. Then the columns headed by “Sets” show how the algebra of sets and the pa are equivalent. Table 4-2. The 10 Nontrivial Binary Connectives (Functors). NameLogic Sets BA Alternation a∨b a∪b ab Conditional a→b a⊆b (a)b Converse a←b a⊇b a(b) Conjunction a∧b a∩b ((a)(b)) ___ NOR a↓b a∪b (ab) ___ Sheffer stroke a|b a∩b (a)(b) Biconditionala↔b a⊆b⊆a (((a)b)(a(b))) -or- ((a)(b))(ab) (Apologies if the Unicode characters got mangled!) Check out http://www.markability.net/sets.htm also. I don't know much about set theory but I think the Universal set stands for the set of everything, no? Cheers, ~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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code [universal language]
Take my word for it, theory comes down to Monday Night Football on ESPN. On Apr 20, 2013 10:13 PM, John Carlson yottz...@gmail.com wrote: I think that concepts in some sense transcend the universe. Are there more digits in pi than there are atoms in the universe? I guess we are asking if there are transcendental volumes which are bigger or more complex than the universe. If the universe contains the transcendental as symbols then how many transcendental symbols are there? I think you still run into Russell's Paradox. On Apr 20, 2013 9:15 PM, Simon Forman forman.si...@gmail.com wrote: On 4/20/13, John Carlson yottz...@gmail.com wrote: Do you need one symbol for the number infinity and another for denoting that a set is inifinite? Or do you just reason about the size of the set? Is there a difference between a set that is countably infinite and one that isn't countable? I barely know Russell's paradox... you're ahead of me. Well, for what it's worth, quoting from Meguire's 2007 Boundary Algebra: A Simple Notation for Boolean Algebra and the Truth Functors: Let U be the universal set, a,b∈U, and ∅ be the null set. Then the columns headed by “Sets” show how the algebra of sets and the pa are equivalent. Table 4-2. The 10 Nontrivial Binary Connectives (Functors). NameLogic Sets BA Alternation a∨b a∪b ab Conditional a→b a⊆b (a)b Converse a←b a⊇b a(b) Conjunction a∧b a∩b ((a)(b)) ___ NOR a↓b a∪b (ab) ___ Sheffer stroke a|b a∩b (a)(b) Biconditionala↔b a⊆b⊆a (((a)b)(a(b))) -or- ((a)(b))(ab) (Apologies if the Unicode characters got mangled!) Check out http://www.markability.net/sets.htm also. I don't know much about set theory but I think the Universal set stands for the set of everything, no? Cheers, ~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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
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 dmbarb...@gmail.com wrote: On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart 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.comwrote: On Mon, Apr 15, 2013 at 11:57 AM, David Barbour dmbarb...@gmail.comwrote: 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
Re: [fonc] 90% glue code
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 casey.obrie...@gmail.comwrote: 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 dmbarb...@gmail.comwrote: On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart 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.comwrote: On Mon, Apr 15, 2013 at 11:57 AM, David Barbour dmbarb...@gmail.comwrote: 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
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 mfidel...@meetinghouse.net To: Fundamentals of New Computing fonc@vpri.org 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 Symbiosisis 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 http://memex.org/licklider.html, 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
It's on the reading list now. Thank you! On Apr 19, 2013, at 5:56 AM, Alan Kay alan.n...@yahoo.com 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 alan.n...@yahoo.com To: Fundamentals of New Computing fonc@vpri.org 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 mfidel...@meetinghouse.net To: Fundamentals of New Computing fonc@vpri.org 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 Symbiosisis 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 http://memex.org/licklider.html, 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
So who cares about functionality we need to mechanically refactor the glue. On 19 April 2013 17:32, David Barbour dmbarb...@gmail.com 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 casey.obrie...@gmail.com 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 dmbarb...@gmail.com wrote: On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart 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 wrote: On Mon, Apr 15, 2013 at 11:57 AM, David Barbour dmbarb...@gmail.com 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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
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
On 4/19/13, Simon Forman forman.si...@gmail.com 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
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
Re: [fonc] 90% glue code
Hi Alan, Your metaphor brought up a connection that I have been thinking about for a while, but I unfortunately don't have enough breadth of knowledge to know if the connection is worthwhile or not, so I am throwing it out there to this list to see what people think. If figuring out module communication can be likened to communicating with aliens, could we not look at how we go about communicating with alien cultures right now? Maybe trying to use real-world metaphors in this case is foolish, but it seemed to work out pretty well when you used some of your thoughts on biology to inform OOP. So can we look to the real world and ask how linguists go about communicating with unknown cultures or remote tribes of people? Has this process occurred frequently enough that there is some sort of protocol or process that is followed by which concepts from one language are mapped onto those contained in the indigenous language until communication can occur? Could we use this process as a source of metaphors to think about how to create a protocol for discovering how two different software modules can map their own concepts onto the other? Anyway, that was something that had been running in the background of my mind for a while, since I saw you talk about the importance of figuring out ways to mechanize the process modules figuring out how to communicate with each other. Thanks, Jeff On Thu, Apr 18, 2013 at 9: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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
The basic idea is to find really fundamental questions about negotiating about meaning, and to invent mental and computer tools to help. David is quite right to complain about the current state of things in this area -- but -- for example -- I don't know of anyone trying a discovery system like Lenat's Eurisko, or to imitate how a programmer would go about the alien module problem, or to e.g. look at how a linguist like Charles Hockett could learn a traditional culture's language well enough in a few hours to speak to them in it. (I recall some fascinating movies from my Anthro classes in linguistics that I think were made in the 50s showing (I think) Hockett put in the middle of a village and what he did to find their language). There are certainly tradeoffs here about just what kind of overlap at what levels can be gained. This is similar to the idea that there are lots of wonderful things in Biology that are out of scale with our computer technologies. So we should find the things in both Bio and Anthro that will help us think. Cheers, Alan From: Jeff Gonis jeff.go...@gmail.com To: Alan Kay alan.n...@yahoo.com; Fundamentals of New Computing fonc@vpri.org Sent: Thursday, April 18, 2013 8:39 AM Subject: Re: [fonc] 90% glue code Hi Alan, Your metaphor brought up a connection that I have been thinking about for a while, but I unfortunately don't have enough breadth of knowledge to know if the connection is worthwhile or not, so I am throwing it out there to this list to see what people think. If figuring out module communication can be likened to communicating with aliens, could we not look at how we go about communicating with alien cultures right now? Maybe trying to use real-world metaphors in this case is foolish, but it seemed to work out pretty well when you used some of your thoughts on biology to inform OOP. So can we look to the real world and ask how linguists go about communicating with unknown cultures or remote tribes of people? Has this process occurred frequently enough that there is some sort of protocol or process that is followed by which concepts from one language are mapped onto those contained in the indigenous language until communication can occur? Could we use this process as a source of metaphors to think about how to create a protocol for discovering how two different software modules can map their own concepts onto the other? Anyway, that was something that had been running in the background of my mind for a while, since I saw you talk about the importance of figuring out ways to mechanize the process modules figuring out how to communicate with each other. Thanks, Jeff On Thu, Apr 18, 2013 at 9: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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
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-endhttp://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 addresshttp://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 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 programminghttp://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 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
Re: [fonc] 90% glue code
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
Re: [fonc] 90% glue code
Alan Kay alan.n...@yahoo.com writes:
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?
I don't think that in this universe, intergalactic communication
(assuming the message is transmitted) to be more difficult than
intragalactic communication. I mean, I don't expect more variability in
intelligent forms in a different galaxy than in the same galaxy,
because we are assuming the same physics laws apply to the whole
universe, and some overall homogeneity in the universe composition.
On the other hand, I'd already expect software, ie. AI, to be more alien
than most intelligent life forms we'll ever encounter. We will
probably have to work hard to make artificial intelligence, or make it
stay, close enough to ourselves.
On the other hand, if you want really to push beyond our imaginations,
inter-universe communication would be a real challenge (always, assuming
the messages can go thru).
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
It depends what you mean by 'glue' - I think if you're going to quantify something you should define it. Do you think accessors in Java and Smalltalk code qualify as 'glue'? I suppose object-relational mapping declarations would as well, likely any code traversing an object to obtain data for presentation to a UI. Is all application code glue, and the only non-glue code is parsing, compilation or interpretation of glue? Alternatively the only non-glue is the hardware :) I've got access to a rather large code base in Smalltalk/Envy format which would be interesting to analyze (15+ years with probably hundreds of developers pounding on it with various levels of skill). There is a feature of John Brant and Don Roberts refactoring browser ( http://www.refactory.com/tools/refactoring-browser) that does some lint-like analysis of code on the class and application level (Envy's equivalent of packages), but I can't imagine where to start. On the other hand, analyzing code that can't be published might not be particularly useful to anyone here. Is glue code code devoid of semantic or computational intent? Are type systems purely glue code if they don't have any value at runtime? Does the term even have any meaning at all? On Tue, Apr 16, 2013 at 7:52 PM, David Barbour dmbarb...@gmail.com wrote: On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart 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.comwrote: On Mon, Apr 15, 2013 at 11:57 AM, David Barbour dmbarb...@gmail.comwrote: 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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
On Wed, Apr 17, 2013 at 8:26 AM, Steve Wart st...@wart.ca wrote: It depends what you mean by 'glue' - I think if you're going to quantify something you should define it. Glue code is reasonably well defined in the community. http://en.wikipedia.org/wiki/Glue_code A related term sometimes used is 'data plumbing'. http://www.johndcook.com/blog/2011/11/15/plumber-programmers/ Do you think accessors in Java and Smalltalk code qualify as 'glue'? Yes. I suppose object-relational mapping declarations would as well, likely any code traversing an object to obtain data for presentation to a UI. Indeed. The traversal code is glue. The precise code deciding (during or after traversal) what to display and how to format it would not be glue. Is all application code glue, and the only non-glue code is parsing, compilation or interpretation of glue? No. Information, e.g. from sensors, is not glue. The logic that decides actuation of a robotic arm or what to display on a UI is not glue code. Music, art, character AIs, procedurally generated worlds, dialog trees, etc. may consist of considerable quantities of data and code that is not glue. Of course, many of these things still involve much glue to integrate them into one coherent application. Alternatively the only non-glue is the hardware :) There is glue hardware, too. :D http://en.wikipedia.org/wiki/Glue_logic Is glue code code devoid of semantic or computational intent? Are type systems purely glue code if they don't have any value at runtime? Does the term even have any meaning at all? Glue code does have computational intent and purpose. Every application must gather data from multiple sources (sensors, user input, various databases), make decisions based on some logic, then effect those decisions by distribution of control streams (robotic arms, monitors, data maintenance). In a world without glue code, at least as source code, only the middle step would be explicit. In state-of-the-art systems, every step is explicit, plus there's a lot of overhead - e.g. explicitly managing local state and caches so we can combine data streams so we can make decisions; ad-hoc recovery code after partial failure; data conversions from different sources or between algorithms. Type systems are not glue code because they don't connect different parts of a system. (Though, they could be leveraged for glue code, e.g. using type-matching for auto-wiring.) Regards, David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
The wikipedia definition is circular, but I agree that people know it when they see it :) Thanks for the thoughtful reply. Steve On Wed, Apr 17, 2013 at 9:52 AM, David Barbour dmbarb...@gmail.com wrote: On Wed, Apr 17, 2013 at 8:26 AM, Steve Wart st...@wart.ca wrote: It depends what you mean by 'glue' - I think if you're going to quantify something you should define it. Glue code is reasonably well defined in the community. http://en.wikipedia.org/wiki/Glue_code A related term sometimes used is 'data plumbing'. http://www.johndcook.com/blog/2011/11/15/plumber-programmers/ Do you think accessors in Java and Smalltalk code qualify as 'glue'? Yes. I suppose object-relational mapping declarations would as well, likely any code traversing an object to obtain data for presentation to a UI. Indeed. The traversal code is glue. The precise code deciding (during or after traversal) what to display and how to format it would not be glue. Is all application code glue, and the only non-glue code is parsing, compilation or interpretation of glue? No. Information, e.g. from sensors, is not glue. The logic that decides actuation of a robotic arm or what to display on a UI is not glue code. Music, art, character AIs, procedurally generated worlds, dialog trees, etc. may consist of considerable quantities of data and code that is not glue. Of course, many of these things still involve much glue to integrate them into one coherent application. Alternatively the only non-glue is the hardware :) There is glue hardware, too. :D http://en.wikipedia.org/wiki/Glue_logic Is glue code code devoid of semantic or computational intent? Are type systems purely glue code if they don't have any value at runtime? Does the term even have any meaning at all? Glue code does have computational intent and purpose. Every application must gather data from multiple sources (sensors, user input, various databases), make decisions based on some logic, then effect those decisions by distribution of control streams (robotic arms, monitors, data maintenance). In a world without glue code, at least as source code, only the middle step would be explicit. In state-of-the-art systems, every step is explicit, plus there's a lot of overhead - e.g. explicitly managing local state and caches so we can combine data streams so we can make decisions; ad-hoc recovery code after partial failure; data conversions from different sources or between algorithms. Type systems are not glue code because they don't connect different parts of a system. (Though, they could be leveraged for glue code, e.g. using type-matching for auto-wiring.) Regards, David ___ 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
On Wed, Apr 17, 2013 at 11:04 AM, Steve Wart st...@wart.ca wrote: The wikipedia definition is circular, but I agree that people know it when they see it :) I don't believe it's circular. It does assume you already know the meaning of glue and code independently. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
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/fonchttp://vpri.org/mailman/listinfo/fonc __**_ fonc mailing list fonc@vpri.org mailto:fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://vpri.org/mailman/listinfo/fonc __**_ fonc mailing list fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://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/fonchttp://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
Sounds like you want stone soup programminghttp://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 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
Re: [fonc] 90% glue code
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? On Mon, Apr 15, 2013 at 12:15 PM, David Barbour dmbarb...@gmail.com wrote: On Mon, Apr 15, 2013 at 11:57 AM, David Barbour dmbarb...@gmail.comwrote: 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
Re: [fonc] 90% glue code
On Mon, Apr 15, 2013 at 12:15:10PM -0700, David Barbour wrote: On Mon, Apr 15, 2013 at 11:57 AM, David Barbour dmbarb...@gmail.com wrote: 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. Err, I may sound nitpicky, but when I say code, I usually mean *source* code. Automatically generated code counts only if it becomes the preferred medium for modification. Most of the time, it isn't: you'd tweak the generation procedure instead. So, maybe it's not hopeless. Maybe we do have ways to reduce the amount (if not the proportion) of glue code. Now, reducing the hardware ressources (CPU, memory…) needed to *run* glue code is another matter. Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart 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.comwrote: On Mon, Apr 15, 2013 at 11:57 AM, David Barbour dmbarb...@gmail.comwrote: 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
Re: [fonc] 90% glue code
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
Re: [fonc] 90% glue code
On Tue, Apr 16, 2013 at 4:28 PM, Loup Vaillant-David l...@loup-vaillant.frwrote: On Mon, Apr 15, 2013 at 12:15:10PM -0700, David Barbour wrote: On Mon, Apr 15, 2013 at 11:57 AM, David Barbour dmbarb...@gmail.com wrote: 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. Err, I may sound nitpicky, but when I say code, I usually mean *source* code. Automatically generated code counts only if it becomes the preferred medium for modification. Most of the time, it isn't: you'd tweak the generation procedure instead. So, maybe it's not hopeless. Maybe we do have ways to reduce the amount (if not the proportion) of glue code. If you have enough setup, parameters, and holes to fill for the generation procedure, then that just becomes a higher layer of glue code. You can't expect huge savings even with automatic methods. OTOH, almost any reduction is worthwhile. One way to think of '90% glue code' is I'm 10% efficient. So if we cut it down to 70% glue code, that's like tripling efficiency - a naive analysis, unfortunately, but a motivating one. Now, reducing the hardware ressources (CPU, memory…) needed to *run* glue code is another matter. Ooh, that's where we can really win, if we approach it right - supporting deep, cross-layer optimizations, fusing intermediate steps, optimize memoization or caching, content distribution networks. But we need to model glue code in higher level languages to achieve such things automatically. Regards, Dave ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
On Tue, Apr 16, 2013 at 8:03 PM, Miles Fidelman mfidel...@meetinghouse.netwrote: 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? Yes. I believe so. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
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). Also, much of the need for glue is caused by unnecessary impedance mismatch in the first place. If everyone in the project would use this *or* that, we wouldn't have to translate from this *to* that. It should come as no surprise that 'scaling' beyond toy projects is often difficult when our infrastructure is 90% low-grade glue. I'd say the way we talk about toy projects is part of the problem. See, what is the single most important metric that come to mind when separatying toy projects from serious ones? Size. By that definition, OMeta and Maru are mere little toys. If they mature correctly, they may even look *more* toyish. If we want them to *appear* mature however, we'll need to add some bloat. Do we know of projecst that are small in size, but which yields Big Buck$? That should set better examples than mere LOC count. Rebol, maybe? Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
On Mon, Apr 15, 2013 at 11:57 AM, David Barbour dmbarb...@gmail.com wrote: On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David l...@loup-vaillant.frwrote: 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
