Comment by tdrgabi
5 years ago
I see this talk given as an example of best talks. I watched it twice. I'm obviously in a minority here, but I don't get it. I hear just truisms. Like: "It's better to be rich and healthy than poor and sick." I know it's hard to summarize a talk in a few paragraphs, but what big point did you get out of it. Honest question, I'm genuinely interested.
1) easiness is subjective, simplicity is objective.
2) simple code is easy to read, but hard to write.
If you're a programmer, and you're not surrounded by people conflating both words, consider yourself lucky. What does a coworker really means by "I did the simplest possible thing" ?
Ok. So it might be a language thing. Not being a native, easy and simple from pov of a customer is the same for me.
For example, for me, statement 1 is false. Simplicity is also subjective
I am one of the people conflating the terms. Are they used from the devs pov? Like what's easiest for you (add one more parameter to this function or another special case handled with its) might make things more complicated.
From the customer pov simple or easy is the same, or?!
It is a language thing, even for native speakers :) That is why he went to a lot of trouble to define each term in the beginning, and kept referring back to his opening definitions throughout the talk:
Simple = One thing not 'mixed - linked - folded' with anything else. That's why he says it is objective - if you look at something and see it's mixed up with something else, it's not simple (in his terms, now it's complex - eg many things woven together)
Easy = Near to you. Near in as you know it already, or you have it already and so on.
His talk is for the dev pov, but even outside of dev, simple does not mean easy all the time.
For example, (and something I am struggling with right now) it is simple to lose weight - eat less calories than you burn each day. Simple.
But I can attest it is far from easy.
1 reply →
The core idea is to separate ease from simplicity and to talk about the implicit trade-offs of adhering to one over the other.
He claims that certain (often popular) tools and practices adhere to ease rather than simplicity, which introduces accidental complexity. And he introduces term „to complect“ which is now widely used in the Clojure community.
Many of the concepts and comparisons he talks about can be found in the design of Clojure and Datomic.
What is simplicity and how it differs from ease? I haven’t got a chance watching the talk yet.
Simplicity is described as being "disentangled" or the opposite of complexity.
I personally often picture complexity as a graph of nodes and edges:
- The more edges you add, the more complex the thing it describes.
- The more rules you can deduce about the graph (for example "it is a unidirectional circle-like") such as the flow of the edges, counting etc. the less complex it is.
The imagery in the talk describes it similar: Complexity is more knotted and interwoven. Simplicity is more straight-forward, clear and composable.
Ease is described as something being "near", also in the dimension of time. Something you already know or can learn/do quickly.
The talk goes on describing how simplicity requires up-front investment and time to achieve and also how ease and simplicity sometimes overlap and when they are at odds.