The command line is an absolutely amazing standard where a lot of hard things are just solved by the underlining layers in a way that is both very simple to use and very flexible.
As the article said, some times a complicated problem has a simple genial solution.
Thanks, I enjoyed this and it rings true. This abstract concept of "space" getting filled up thoughtlessly, and that "space" being created by unnecessarily breaking things up into smaller parts that don't really need to be separate, makes a lot of sense and I think I've seen this happen.
The article stops short of proposing a clear plan for how to handle the opposite problem, though: Entrenched monoliths. Once a class (or other abstraction) has grown for long enough (e.g. perhaps someone has read this article and is trying to avoid unnecessary complexity of code structure), it can become very difficult to break it up.
Related: https://news.ycombinator.com/item?id=40711661
Space and time ... "work expands so as to fill the time available for its completion" https://en.wikipedia.org/wiki/Parkinson%27s_law
At least complexity seems bounded, Bureaucracy, in contrast, expands to meet the growing needs of the Bureaucracy.
So complexity is liquid and bureaucracy, a gas?
Bureaucracy is complexity vapourware?
Very true. As a followup, I think it's worth pointing out that CLI applications in particular can cram a lot of functionality into very few LOC.
Last night, I read through the source code for `cat` (yes, that `cat`) and it was only about 800 lines of fairly breezy C: https://github.com/coreutils/coreutils/blob/master/src/cat.c
And a tiny CLI tool I use every day, several times a day, for learning Finnish, is about 200 lines of Python: https://github.com/hiAndrewQuinn/finstem
Jos tarvitset apua, niin heittää viesti.
Kiitos paljon, saatan!
The command line is an absolutely amazing standard where a lot of hard things are just solved by the underlining layers in a way that is both very simple to use and very flexible.
As the article said, some times a complicated problem has a simple genial solution.
Thanks, I enjoyed this and it rings true. This abstract concept of "space" getting filled up thoughtlessly, and that "space" being created by unnecessarily breaking things up into smaller parts that don't really need to be separate, makes a lot of sense and I think I've seen this happen.
The article stops short of proposing a clear plan for how to handle the opposite problem, though: Entrenched monoliths. Once a class (or other abstraction) has grown for long enough (e.g. perhaps someone has read this article and is trying to avoid unnecessary complexity of code structure), it can become very difficult to break it up.
https://en.wikipedia.org/wiki/Space-filling_curve
A huge spaghetti monolith is much better than a huge spaghetti collection of micro services.