diff options
Diffstat (limited to 'blogs')
| -rw-r--r-- | blogs/2026-10-09-simple-made-easy.md | 70 |
1 files changed, 70 insertions, 0 deletions
diff --git a/blogs/2026-10-09-simple-made-easy.md b/blogs/2026-10-09-simple-made-easy.md new file mode 100644 index 0000000..9399da0 --- /dev/null +++ b/blogs/2026-10-09-simple-made-easy.md @@ -0,0 +1,70 @@ +--- +title: "Simple Made Easy" +description: "" +date: 2026-10-09 +--- + +Due to a recent conversation I had, I remembered a talk I watched a while ago that was really +influetial to how I view software develop and life in general, so I thought it'd be valuable +to write this short blog to hopefully make more people aware of it. + +The original talk: https://www.youtube.com/watch?v=SxdOUGdseq4 + +How I discovered the talk: https://www.youtube.com/watch?v=8eXiWkPSb50 + +## Simple Made Easy + +As a non-native English speaker, I always treated "easy" and "simple" and "complex" and "hard" as +just synonyms to each other, but there is actually a very important distinction between them. + +Simple <-> Complex +Easy <-> Hard + +Simple and Complex come from Latin, where Complex used to mean braid, as in many interleaved things +while Simple used to mean 0 braiding (no braid, no interleaving)[^1] + +Whether there is interleaving, and how much interleaving there is, is a completely objective +question, and so is Simple and Complex, they are objective. + +Easy and Hard on the other hand, are subjective, for example, German is very Easy to Germans, or +languages that are similar to it, and Japanese is Easy for a Japanese person, yet a German person +finds Japanese Hard, and a Japanese finds German Hard, hence it's subjective. +While kids learning language learn it all at about the same age, showing the Complexity of the +languages themselves is indistinguishably similar[^2] + +When we say a codebase is Complex or a programming language is Simple, we specificaly don't mean +how Easy or Hard is it to learn or understand, we specifically mean _how much interleaving there is_. +And in a programming context, 2 concepts are considered interleaved if it's impossible to understand +them separately, they must be looked at together to understand them. + +Assembly language is generally very Simple[^3] -- there are a few main instructions, which can be +looked at separately, which do very basic operations that are Easy to reason about, yet, assembly +is notoriously difficult to read and write, while a language such as python is way more Complex, +there there is a lot more going on even in a single `a + b` expression, it is a very common +"beginner language" due to how Easy it is to learn. + +"Coupling" is the act of _interleaving_ things, making them intertwined, having to consider them +together to understand them, while "Decoupling" is the opposite, taking things that used to be +interleaved and separating them so they can be looked at independently, "Separation of Concerns". + +I'd like to introduce a new concept, "Unnecessary Complexity" and "Inherent Complexity", to quote Terry Davis - +"An idiot admires Complexity, a genius admires Simplicity". +As the name suggest, Unnecessary Complexity is unnecessary, it is additional complexity layered +on top, while Inherent Complexity is instrinc to the problem at hand, it cannot be avoided. +While real languages developed naturally, they have obtained a bunch of unnecessary complexity +while something such as the Quadratic formula is entirely filled with Inherent Complexity, or in +other words, it's impossible to simplify it, it cannot be made more simple. + +To end it on a programming related note, I'd leave you with this quote: + +> (Unnecessary) Complexity is the root of all evil + +[^1]: this is from memory, I might have butchered the explanation a bit, watch the original talk. + +[^2]: + All languages... except Danish, which shows slower development in children compared to other + languages, likely due to the difficulty identifying word boundaries. + +[^3]: + The basic instruction set needed for turing complete programs (move, jump, load, store, etc), + I, of course, don't mean the entirety of, say, x86_64 is simple. |
