Fantastic talk, covering the difference between “simple” and “easy”, and how (when you can’t have both) the former is preferable.
I find it interesting that Python, despite being widely described as a simple language, takes the opposite approach. The language isn’t simple at all [0], it prefers to make things easy. This preference even appears (in the contrapositive) in the “Zen of Python”: “Complex is better than complicated.”
As a specific example, Python 3.7 introduced dataclasses, making them dependent on type hints when they could have been completely orthogonal. The language design ignored this talk’s advice against “complecting” features.
> I wrote a #clojure program for logic A in 4 hours. I've been asked to rewrite it in #python because of some product requirements. It's been 3 days since i've started and still on the first 25% of it. Note: I'm using python for more than 13 years.
Yeah, no way that's true if his python and clojure knowledge are at the same level. That tweet sounds like what you see on r/clojure all the time, a cult.
All of the Rich Hickey talks I watched (there are many!) are insightful and entertaining. He manages to talk about technical things on a abstract, sometimes philosophical level. I even re-watched some talks after a couple of years and got something new out of them.
One of the most entertaining ones I watched was "Spec-ulation". It is less general than some of the more shared/cited ones but really funny.
This talk had a profound effect on how I think about complexity, and taught me not to conflate easy and simple, 2 words in english that are often treated as synonyms. It really opened my eyes to how much tooling we use as devs (particularly in ops) that hides much of the complexity of a system. I’m much more dubious now whenever a tool comes around that makes X easier, and look for any added costs to complexity to see if there’s a hidden tradeoff.
This talk turned an inflection point in my career. The physical metaphor of a braid and having that braid straightened out applies to so many areas of software. "Unbraidedness" is a very useful (albeit informal) measure of quality for me. It helps me detect when something's not right, as well as hinting how I can help straighten it out.
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?!
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.
Wow it has been close to a decade since then. Is there a simple made Easy 2? He presents a number of grandiose ideas, it would be interesting to see what he thinks he got right and what went off the rails.
He indirectly recognized the importance of declaring the shape of data 6 years later by introducing spec, which to date still has big issues and screams "just use a proper statically typed language".
Everytime I read your name, you subtile spread some negativity :)
Maybe Hickey just didn't prioritized "types" as high as some other ideas to spend his time on. And in my opinion he focused on the right things and achieved something really great.
As general advice stay positiv, focus on the things you like instead of telling everyone what you don't like, it's better for your mental health ;)
> spec, which to date still has big issues and screams "just use a proper statically typed language"
I think this statement is unfair.
I don't think there is a widely used statically typed language that is nearly as expressive and simple as spec. Also the opt-in nature of it retains the advantages of dynamic typing.
There's no "proper statically typed language." Every single statically typed language I tried, comes with certain drawbacks. However, I'd like to add - I do miss sometimes static types in dynamic langs, including Clojure. Bottom line - there are truly no silver bullets. That's why we keep inventing new programming languages and new paradigms. But of course, once we pick up one "religion," we feel compelled to yell at others: "you're doing it wrong!"
I believe conditionals is referring to if statements (and their ilk, switch/case/cond etc). Rules is referring to rule systems and/or more generally declarative knowledge systems. Things like core.logic in clojure (or prolog, datalog and minikanren in the wider world).
Stuff like this is not specific to clojure, however it would be harder to have an embedded rules system in your language if its not a lisp. You'd probably have have to resort to a string based DSL (something like drools in java).
Fantastic talk, covering the difference between “simple” and “easy”, and how (when you can’t have both) the former is preferable.
I find it interesting that Python, despite being widely described as a simple language, takes the opposite approach. The language isn’t simple at all [0], it prefers to make things easy. This preference even appears (in the contrapositive) in the “Zen of Python”: “Complex is better than complicated.”
As a specific example, Python 3.7 introduced dataclasses, making them dependent on type hints when they could have been completely orthogonal. The language design ignored this talk’s advice against “complecting” features.
[0] https://twitter.com/raymondh/status/1280946969116995584
https://twitter.com/lxsameer/status/1273546170137300992
> I wrote a #clojure program for logic A in 4 hours. I've been asked to rewrite it in #python because of some product requirements. It's been 3 days since i've started and still on the first 25% of it. Note: I'm using python for more than 13 years.
Yeah, no way that's true if his python and clojure knowledge are at the same level. That tweet sounds like what you see on r/clojure all the time, a cult.
6 replies →
All of the Rich Hickey talks I watched (there are many!) are insightful and entertaining. He manages to talk about technical things on a abstract, sometimes philosophical level. I even re-watched some talks after a couple of years and got something new out of them.
One of the most entertaining ones I watched was "Spec-ulation". It is less general than some of the more shared/cited ones but really funny.
Anyone else interested it is available at https://www.youtube.com/watch?v=oyLBGkS5ICk
This talk had a profound effect on how I think about complexity, and taught me not to conflate easy and simple, 2 words in english that are often treated as synonyms. It really opened my eyes to how much tooling we use as devs (particularly in ops) that hides much of the complexity of a system. I’m much more dubious now whenever a tool comes around that makes X easier, and look for any added costs to complexity to see if there’s a hidden tradeoff.
I highly recommend giving the talk a listen to.
This talk turned an inflection point in my career. The physical metaphor of a braid and having that braid straightened out applies to so many areas of software. "Unbraidedness" is a very useful (albeit informal) measure of quality for me. It helps me detect when something's not right, as well as hinting how I can help straighten it out.
Even the informal concept is useful, but I suspect it could be formalized. I'd love to hear from a theoretical CS person about that notion.
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?!
2 replies →
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.
1 reply →
Wow it has been close to a decade since then. Is there a simple made Easy 2? He presents a number of grandiose ideas, it would be interesting to see what he thinks he got right and what went off the rails.
That’s precisely what this is, including what he got right &c — “10 Years of Clojure” https://youtu.be/2V1FtfBDsLU
He indirectly recognized the importance of declaring the shape of data 6 years later by introducing spec, which to date still has big issues and screams "just use a proper statically typed language".
Everytime I read your name, you subtile spread some negativity :)
Maybe Hickey just didn't prioritized "types" as high as some other ideas to spend his time on. And in my opinion he focused on the right things and achieved something really great.
As general advice stay positiv, focus on the things you like instead of telling everyone what you don't like, it's better for your mental health ;)
> spec, which to date still has big issues and screams "just use a proper statically typed language"
I think this statement is unfair.
I don't think there is a widely used statically typed language that is nearly as expressive and simple as spec. Also the opt-in nature of it retains the advantages of dynamic typing.
There's no "proper statically typed language." Every single statically typed language I tried, comes with certain drawbacks. However, I'd like to add - I do miss sometimes static types in dynamic langs, including Clojure. Bottom line - there are truly no silver bullets. That's why we keep inventing new programming languages and new paradigms. But of course, once we pick up one "religion," we feel compelled to yell at others: "you're doing it wrong!"
I wonder what he meant by "Rules" (compared to "Conditions"), in his table where he describes "Complexity" vs "Simplicity".
Is it some kind of paradigm that exist in Clojure but not in procedural languages?
I believe conditionals is referring to if statements (and their ilk, switch/case/cond etc). Rules is referring to rule systems and/or more generally declarative knowledge systems. Things like core.logic in clojure (or prolog, datalog and minikanren in the wider world).
Stuff like this is not specific to clojure, however it would be harder to have an embedded rules system in your language if its not a lisp. You'd probably have have to resort to a string based DSL (something like drools in java).