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 <[email protected]>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 <[email protected]>wrote: > >> >> On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart <[email protected]> wrote: >> >>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich >>> > In real systems, 90% of code (conservatively) is glue code. >>> >>> What is the origin of this claim? >>> >> >> I claimed it from observation and experience. But I'm sure there are >> other people who have claimed it, too. Do you doubt its veracity? >> >> >>> >>> >>> On Mon, Apr 15, 2013 at 12:15 PM, David Barbour <[email protected]>wrote: >>> >>>> >>>> On Mon, Apr 15, 2013 at 11:57 AM, David Barbour <[email protected]>wrote: >>>> >>>>> >>>>> On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David < >>>>> [email protected]> wrote: >>>>> >>>>>> On Sun, Apr 14, 2013 at 04:17:48PM -0700, David Barbour wrote: >>>>>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich >>>>>> > In real systems, 90% of code (conservatively) is glue code. >>>>>> >>>>>> Does this *have* to be the case? Real systems also use C++ (or >>>>>> Java). Better languages may require less glue, (even if they require >>>>>> just as much core logic). >>>>>> >>>>> >>>>> Yes. >>>>> >>>>> The prevalence of glue code is a natural consequence of combinatorial >>>>> effects. E.g. there are many ways to partition and summarize properties >>>>> into data-structures. Unless we uniformly make the same decisions - and we >>>>> won't (due to context-dependent variations in convenience or performance) >>>>> - >>>>> then we will eventually have many heterogeneous data models. Similarly can >>>>> be said of event models. >>>>> >>>>> We can't avoid this problem. At best, we can delay it a little. >>>>> >>>> >>>> I should clarify: a potential answer to the glue-code issue is to >>>> *infer* much more of it, i.e. auto-wiring, constraint models, searches. We >>>> could automatically build pipelines that convert one type to another, given >>>> smaller steps (though this does risk aggregate lossiness due to >>>> intermediate summaries or subtle incompatibilities). Machine-learning >>>> could be leveraged to find correspondences between structures, perhaps >>>> aiding humans. 90% or more of code will be glue-code, but it doesn't all >>>> need to be hand-written. I am certainly pursuing such techniques in my >>>> current language development. >>>> >>>> >>>> _______________________________________________ >>>> fonc mailing list >>>> [email protected] >>>> http://vpri.org/mailman/listinfo/fonc >>>> >>>> >>> >>> _______________________________________________ >>> fonc mailing list >>> [email protected] >>> http://vpri.org/mailman/listinfo/fonc >>> >>> >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> >> > > > -- > Casey Ransberger > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
