As usual I'd like to first point out that my opinion should not be thought of highly. I'm just not experienced enough to be too confident on these high level things, but I'll share my opinion anyway.
I really like the heart of the message that Rich Hickey is presenting in that talk. I don't think I do a good enough job forcing myself to weigh the simplicity cost at each step of development.
However I do get a little frustrated with talks like this that claim to have a good idea at an abstract level, but haven't done the work of really converting that into something I can reason about. For instance, in this talk he starts with "simplicity is something we can measure" and then at no point even suggests a unit of measure or a way of taking measurements, nor does he actually demonstrate a single measurement of simplicity. Which leads to a situation where he asserts that "variables" are complex, and I am left wondering what on earth he is talking about.
In short: It sounds fine, but mostly impossible to turn into actionable advice given a lack of precise definitions.
I really like the heart of the message that Rich Hickey is presenting in that talk. I don't think I do a good enough job forcing myself to weigh the simplicity cost at each step of development.
However I do get a little frustrated with talks like this that claim to have a good idea at an abstract level, but haven't done the work of really converting that into something I can reason about. For instance, in this talk he starts with "simplicity is something we can measure" and then at no point even suggests a unit of measure or a way of taking measurements, nor does he actually demonstrate a single measurement of simplicity. Which leads to a situation where he asserts that "variables" are complex, and I am left wondering what on earth he is talking about.
In short: It sounds fine, but mostly impossible to turn into actionable advice given a lack of precise definitions.
Edited by Allen Webster
on
I'm a fan of his talks. :) Simple Made Easy and Hammock Driven Development and Are We There Yet are also good.
I'm not very experienced in Clojure, but I've poked around with it and read the first half of The Joy of Clojure. Clojure really does try to follow through on these ideas. Both of those Complex vs Simple tables are indirectly referring to Clojure features. I assume he's refraining from being explicit about those since he's speaking at a Ruby conference.
Of course not everyone would draw the same conclusions. E.g. he put classes under the "complex" heading, yet they added two type validation systems to the standard library: core/typed and core/schema. Also, the guy who wrote core/typed is looking into making yet another that would work more like typed Racket, so clearly the jury is still out with regards to that.
The thing that really resonated with me (I've been reorganizing horrible UI code at work so I can add more features) is simplicity as a defense mechanism versus simplicitly that provides opportunities.
Defensive simplicity is like a pathological application of compression-oriented programming, where you never take the time to reflect on what you're building. It's often not actually simple, just familiar, because it applies the same kludges you see in other parts of the codebase so at least everything is consistently terrible. It's almost always the "most obvious thing that could possibly work" strategy applied inappropriately.
Simplicity that arises from having separated out all of the constituent concepts takes time, but is really where you want to inevitably end up. It's an obvious idea, but there's no obvious technique to use that works every time.
I'm not very experienced in Clojure, but I've poked around with it and read the first half of The Joy of Clojure. Clojure really does try to follow through on these ideas. Both of those Complex vs Simple tables are indirectly referring to Clojure features. I assume he's refraining from being explicit about those since he's speaking at a Ruby conference.
Of course not everyone would draw the same conclusions. E.g. he put classes under the "complex" heading, yet they added two type validation systems to the standard library: core/typed and core/schema. Also, the guy who wrote core/typed is looking into making yet another that would work more like typed Racket, so clearly the jury is still out with regards to that.
The thing that really resonated with me (I've been reorganizing horrible UI code at work so I can add more features) is simplicity as a defense mechanism versus simplicitly that provides opportunities.
Defensive simplicity is like a pathological application of compression-oriented programming, where you never take the time to reflect on what you're building. It's often not actually simple, just familiar, because it applies the same kludges you see in other parts of the codebase so at least everything is consistently terrible. It's almost always the "most obvious thing that could possibly work" strategy applied inappropriately.
Simplicity that arises from having separated out all of the constituent concepts takes time, but is really where you want to inevitably end up. It's an obvious idea, but there's no obvious technique to use that works every time.
Edited by drjeats
on
Reason: formatting, wording
clojure is a funtional language built on top of the JVM, so no, it doesn't really align with this talk (but that's just my opinion). But I do like the ideas here, and I just wanted to add this to the list of good videos to watch for new people just dipping into the handmadedev waters.
I'm not sure, but I imagine that doing this and shipping software will be fighting each other the whole way.
I'm not sure, but I imagine that doing this and shipping software will be fighting each other the whole way.
Clojure is a Lisp variant.
When he says variables are complex, he means that they are more complex than values.
A value can't change, a variable can. Ergo a variable is more complex than a value.
Of course, I question whether this always leads to simpler code, sometimes adhering to immutability causes you to have to bend over backwards in other ways. As per usual, I would love to see claims about language design supported by experimental evidence rather than sophistry. We programmers are still in the pre-science era.
When he says variables are complex, he means that they are more complex than values.
A value can't change, a variable can. Ergo a variable is more complex than a value.
Of course, I question whether this always leads to simpler code, sometimes adhering to immutability causes you to have to bend over backwards in other ways. As per usual, I would love to see claims about language design supported by experimental evidence rather than sophistry. We programmers are still in the pre-science era.
MandleBro
We programmers are still in the pre-science era.
Yes this is my thinking too. We have a good handle on the mathematical method and the engineering method, but we have basically no grasp on the scientific method. And I think that's the best method for deciding between these "styles" or "approaches" or whatever.
MandleBroIncidentally, I feel between this and pure functions debugging is much easier. If old values live either further up in the stack or in different values in your watch window, reconstructing the flow of state in your mind is much easier (I think this might be true just reading the code, too) and jumping to a prior instruction is far less risky. So there are immediate benefits to it, and not just hand waving about complexity. Also if someone could come up with a nice syntax for it I'd get real use out of single static assignment's phi operator
Clojure is a Lisp variant.
When he says variables are complex, he means that they are more complex than values.
A value can't change, a variable can. Ergo a variable is more complex than a value.
Very inspiring talk, I identify to the basic idea of allowing future agility, more in the way tools are designed than final products. I don't know about the practical solutions proposed, like over-using maps for data, but it's interesting.
Nothings made me aware of this more than anyone, simple tools are the most effective, you don't want to recode the pillars all the time so it needs to be reusable and separate (simple). I lost so much time re-programming things in the past... When the time comes to make an actual product though, I just want to do the job, I don't necessarily want agility.
Nothings made me aware of this more than anyone, simple tools are the most effective, you don't want to recode the pillars all the time so it needs to be reusable and separate (simple). I lost so much time re-programming things in the past... When the time comes to make an actual product though, I just want to do the job, I don't necessarily want agility.
Edited by anaël seghezzi
on
cgag
He gets pretty concrete and actionable at around 26 minutes in, when he breaks down common techniques / language constructs he thinks are complex and suggests alternatives.
Except he barely explains them
Thanks for the link to the talk, I thought it was really interesting. I particularly liked the way he distinguishes between easy and simple. I've often come across (and caused) problems by at each stage doing the easiest rather than the simplest thing. With deadlines pressing it seems like the right thing to do (oh I'll just grab a library to do that for me) but every time I do that I add to the technical debt, making the program more complex and slowing things down in the long run. It's something I'm definitely keen to be more conscious of going forwards.
I'm a Clojure programmer by day. Many parts of the language do embody these ideas. It's a breathe of fresh air compared to working in OOP languages, that's for sure.
The parts that do embody these ideas are the emphasis on being explicit about state, pure functions, and using values as much as possible.
There are parts of the language which are more complex, like lazy sequences tend to bite people at times, but I think the main issue is being on the JVM (even though this is seen as a benefit too). You're just too far away from the machine. You have no control of memory layout, or the GC, and you are pretty much at the mercy of the JIT. Also you're naturally bound to the dependency management in the JVM ecosystem, and you do find Clojure projects with way too many dependencies as a result.
I understand there are also pragmatic reasons for being on the JVM (access to a host of libraries etc), but I don't think the tradeoffs of this are considered enough.
The parts that do embody these ideas are the emphasis on being explicit about state, pure functions, and using values as much as possible.
There are parts of the language which are more complex, like lazy sequences tend to bite people at times, but I think the main issue is being on the JVM (even though this is seen as a benefit too). You're just too far away from the machine. You have no control of memory layout, or the GC, and you are pretty much at the mercy of the JIT. Also you're naturally bound to the dependency management in the JVM ecosystem, and you do find Clojure projects with way too many dependencies as a result.
I understand there are also pragmatic reasons for being on the JVM (access to a host of libraries etc), but I don't think the tradeoffs of this are considered enough.