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.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 > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
