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
