Small Isn't Simple: Why Unix Pipelines Hide Their Complexity

Drawing on Rich Hickey’s definition of ‘simple’ as having a single braid rather than many things twisted together, this essay argues that the software world routinely confuses simplicity with smallness. A Unix pipeline that counts word frequencies looks clean and concise, but it is actually coupled: because there is no native ‘frequencies’ operation, you reach for ‘sort | uniq -c’, which welds aggregation to ordering. The cost only becomes visible when requirements shift. Asking for output in original file order is a trivial change in a Clojure version but forces a mess of temp files, opaque regexes, and joins in Bash. The tools are small, but they are not simple.

The inverse also holds. Google Drive for Desktop is an enormous program — platform file watchers, network sync, conflict resolution — yet it feels simple to the user because its features are decoupled from one another. The author locates real complexity in unnecessary coupling, and illustrates it with Rust structs, which bind type-checking to a fixed data representation and so make iteration or reflection awkward. Clojure, by contrast, treats structs as annotated maps and pushes schema checks into a runtime library (Malli), keeping data representation, type safety, and introspection independent. Typed Racket achieves the same separation at compile time via macros.

The practical takeaway: smallness is a reasonable goal only when resources are scarce — a solo maintainer, constrained hardware, limited support. Simplicity, meaning the absence of gratuitous coupling, should be the goal always, because coupling hurts both maintainers and users with little upside. Getting there is the hard part, demanding a strong mental model, taste that is difficult to teach, and a willingness to write the genuinely hard, decoupled thing — the declarative model that CSS and SQL exemplify.