I recently watched a video [0] that contrasted all of the OO Design Patterns with Functional Programming equivalents. After reading about how this author wants to make "glue" code "first class" and how the Unix pipe operator is an example of single-character-glue-code, my thoughts immediately went to the aforementioned video presentation. Perhaps my "glue code" is simply gold-old "function composition"?<p>[0] Scott Wlaschin "Functional programming design patterns" <a href="https://vimeo.com/113588389" rel="nofollow">https://vimeo.com/113588389</a><p>[Edit] Spoiler alert: each of the design patterns reviewed and contrasted in the video I mentioned seemed to "disappear" in FP since the equivalent is simply to use functions and/or function composition. Recently transitioning from C# to F# for my .NET Core projects, I felt the "glue code" the author mentions disappear in a similar manner with greatly-reduced code bloat.
This is a really excellent topic to bring up -- the fact that glue code grows essentially quadratically.<p>Has it been a topic of exploration much in computer science? Any literature?<p>After all, sometimes it feels like <i>most</i> of the programming you wind up doing is glue code.<p>On the one hand, it feels like the kind of thing that there should be better tools for at least writing it <i>declaratively</i>, and let the computer turn it into code.<p>But on the other hand, it feels like a lot of that already <i>is</i> taken care of. E.g. CSS is essentially declarative glue code for what would otherwise be a huge number of painting and layout lines of code.<p>And most of the glue code I myself wind up writing winds up being written specifically to handle various constraints around memory, disk space, etc -- e.g. how to import a protobuf that changes every 30 seconds and convert it to 10,000 rows in a live database in a way that's performant -- and so isn't as amenable to something simple.<p>But I do still wonder if there's more opportunity here for more declarative coding when it comes to "glue".
Treating shell scripts as first class has taken me on a bit of a journey over the last decade:<p>- Learned from shunit2 that it's possible to write solid shell scripts, and that writing test code in shell scripts is hard to learn but doable. Bonus: I'd rather write the test script in a more easily debuggable language, such as Python.<p>- Bash has many more surprises in store for you than any other mainstream language. How $IFS affects things, how looping over files is either completely trivial (`for file in *`) or damn near impossible (`while IFS= read -d '' -r -u 3; do …; done 3< <(find … -exec printf '%s\0')`) based on the pattern you want to match, exit codes of arithmetic assignments, all the tricks to deal with not having exceptions, how `ls` is unsuitable for scripting despite being ubiquitous, locales, variable flags, and so on.<p>- `shellcheck` is fantastic, especially for including URLs to more information about each warning.<p>- Greg's Wiki[0], despite being hard to find in search engines, is the best place by far for learning about Bash.<p>- Writing a shell script to do some fast, asynchronous processing is maybe 30-100 times faster than writing the same in Python, but getting the nitty-gritty details right is about 30-100 times harder as well.<p>[0] <a href="https://mywiki.wooledge.org/" rel="nofollow">https://mywiki.wooledge.org/</a>
One patten I've seen to address this is to define a "plugin architecture" where disparate components are integrated into the main system via fixed "sockets". The sockets themselves are generic as is the glue code that attaches plugin and socket.<p>This does create a lot of boiler plate, but that boiler plate is predictable and uninteresting, and a good candidate for code generation.
Isomorphisms.<p>They let us think about things very easily, and express ideas very cleanly.
When I Think about a system, I treat isomorphic things as almost exactly the same.<p>But when actually writing code, I need to fully spell out the isomorphism. That is glue code.So the code becomes my clear ideas, with awkward glue in between.<p>My dream is a compiler that knows these isomorphisms, and automatically implements them with decent (perhaps guided by me) optimization.<p>This way, the idea in my head and the code in my editor start looking like eachother a whole lot more.
I'm not understanding the importance of distinguishing glue code from non glue code. It's still work that needs to be done whether it's "first class" or not. That difference boils down to who writes it, not the fact that it is present in the code base (as measured by LOC, which the author measures and attributes the cause of high LOC to glue code)
I read this article but am having a hard time understanding the point in concrete terms. What does it mean to make invisible glue code first class? How would reduce the #LOC, which is something the author mentioned many times?
It's worth researching the demoscene[0] and how demos that looked <i>very complex</i> were made with as few lines of code as possible. Every byte was accounted for and nothing went to waste.<p>This is a common thing in games and Super Mario even re-used the cloud sprite for the bushes[1]<p>Now we have to deal with gargantuan Electron apps that hog your PC's resources for housing what essentially is a lightweight webapp.<p>[0] <a href="https://en.wikipedia.org/wiki/Demoscene" rel="nofollow">https://en.wikipedia.org/wiki/Demoscene</a><p>[1] <a href="https://www.todayifoundout.com/index.php/2010/01/the-clouds-and-bushes-in-super-mario-bros-are-the-same/" rel="nofollow">https://www.todayifoundout.com/index.php/2010/01/the-clouds-...</a>
I posted this to Lobste.rs when this story hit there and I'll post it again here:<p>> The pipe is one-character glue: “|”.<p>I think that this is mistaken. Pipe makes it easy to connect the output of one program to the input of another, but that is not the same as “gluing” them - you have to do text processing to actually extract the fields of data out of the output from one command and convert it into the right format for input to another.<p>This is why you see tr, cut, sed, awk, perl, grep, and more throughout any non-trivial shell script (and even in many trivial ones) - because very, very few programs actually speak “plain text” (that is, fully unstructured text), and instead speak an ad-hoc, poorly-documented, implementation-specific, brittle semi-structured-text language which is usually different than the other programs you want them to talk to. Those text-processing programs are the Unix glue code.<p>The explicit naming of “glue code” is brilliant and important - but the Unix model, if anything, increases the amount of glue code, not deceases it. (and not only because of the foolish design decision to make everything “plain” text - the “do one thing” philosophy means that you have to use more commands/programs (which are equivalent to functions in a program) to implement a given set of features, which increases the amount of glue code you have to use - gives you a larger n, which is really undesirable if your glue code scales as n^2)