Rich Hickey: Simple Made Easy
infoq.com
infoq.com
Reading the comments on the infoQ page jogged my memory a bit. I remember thinking that his concept of "complect" was the same as "connascence" - a term I learned from a Jim Weirich talk [1]. Minimizing complectity/connascence (variables shared between modules) is good.
Is there something more striking (and summarizable) I should have remembered?
1. http://www.bestechvideos.com/2009/03/29/mountainwest-rubycon...
It's mainly the basic philosophy that Hickey focuses on that changed a lot for me, not any of the specific examples. After watching Hickey I've read great books such as Pragmatic Programmer, Passionate Programmer, Coders at Work, and other books that have helped me, as a recent university graduate, build my "coding philosophy". Hickey was just a very inspiring "first step" in changing how I look at code.
Another example, where I immediately thought of simple/easy as it came up: I realized the other day that a component of an app I've been designing serves two almost independent purposes, and I can drastically simplify the design by making separate components.
The video you linked doesn't seem to be available anymore. The slides are available on scribd, but they don't seem to make much sense without the context of the talk.
He mentions that back in the 70s he was writing Fortran for NASA and his mentor recommended he read a book called Composite/Structured Design. "Structured Design" was the big thing back then and the controversy was using if-else and while loops instead of Gotos. Nobody was worried about strongly vs weakly typed langauges (perl!).. Key chapter in that book is on Coupling and Cohesion.
Junp to the late 90s for his second book recommendation: "What Every Programmer Should Know About Object-Oriented Design", really just the third part of the book which introduces "connascence". Two pieces of software share connascence when a change in one requires a corresponding change in the other.
I love the historical angles on this stuff.
What I would like to see, or create if I have to, is a condensed version of this argument that is meant for the non-programmers, the managers, and the c-level employees of a business. The underlying premise of believing in and executing with simplicity is one that nearly requires air support, and buy-in.
I think in his summary at the end there are a few key statements he makes:
"The bottom line is that simplicity is a choice. It's your fault if you don't have a simple system.... it requires constant vigilance... You have to start developing sensibilities about entanglement... You have to have entanglement radar... You have to start seeing the interconnections between things that could be independent."
But the stuff about how simplicity and easiness are not the same (at least in the short run) is very good.
"Complicate" was a candidate, but is decidedly unsatisfying. It just means "make complex", saying nothing more about how; nor about what it means to be complex. For many people, simply adding more stuff is to "complicate", and that was another presumption I wanted to get away from. There is also some intention in "complicate", as in, "to mess with something", vs the insidious complexity that arises from our software knitting.
I wanted to get at the notion of folding/braiding directly, but saying "you braided the software, dammit!" doesn't quite work :)
Reasonable people can obviously have different associations, but I thought "coupling" and "decoupling" were pretty standard terms in software. You know, "low coupling high cohesion" and all that.
What about when we simplify a design by removing dependencies between things? Surely we're not going to say we've "decomplected" them?
It goes without saying that we agree on the more important point, which is that whatever we call that thing we do to software where we make everything depend on everything, we fuck it up :)
Simplified.
tr. & intr.v. com·pli·cat·ed, com·pli·cat·ing, com·pli·cates
1. To make or become complex or perplexing.
2. To twist or become twisted together.
* ---> To make or become complex <--- *
Why did we need this complect business again?
The word "complicated" is generally synonymous with the word "complex", but that doesn't matter - the word "simple" is generally synonymous with the word "easy", after all. If Rich Hickey had said "complicate" viewers may well have asked whether he meant "to make complex" or "to make complicated", and perhaps wonder whether he was trying to draw a distinction between those concepts as well.
The word is now strongly connected to the concepts of easy and simple which Rich tries to untangle. From now on, when you hear someone tell you that you have "complected" something, it will most likely cause you to remember the talk and sort of forces you to think.
Just hearing talk about "coupling" might not trigger such a reaction.
http://blip.tv/clojure/hammock-driven-development-4475586
http://www.popscreen.com/v/5WwVV/Hammockdriven-Development
or his recent talks about reducers or Datomic.
For me the talk about reducers was especially jaw-dropping experience because it was about something simple we all do every day - crunching data in collections (how many times you have implemented lists library? :). Yet after decades of collection traversing, there is a still a place for fresh approach, if you are willing to thing hard.
This is the difference between blindly following known programming patterns (cargo-cult programming I would say) and really thinking about a design.
http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-easy...
Rich gave also another presentation about the modeling process that I find great (slides from Goto Con) : gotocon.com/dl/jaoo-aarhus-2010/slides/RichHickey_ModelingProcess.pdf
Having properties like immutability and pureness in your language makes it lot easier to trust your code and to reason about it.
Please, read exactly.
"... unless you're working in Haskell and even there you could find ways to screw things up by interacting with the outside world, which isn't immutable."
The whole point is, that you're able to express immutability and pureness in a language like Haskell _AND_ have a compiler which can verify it.
You will never be able to prohibit any screwing, but you can make it a lot harder to screw something.
X = 5.
X2 = X+1.
const int x = 5;
const int x2 = x + 1.
const_cast isn't the big issue, because there's also unsafePerformIO in Haskell. For both you could say, that they shouldn't be used, that it's bad programming practice to use them.
The point is, even if you follow good programming practices in C++, you can't express them and your compiler can't help you in the verification, if you're really following them.
That doesn't might seem like a big thing, it's also not related to your smartness, because it mostly depends on the size and complexity of your system.
A good type system allows you to reason more easily about your system and checks if you're violating the rules of the system.
Looking at static typing and only see inheritance and the increased complexity, is only looking at static typing a la C++/Java.
Is one of them better in any form?
http://www.infoq.com/presentations/Simple-Made-Easy-QCon-Lon...