The word simple is used here a way I'm having trouble wrapping my head around.<p>This specific usage appears to come from this linked talk, Simple Made Easy:<p><a href="https://www.youtube.com/watch?v=SxdOUGdseq4" rel="nofollow">https://www.youtube.com/watch?v=SxdOUGdseq4</a><p>My reaction to the Unix pipeline was that, the reason it exploded in complexity is because the pieces were <i>too</i> simple. They were insufficiently expressive.<p>But the word is used in a different way here, and I'll have to watch the talk to understand what exactly is meant. (Something like orthogonality?)
Great piece, very straightforward examples, although I did have to squint for quite a while to grok the Closure portion.<p>I am currently building a piece of <i>very</i> modular software and it has been the hardest-to-design project of my entire career. I would never be allotted this amount of time-effort at any job I have held to make something this robust and clearly defined. Many aspects of this project have taken 3-5 rounds trying-and-trashing to get an abstraction that is uncomplicated.<p>This is precisely why vibe coding is so successful for building tiny isolated scripts, and so disastrous for anything else. It's just really dang hard to build something large <i>and</i> simple.
Important to note as well, is that "simple" isn't "lesser" or "dumber", it can be "more" and "wider", yet still "simpler".<p>Unexpectedly, Rich Hickey explains it best, watch the "Simple Made Easy" talk if you haven't before, one of the few talks I probably watch bi-yearly: <a href="https://www.youtube.com/watch?v=SxdOUGdseq4" rel="nofollow">https://www.youtube.com/watch?v=SxdOUGdseq4</a><p>Few things, concepts and ideas have changed as much of my programming mind as Hickey's talk and ultimately Clojure have done over the years.<p>Wish we had new amazing Hickey talks to link to, maybe it seems he's about the hang up the hammock perhaps?
This argument is just based on "I wish the things I need to do were baked into the language." It's nice when that happens, but once programs get sufficiently large and complex, it stops mattering--you're dealing with domain-specific concepts that have zero built-in helpers and you're just building everything yourself regardless.
The examples in the essay are perhaps not specific enough - they do gesture in the direction of the author’s point, but they also admit other valid interpretations like your own. I think the Rich Hickey talk “Simple Made Easy”, which this post is based on, makes the point more clearly and precisely.<p>(For what it’s worth, the point of both this essay and the aforementioned talk is that programs <i>do not have to get complex</i>, even when they get large, even when it gets hard because there are no more easy / close-at-hand / familiar helpers in the language to tackle the domain specifics. In support of this point I will note that Rich Hickey is the creator of Clojure, a language in which “building domain-specific helpers yourself” is very nearly idiomatic.)