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
