15 ms·

The Danger of “Simplicity”

279 points by emrehan 7y ago

ftvy 7y ago
TFA seems to build upon confusion of how "simplicity" is defined. 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.
- mattbuilds 7y ago
  I’ve actually been writing a post about just this concept. When I think simple, I think solving the problem in a way that adds value and doesn’t have unnecessary overhead. I think it’s important to highlight the differences between simple, complex, and complicated (like from the Zen of Python). The basic idea is that if possible you want a simple program, but most problems aren’t that’s simple. So the solution needs to be complex with lots of parts. Those parts can and should be simple though. Complicated means adding things that don’t any value. Maybe it’s using containers on a CRUD app that doesn’t need it because it looks good on a resume.
- mbrock 7y ago
  I think Ousterhout’s pragmatic definition of complexity is the best one when discussing actual code bases: complexity is anything that makes the system hard to change, taking into account how often the relevant part needs to change.
  - frou_dh 7y ago
    Hard to change is subjective. Maybe something you found hard to change, your colleague would have no trouble with. And vice versa.
    - rob74 7y ago
      Yeah, some colleagues have absolutely no trouble changing any code... and then it starts breaking for some edge cases that they weren't aware of :D
    - mbrock 7y ago
      Yeah, with this definition, complexity is something you notice as a working team, not something you can directly measure with syntactic criteria (of course syntactic criteria may correlate with the complexity).
nnq 7y ago
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. 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 other majority of the code 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. Sure, if infrastructure IS your very product like Go's use case probably is, then it probably makes sense to not have features for such separation.
- friendly_chap 7y ago
  > error handling tucked away in different system I'm not sure that can ever be done. I agree Go could use some syntactic around error handling but I think even modern software is incredibly flaky and Go is a step in the right direction. It's tiring to think about all the failure cases but it might lead to a world where the ATM gives me money instead of Windows BOD.
- Kye 7y ago
  I experienced a good example of this recently when trying to decide between Bitwig and an upgrade of Ableton Live Lite to Suite. Suite comes with a full-featured audio programming environment called Max for Live. It has some high level devices for common functions, but you can go very low level and make just about anything. The building blocks are all very simple and basic: oscillators, math functions, routing, etc. Bitwig's Grid takes a different approach with a small number of powerful building blocks. The range of possibilities is smaller, but you can be more productive if the thing you want to make is composable from the available devices.
- fauigerzigerk 7y ago
  >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... How so? Can you not write modular code in just about any language? I'm not saying programming languages don't matter, but in terms of seperating business logic from plumbing I don't see huge differences. I also don't think you can seperate errors from the rest of your code on the same level of abstraction. Business logic errors such as "account overdrawn" are business logic. Plumbing errors such as a broken network connection are plumbing. The only errors that can and should be kept separate are bugs that need to be fixed.
ds_ 7y ago
"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'" - https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
- blondin 7y ago
  wouldn't say simple is the opposite of complex though? especially when talking about software systems or other systems in general. what i am thinking is that some complex systems can be made of very simple components. the best example is our complex brain being made of simpler components working together. maybe the opposite of complex is chaotic? i don't know...
  - cuddlecake 7y ago
    I imagine that a software system that is made of simple components can still be complex. So I'd still go for simple vs complex
  - ajdegol 7y ago
    Simple systems can indeed be made of complex components; however it is a measure of interconnectedness. The key concept is that we can only hold a finite amount of complexity in our heads at any one time, and so if we can minimise that we can be more efficient and effective. The analogy is a lego castle vs a wool castle. A lego brick is very simple and contained, and from this you can build wonderful structures; in addition if you wish to change out a portion it is easy to do because changing on part of the system (i.e. implementation) doesn't affect the rest so long as the contract between components is maintained. Contrasting: should you pull on a thread in a wool castle it will affect other parts of the castle. A lot of software is like this, which makes it very hard to reason about.
    - roenxi 7y ago
      And the Lego analogy works in particularly nicely considering just how much effort, precision and design work needs to go in to making the blocks simple [0]. This is a nice analogy for how keeping software components simple and making them interface cleanly is a difficult task. [0] https://en.wikipedia.org/wiki/Lego#Design https://en.wikipedia.org/wiki/Lego#Design
anoplus 7y ago
I think the confusion around simplicity is in what terms a thing is simple. For example, 2 pieces of text can be simple in 2 different ways: 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. 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. "Neat" code can be "simple" to maintain. "Messy" code can be "simple" to implement.
- collyw 7y ago
  >"Neat" code can be "simple" to maintain. "Messy" code can be "simple" to implement. I was thinking something similar recently. Good code should take the next developer less time / effort to understand it than it took the original developer to write it (assuming similar levels of ability).
  - bonoboTP 7y ago
    > the next developer And that's often you, just in a few months' time.
    - collyw 7y ago
      True. And as I mentioned in another comment, I learned the most by building a system from scratch and maintaining git for 4 and a half years. If I couldn't understand a bit of code that had written more or less straight away, then it was usually time to refactor it.
- weego 7y ago
  I don't think there is a confusion around simplicity. It just seems like strawman blog filler and this article is no different.
- zzzcpan 7y ago
  What you are describing here is approaching usability. And when it comes to usability simplicity doesn't matter on its own, there are four other things to always keep in mind together with simplicity: consistency, flexibility, universality and familiarity. And then understanding what users need your piece of text for applying those concept to come up with the best balance to make users think and learn as little as possible throughout the whole lifecycle of the use. Take, for example, familiarity. If you use a richer vocabulary that your users already familiar with, they certainly wouldn't need to learn more words and the piece with richer vocabulary would be easier for them to go through, than the longer piece with poorer vocabulary. Simple doesn't mean more usable, but it's a pretty straightforward concept to understand, there is no confusion around it.
codingdave 7y ago
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. 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. 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. 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.
- nessunodoro 7y ago
  "Making things simple is hard work." - Rich Hickey When I think of the simple vs complex bifurcation I think of fractals, a "simple" set of rules expressed in a complex way. The complexity arises from their expression/expansion iterated over time, but the rules that govern that expression are economical and compact. Think of an acorn: the encoding of a tree is all there. Its self-similarity, recusively expressed, creates the complex output of a tree. But nature always prefers the most economical solution because in the physical universe, resources are limited. It might make more sense to s/simple/economical/.
- cytzol 7y ago
  > "If I had more time, I would have written a shorter letter" I don't like seeing this quote in the context of programming. Sure, they're both about writing, but in different settings. A person who writes a letter has one goal: for the intent of the letter to be understood by the recipient. However, a programmer writing code has two goals: not only for the intent of the code to be understood by future programmers, but also to make the code easy to change in response to unknown requirements without causing any regressions. The article is a bit all-over-the-place, but I do agree with it in general, because I've seen far more bugs in production caused by changing code than by adding it. Therefore, I would rather use a language with advanced features I can use to make my code harder to change in the wrong way. I think that if you phrase it like that, it makes it more acceptable to "avoid simplicity".
slowenough 7y ago
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.
haolez 7y ago
I’m starting to think that I’m in the minority that agrees with most (if not all) Go’s design decision and appreciate Rob Pike’s stewardship so far.
- yahyaheee 7y ago
  That’s possible, in the early days of Go I guess they spent a lot of time trying to optimize the compiler with googles ML teams
- cytzol 7y ago
  I'm in the opposite camp from you — I like generics, lack of null, and syntax highlighting — but that's fine! I don't think this is something we have to 'agree' or 'disagree' with. It simply means that you're within Go's target market. If you want to use a simple language, and the software you're writing works just fine without these features in your code, then of course it's OK to jettison them and stick with the simple language. I need those features because of the software I write, so I need to stick with a more feature-ful language. Acting like there needs to be some 'one true way' when we're writing completely different pieces of software is how pointless internet arguments get started.
  - meddlepal 7y ago
    The problem is not all of us get to choose the language we work in and sometimes someone picks a language for all the wrong reasons and then you're stuck with it because a rewrite is costly and usually not an option. So these debates do have some merit.
    - cytzol 7y ago
      You're right, and that is unfortunate. But "people sometimes make the wrong decisions" is a much tougher nut to crack! I agree that we should have these debates — but on a "is this language acceptable for my use case" level, not a "is this language acceptable for any use cases" level.
  - haolez 7y ago
starbugs 7y ago
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. 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.
z3t4 7y ago
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. A world class athlete makes something hard look easy. So just because the code looks simple, doesn't mean it is easy. 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? 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.
nottrobin 7y ago
I think this piece risks being interpreted as saying that simplicity is not important. The fact that simplicity is hard to achieve will be obvious to anyone who has ever truly tried to achieve it. 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.
austincheney 7y ago
Simplicity is objectively measurable. Here is a practical suggestion, though directly applied to mechanical engineering is readily adaptable to application design. https://www.sciencedirect.com/science/article/pii/S2351978918302361 https://www.sciencedirect.com/science/article/pii/S235197891... 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.
- sabas123 7y ago
  The metric chosen here is still arbitrary, why would the number of interfaces be more important than the number of the amount of interconnected interfaces? It is still subjective and hence simplicity is still subjective too
  - austincheney 7y ago
    When a metric is quantifiable with numbers it is objective. It may not be the best tool for the job or even valid at all, but it is still objective. Subjectivity, on the other hand, means to prioritize a content or bias above its measures.
    - sabas123 7y ago
      The problem is that no matter which metric you choose, I can pick another one leading me to have opposite outcomes in a manner that you cannot argue with. The importance of your objective metric will still be subjective based on how important I think each metric system is. Making the entire thing subjective.
      - austincheney 7y ago
        You are confusing cause and effect. The measure itself is the objective part. What you do or what you believe from that number is the subjective part. If objectivity were important to you then you would use many measures.
panpanna 7y ago
Let me answer this once and for all: > What are we optimizing for? 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). Thats why I like Go. And C, now that I think about it...
- yahyaheee 7y ago
  Exactly, I think the article is a bit self centered and overlooks this concept
- ken 7y ago
  I agree with the first part -- which is why I don't like low-level languages like C. I can't count the number of times I've encountered old C code that uses pointers and bytes and arrays, and I discover a bug, and on further inspection I can't even figure out what they were trying to do. It's all just pointers and bytes and arrays. The language is too low-level to encode intent, except at the lowest level, so you're putting all your trust in comments.
  - empthought 7y ago
    You can also use structs and preprocessor macros. Have a look at the PostgreSQL source sometime.
  - clarry 7y ago
    Functions are the basic abstraction in C. They are good for describing intent. Likewise, structs are good for giving pointers and bytes meaning. Pointers and bytes and arrays are the least of all my problems in dealing with old C code.
tw1010 7y ago
Thought this was gonna be a cybertruck jab.
brlewis 7y ago
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. Overall I like this article and the YAGNI one it links to.
- ninkendo 7y ago
  I take YAGNI to mean not developing abstractions until you have enough use cases to back them up. If you don't have a reason now to make an abstraction, don't do it yet. Wait until you have at least 3 use cases where you're repeating yourself before you come up with an abstraction that collapses them. You'll know better what the right abstraction will be once you have those use cases... any abstraction you come up with now is much more likely to be wrong. And a wrong abstraction is much worse than repeating yourself. Of course, if this is the umpteenth time you've done the same CRUD app that wraps a relational database, go ahead and use the abstractions you know worked before, because in that case, you've already seen the use cases before and you have a better idea of what abstractions will work.
  - Kivutar 7y ago
    Exactly.
  - brlewis 7y ago
    https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
- rubinelli 7y ago
  It is easy to look back and say, "I should have made this modular," or "I should have isolated that external dependency." It is easier to see how another level of indirection would have saved you work after the fact, but maybe YAGNI was the right call at the time. That's the trap that Magic and poker players call results-oriented thinking: You got burned once by making the best decision available given the information you had, and you give that experience a disproportionate weight, like the player that lost big with a pair of kings in his hand, and undervalues a pair of kings after that.
kresten 7y ago
What’s the point being argued here? Seems to go all over the place. Seems like it’s a rant mainly about semantics.
- brlewis 7y ago
  I took the point to be that there isn't always a clear "simpler" way to implement something, and that when someone is hesitant to accept what to you is the obvious simple solution, listen to their concerns. Mainly this comes from the 2nd paragraph.
pron 7y ago
> 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. - Fred Brooks, No Silver Bullet, 1986 > Complexity is the business we are in, and complexity is what limits us. - Fred Brooks, No Silver Bullet Refired, 1995
csours 7y ago
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. Other times, you have to cut the string and you lose fidelity in your solution. 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. This isn't the only analogy, and it's incomplete, but I still like it.
kyancey 7y ago
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.
gatestone 7y ago
"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
theaeolist 7y ago
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.
- chasd00 7y ago
  i can't remember the author but there was a disucssion on usenet about comm. protocols years ago and someone said "it's not finished when there's nothing left to add, it's finished when there's nothing left to take away". To me, that's what simple means and i think it also equally applies to "fit for purpose". A perfect fit for purpose is an implementation with nothing left to take away. I feel like when you someone sees a perfect fit for purpose they would also think "this is really simple" whether it be an F-35 dashboard, nuclear reactor control room, or the controls on a lawn mower. edit: after thinking about this for a few min. there's larger than normal holes in my point heh. However, i really like OPs point.
api 7y ago
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. 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.
lurker5000 7y ago
Here's a few more if anyone is compiling a list: https://www.vitsoe.com/gb/about/good-design https://www.vitsoe.com/gb/about/good-design http://lawsofsimplicity.com/ http://lawsofsimplicity.com/
lurker5000 7y ago
Here's a few more if anyone is compiling a list: Dieter Rams -- https://www.vitsoe.com/gb/about/good-design https://www.vitsoe.com/gb/about/good-design John Maeda -- http://lawsofsimplicity.com/ http://lawsofsimplicity.com/
Roark66 7y ago
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...
kerblang 7y ago
I classify easy/hard as 1) Concise vs. Verbose 2) Straightforward vs. Confusing 3) Flexible vs. Inflexible 4) Efficient vs. Inefficient 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.
ashton314 7y ago
If Buttercup and Westley from _The Princess Bride_ were working on software, the conversation might have gone something like this: Buttercup: I balk at your complexity! Westley: Software is complexity! Anyone who says otherwise is selling SaaS.
ken 7y ago
> 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. I feel like this misses the point of high-level languages. In my experience, higher-level code is easier to read and write. For one thing, there's simply a lot less of it. 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 user will notice right away, too! > 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. 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. 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. Just because you can explain something with lots of tiny words does not necessarily make it easy for anyone to understand: https://www.muppetlabs.com/~breadbox/txt/al.html https://www.muppetlabs.com/~breadbox/txt/al.html
- camgunz 7y ago
  > ...concision Wrapping up important concepts under good names is clearly a good idea. But on the other end of the spectrum, factoring out a single line from 2 methods and giving it a bad name does far more harm than good. Probably 90% of DRY I come across is this bad kind, I would guess because refactoring for better semantic clarity takes much more effort than just factoring out the common stuff under a different name. I think this downside doesn't get nearly enough airtime as it should.
- tabtab 7y ago
  Re: "Lisp isn't more productive just because..." Whether Lisp or functional programming is "more productive" in general or just in the hands of a few is a controversial topic. Example debates: https://wiki.c2.com/?IfFooIsSoGreatHowComeYouAreNotRich https://wiki.c2.com/?IfFooIsSoGreatHowComeYouAreNotRich https://wiki.c2.com/?GreatLispWar https://wiki.c2.com/?GreatLispWar I personally find functional harder to debug and haven't got past that bottleneck yet. Yes, maybe I'm "doing it wrong", but can't find "right". Somebody else once told me, "functional makes it easier to express what you want but imperative (traditional programming) makes it easier to figure out what's actually happening". That rings very very true for me. In terms of productivity, it looks the second is trumping the first. In another forum, the "solution" was "just don't make bugs". Doh! Even if true for an individual, it may not scale to a bigger team.
Kivutar 7y ago
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." By simplicity, we mean frugality. If you can implement something without adding a ton of dependencies, abstraction layers, and design patterns, it will be easier to understand and debug. YAGNI is everything but abused.
breck 7y ago
> The problem with these approaches is that “simplicity” never gets a rigorous definition 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: https://github.com/treenotation/research/blob/master/papers/paper3/countingComplexity.pdf https://github.com/treenotation/research/blob/master/papers/...
Kalium 7y ago
I once worked on a system where the senior engineer on the project had a dogmatic definition of simple. 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. 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 very useful.
- tabtab 7y ago
  Yip, I've also encountered "architects" who obsess on certain things, and make a mess in the process, at least something that is a "mess" to the majority of coders. One is left with a dilemma of complain harder or leave. Unfortunately, leaving is probably the only way out. Often such people have "connections" and are thus not correctable. They have outlier minds and want a system that models their outlier brain even if multiple developers complain. Bail out.
mbostleman 7y ago
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.
- hinkley 7y ago
  I really noticed this when I caught business folks conflating the two. Often the more easily you can describe the situation, the more code it takes to make it Just Work. Simple for the user is harder for me.
  - mbostleman 7y ago
    Exactly
EricE 7y ago
Heh “I apologize for such a long letter - I didn't have time to write a short one.” ― Mark Twain
ajbonkoski 7y ago
I would define simplicity as "the approach that minimizes cognitive load while meeting all other objectives" I would hope that people with the same objectives would agree on simplicity for that domain. Examples: 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) C is probably the simplest 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. Something like Python is probably simplest Etc etc etc 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.
- zmmmmm 7y ago
  > I would define simplicity as "the approach that minimizes cognitive load while meeting all other objectives" That's one dimension of simplicity, but it doesn't take into account some of the other benefits of simplicity, such as, eg: robustness. Another definition would be "the approach that minimizes the total number of possible interactions" (akin to "moving parts" in a physical machine). In that sense, the fewer total possible interactions, the fewer places something can break. There might be MORE cognitive load to a human in direct sense, but the system is far more constrained to only do the "right thing". I sometimes think of the generalization of it being "the approach that minimises the total state space of the system, including the brain of the human trying to understand it".
tabtab 7y ago
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. Another rule of thumb to add is "don't obsess on a single rule of thumb; they are all important." 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.
- gambler 7y ago
  >There are several key "rules of thumb" to keep in mind, and they are often contradictory. Rules of thumb in software engineering is bullshit masquerading as wisdom. Don't keep them in mind. They will hog your cognitive bandwidth which you could use to actually reason about problems. Real engineering involves balancing tradeoffs. To balance them, you need to understand what they are. Sloganistic "rules of thumb" do not help with that at all. For example: YAGNI. "Your ain't gonna need it." It could be used to advocate for deferring a decision for which you don't have enough info or it could be used to advocate for ignoring a critical design flaw that's guaranteed to bite you in the ass later on. Good engineers don't spew out slogans. They explain their reasoning.
  - tabtab 7y ago
    Re: "For example: YAGNI. "Your ain't gonna need it." It could be used to advocate for deferring a decision for which you don't have enough info..." Another rule of thumb is "know your domain". Re: "Good engineers don't spew out slogans. They explain their reasoning." That is true, but it's also good to have summary reminders. People won't remember most 2 hour lectures unless refreshed over time, and rules of thumb are one way to do this without re-attending the same 2 hour lecture over and over. In the ideal world they'd re-attend the full lectures (or close to) to get a refresh, but that's not the way most humans do things.
divan 7y ago
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. 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".
- jolmg 7y ago
  > mostly it seems to be a "I like Rust and Haskell, and don't like Go" type of articles The mentions of Rust, Haskell, and Go are limited to a single section of the article, so I'm not sure what you're talking about. Most of the article seems to stay abstract with concrete cases brought as examples.
  - divan 7y ago
    I might be biased, as I had to read every Go rant back then when writing a "How to complain about Go" article, and this is clearly the same narrative. Author did a good job to hide it, but if you look closer you'll see indirect Go mentioning throughout the whole article: - "“What do you mean, you think Go’s error handling is bad? It’s simple!”" - How can we articulate a position more powerful than “syntax highlighting is juvenile?” <- refers to the Rob Pike's opinion about syntax highlight - "Go’s error handling has become a meme," - "The creators of Go have said, sometimes in pejorative terms,1 that “average programmers” have difficulty understanding complex languages," - "It’s inflammatory, but the article “Why Go’s design is a disservice to intelligent programmers” is worth reading just for the quotes from Rob Pike."
teucris 7y ago
quote of the month: “Code, in itself, is not an asset. A solved problem is an asset.”
BenoitEssiambre 7y ago
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 (https://medium.com/@b.essiambre/product-market-crossfit-c09b019188f3?source=friends_link&sk=5a57eddd18dd948ebb512afb40a21667 https://medium.com/@b.essiambre/product-market-crossfit-c09b...). Well tuned knowledge is not an easy thing.
carapace 7y ago
Recognizing simplicity requires familiarity with complexity. - - - - FWIW, Category Theory provides a mathematical formalism for determining when your system is "as simple as possible, but no simpler". - - - - > “average programmers” have difficulty understanding complex languages 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.
sint762 7y ago
dumb
sytelus 7y ago
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 delightful complexity. 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! 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.

279 points by emrehan 7y ago

ftvy 7y ago

TFA seems to build upon confusion of how "simplicity" is defined. 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.

mattbuilds 7y ago
I’ve actually been writing a post about just this concept. When I think simple, I think solving the problem in a way that adds value and doesn’t have unnecessary overhead. I think it’s important to highlight the differences between simple, complex, and complicated (like from the Zen of Python). The basic idea is that if possible you want a simple program, but most problems aren’t that’s simple. So the solution needs to be complex with lots of parts. Those parts can and should be simple though. Complicated means adding things that don’t any value. Maybe it’s using containers on a CRUD app that doesn’t need it because it looks good on a resume.
mbrock 7y ago
I think Ousterhout’s pragmatic definition of complexity is the best one when discussing actual code bases: complexity is anything that makes the system hard to change, taking into account how often the relevant part needs to change.
- frou_dh 7y ago
  Hard to change is subjective. Maybe something you found hard to change, your colleague would have no trouble with. And vice versa.
  - rob74 7y ago
    Yeah, some colleagues have absolutely no trouble changing any code... and then it starts breaking for some edge cases that they weren't aware of :D
  - mbrock 7y ago
    Yeah, with this definition, complexity is something you notice as a working team, not something you can directly measure with syntactic criteria (of course syntactic criteria may correlate with the complexity).

nnq 7y ago

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. 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 other majority of the code 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. Sure, if infrastructure IS your very product like Go's use case probably is, then it probably makes sense to not have features for such separation.

friendly_chap 7y ago
> error handling tucked away in different system I'm not sure that can ever be done. I agree Go could use some syntactic around error handling but I think even modern software is incredibly flaky and Go is a step in the right direction. It's tiring to think about all the failure cases but it might lead to a world where the ATM gives me money instead of Windows BOD.
Kye 7y ago
I experienced a good example of this recently when trying to decide between Bitwig and an upgrade of Ableton Live Lite to Suite. Suite comes with a full-featured audio programming environment called Max for Live. It has some high level devices for common functions, but you can go very low level and make just about anything. The building blocks are all very simple and basic: oscillators, math functions, routing, etc. Bitwig's Grid takes a different approach with a small number of powerful building blocks. The range of possibilities is smaller, but you can be more productive if the thing you want to make is composable from the available devices.
fauigerzigerk 7y ago
>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... How so? Can you not write modular code in just about any language? I'm not saying programming languages don't matter, but in terms of seperating business logic from plumbing I don't see huge differences. I also don't think you can seperate errors from the rest of your code on the same level of abstraction. Business logic errors such as "account overdrawn" are business logic. Plumbing errors such as a broken network connection are plumbing. The only errors that can and should be kept separate are bugs that need to be fixed.

ds_ 7y ago

"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'" - https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/

blondin 7y ago
wouldn't say simple is the opposite of complex though? especially when talking about software systems or other systems in general. what i am thinking is that some complex systems can be made of very simple components. the best example is our complex brain being made of simpler components working together. maybe the opposite of complex is chaotic? i don't know...
- cuddlecake 7y ago
  I imagine that a software system that is made of simple components can still be complex. So I'd still go for simple vs complex
- ajdegol 7y ago
  Simple systems can indeed be made of complex components; however it is a measure of interconnectedness. The key concept is that we can only hold a finite amount of complexity in our heads at any one time, and so if we can minimise that we can be more efficient and effective. The analogy is a lego castle vs a wool castle. A lego brick is very simple and contained, and from this you can build wonderful structures; in addition if you wish to change out a portion it is easy to do because changing on part of the system (i.e. implementation) doesn't affect the rest so long as the contract between components is maintained. Contrasting: should you pull on a thread in a wool castle it will affect other parts of the castle. A lot of software is like this, which makes it very hard to reason about.
  - roenxi 7y ago
    And the Lego analogy works in particularly nicely considering just how much effort, precision and design work needs to go in to making the blocks simple [0]. This is a nice analogy for how keeping software components simple and making them interface cleanly is a difficult task. [0] https://en.wikipedia.org/wiki/Lego#Design https://en.wikipedia.org/wiki/Lego#Design

anoplus 7y ago

I think the confusion around simplicity is in what terms a thing is simple. For example, 2 pieces of text can be simple in 2 different ways: 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. 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. "Neat" code can be "simple" to maintain. "Messy" code can be "simple" to implement.

collyw 7y ago
>"Neat" code can be "simple" to maintain. "Messy" code can be "simple" to implement. I was thinking something similar recently. Good code should take the next developer less time / effort to understand it than it took the original developer to write it (assuming similar levels of ability).
- bonoboTP 7y ago
  > the next developer And that's often you, just in a few months' time.
  - collyw 7y ago
    True. And as I mentioned in another comment, I learned the most by building a system from scratch and maintaining git for 4 and a half years. If I couldn't understand a bit of code that had written more or less straight away, then it was usually time to refactor it.
weego 7y ago
I don't think there is a confusion around simplicity. It just seems like strawman blog filler and this article is no different.
zzzcpan 7y ago
What you are describing here is approaching usability. And when it comes to usability simplicity doesn't matter on its own, there are four other things to always keep in mind together with simplicity: consistency, flexibility, universality and familiarity. And then understanding what users need your piece of text for applying those concept to come up with the best balance to make users think and learn as little as possible throughout the whole lifecycle of the use. Take, for example, familiarity. If you use a richer vocabulary that your users already familiar with, they certainly wouldn't need to learn more words and the piece with richer vocabulary would be easier for them to go through, than the longer piece with poorer vocabulary. Simple doesn't mean more usable, but it's a pretty straightforward concept to understand, there is no confusion around it.

codingdave 7y ago

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. 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. 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. 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.

nessunodoro 7y ago
"Making things simple is hard work." - Rich Hickey When I think of the simple vs complex bifurcation I think of fractals, a "simple" set of rules expressed in a complex way. The complexity arises from their expression/expansion iterated over time, but the rules that govern that expression are economical and compact. Think of an acorn: the encoding of a tree is all there. Its self-similarity, recusively expressed, creates the complex output of a tree. But nature always prefers the most economical solution because in the physical universe, resources are limited. It might make more sense to s/simple/economical/.
cytzol 7y ago
> "If I had more time, I would have written a shorter letter" I don't like seeing this quote in the context of programming. Sure, they're both about writing, but in different settings. A person who writes a letter has one goal: for the intent of the letter to be understood by the recipient. However, a programmer writing code has two goals: not only for the intent of the code to be understood by future programmers, but also to make the code easy to change in response to unknown requirements without causing any regressions. The article is a bit all-over-the-place, but I do agree with it in general, because I've seen far more bugs in production caused by changing code than by adding it. Therefore, I would rather use a language with advanced features I can use to make my code harder to change in the wrong way. I think that if you phrase it like that, it makes it more acceptable to "avoid simplicity".

slowenough 7y ago

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.

haolez 7y ago

I’m starting to think that I’m in the minority that agrees with most (if not all) Go’s design decision and appreciate Rob Pike’s stewardship so far.

yahyaheee 7y ago
That’s possible, in the early days of Go I guess they spent a lot of time trying to optimize the compiler with googles ML teams
cytzol 7y ago
I'm in the opposite camp from you — I like generics, lack of null, and syntax highlighting — but that's fine! I don't think this is something we have to 'agree' or 'disagree' with. It simply means that you're within Go's target market. If you want to use a simple language, and the software you're writing works just fine without these features in your code, then of course it's OK to jettison them and stick with the simple language. I need those features because of the software I write, so I need to stick with a more feature-ful language. Acting like there needs to be some 'one true way' when we're writing completely different pieces of software is how pointless internet arguments get started.
- meddlepal 7y ago
  The problem is not all of us get to choose the language we work in and sometimes someone picks a language for all the wrong reasons and then you're stuck with it because a rewrite is costly and usually not an option. So these debates do have some merit.
  - cytzol 7y ago
    You're right, and that is unfortunate. But "people sometimes make the wrong decisions" is a much tougher nut to crack! I agree that we should have these debates — but on a "is this language acceptable for my use case" level, not a "is this language acceptable for any use cases" level.
- haolez 7y ago

starbugs 7y ago

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. 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.

z3t4 7y ago

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. A world class athlete makes something hard look easy. So just because the code looks simple, doesn't mean it is easy. 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? 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.

nottrobin 7y ago

I think this piece risks being interpreted as saying that simplicity is not important. The fact that simplicity is hard to achieve will be obvious to anyone who has ever truly tried to achieve it. 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.

austincheney 7y ago

Simplicity is objectively measurable. Here is a practical suggestion, though directly applied to mechanical engineering is readily adaptable to application design. https://www.sciencedirect.com/science/article/pii/S2351978918302361 https://www.sciencedirect.com/science/article/pii/S235197891... 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.

sabas123 7y ago
The metric chosen here is still arbitrary, why would the number of interfaces be more important than the number of the amount of interconnected interfaces? It is still subjective and hence simplicity is still subjective too
- austincheney 7y ago
  When a metric is quantifiable with numbers it is objective. It may not be the best tool for the job or even valid at all, but it is still objective. Subjectivity, on the other hand, means to prioritize a content or bias above its measures.
  - sabas123 7y ago
    The problem is that no matter which metric you choose, I can pick another one leading me to have opposite outcomes in a manner that you cannot argue with. The importance of your objective metric will still be subjective based on how important I think each metric system is. Making the entire thing subjective.
    - austincheney 7y ago
      You are confusing cause and effect. The measure itself is the objective part. What you do or what you believe from that number is the subjective part. If objectivity were important to you then you would use many measures.

panpanna 7y ago

Let me answer this once and for all: > What are we optimizing for? 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). Thats why I like Go. And C, now that I think about it...

yahyaheee 7y ago
Exactly, I think the article is a bit self centered and overlooks this concept
ken 7y ago
I agree with the first part -- which is why I don't like low-level languages like C. I can't count the number of times I've encountered old C code that uses pointers and bytes and arrays, and I discover a bug, and on further inspection I can't even figure out what they were trying to do. It's all just pointers and bytes and arrays. The language is too low-level to encode intent, except at the lowest level, so you're putting all your trust in comments.
- empthought 7y ago
  You can also use structs and preprocessor macros. Have a look at the PostgreSQL source sometime.
- clarry 7y ago
  Functions are the basic abstraction in C. They are good for describing intent. Likewise, structs are good for giving pointers and bytes meaning. Pointers and bytes and arrays are the least of all my problems in dealing with old C code.

tw1010 7y ago

Thought this was gonna be a cybertruck jab.

brlewis 7y ago

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. Overall I like this article and the YAGNI one it links to.

ninkendo 7y ago
I take YAGNI to mean not developing abstractions until you have enough use cases to back them up. If you don't have a reason now to make an abstraction, don't do it yet. Wait until you have at least 3 use cases where you're repeating yourself before you come up with an abstraction that collapses them. You'll know better what the right abstraction will be once you have those use cases... any abstraction you come up with now is much more likely to be wrong. And a wrong abstraction is much worse than repeating yourself. Of course, if this is the umpteenth time you've done the same CRUD app that wraps a relational database, go ahead and use the abstractions you know worked before, because in that case, you've already seen the use cases before and you have a better idea of what abstractions will work.
- Kivutar 7y ago
  Exactly.
- brlewis 7y ago
  https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
rubinelli 7y ago
It is easy to look back and say, "I should have made this modular," or "I should have isolated that external dependency." It is easier to see how another level of indirection would have saved you work after the fact, but maybe YAGNI was the right call at the time. That's the trap that Magic and poker players call results-oriented thinking: You got burned once by making the best decision available given the information you had, and you give that experience a disproportionate weight, like the player that lost big with a pair of kings in his hand, and undervalues a pair of kings after that.

kresten 7y ago

What’s the point being argued here? Seems to go all over the place. Seems like it’s a rant mainly about semantics.

brlewis 7y ago
I took the point to be that there isn't always a clear "simpler" way to implement something, and that when someone is hesitant to accept what to you is the obvious simple solution, listen to their concerns. Mainly this comes from the 2nd paragraph.

pron 7y ago

> 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. - Fred Brooks, No Silver Bullet, 1986 > Complexity is the business we are in, and complexity is what limits us. - Fred Brooks, No Silver Bullet Refired, 1995

csours 7y ago

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. Other times, you have to cut the string and you lose fidelity in your solution. 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. This isn't the only analogy, and it's incomplete, but I still like it.

kyancey 7y ago

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.

gatestone 7y ago

"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

theaeolist 7y ago

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.

chasd00 7y ago
i can't remember the author but there was a disucssion on usenet about comm. protocols years ago and someone said "it's not finished when there's nothing left to add, it's finished when there's nothing left to take away". To me, that's what simple means and i think it also equally applies to "fit for purpose". A perfect fit for purpose is an implementation with nothing left to take away. I feel like when you someone sees a perfect fit for purpose they would also think "this is really simple" whether it be an F-35 dashboard, nuclear reactor control room, or the controls on a lawn mower. edit: after thinking about this for a few min. there's larger than normal holes in my point heh. However, i really like OPs point.

api 7y ago

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. 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.

lurker5000 7y ago

Here's a few more if anyone is compiling a list: https://www.vitsoe.com/gb/about/good-design https://www.vitsoe.com/gb/about/good-design http://lawsofsimplicity.com/ http://lawsofsimplicity.com/

lurker5000 7y ago

Here's a few more if anyone is compiling a list: Dieter Rams -- https://www.vitsoe.com/gb/about/good-design https://www.vitsoe.com/gb/about/good-design John Maeda -- http://lawsofsimplicity.com/ http://lawsofsimplicity.com/

Roark66 7y ago

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...

kerblang 7y ago

I classify easy/hard as 1) Concise vs. Verbose 2) Straightforward vs. Confusing 3) Flexible vs. Inflexible 4) Efficient vs. Inefficient 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.

ashton314 7y ago

If Buttercup and Westley from _The Princess Bride_ were working on software, the conversation might have gone something like this: Buttercup: I balk at your complexity! Westley: Software is complexity! Anyone who says otherwise is selling SaaS.

ken 7y ago

> 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. I feel like this misses the point of high-level languages. In my experience, higher-level code is easier to read and write. For one thing, there's simply a lot less of it. 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 user will notice right away, too! > 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. 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. 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. Just because you can explain something with lots of tiny words does not necessarily make it easy for anyone to understand: https://www.muppetlabs.com/~breadbox/txt/al.html https://www.muppetlabs.com/~breadbox/txt/al.html

camgunz 7y ago
> ...concision Wrapping up important concepts under good names is clearly a good idea. But on the other end of the spectrum, factoring out a single line from 2 methods and giving it a bad name does far more harm than good. Probably 90% of DRY I come across is this bad kind, I would guess because refactoring for better semantic clarity takes much more effort than just factoring out the common stuff under a different name. I think this downside doesn't get nearly enough airtime as it should.
tabtab 7y ago
Re: "Lisp isn't more productive just because..." Whether Lisp or functional programming is "more productive" in general or just in the hands of a few is a controversial topic. Example debates: https://wiki.c2.com/?IfFooIsSoGreatHowComeYouAreNotRich https://wiki.c2.com/?IfFooIsSoGreatHowComeYouAreNotRich https://wiki.c2.com/?GreatLispWar https://wiki.c2.com/?GreatLispWar I personally find functional harder to debug and haven't got past that bottleneck yet. Yes, maybe I'm "doing it wrong", but can't find "right". Somebody else once told me, "functional makes it easier to express what you want but imperative (traditional programming) makes it easier to figure out what's actually happening". That rings very very true for me. In terms of productivity, it looks the second is trumping the first. In another forum, the "solution" was "just don't make bugs". Doh! Even if true for an individual, it may not scale to a bigger team.

Kivutar 7y ago

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." By simplicity, we mean frugality. If you can implement something without adding a ton of dependencies, abstraction layers, and design patterns, it will be easier to understand and debug. YAGNI is everything but abused.

breck 7y ago

> The problem with these approaches is that “simplicity” never gets a rigorous definition 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: https://github.com/treenotation/research/blob/master/papers/paper3/countingComplexity.pdf https://github.com/treenotation/research/blob/master/papers/...

Kalium 7y ago

I once worked on a system where the senior engineer on the project had a dogmatic definition of simple. 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. 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 very useful.

tabtab 7y ago
Yip, I've also encountered "architects" who obsess on certain things, and make a mess in the process, at least something that is a "mess" to the majority of coders. One is left with a dilemma of complain harder or leave. Unfortunately, leaving is probably the only way out. Often such people have "connections" and are thus not correctable. They have outlier minds and want a system that models their outlier brain even if multiple developers complain. Bail out.

mbostleman 7y ago

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.

hinkley 7y ago
I really noticed this when I caught business folks conflating the two. Often the more easily you can describe the situation, the more code it takes to make it Just Work. Simple for the user is harder for me.
- mbostleman 7y ago
  Exactly

EricE 7y ago

Heh “I apologize for such a long letter - I didn't have time to write a short one.” ― Mark Twain

ajbonkoski 7y ago

I would define simplicity as "the approach that minimizes cognitive load while meeting all other objectives" I would hope that people with the same objectives would agree on simplicity for that domain. Examples: 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) C is probably the simplest 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. Something like Python is probably simplest Etc etc etc 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.

zmmmmm 7y ago
> I would define simplicity as "the approach that minimizes cognitive load while meeting all other objectives" That's one dimension of simplicity, but it doesn't take into account some of the other benefits of simplicity, such as, eg: robustness. Another definition would be "the approach that minimizes the total number of possible interactions" (akin to "moving parts" in a physical machine). In that sense, the fewer total possible interactions, the fewer places something can break. There might be MORE cognitive load to a human in direct sense, but the system is far more constrained to only do the "right thing". I sometimes think of the generalization of it being "the approach that minimises the total state space of the system, including the brain of the human trying to understand it".

tabtab 7y ago

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. Another rule of thumb to add is "don't obsess on a single rule of thumb; they are all important." 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.

gambler 7y ago
>There are several key "rules of thumb" to keep in mind, and they are often contradictory. Rules of thumb in software engineering is bullshit masquerading as wisdom. Don't keep them in mind. They will hog your cognitive bandwidth which you could use to actually reason about problems. Real engineering involves balancing tradeoffs. To balance them, you need to understand what they are. Sloganistic "rules of thumb" do not help with that at all. For example: YAGNI. "Your ain't gonna need it." It could be used to advocate for deferring a decision for which you don't have enough info or it could be used to advocate for ignoring a critical design flaw that's guaranteed to bite you in the ass later on. Good engineers don't spew out slogans. They explain their reasoning.
- tabtab 7y ago
  Re: "For example: YAGNI. "Your ain't gonna need it." It could be used to advocate for deferring a decision for which you don't have enough info..." Another rule of thumb is "know your domain". Re: "Good engineers don't spew out slogans. They explain their reasoning." That is true, but it's also good to have summary reminders. People won't remember most 2 hour lectures unless refreshed over time, and rules of thumb are one way to do this without re-attending the same 2 hour lecture over and over. In the ideal world they'd re-attend the full lectures (or close to) to get a refresh, but that's not the way most humans do things.

divan 7y ago

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. 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".

jolmg 7y ago
> mostly it seems to be a "I like Rust and Haskell, and don't like Go" type of articles The mentions of Rust, Haskell, and Go are limited to a single section of the article, so I'm not sure what you're talking about. Most of the article seems to stay abstract with concrete cases brought as examples.
- divan 7y ago
  I might be biased, as I had to read every Go rant back then when writing a "How to complain about Go" article, and this is clearly the same narrative. Author did a good job to hide it, but if you look closer you'll see indirect Go mentioning throughout the whole article: - "“What do you mean, you think Go’s error handling is bad? It’s simple!”" - How can we articulate a position more powerful than “syntax highlighting is juvenile?” <- refers to the Rob Pike's opinion about syntax highlight - "Go’s error handling has become a meme," - "The creators of Go have said, sometimes in pejorative terms,1 that “average programmers” have difficulty understanding complex languages," - "It’s inflammatory, but the article “Why Go’s design is a disservice to intelligent programmers” is worth reading just for the quotes from Rob Pike."

teucris 7y ago

quote of the month: “Code, in itself, is not an asset. A solved problem is an asset.”

BenoitEssiambre 7y ago

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 (https://medium.com/@b.essiambre/product-market-crossfit-c09b019188f3?source=friends_link&sk=5a57eddd18dd948ebb512afb40a21667 https://medium.com/@b.essiambre/product-market-crossfit-c09b...). Well tuned knowledge is not an easy thing.

carapace 7y ago

Recognizing simplicity requires familiarity with complexity. - - - - FWIW, Category Theory provides a mathematical formalism for determining when your system is "as simple as possible, but no simpler". - - - - > “average programmers” have difficulty understanding complex languages 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.

sint762 7y ago

dumb

sytelus 7y ago

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 delightful complexity. 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! 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.