> Why so much glue? Because the right glue to use depends on the materials being joined, and the context in which the joint will need to survive (moisture, temperature, duration).

On that topic, I am obligated to link to a wonderful no-nonsense guide choosing on the best glue for your particular materials:

http://www.thistothat.com/

Unix pipes and filters were not presented as "the" solution, but as an example for the properties we want from our glue, i.e. we should be able to glue our pieces together without having to write much additional code.

And yes, in order for this to work, we need lots of different kinds of glue: https://blog.metaobject.com/2019/02/why-architecture-oriente...

However, for most programming tasks, we have one kind of glue (with minor sub-variants): the procedure call. And so instead of having something that snaps together with a bit of glue, we have to write enormous amounts of boiler-plate in order to make the pieces fit. (The analogy only goes so far...)

I'm been a compiled-language programmer for 35 or so years. I don't view procedure calls as glue, I perceive them as a fundamental mechanism for organizing code. At the level of code that I normally operate at, if you don't write everything in-line, then you've got procedure calls. Not glue, at least, not primarily.

Glue is a way to move data (and perhaps other stuff too) across code boundaries that are imposed by design, language or other constraints. So, sure, stuffing a bunch of stuff on the stack, jumping to a new address and doing something with whatever is on the stack is, in some sense, a sort of glue.

But your TFA seems to be talking about a much higher level of glue than this, I think. The sort of glue that's represented by things like (random list): protobufs, RPC, serialized JSON, even ye olde CORBA/OLE models. Questions like "I've got this customer data, I need to give it to some code that will munge it in some way... how do I do that?"

In that sense, procedure calls are low level mechanism that will support a higher level solution. Again, if it's not all just inline execution of machine code, then at some point, there's going to be a procedure call no matter what abstraction level you're working at.

Great response, thank you!

> I'm been a compiled-language programmer for 35 or so years.

40 or so for me. :-)

> I perceive [procedure calls] as a fundamental mechanism for organizing code.

Yes, I've been arguing this for some time: that the call/return architectural style has been so incredible dominant for so long that it is not really seen as a specific architectural style, but instead as simply all there is. It is the mechanism for organising code.

A paradigm in the true sense.

I call this The Gentle Tyranny of Call/Return[1]. "Gentle" because as architectural style go, it's probably one of the better ones to have, particularly if you only get one.

Anyway, if you study software architecture, you will find that procedure calls[2] are just one of many ways to organise software. However, they are given special status, because they have special language support. So if you use procedure calls to organise your code, to glue your components together, you get to write code naturally. If not, it starts to look messy. And it turns out that procedure calls not always ideal, because...

> Glue is a way to move data (and perhaps other stuff too) across code boundaries that are imposed

And a lot of what we do today is moving data around. Computers don't really compute all that much[3].

>But your TFA seems to be talking about a much higher level of glue than this, I think.. protobufs, RPC, serialized JSON, even ye olde CORBA/OLE models

Yes, these are also glue. But so are procedure calls.

> In that sense, procedure calls are low level mechanism that will support a higher level solution.

One might even say they are the "Assembly Language" for connecting: [2]

[1] https://2020.programming-conference.org/details/salon-2020-p...

[2] https://resources.sei.cmu.edu/library/asset-view.cfm?assetid...

[3] https://www.youtube.com/watch?t=278&v=EKWGGDXe5MA&feature=yo...

Also, note that the use of a pipe from a Unix shell is very different from the use of a pipe in most (all?) languages. So the property you're interested in is not really the fundamental mechanism (which is quite a complicated object, with error conditions and required logic to handle i/o), but the abstraction presented by the shell.

Correct, no single interface does what the UNIX pipe did for command-line text-based IO-stream processing programs. In FOAM, we have about 20 standard interfaces, which correspond to your different glue types. Things like DAO (Data Access Object), Model, View, Factory, Parser, Adapter, Authenticator, Outputter, Validator, ... and as long as everything that does a certain thing, implements the corresponding interface, then everything can be piped together. Again, see: https://www.youtube.com/watch?v=S4LbUv5FsGQ or the longer more complete version: https://www.youtube.com/watch?v=PsFLlgrzn2E

To continue your analogy, if 95% of your house were made of glue, and 85% of the cost of your house was to buy glue, then that would be some cause for concern. That is pretty close to the truth for software.