9 ms·

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

• 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
    • hyperpallium 7y ago
      "Interconnectedness" is also a measure of resistence to hierarchical decomposition (or factoring ax+bx -> (a+b)x); irreducable complexity. One technique is redefining the problem, to smaller or bigger: Work on only part of a problem, a subset, leaving something out. e.g. git's data model does not represent renames as first class constucts, enabling it to be disproportionately simpler. Expand the problem, a superset, to integrate lower or higher level or associated parts that aren't usually included. Previously scattered commonalities may then appear, enabling decomposition.
  • nkrisc 7y ago
    A very big object can be made of lots of small objects, but that doesn't mean big isn't the opposite of small.
  • mnsc 7y ago
    > maybe the opposite of complex is chaotic? Cynefin would agree! https://en.wikipedia.org/wiki/Cynefin_framework https://en.wikipedia.org/wiki/Cynefin_framework
• ajdegol 7y ago
  If you haven't seen this talk; watching it will make you a 10x better programmer. This is what I take for my definition of complex and it applies broadly in a very practical manner.
  • simongray 7y ago
    Also: try out Clojure (... the programming language created by Rich Hickey based on this principle).
  • heinrich5991 7y ago
    >watching it will make you a 10x better programmer. That sounds wrong. Can we drop this rhetoric?
    • Ma8ee 7y ago
      It's obviously hyperbole.
      • radicalbyte 7y ago
        It needs to be rephrased into this: "Watching this video will make you into a developer who is respected 10x more by their peers."
        • coldtea 7y ago
          Would it?
          • _jal 7y ago
            Well, no, but it will make you 10x richer.
            • Ma8ee 7y ago
              harhar
• leggomylibro 7y ago
  I had a math teacher in primary school who used to shout with an exaggerated accent, "simple is not the same as easy!" She really wanted to drill the idea into our heads that just because you know exactly how to do something, doesn't mean that it will be quick or easy to accomplish. Like, for a schoolchild, long division. The rules are simple, but given big enough numbers you'll probably mess up at least once. And then the same thing turns out to be true with algebra, geometry, derivation/integration, and on. It's not a bad mantra.
  • Ma8ee 7y ago
    "It is straightforward to show that..." means that you could probably do it with your current knowledge, but it will take 6 dense pages, four false starts and about a week of focused work.
    • bitwize 7y ago
      I used to joke that when a solution was known to exist the problem was "trivial"; when a solution was not known to exist it was "nontrivial". A problem that's bloody well impossible is "decidedly nontrivial".
    • andreareina 7y ago
      If you were Feynman you'd even call it "elementary" https://mavenroundtable.io/originalpath/path-helpers/feynman-s-lost-lecture-W1juMFAHE0ycVFiybjO8KA/ https://mavenroundtable.io/originalpath/path-helpers/feynman...
    • hinkley 7y ago
      'You' being personified here, rather than the general you. Straightforward tends to suggest we don't have to have a bunch of meetings about it, because the right person either has the knowledge or we know precisely where to get it.
      • Ma8ee 7y ago
        It depends on the context. I had the math professor lecturing her students in mind.
• username90 7y ago
  They key takeaway that you should strive to be a simple person, not an easy person.
• masswerk 7y ago
  Simplicity is often a matter of perspective, a function of a certain perception of a complex subject and the set of expectations that go with this perception. There is no absolute in analysis and in modelling synthetic propositions from the atoms used by the particular analysis. (E.g., we may analyse and model an action in terms of verb-noun or of noun-verb, with major differences in what may be perceived as "simple" in the respective model.)
  • astrobe_ 7y ago
    > Simplicity is often a matter of perspective Complexity was formally defined by Kolmogorov, using with Turing machines even. Hence, Simplicity is also objectively defined.
    • masswerk 7y ago
      Referring to the above example of verb-noun vs noun-verb grammar: take for example the infinitive verb form. With the former (verb-noun) it's just the verb devoid of any context, simplicity in its purest, which is also, why and how it's listed in a lexicon. Looking at this from the noun-verb perspective, you've to construct a hypothetical minimal viable object, which will be also – as you want to keep things simple – the object every other object inherits from, the greatest common denominator of any objects that may appear in your system. By this, you arrived at the most crucial architectural questions of your system and its reach and purpose. While it's still about simple things, neither the task nor the definitions derived from the process will be simple at all. Nor is there a universally accepted simple answer, as a plurality of object oriented approaches may testify for. The question is on an entirely different scale and level for the two approaches. On the other hand, for a verb-noun approach, similar may appear for anything involving relations, which are already well defined in an object oriented approach. And, as you've arrived at these simple fundamentals of simplicity in your system, what may be simple or not in your systems will depend on the implicit contracts included in these definitions and how well they stand the test of time and varying use and purpose.
• loquor 7y ago
  On a related note, the late Patrick Winston strongly states in his MIT AI Course that simple is not the same as trivial. Simplicity is powerful. Simple points may sound trivial and obvious, but simple things can add up to make something magnificent.
• nohuck13 7y ago
  The speaker is Clojure creator Rich Hickey, but the talk is about a mental model for thinking about complexity. Inherent complexity involves tradeoffs. Incidental complexity you can fix for free. "And because we can only juggle so many balls, you have to make a decision. How many of those balls do you want to be incidental complexity and how many do you want to be problem complexity?" The article is about the former. I bet the latter dominates day-to-day line-of-business coding. Highly recommend the talk, as other have said.
• hzhou321 7y ago
  I am yet to appreciate Rich Hickey's now famous "Simple Made Easy". While I agree with his points, I don't understand the significance of it. Simpler is easier than complex, right? Even the title said "simple-made-easy". What is the fuss about emphasizing "Simple is erroneously mistaken for easy"? They are not the same, but they are intimately related. Or is this an emphasis on relative vs absolute -- that relative simple can still be relatively not easy? I don't think I misunderstood Rich Hickey, and I don't think I disagree. But I don't understand why people quote the opening sentence and feel so significant for them? To me, that is just a click-bate.
  • tempguy9999 7y ago
    > Simpler is easier than complex, right? Well, no. Complexity has an obvious price but simplicity does too. You have to work for simplicity, even fight for it. Think of code; it just somehow becomes more complex. You have to work to pare it back to what's needed. I can't think ATM of better examples (and you deserve some), but no, simplicity does not come easy. A nice phrase I came across: "elegance is refusal".
    • hzhou321 7y ago
      Until you find a good example, I challenge your understanding :) Similar to my response to another comment, I suspect there is a switching of subjects. It starts with a problem, and the subject is a solution to the problem. Simpler solution is easier to understand and manage. A more complex solution is more difficult. Is there a counter example? Try not to switch out the subject here. For example, one may propose to use a library to solve the problem by calling `library.solve`. And then one may argue that the simplicity of the code is actually more difficult to manage as one need trouble shoot all the details/bugs/interfaces with the library. We should recognize that the library itself is not the same as the solution. The solution includes the calling the library and its details/bugs/interfaces/packaging/updating/synchronizing etc. And these elements interwine to make the complexity. So the solution itself using the library is not necessarily simple. It is difficult exactly because of the complexity. As you can tell, I am essentially making the same opinion as Rich Hickey, which is `simple-made-easy`. And it is very far away from the click-bate opening statement of "simple is often erroneously mistaken for easy". A more correct sentence probably should be "simple is often erroneously labeled by partial". EDIT: To clarify, I am not saying a solution using a library is more complex. It depends. With a library, the solution is layered and delegated. The entire solution is more complex and more difficult to understand -- if one is to understand every byte of it. However, the layering means not all complexity need to be understood for practical reasons. So with proper layering and a good judgement of practicality, the part of the complexity that you practically need manage may well be simpler (and easier) by using a library, or not. It depends.
• nohuck13 7y ago
  Later in the talk, he draws a distinction between inherent complexity (the focus of the article) and incidental complexity (which you can fix without tradeoffs). Tradeoffs can be critically important, but the latter kind of complexity probably dominates my day-to-day life. I find this oddly encouraging, in a free-lunch sort of way. "And because we can only juggle so many balls, you have to make a decision. How many of those balls do you want to be incidental complexity and how many do you want to be problem complexity?" Watch the talk.
• hinkley 7y ago
  I think it's important to note that 'simple' can be used as an epithet.
• jolmg 7y ago
  Problem: Finely chopping food Complex and Easy: Stick blender with chopper attachment. Simple and Hard: Knife and cutting board. - Problem: Making a drawing Complex and Easy: Computer and printer Simple and Hard: Paper and pencil - Problem: Sewing lots of clothes (perfect stitches) Complex and Easy: Sewing machine Simple and Hard: Thread and needle - Problem: Software Complex and Easy: Graphical User Interface Simple and Hard: Command-Line Interface
  • msla 7y ago
    > Problem: Software > Complex and Easy: Graphical User Interface > Simple and Hard: Command-Line Interface GUIs are easy for the specific things the programmers made easy, and potentially impossible for everything else. The moment you want something the developers didn't put in the GUI, there's no recourse other than writing your own tool. Command lines are harder to begin with, but modern command lines give you a gentler ramp up to writing your own tools.
    • jolmg 7y ago
      Same is true with the other examples, I believe. Simpler tools tend to be the more versatile ones.
  • Ma8ee 7y ago
    In all your examples, the complexity is hidden in the underlying technology, which I think makes them less than ideal. Sewing with a sewing machine is usually both less complex and simpler than sewing by hand. If you count the complexity of the hardware and the operating system and compiler, nothing in development is simple. For me the dichotomy is better is better illustrated by: I need to create a new class that, with a few exceptions, does exactly what an existing class already does. The easy way is to copy the existing class and make the small necessary changes in the copy. The simple way would be to refactor and put all the differences in delegates.
    • jolmg 7y ago
      > both less complex and simpler Did you mean "easier"? Because complex and simpler are antonyms, so it seems kind of redundant to use both words. > the complexity is hidden in the underlying technology The complexity is there. Maybe not all get involved with it, but it's still there. > Sewing with a sewing machine is usually [simpler] than sewing by hand The technology is more complex. The operation is maybe on par, though I would think it's also more complex. I may be biased in that I've hand-stitched many times and I find it super-simple, but I'm still a bit intimidated at the prospect of learning the basic use of a sewing machine. For very basic hand-stitching, you just put the thread through the needle, and the needle through the clothes in some pattern. That's it. For the sewing machine, I guess you have to lead the thread through some parts of the machinery, select some stuff through the knobs, etc. I think there certainly is a need to know a bit on the construction and workings of the sewing machine to be able to fix issues that arise. > If you count the complexity of the hardware and the operating system and compiler, nothing in development is simple. Complex and simple are relative terms, after all. If you refer to the last example of CLI vs GUI, they both involve the OS and compiler, etc. so that cancels out and we can refer to one as simpler or more complex than the other just based on the differences. Now, if you compare software development to making a sandwich, then sure, nothing in software development is as simple as making a sandwich. > The easy way is to copy the existing class and make the small necessary changes in the copy. The simple way would be to refactor and put all the differences in delegates. I agree to that, and that also aligns with the examples I gave. The complexity is mainly in how the thing is constructed. Duplicated code adds complexity to how the program is constructed. When you want to make a change to the common code, you have to make the change twice, maybe with a few differences. That makes development of the program also more complex. It's the same as a sewing machine, or a stick blender with chopper attachment. Their construction and maybe operation is more complex than their counterparts.