But the stuff about how simplicity and easiness are not the same (at least in the short run) is very good.
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.
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?
Having properties like immutability and pureness in your language makes it lot easier to trust your code and to reason about it.
X = 5.
X2 = X+1.
const int x = 5;
const int x2 = x + 1.
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...
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."
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
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...