3 ms·

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 piec

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-oriented-programming.html 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...)

PaulDavisThe1st 5y ago
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.
- mpweiher 5y ago
  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-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p... [2] https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=12137 https://resources.sei.cmu.edu/library/asset-view.cfm?assetid... [3] https://www.youtube.com/watch?t=278&v=EKWGGDXe5MA&feature=youtu.be https://www.youtube.com/watch?t=278&v=EKWGGDXe5MA&feature=yo...
PaulDavisThe1st 5y ago
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.

PaulDavisThe1st 5y ago

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.

mpweiher 5y ago
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-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p... [2] https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=12137 https://resources.sei.cmu.edu/library/asset-view.cfm?assetid... [3] https://www.youtube.com/watch?t=278&v=EKWGGDXe5MA&feature=youtu.be https://www.youtube.com/watch?t=278&v=EKWGGDXe5MA&feature=yo...

PaulDavisThe1st 5y ago

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.