Glue
Posted by Daniel Lyons Mon, 06 Aug 2007 08:55:00 GMT
I’ve been thinking about glue code a lot lately.
As a lazy programmer, I chafe at how much of my time is spent writing glue between two different systems. These two systems usually are pretty similar or I wouldn’t be bridging them. For example, for one client, I’m bridging a templating system and an API for sending email. Obvious. Another client is getting the ubiquitous bridge between the database and HTML for editing. It seems like an awful lot of this code is basically duplicated effort.
The advanced programming languages of today seem, to me, to be focused on helping you be more abstract. In some cases, this pays off immediately in terms of reducing glue. C++ may not have lambda abstractions, but at least I don’t have to write my own quicksort for my weird data structure or weird data types. In a sense, the code that normally would go between quicksort and your linked list or your array or whatever would be glue. In the best case scenario. In the average case, you’d probably wind up rewriting it altogether.
Lambda abstraction is in my opinion fundamental. Without it, there are things you simply cannot abstract out. The Y combinator may not be the most practical tool, but it’s an excellent demonstration of how powerful the tool is. There’s no way in C to abstract out recursion. Yet every language with lambda can. So there is, at least in theory, a whole category of glue that you have to duplicate in languages which lack lambda or equivalent abstraction mechanisms.
Haskell and Forth don’t have much in common, but both have a simplifying concept at the core which enables powerful abstraction of glue code. In Haskell, every function essentially is of one parameter, returning either another function of one parameter or one value. This, plus a general amenability to functional abstraction through higher-order functions like map and flip, makes it easy to stuff a function into a situation it wasn’t intended for. In PHP, you’d have to write a new function in the best case scenario, or more likely just repeat the same loop all over again.
Forth uses the simplifying concept of a stack as input and output. Does some word use a different API than is convenient for you? Just mangle the stack a little bit.
In a sense, object orientation also provides you with this power. You have an object which expects some API on some other object, but you have something that doesn’t quite fit? No problem, just inherit the right thing, fill in the methods you need and you’re set. Yet, looking at it now, from these other sides of the fence, I have to wonder if this is more powerful or more general or just wordier.
I see there being a lot of computation taking place simply to translate one thing into a different format. This has bothered me a lot for a long time. I’m no longer convinced that that step can be avoided—but if it cannot, is it at least possible to step out from between the two formats and let the computer perform the translation, without having to manually glue these systems together? It seems like many of the gains of functional programs are simply that they prevent you from being more involved in the process than you have to be. How far can we take this concept?
