"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'" - <a href="https://www.infoq.com/presentations/Simple-Made-Easy/" rel="nofollow">https://www.infoq.com/presentations/Simple-Made-Easy/</a>
The quote of "If I had more time, I would have written a shorter letter" has been quoted so often that it is arguable who said it first, but it is definitely at least a 300+ year old concept.<p>Simplicity takes effort. It takes time. And you often cannot write simple software in the first version because you are designing it as you go. Simplicity comes from maturity both in the product design and the development staff, and is a long term goal.<p>It is not something that you achieve by critiquing individual PRs, but by insightful long-term thought into how to solve your problem with your code, and many refactors over time.<p>It is wise strive for simplicity in all code you write, but wiser to have the patience to let it develop over the lifecycle of your product.
> For example, dynamically typed languages like Python (or Ruby, Lisp, etc.) are easy and pleasant to write. They avoid the difficulty of convincing a compiler that you’ve written your code correctly, but they’re harder for a new team member to comprehend: you’re trading fluent writing for more laborious reading.<p>I feel like this misses the point of high-level languages. In my experience, higher-level code is easier to read <i>and</i> write. For one thing, there's simply a lot less of it.<p>Lisp isn't more productive just because it's easier to "convince a compiler that you've written your code correctly". After all, if you haven't written it correctly, the <i>user</i> will notice right away, too!<p>> Short functions, methods, and classes are quick to read, but must either be built of many lower-level functions or themselves comprise parts of larger compositions in order to accomplish anything. You’re trading away locality in favor of concision.<p>That's how languages work. You used the word "concision" rather than spelling out what it means in tiny words, and count on us readers to know it, or look it up. That's usually a win, especially if we have a standard set of words.<p>Again, this is where higher-level languages win big. You can encode higher-level concepts. I can write MAP or FILTER and people know what they mean. Or if my language doesn't have those, I can write them.<p>Just because you can explain something with lots of tiny words does not necessarily make it easy for anyone to understand: <a href="https://www.muppetlabs.com/~breadbox/txt/al.html" rel="nofollow">https://www.muppetlabs.com/~breadbox/txt/al.html</a>
There was a wise thing along the lines of "to build a simpler system, start with more powerful (and complex, by necessity) building blocks"... I think it was Alan Kay who said this or something very similar.<p>Worst thing is that "simple" languages like Go force you to mix up "business logic" with "plumbing/infra logic" with "error handling logic" if you try to be idiomatic... I know that for security crucial code you might want to see all error paths next to a piece of code, for for the <i>other majority of the code</i> I want error handling tucked away in different system, and also the business logic factored out in some other very generic one that doesn't care about actual implementation of infrastructure.<p>Sure, if <i>infrastructure IS your very product</i> like Go's use case probably is, then it probably makes sense to not have features for such separation.
I once worked on a system where the senior engineer on the project had a dogmatic definition of simple.<p>It was an MVC web application. He insisted that having any form of flow control or logic in views was too complex - it was simpler to regard all logic as application logic and put it in the controller. This meant that instead of one controller being able to drive multiple views, something as straightforward as rendering a table a row at a time required a dedicated controller action.<p>That engineer's definition of simplicity produced an explosion of complexity in the codebase. That was when I came to understand that hand drills may be simple, but power drills are <i>very</i> useful.
The article refers to "the much-abused YAGNI" and links to another blog post that goes into detail. Apparently some people take YAGNI to mean never anticipate anything. Is that your experience? I've always taken it as a tie-breaker when you're unsure whether to anticipate or not, and I've had the impression that others take it the same way.<p>Overall I like this article and the YAGNI one it links to.
I think the confusion around simplicity is in what terms a thing is simple.<p>For example, 2 pieces of text can be simple in 2 different ways:<p>First text is long but uses fewer words in vocabulary. So it is "simple" in a sense you need to learn only few words to read it.<p>Second text is short but uses richer vocabulary to describe things with fewer words (syntactic sugar). It is "simple" in a sense you only need few words to describe stuff, but more "complicated" because you need to learn more words.<p>"Neat" code can be "simple" to maintain. "Messy" code can be "simple" to implement.
Go's parsimony is about cognitive load. I've programmed for 30 years and am an expert in complex languages like C++. I find that when I write Go my mind spends far more time thinking about the problem than the language, which I like.<p>The language is modern and powerful enough to spare the programmer from some of the worst drudgery (unlike C) and is much more inherently safe, but it's not a jungle gym of complicated constructs and difficult quasi-mathematical concepts that (while interesting) detract from the task at hand.
If Buttercup and Westley from _The Princess Bride_ were working on software, the conversation might have gone something like this:<p>Buttercup: I balk at your complexity!
Westley: Software is complexity! Anyone who says otherwise is selling SaaS.
> The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstracts away its essence.<p>- Fred Brooks, <i>No Silver Bullet</i>, 1986<p>> Complexity <i>is</i> the business we are in, and complexity is what limits us.<p>- Fred Brooks, <i>No Silver Bullet Refired</i>, 1995
> The problem with these approaches is that “simplicity” never gets a rigorous definition<p>Last I counted there were 48 proposed methods of defining simplicity. I created one as well and am biased and think it is the best way to rigorously define simplicity/complexity: <a href="https://github.com/treenotation/research/blob/master/papers/paper3/countingComplexity.pdf" rel="nofollow">https://github.com/treenotation/research/blob/master/papers/...</a>
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."<p>By simplicity, we mean frugality.<p>If you can implement something without adding a ton of dependencies, abstraction layers, and design patterns, it will be easier to understand and debug.<p>YAGNI is everything but abused.
One analogy I like for software problems is knotted string. You approach the problem, loosen some things up, try some approaches, and sometimes you get lucky and shake things loose.<p>Other times, you have to cut the string and you lose fidelity in your solution.<p>Other times, you can only move the problem around so it looks simple to the user; there's still a knot there, but it may be hidden in the back end.<p>This isn't the only analogy, and it's incomplete, but I still like it.
I classify easy/hard as<p>1) Concise vs. Verbose 2) Straightforward vs. Confusing 3) Flexible vs. Inflexible 4) Efficient vs. Inefficient<p>The important thing about these 4 is _they get along horribly_. The most concise solution is often confusing, inflexible, and/or inefficient in many respects. I should also note that straightforward-confusing is the hardest one to measure objectively.
The two perspectives that I often find at opposite poles when proposing simplicity is that of the developer vs. that of the user. Generally what's simple for the user drives less simple solutions for the developer and vice versa. It's not always possible, but when it is, I strive to find the solution that ends up being dead simple for both.
Let me answer this once and for all:<p>> What are we optimizing for?<p>You mean who are we optimizing for. For the guy who has to understand and maintain this code 2 years from now. (This guy could in fact be you yourself).<p>Thats why I like Go. And C, now that I think about it...
I agree with the author that the simplicity of learning the language is not the only type of simplicity. There are other types of simplicity like the simplicity of how consistent the language is. For instance, I've felt for some time that Python has become too complex. I started out quite simple, and there are now like 3-4 different ways to write a method signature.
Steve Jobs created many things and also destroyed a many. One of them is the openness of platforms and another is what I'd call <i>delightful complexity</i>. Simplicity is not always a joy and lot of overjealous wanna-be-Jobs seem to forget about that. I do want all those buttons and choices in my music app that let's me be expressive and opiniated about my taste. And I definitely want generics!<p>A bigger issue is that a many times simplicity for you is not simplicity for others. This often comes back to haunt you in software design. You might think that complex design is not good for you and you may strive to simplify internals even though it might make life awkward for users of your creation. I feel a lot of such decisions have been made in designing Go. Overjealous pursuit of simplicity has led its designer to keep compiler less complex, internally beutiful and work of art but at the expense of external usability for its users. This article captures the sentiment pretty well.
I don’t think it’s a good idea to introduce complexity to the definition of simplicity and I think this is what the author is trying to do.<p>It’s completely backwards. The whole point of calling for simplicity is to make you think about whether there is a simpler way to express yourself that still solves the problem at hand. This might be a hard task, but it’s not a complex one.
I think this piece risks being interpreted as saying that simplicity is not important.<p>The fact that simplicity is hard to achieve will be obvious to anyone who has ever truly tried to achieve it.<p>Personally I would worry far more about people thinking simplicity is a fools errand and so not trying hard enough to achieve it, rather than people thinking it might be easier than it is.
TFA seems to build upon confusion of how "simplicity" is defined.<p>It's easier to compare it against "complexity" which is the sum of parts; e.g. a complex machine, so "simplicity" must be attributed to an atomic design of "the smallest part which cannot be broken any further"; i.e. think of a simple machine like a lever.
I'm usually in favor of the good old KISS principle, but I've experienced few situations where "simple" ready made solutions were chosen on the basis of few demos showing "how simple it is to use this or that feature" over writing in-house scripts in general purpose language like python. In all of those unrelated situations there was trouble later when it transpired that indeed it is simple to use feature A, B and C that works exactly as original author's wanted, but the moment you want to tweak something manipulating the whole thing is terribly inefficient, and/or complex. In the end tweaking those simple ready made solutions required more work than re implementing the whole thing from scratch would take in the first place...
I would define simplicity as "the approach that minimizes cognitive load while meeting all other objectives"<p>I would hope that people with the same objectives would agree on simplicity for that domain.<p>Examples:<p>Need a lot of machine control, direct memory control (page alignment, cache alignment, shared memory, numa, etc) interact with system calls directly, interact with hardware, and security is not important in the domain (e.g. private hpc cluster behind a firewall)<p>C is probably the simplest<p>Need to quickly prototype something medium sized that involves non-trivial data structures or needs to interact with an http server. And you don't care about performance.<p>Something like Python is probably simplest<p>Etc etc etc<p>By contrast.. try doing the former with Python, Java, etc and see how much additional cognitive load you have to add.. ever try the later with C.. no fun.
I like to take an information theoretic, model-problem fit stance on simplicity.
It's useful to reason about it in terms of overfitting vs underfitting, over-abstraction vs under-abstraction, high resolution fit vs low resoltion fit, and in terms of cross entropy between the knowledge embedded into a software system and the information relevant to solve the corner cases of the problems (<a href="https://medium.com/@b.essiambre/product-market-crossfit-c09b019188f3?source=friends_link&sk=5a57eddd18dd948ebb512afb40a21667" rel="nofollow">https://medium.com/@b.essiambre/product-market-crossfit-c09b...</a>).
Well tuned knowledge is not an easy thing.
My take on simplicity is how strong the abstraction layers are. Using a web framework to show "hello world" versus making a video card driver and make it show "hello world" on the screen.<p>A world class athlete makes something hard look easy. So just because the code looks simple, doesn't mean it is easy.<p>Remember when you first learned how to code, or learned some new concept, and now you can't remember what was so difficult about it?<p>Just one line of code might touch several computers, hardware components, with several software layers. Everything has to go right, all the way down to atomic level. Nothing is simple. It just appears to be simple through strong abstraction layers.
Recognizing simplicity requires familiarity with complexity.<p>- - - -<p>FWIW, Category Theory provides a mathematical formalism for determining when your system is "as simple as possible, but no simpler".<p>- - - -<p>> “average programmers” have difficulty understanding complex languages<p>That's not pejorative IMO, that's practically tautological: If "average programmers" have difficulty understanding a language, isn't that an indicator that it might be too complex? Anyhow, trawling though e.g. Stackexchange provides adequate evidence, IMO. Or a thread about Haskell with all the people complaining about how hard it is to understand FP, etc.
There are several key "rules of thumb" to keep in mind, and they are often contradictory. Knowing how to weigh them well against each other takes experience in both the domain and IT in general.<p>Another rule of thumb to add is "don't obsess on a <i>single</i> rule of thumb; they are all important."<p>In my experience "keep it approachable" often overrides "less code" and DRY. Maintenance staff changes and you probably cannot control the quality of the next maintainer such that if your code requires an abstraction guru to figure out, you may put your org in a difficult spot.
"There are two ways to design a system: make it simple enough to be obviously right, or make it complex enough not to be obviously wrong" -- Charles Hoare
Simplicity cannot be a goal in itself. Is the dashboard of a F35 worse than the dashboard of a car -- because it's less simple? It's the same thing with programs and programming languages. Computers are universal devices, they can be F35s or just basic cars. The important thing is 'fit for purpose', which is more elusive and not so amenable to simplistic ideological statements.
Here's a few more if anyone is compiling a list:<p>Dieter Rams -- <a href="https://www.vitsoe.com/gb/about/good-design" rel="nofollow">https://www.vitsoe.com/gb/about/good-design</a>
John Maeda -- <a href="http://lawsofsimplicity.com/" rel="nofollow">http://lawsofsimplicity.com/</a>
Here's a few more if anyone is compiling a list:
<a href="https://www.vitsoe.com/gb/about/good-design" rel="nofollow">https://www.vitsoe.com/gb/about/good-design</a>
<a href="http://lawsofsimplicity.com/" rel="nofollow">http://lawsofsimplicity.com/</a>
Simplicity is objectively measurable. Here is a practical suggestion, though directly applied to mechanical engineering is readily adaptable to application design.<p><a href="https://www.sciencedirect.com/science/article/pii/S2351978918302361" rel="nofollow">https://www.sciencedirect.com/science/article/pii/S235197891...</a><p>One way to think about simplicity is to accomplish the greatest number of business objectives with the fewest number of abstractions. As others have said, that isn't easy. It takes increased effort to achieve simple.
There is a lot of noise in the article (like mentioning Rob Pike's take on syntax highlighting), but mostly it seems to be a "I like Rust and Haskell, and don't like Go" type of articles. Could've been a single tweet.<p>Attempt to explain the dangers of simplicity is lost in vague sentences like "Rust has different concept of simplicity -> Rust authors wanted to protect from memory errors" or TBU (True But Useless) phrases like "every choice has a cost"/"everything is a tradeoff".
The link about Go with quotes by Rob Pike lets me think that maybe Abc.xyz made Go like they did because they wanted to be able to have some sort of AI generate code eventually.