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 <[email protected]> wrote: > > On Wed, Apr 17, 2013 at 8:26 AM, Steve Wart <[email protected]> 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 > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
