So who cares about functionality we need to mechanically refactor the glue.
On 19 April 2013 17:32, David Barbour <[email protected]> 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 <[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 > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
