Or, the one in which we hand-craft nano Unix tools using Bash functions.

As we saw in the previous post, functions obey stdio and we can mix and match them with built-ins (grep, sed, cat etc.) and other installed tools (like jq, pandoc, babashka etc.). We used functions to name parts of Douglas McIlroy’s pipeline and mess around a bit.

I tend to make libraries of pure functions that I can source in shell sessions and use just like any other shell tool, complete with tab-completion. e.g. bash-toolkit and shite.

Now we step back and try to build good intuitions about

• what functions are
• how to design good functions
• how to design programs with functions
• how to name them :)

Or, the one in which we “take apart” Douglas McIlroy’s pipeline from 1986.

Doing so teaches an object lesson about the essence of modular, composable, functional architecture. And things start to really heat up when it dawns on us, how a good set of standard parts can be used to express totally different ideas just by composing them in different ways.

(Edit 2022-03-10: speaking of lessons, how about the one in the appendix?!)

“Designing is fundamentally about taking things apart. It’s about taking things apart in such a way that they can be put back together. i.e. Separating into things that can be composed.”

• Rich Hickey, “Design, Composition, and Performance”, 2013

tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn | sed 10q

• Douglas McIlroy, Communications of the ACM, 1986

• The Pipeline that Douglas Built
• Take Apart! Semantics/Idioms -> Functions
• Play! Semantics -> Functions -> “Ooh, what if I…"
• Compose Again! Semantics -> Functions -> Play -> Grand New Pipeline
• Addendum: Remarkable aspects of Doug’s O.G. pipeline
• Appendix: an unexpected masterclass!
  • The danger lurking in the pipes
  • Backstory
  • Postscript

Previously: Shell ain’t a bad place to FP: part 0/N

Or, Supremely Functional Bash Programming, an exploration in N parts…

Once upon a time, while fiddling with a log processing shell pipeline, it hit me that the UNIX Way is a Surprisingly Functional Way, and so Functional Programming (FP) and Bash must be a natural fit. They fit. The world was never the same again.

Now I believe it so much, that I will go on a limb and assert that it is highly inappropriate to write imperative-style Bash when we can just as easily write supremely functional Bash. Why? Because it makes for supremely better Bash (more reusable, more composable, more scalable, more enjoyable).

Yes, I truly believe.

Yes, I’m sane.

No? Well OK, humour me…

• Obligatory mea culpa
• An outline of the “N” parts
• Prelude: Seeing the UNIX tools philosophy as a functional design philosophy
• “Screw that, show me your code”

In which we ponder the Functional Nature of Life, The Universe, and Everything. Please feel free to follow through the weeds, or jump straight to the bottom for my 2 nano BTC on the matter. (Or my current state of mind, at any rate.)

Disclaimer: I live in the Land of Lisp, meditate in the Church of Alonzo, and am ever-wary of The State. Only converts might find some entertainment value.

“For the love of State is the root of all evil: which while some coveted after, they have erred from Lambda the Ultimate, and pierced themselves through with many sorrows."

• Is it already suffusing your very being?
• Is it Mathematics?
• Is it being “declarative”?
• Is it being “data-oriented”?
• Is it about “Statelessness”?
• Is it about “managed” environments?
• Is it about following some discipline, and maybe automating it?
• My 2 nano BTC on the matter