| There’s an interesting relationship too: The more advanced your programming tools are, the more complex your code can get before you hit your limit and need to refactor. It’s great up til that point, but once you cross the line you are in mind melting territory. I code in a tiny subset of JavaScript, wrap at 40 character width, without allowing any build tools, and only single-file repos. This probably seems insane to most, but it has a powerful effect: Complexity becomes painful very fast, and so I am forced to refactor aggressively, which causes me to put more effort into good separation of concerns earlier in my implementation process. It’s not for everyone, but if you enjoy the discovery of medium-sized single purpose modules, I would encourage you to try this, in your language of choice. Just pick a small set of native primitives and stick to them, and libraries written in (close to) the same subset. As a side note: Some people might be thinking, “huh? Rich type systems and control structures HELP you write single purpose code with clear boundaries.” To which I agree. But I said “medium sized”. Rich toolsets will push you towards a combination of very small and very large API surfaces: small modules that do one arcane abstract thing that has no immmediate value, and then a huge surface which is the entire set of all of those small modules. Modular subset programming makes both small and large modules awkward... small modules are awkward because you need to include them over and over. Large modules are awkward. It squeezes you from both sides into finding concerns that are good brain-sized nuggets. |
I like this idea! I've sort of gravitated toward it myself -- inspired by the exceedingly clear pieces of code that can be found in older books on programming -- but I have yet to make it an expölicit purpose of mine. I may want to try that!