Like for example Bill Atkinson's famous productive -2000 lines: https://www.folklore.org/Negat...
For decades I've been suggesting on-and-off that a big problem is too many commercial programmers writing too much code and making too much work for each other with an endless proliferation adhoc interfaces, each a new "standard".
As an egregious example, years ago I read somewhere that Microsoft Office embeds like six entirely different virtual machines. Maybe it has improved since with the CLR?
Except for proprietary competitive forces, how many spreadsheets, compilers, VMs, email clients, word processors, and databases do we really need? Even in the realm of games, how many game engines do we need? Granted, game content may be a different story, but even there how many low-to-medium-quality games do we need?
The same is true to an extent with the entire internet. How many low-to-medium-quality comments do we need to wade through on various topics?
Imagine if everyone was using, say, (optionally-typed) Scheme with a great set of libraries to write everything (including with "org mode" in a Scheme-powered emacs-like multi-tool with a calendar etc), and there was just no "JSON" or "JavaScript" or "XML" or "Office-compatible adhoc file formats" or even "C" or "Rust". Not saying that an optionally-typed Scheme is the best choice, but what a different computing world to imagine. Guess my Symbolics 3600 Lisp machine experience in the 1980s spoiled me. :-) And I have to admit that TypeScript on widespread Scheme-inspired JavaScript VMs with WebAssembly has moved the computing world a lot in that direction with pros and cons.
I know an obvious objection (as with Linux's endless front-end and distributions) is about choice, but at some point there is a tyranny of excessive choice, like "twisty little passage ways all alike".
https://en.wikipedia.org/wiki/...
"The Paradox of Choice - Why More Is Less is a book about overchoice written by American psychologist Barry Schwartz and first published in 2004 by Harper Perennial. In the book, Schwartz argues that eliminating consumer choices can greatly reduce anxiety for shoppers. The book analyzes the behavior of different types of people (in particular, maximizers and satisficers). This book argues that the dramatic explosion in choice--from the mundane to the profound challenges of balancing career, family, and individual needs--has paradoxically become a problem instead of a solution and how our obsession with choice encourages us to seek that which makes us feel worse."
I have no problem with people writing personal code for fun or learning or personal growth (which I highly recommend) -- the same way a person may play the piano as a hobby without expecting every time they play a tune the result needs to become a packaged commercial musical product.
The main thing I think about these days is how to have a much simpler tech ecosystem. Including for this reason outlined by Rich Hickey (author of Clojure) in "Simple Made Easy":
https://www.infoq.com/presenta...
====
Rich Hickey emphasizes simplicity's virtues over easiness', showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path.
We should aim for simplicity because simplicity is a prerequisite for reliability.
Simple is often erroneously mistaken for easy. "Easy" means "to be at hand", "to be approachable".
"Simple" is the opposite of "complex" which means "being intertwined", "being tied together". Simple != easy.
What matters in software is: does the software do what is supposed to do? Is it of high quality? Can we rely on it? Can problems be fixed along the way? Can requirements change over time? The answers to these questions is what matters in writing software not the look and feel of the experience writing the code or the cultural implications of it.
The benefits of simplicity are: ease of understanding, ease of change, ease of debugging, flexibility.
Complex constructs: State, Object, Methods, Syntax, Inheritance, Switch/matching, Vars, Imperative loops, Actors, ORM, Conditionals.
Simple constructs: Values, Functions, Namespaces, Data, Polymorphism, Managed refs, Set functions, Queues, Declarative data manipulation, Rules, Consistency.
Build simple systems by:
* Abstracting - design by answering questions related to what, who, when, where, why, and how.
* Choosing constructs that generate simple artifacts.
* Simplify by encapsulation.
====
Or, as a joke:
"Weinberg's Law: If builders built buildings the way (current-AI-enhanced-HR-staffer) programmers wrote programs, then the first woodpecker that came along would destroy civilization."
https://quoteinvestigator.com/...
