6 ms·

> “Good code is simple” doesn’t actually say anything. [...] What we call “simple” depends on our experience, skills, interest, patience, and curiosity. I like

> “Good code is simple” doesn’t actually say anything. [...] What we call “simple” depends on our experience, skills, interest, patience, and curiosity. I like Rich Hickey's stance on this: "simple" is objective (antonym: "complex"), whereas "easy" is subjective (antonym: "hard"). Easy depends on skills, interest, patience, curiosity - but simple does not. Simple is about lack of intertwining of concerns. About writing code that can be understood without "bringing in" the entire codebase into your mind. Like, you can understand a pure function just by looking at it (it's simple). If it modifies or uses a global variable, now you have to look at all the places that "touch" that global variable, in order to understand what your function does; the code is thus much more complex. With that definition - it's absolutely correct to say that the code should be as simple as possible. And that writing simple code is typically very hard.

artimaeis 9y ago
Python's PEP 20 utilizes this view on simple v complex, and also covers the idea of complicated. > Simple is better than complex. Complex is better than complicated. I've stuck by those two lines of PEP 20 since I learned about them. The object is to write simple code, but it's okay to write complex code if your goal is to avoid complicated (unreadable) code.
- virgilp 9y ago
  That is a strange and "unnatural" (for me) use of the word "complicated". Cynefin[1] defines 'complicated' as "known unknows" and 'complex' as 'unknown unknowns'. The idea is that complicated things are non-obvious, but they are understandable (with expertise, you get the relationship between cause and effect). With complex, full cause & effect cannot be known apriori, it's just observable after the fact. That somewhat resonates with the definition that complex (code) is about intertwining - 'complex' is problematic because as things get more and more complex, you can have only a local understanding, and can't possibly hope to grasp all the implications of a code change. This suggests that "complicated" is something that is "somewhat complex, but still manageable with sufficient expertise/domain knowledge". I tend to use "complicated" to denote something that has inherent complexities (due to the nature of the real world); and "complex" to denote something that is artificially complex, due to ... well, lack of thought into making it as simple as it could be. In that sense, I view "complex" as being definitely worse than "complicated" [1]https://en.wikipedia.org/wiki/Cynefin_framework https://en.wikipedia.org/wiki/Cynefin_framework
  - kstrauser 9y ago
    I see it the opposite way. Some things are inherently complex, like heart surgery or launching a rocket. There are many things that have to work together perfectly or the whole thing goes south. Complicated to me means that complications have been added where they weren’t needed. A Rube Goldberg machine solves a simple problem that has been complicated.
    - virgilp 9y ago
      Hmmm... I looked up word origins. "com" + "plicare" - "to fold together". You seem to be right, it's closer to the original meaning to use them like you say ("complex" = inherent complexity; "complicated" = "incidental/ added complexity"). I can't reconcile it with Cynefin, but I'll have to update my usage of those terms in a coding context.
      - kstrauser 9y ago
        I've had this conversation with few people - mainly peers with whom I'm discussing our craft. Most recently it was with a junior engineer, and I wanted to pin these definitions down precisely so that we had a common vocabulary for describing ideas we were developing. I mention this because I haven't heard these terms commonly used in any particular context so I don't think there's an agreed upon "correct" definition of them. I think my definitions more closely jibe with the normal English meanings, though.
    - chriswarbo 9y ago
      I've come across these meanings too, and they're the ones I use. Complexity is a property of the problem; complication is a property of the solution. Whilst over-complication is bad (e.g. your Rube Goldberg example), so is being simplistic (not enough complications to handle the complexity). Examples of simplistic solutions can be found in all of those "What programmers don't know about FOO" articles (human names, timezones, distributed systems, etc.)
      - kstrauser 9y ago
olau 9y ago
> With that definition - it's absolutely correct to say that the code should be as simple as possible. Yet, it is humans who need to read it. This is the end goal. If you rewrite the code to satisfy a theoretical objective criteria of simplicity, but end up with something that people reading the code find harder to read, then you have failed. It's the same when you design a UI.
- virgilp 9y ago
  But if you don't have an objective criteria of simplicity, how can you even hope to have universal agreement of what is "simpler"? Humans are complicated beasts. Saying "people find the code harder to read" doesn't help me know what I should do. If I have no objective criteria, then it must be subjective, and then all that "simple" means is that "this is easiest for me right now" - which, from experience, I claim to be a very unlikely path to produce code that multiple people agree to be "simple". (except if the problem was trivial to begin with - but then, who cares?)
  - vec 9y ago
    "Which is the better painting, Van Gogh's Starry Night or Seurat's La Grande Jatee?" is a deeply subjective question. "Which is the better painting, Van Gogh's Starry Night or a kindergartener's watercolor of their family?", on the other hand, appears to have a correct answer. There are multiple competing definitions of "simple" with respect to code and multiple kinds of simplicity that often have to be traded off against one another, and reasonable programmers can and do disagree about which compromises to make and where. Code quality (including, but not limited to legibility) is in many regards a subjective endeavor. That doesn't mean, though, that all decisions are equally justifiable. Trust your sense of aesthetics. It's usually trying to tell you something important, even if you don't know how to put it into words yet. With subjective endeavors there is no perfect, but there is usually better. Chase that.
    - virgilp 9y ago
      In your first example, both are exceptional, so really "which is better" is irrelevant. In the second, the difference is so big that it's obvious for anyone which is better, but that still doesn't make it useful for getting better at painting. "Paint more like a Van Gogh and less like a kindergarten kid" is not useful advice. People do have art critics and manuals that attempt to write down exactly what made Van Gogh paintings great. Those writings are useful, and many artists do indeed study them.
rimliu 9y ago
There is readability and there is understandability. Which may or may not be the same. Just like text you may have text that is cramped with very long lines and no line spacing, maybe no word spacing—it may be very hard to read it but once read it can be easy to understand. OTOH you can have a nicely typeset text which is impossible to understand. And if you talk about code there is also changeability. Which is somehow at odds with understandability. To make code easier to change you must move to abstractions, and more abstractions make a code more difficult to understand—but easier to change.
srett 9y ago
This is one of the things that get all weird the more I think about it. Trying to define an objective term like "simple" is of no use if you can't map it to something in human perception. Let's say we have some all-knowing oracle that can tell us which algorithm for problem X is the simplest one. If nobody would agree, what is the point? Or, if 51% of programmers would say A is simplest while the other 49% consider algorithm B more simple, should we just go "yay majority" and call it a day? In reality we have no way of knowing which one is objectively most simple, because at least regarding this domain, we as humans are unable to make an objective judgment. Is the simplest solution always the one with the least lines of code? Least number of classes? Singletons vs static classes? Recursive approach vs. iterative approach? C style linked lists (next-pointer in data type) vs. "proper" list class? In general: Could we formalize this, ie. come up with an algorithm how to determine how simple code is? Often times code that is easier to understand might be harder to work with, while more elaborated code with indirections and abstractions is harder to grasp (simply because it's more LoC/classes, just more reading), but once you got familiar with the code base, much easier to work with. So when you say objectively simple, do you mean "simple to understand so you can tell what it does", or "simple to understand wrt maintaining, extending and fixing"? And which kind of simple should I go for when writing code?
unabst 9y ago
I've understood "simple" in coding to mean "with the fewest abstractions possible." This. Is. Hard. It does help when the language is simpler. But as I code, when I find the need to deal with more exceptions, more functions, and more words just to get something to work... I just assume I should do it differently. Unfortunately, that's most of the time I spend coding.
FLUX-YOU 9y ago
Simple code is usually what you have before exception handling, logging, and robustness.
afarrell 9y ago
Which is the more simple object: an apple, or an internal combustion engine?

artimaeis 9y ago

Python's PEP 20 utilizes this view on simple v complex, and also covers the idea of complicated. > Simple is better than complex. Complex is better than complicated. I've stuck by those two lines of PEP 20 since I learned about them. The object is to write simple code, but it's okay to write complex code if your goal is to avoid complicated (unreadable) code.

virgilp 9y ago
That is a strange and "unnatural" (for me) use of the word "complicated". Cynefin[1] defines 'complicated' as "known unknows" and 'complex' as 'unknown unknowns'. The idea is that complicated things are non-obvious, but they are understandable (with expertise, you get the relationship between cause and effect). With complex, full cause & effect cannot be known apriori, it's just observable after the fact. That somewhat resonates with the definition that complex (code) is about intertwining - 'complex' is problematic because as things get more and more complex, you can have only a local understanding, and can't possibly hope to grasp all the implications of a code change. This suggests that "complicated" is something that is "somewhat complex, but still manageable with sufficient expertise/domain knowledge". I tend to use "complicated" to denote something that has inherent complexities (due to the nature of the real world); and "complex" to denote something that is artificially complex, due to ... well, lack of thought into making it as simple as it could be. In that sense, I view "complex" as being definitely worse than "complicated" [1]https://en.wikipedia.org/wiki/Cynefin_framework https://en.wikipedia.org/wiki/Cynefin_framework
- kstrauser 9y ago
  I see it the opposite way. Some things are inherently complex, like heart surgery or launching a rocket. There are many things that have to work together perfectly or the whole thing goes south. Complicated to me means that complications have been added where they weren’t needed. A Rube Goldberg machine solves a simple problem that has been complicated.
  - virgilp 9y ago
    Hmmm... I looked up word origins. "com" + "plicare" - "to fold together". You seem to be right, it's closer to the original meaning to use them like you say ("complex" = inherent complexity; "complicated" = "incidental/ added complexity"). I can't reconcile it with Cynefin, but I'll have to update my usage of those terms in a coding context.
    - kstrauser 9y ago
      I've had this conversation with few people - mainly peers with whom I'm discussing our craft. Most recently it was with a junior engineer, and I wanted to pin these definitions down precisely so that we had a common vocabulary for describing ideas we were developing. I mention this because I haven't heard these terms commonly used in any particular context so I don't think there's an agreed upon "correct" definition of them. I think my definitions more closely jibe with the normal English meanings, though.
  - chriswarbo 9y ago
    I've come across these meanings too, and they're the ones I use. Complexity is a property of the problem; complication is a property of the solution. Whilst over-complication is bad (e.g. your Rube Goldberg example), so is being simplistic (not enough complications to handle the complexity). Examples of simplistic solutions can be found in all of those "What programmers don't know about FOO" articles (human names, timezones, distributed systems, etc.)
    - kstrauser 9y ago

olau 9y ago

> With that definition - it's absolutely correct to say that the code should be as simple as possible. Yet, it is humans who need to read it. This is the end goal. If you rewrite the code to satisfy a theoretical objective criteria of simplicity, but end up with something that people reading the code find harder to read, then you have failed. It's the same when you design a UI.

virgilp 9y ago
But if you don't have an objective criteria of simplicity, how can you even hope to have universal agreement of what is "simpler"? Humans are complicated beasts. Saying "people find the code harder to read" doesn't help me know what I should do. If I have no objective criteria, then it must be subjective, and then all that "simple" means is that "this is easiest for me right now" - which, from experience, I claim to be a very unlikely path to produce code that multiple people agree to be "simple". (except if the problem was trivial to begin with - but then, who cares?)
- vec 9y ago
  "Which is the better painting, Van Gogh's Starry Night or Seurat's La Grande Jatee?" is a deeply subjective question. "Which is the better painting, Van Gogh's Starry Night or a kindergartener's watercolor of their family?", on the other hand, appears to have a correct answer. There are multiple competing definitions of "simple" with respect to code and multiple kinds of simplicity that often have to be traded off against one another, and reasonable programmers can and do disagree about which compromises to make and where. Code quality (including, but not limited to legibility) is in many regards a subjective endeavor. That doesn't mean, though, that all decisions are equally justifiable. Trust your sense of aesthetics. It's usually trying to tell you something important, even if you don't know how to put it into words yet. With subjective endeavors there is no perfect, but there is usually better. Chase that.
  - virgilp 9y ago
    In your first example, both are exceptional, so really "which is better" is irrelevant. In the second, the difference is so big that it's obvious for anyone which is better, but that still doesn't make it useful for getting better at painting. "Paint more like a Van Gogh and less like a kindergarten kid" is not useful advice. People do have art critics and manuals that attempt to write down exactly what made Van Gogh paintings great. Those writings are useful, and many artists do indeed study them.

rimliu 9y ago

There is readability and there is understandability. Which may or may not be the same. Just like text you may have text that is cramped with very long lines and no line spacing, maybe no word spacing—it may be very hard to read it but once read it can be easy to understand. OTOH you can have a nicely typeset text which is impossible to understand. And if you talk about code there is also changeability. Which is somehow at odds with understandability. To make code easier to change you must move to abstractions, and more abstractions make a code more difficult to understand—but easier to change.

srett 9y ago

This is one of the things that get all weird the more I think about it. Trying to define an objective term like "simple" is of no use if you can't map it to something in human perception. Let's say we have some all-knowing oracle that can tell us which algorithm for problem X is the simplest one. If nobody would agree, what is the point? Or, if 51% of programmers would say A is simplest while the other 49% consider algorithm B more simple, should we just go "yay majority" and call it a day? In reality we have no way of knowing which one is objectively most simple, because at least regarding this domain, we as humans are unable to make an objective judgment. Is the simplest solution always the one with the least lines of code? Least number of classes? Singletons vs static classes? Recursive approach vs. iterative approach? C style linked lists (next-pointer in data type) vs. "proper" list class? In general: Could we formalize this, ie. come up with an algorithm how to determine how simple code is? Often times code that is easier to understand might be harder to work with, while more elaborated code with indirections and abstractions is harder to grasp (simply because it's more LoC/classes, just more reading), but once you got familiar with the code base, much easier to work with. So when you say objectively simple, do you mean "simple to understand so you can tell what it does", or "simple to understand wrt maintaining, extending and fixing"? And which kind of simple should I go for when writing code?

unabst 9y ago

I've understood "simple" in coding to mean "with the fewest abstractions possible." This. Is. Hard. It does help when the language is simpler. But as I code, when I find the need to deal with more exceptions, more functions, and more words just to get something to work... I just assume I should do it differently. Unfortunately, that's most of the time I spend coding.

FLUX-YOU 9y ago

Simple code is usually what you have before exception handling, logging, and robustness.

afarrell 9y ago

Which is the more simple object: an apple, or an internal combustion engine?