Lambda the Ultimate

One of the early "blindingly obvious" points the author makes is the distinction between writing glue code (he refers to it as "menu-lookup") and programming (he calls it "real programming"). He writes: "Real programming means to increase the computational capacity, to begin with a set of operations, and develop them into new operations that were not obviously implicit in the original set."

Of course I was aware, on some level, of the distinction between these two modes of programming. But until I read that passage, it never really occurred to me that in any given project, the portion of time I spent on glue code was always attended with drudgery and a sense of wasted time, while the portion spent on "real programming" (though occasionally lengthy) always seemed to pass in a flash. When I would speak to others about code I'd written, I always seemed to focus on the "real programming". And any new techniques I would learn, particularly from PLT, would always appear in the "real programming" domain, and only seldom in the glue code.

I realised, then, that "real programming" was what was fun about programming, for me. The intricate logic puzzles it presented, the experience of insight when a complicated solution became simple, were the reasons I entered the field in the first place, and the reasons I stay.

I also realised that in most of the work I've done in industry, the vast bulk of the code I've written or supervised has been glue code. There has been a fair bit of "real programming", to be sure, but in terms of either lines of code or hours in the chair, it's swamped by the glue. And that has significance for programming technologies, and the practical application of PLT in general.

One of the early "blindingly obvious" points the author makes is the distinction between writing glue code (he refers to it as "menu-lookup") and programming (he calls it "real programming").

I'm certainly familiar with this distinction, but I find it somewhat unproductive, both from a systems development point of view and a PLT point of view.

From a systems development point of view, as your system get large the glue becomes the system: if you are only interested in applying "real programming" skills to the "exciting bits" you are going to end up with a mess. Learning to deal with large amounts of glue often requires more skill than the "real programming" tasks taken individually.

From the PLT point of view, the kinds of abstraction tools that we often discuss in PL design are in essence "different kinds of glue". Algorithms in isolation can be studied in any language (q.v. TAOCP and MIX); gluing together algorithms in clear and powerful ways is where the power of better language abstractions shine.

I don't find it unproductive, actually. It's well known that when you start building really big systems, functionality is strongly sublinear in the size of the system (as measured by LOC). That's because the code base becomes too large to be discoverable, and that means that lots of wheels get reinvented because the programmers simply didn't realize that someone else had written a caching framework already. There really, genuinely, isn't much fun or intellectual merit in writing glue code to make two independently evolved, slightly buggy, message buses talk to each other. It's pure accidental complexity.

Powerful abstraction mechanisms let you fight this tendency for longer, because they make factoring those reimplementations away easier. This is one of the reasons why programmers like them so much.

There really, genuinely, isn't much fun or intellectual merit in writing glue code to make two independently evolved, slightly buggy, message buses talk to each other.

You have given an example of my concern about the distinction: you seem to assume that "glue" is mere donkey hackery.

The challenge is to, using your example, write a unified, bug-free common substrate that the two older systems can be replaced with or plugged-into, so that over time their redundant functionalities can be worn away.

This is what makes the difference between keeping a large system maintainable or ending up with a big ball of goo. Writing good "glue" is hard, requires advanced skills, is just a intellectually stimulating as individual algorithm work, and, I would argue, is the most vital skill of a large system developer.

Moreover, it gets a big boost from understanding PLT.

That's because all large programs are too big to be discoverable. It is cognitively impossible for a developer to understand even all of the most important interfaces in the system. This means that developers will inevitably reinvent the same structures over and over and over again, because they don't know what the other developers on the other side of the country were doing five years ago. This is a brute fact of nature, arising from the limited capacity of the human brain. You can dislike it, but you can't change it.

What good abstractions let you do is delay the day of reckoning, by reducing the rate of growth per chunk of additional functionality. But if you keep growing the code base then entropy will win, period. A ten million line Haskell program will be just as ill-structured as a ten million line Java program will be just as ill-structured as a ten million line C program. It's just that the Java program won't have twenty different implementations of strings, and the Haskell program won't have twenty different ad-hoc parsers.

But the ten million line Java program won't do as much more than the ten million line C program as you would guess by comparing ten thousand line programs, and likewise for Haskell and Java. That's because they will all have an unavoidable failure of structure at scale. And coping with that failure is neither fun nor intellectually interesting, because you can't fix it.

If you could dream a really big dream, what tools would help to actually fix it? Seems like back in the 60's Englebart showed augmentation and where better to start than with tools for managing software?

For example, a (most impossible?) dream would to have some kind of natural language system one can interact with to ask "i want to do X, tell me how it was done before in this system [or others]". What would be required to get there? What bits of that could we do first to help us?

My suspicion is that it's not possible, for the following reason: the software crisis was diagnosed in the early 1960s, and has not been alleviated one iota in the past forty years. This is despite the fact that modern tools, languages, and environments are overwhelmingly better than they were in 1965.

I think programmers always push their complexity-handling tools to the limit in order to solve new problems. If you give them new tools (eg, garbage collection, objects, abstract types, higher-order functions, debuggers, refactoring browsers), then they will immediately start trying to tackle harder problems, and soon enough we're at the limit of these new tools too.

SEI types say that any project worth doing will end up lowering your organization's maturity level, because it's a new problem of a type you haven't solved before and in trying it you will discover exciting new ways for your processes to fail. That's a principle that generalizes well beyond software process, I think.

If I may be forgiven for quoting myself from the Spirit of LtU page:

[It is common habit] to over-generalize one's experience as typical of all programming environments and problems.

I'll have to invoke that principle here and politely agree to disagree with Neel and Wolf in this thread.

Suffice it to say that I would recommend anyone who can't find some way to make working with glue challenging and satisfying, or who thinks that large scale development is a lost cause, may not want to consider a career as an industrial programmer or as an industrial PL designer. ;-)

Fortunately, there are lots of other excellent ways to fulfill one's interests in this regard.

Wow.

I appreciate the reference to over-generalisation. I had certainly been trying to contain my arguments to my own experience, without trying to encompass the enormity of programming in general. My experience, however, is itself wide and varied, within the general confines of "commercial programming". There certainly are commonalities among the various environments and programmers I've encountered, and I stand by my statement that the majority of them involve subjects and situations that are dramatically under-represented in this forum, as well as in academic PLT in general.

As I pointed out in a reply a bit downthread, I have indeed come to develop ways to make working with glue challenging and satisfying. That's not in question here. The quote I pulled from the book quite a ways upthread triggered a recognition in me that the dull, soulless cut-and-paste that comprises the majority of current real-world programming is not, in fact, programming at all. In order to make it such, it must be approached (as you point out) as an actual programming problem, and the proper techniques applied.

I think we can agree on that.

A separate point (and one that I've noticed is apparently not acceptable in this forum) is that programming, for many, is not what the denizens of LtU would have it be. There's a certain disconnect there (I've seen it referred to as "ivory-tower-ism"), and I've watched it arise in thread after thread. I'm going to assume at this point that it's one of those perennial arguments, like "dynamic typing" v. "static typing", that has no real resolution, and probably shouldn't be raised here.

I hope we can agree on that, too.

However, even with a smiley, your recommendation still appears condescending. I'm working hard not to read it that way.

that programming, for many, is not what the denizens of LtU would have it be

I strongly disagree with this. I think people raise this argument often but it is never substantiated with good evidence. It is simply easy to call anyone who disagrees with you about programming methodology an "academic". We had many threads in which people told about their careers and proved to my satisfaction that you can have plenty of experience in industrial settings, and still appreciate PLT. To me the claim about the "ivory tower" sound condescending to the extreme (yes, anti-intellectualism is often condescending).

I didn't read Marc's comment as condescending. I thought he was applying the principle of over-generalization to himself.

I'm sorry. I did not intend to be condescending myself, rather point out that I see this kind of industry/academia tension common in many threads on LtU, and that they often seem to end up going the same way.

I'm not claiming that industry has no appreciation for PLT. I'm in industry, and I have an appreciation for PLT, so I may use myself as an example of that very phenomenon. But recent discussions in a thread entitled "Why people don't use functional programming?" began to head in this direction, too.

I will attempt to restrict myself to less-philosophical subjects in future.

Apology accepted.

As a meta-argument about threads rather than people, the claim is arguably true. Personally, I try to stay away from threads that go in this direction, since it's no productive from a theoretical persepctive nor from a practical one. There enough threads, I assure you, that don't go down this path...

Responding quite selectively to the parent comment:

There certainly are commonalities among the various environments and programmers I've encountered, and I stand by my statement that the majority of them involve subjects and situations that are dramatically under-represented in this forum, as well as in academic PLT in general.
[...]
The quote I pulled from the book quite a ways upthread triggered a recognition in me that the dull, soulless cut-and-paste that comprises the majority of current real-world programming is not, in fact, programming at all.
[...]
A separate point (and one that I've noticed is apparently not acceptable in this forum) is that programming, for many, is not what the denizens of LtU would have it be.

In what way? We're interested in programming languages, and studying programming languages tends to make one keenly aware of the shortcomings, limitations, possibilities, etc. inherent in any given language. Many people here would like to see better programming languages become more commonplace (where "better" is a subjective term, which certainly does not necessarily correlate simply to e.g. "FP").

If one has any interest in improving the state of the art, then arguably the main interest provided by the current practice of "real-world" programming is as a source of information about opportunities for improvement. If there's a disconnect in this area, I'd suggest a big part of that disconnect may come from people looking at the discussion here from the perspective of a working programmer, and seeing it as impractical because it often discusses ideas that can't practically be exploited today in BigCorpLang 4.0. That's a kind of category error which we've seen over and over, arguably even within the last day or two (in other threads).

There's a certain disconnect there (I've seen it referred to as "ivory-tower-ism"), and I've watched it arise in thread after thread. I'm going to assume at this point that it's one of those perennial arguments, like "dynamic typing" v. "static typing", that has no real resolution, and probably shouldn't be raised here.

I think that depends on exactly what's being raised, and how it's being raised (I can't quite tell what your specific point is from the above). For example, I work in industry myself, and deal with a lot of glue code, and agree that it's important to treat it as a programming problem, and apply good design techniques to it. However, that process is not, much of the time, particularly interesting from a programming language perspective — it can be, in theory, if we're discussing particular PLs or PL features that address glue-related problems, etc., but that doesn't seem to have often been the case. So if you're observing that something isn't acceptable in this forum because it doesn't relate to programming languages as such, that's probably correct. But if you're talking about an issue that relates to the design, theory etc. of programming languages, it shouldn't be unacceptable here, unless it's raised in a particularly contentious way. So if you have a point to raise that's relevant to programming languages, by all means raise it. (Possibly in a new topic.)

However, even with a smiley, your recommendation still appears condescending. I'm working hard not to read it that way.

My apologies if my comment seemed condescending to you. The intent was the opposite. As Ehud correctly interpreted, I was invoking the Spirit for myself: we had each expressed the insights of our experience and had come to different conclusions from our experience, and I could only assume that we have different but equally valid experiences, so I thought it would be unwise of me to offer further debate.

The joke about not becoming an industrial programmer, aside from its humour value (however slim that may be ;-)), was more for the benefit of an imagined lurking reader considering their future options based on our conversation, so that they might take inspiration or take warning as they felt appropriate to themselves. ;-)

[Small typo fix]

Marc, after rereading my comments I'd like to apologize -- they come across as much more hostile than I intended.

One of the most satisfying moments in my career was making a program ten times smaller and a hundred times faster, as well as more readable, more debuggable and easier to build at the same time. Creating unity and harmony where there wasn't any before is fun and challenging, and I don't mean to suggest otherwise. But to my mind the value and the challenge was in eliminating the glue code rather than creating it.

But if you've seen some glue that you thought was beautiful, I'd love to hear you talk about what made it so.

after rereading my comments I'd like to apologize

No apology necessary; I didn't take offense. As in the case of Wolf, I had to assume you were simply drawing on a different set of circumstances and experiences than I was.

But to my mind the value and the challenge was in eliminating the glue code rather than creating it.

I think we are substantively in agreement, but interpreting the glue metaphor slightly differently. I'm not advocating for quantities of glue, and certainly not for cut-and-paste (pardon the pun), but rather for intelligently and minimally performing the necessary gluing functions.

As I mentioned previously, whenever I post in a forum such as this, I'm very mindful of the lurking university student, for example, who is considering a career related to software development or PLT, or who has just started out and is frustrated with the apparent "state of the art". Such a person who read this thread and concluded that "only suckers write glue code" would probably end up either miserable working in the field or not very good at it, since they might avoid and neglect the skills needed to make the best of it (such as those you mentioned).

Likewise, someone who wanted to design PLs, but saw glue as trivial might neglect it in their language and thereby not serve the developers that will end up using it.

I personally quite frequently get great pleasure and satisfaction from refactoring glue code to be more elegant, using all the tools of abstraction and analysis at my disposal (and in the PL at hand). Aside from giving me a mental workout, it also reduces the system entropy that you alluded to and makes the application more maintainable and robust, which has the added benefit of making my employer happy. ;-)

Just today I was implementing/adapting the HaXml combinators in/to C# (2.0). It was enjoyable* (except bugger not being able to yield return in an anonymous function!**). I'm certain using the combinators will be more enjoyable than (at least) the raw XML processing techniques. It'll be interesting to see what happens with them.

[edit: I forgot to mention the relevant fact that this was at work. Further, it was inspired by some less than beautiful glue.]

* C# was much better than I was expecting and is much better than Java (language-wise) in my opinion. I still want TCO though...

** Okay, I can think of potential reasons why this is disallowed, though I'd have to think more than I care to at this point to see if there is any meat to them.

I disagree. The glue that I've had to deal with has, in most cases, been cleanly written, concise, maintainable...and usually built from a small set of constructs. That is, most glue code is the same thing, over and over and over again, because most of the systems it ends up gluing together are themselves built around only a few basic concepts.

The majority of my programming time has been in large system development, and most of that has simply been trying to wire together different vendors' interfaces. While there have been a few challenging bits, most of it is, in fact, "donkey hackery". Really. Yes, it's possible to write systems integration code in a very elegant and clever way, and it might even be satisfying, but it's not going to get you paid.

Glue isn't "bad", nor is it "pointless", it's simply "boring" because it's overwhelmingly mechanical. In industry, as well, there's a great deal of pressure for glue code to be written quickly (and often dirtily), since "all the hard stuff's in the libraries already". The dulling effect this has is often underestimated -- the vast majority of programmers I've encoundered believe that glue (and a couple algorithmic idioms) really is all there is to programming, and after a few years in the field quickly burn out into bitter drones. That these people represent a large chunk of the programming population outside of schools is, I think, why some bits of academic theory are ignored by industry.

Now, since glue isn't going away, I find myself more often these days meta-programming, and discovering ways to write code to handle the gluing itself. This sometimes involves writing little languages, or code generators, or logic systems, or some other tool that lets me work with the glue at a higher level of abstraction. This is a good thing for everyone: I get to remain engaged with problems that are interesting and challenging, the glue that's generated is usually more robust (and at the very least much more consistent), and the resulting system is more maintainable and extensible.

Just so that we're clear, here...I'm not speaking of the glue involved in handling, say, a transactional communication channel between tiers in a multi-tier app. That does qualify as glue, it is indeed hard to write a good one, and it does yield to formal analysis. However, no one (outside the big vendors) actually writes that code anymore -- they use the transactional communication channel provided by the framework, and string together a set of boilerplate code to stuff the right stuff in and pull the right stuff out. That's "donkey hackery".

I think it's following the path of least (business) resistance: Figuring out a business case for a program without glue is hard. OTOH, a program that talks to this database and calls that webservice and sends this email and renders this helicopter image presents an easier business case.

Applications turn into organisms, and we're not doing biology anymore, we're taking care of a patient. That's why some of us think that just this is all there is for programming.

we're taking care of a patient

That's a great metaphor!

...but since my primary job over the last 12 months involves software for running medical practices, there happen to be real patients involved. Perhaps a metaphor from a different discipline - something like Rocket Science. :-)

Who is sicker, the patients or the software?

Since you are on the case the software is probably in fine shape, but in general only hospital computer systems encounter people as sick as most of the programs out there...

And looking at the preview, I think I am going to have to get a copy (the somewhat disturbing distinction between glue code and "real programming" notwithstanding), if only for Notion 41: The Ellipsis Is Not A Definition.

Thanks for the pointer.