Rich Hickey: Simple Made Easy

Normally I am opposed to chronic reposting but I have watched this video start to finish 5+ times and it has never been time wasted. It is an eloquent expression of a philosophy that has shaped how I approach problem-solving more than any other. If you've never watched it, you're doing yourself (and those who depend on your ability to efficiently and effectively solve problems) a disservice.

This was worth watching again so I'm glad it was reposted and brought back to my attention. I was as struck by it this time as when I was sitting in the room listening to him last year.<p>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.<p>I think in his summary at the end there are a few key statements he makes:<p>"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."

If, like me, you're overwhelmed with complexity in software projects, you need 'Out Of The Tar Pit'[1]. This essay is so good, I've read it four times, gaining new insights every time.<p>[1] <a href="http://web.mac.com/ben_moseley/frp/paper-v1_01.pdf" rel="nofollow">http://web.mac.com/ben_moseley/frp/paper-v1_01.pdf</a>

I like most of the points he makes but that "complect" business is fingers-on-a-chalkboard pretentious to my ears. "Coupling" and "complexity" are perfectly good words and have been used for decades to talk about this stuff.<p>But the stuff about how simplicity and easiness are not the same (at least in the short run) is very good.

I also recommend Rich's talk called hammock-driven development<p><a href="http://blip.tv/clojure/hammock-driven-development-4475586" rel="nofollow">http://blip.tv/clojure/hammock-driven-development-4475586</a><p><a href="http://www.popscreen.com/v/5WwVV/Hammockdriven-Development" rel="nofollow">http://www.popscreen.com/v/5WwVV/Hammockdriven-Development</a><p>or his recent talks about reducers or Datomic.<p>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.<p>This is the difference between blindly following known programming patterns (cargo-cult programming I would say) and really thinking about a design.

Been really impressed by the man, the language and the philosophy ever since I saw the video. Clojure has been a challenging and yet eye-opening experience, and I plan to continue learning it and using it in as many projects as I can from now on.

Tip: If the video and the slides don't fit on your widescreen display, shrink your browser window <i>horizontally</i>.

If you haven't seen it, Stuart Halloway's "Simplicity Ain't Easy" is a more Clojure-specific talk that's a nice complement to this one. It has some more concrete examples pulled from Clojure.<p><a href="http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-easy-4842694" rel="nofollow">http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-easy...</a>

I'm glad Rich and its presentation gets the popularity they deserve. I attended to that one at QCon London in March and it was the presentation that struck me the most.<p>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

If someone wants to do a talk about how to get as close to this as possible in a language like C++, I would watch it.

In a way dynamic typing is easy and static typing a la Haskell is pretty hard.<p>A good type system allows you to reason more easily about your system and checks if you're violating the rules of the system.<p>Looking at static typing and only see inheritance and the increased complexity, is only looking at static typing a la C++/Java.

Has anyone seen this recording and the newer one [1]?<p>Is one of them <i>better</i> in any form?<p><a href="http://www.infoq.com/presentations/Simple-Made-Easy-QCon-London-2012" rel="nofollow">http://www.infoq.com/presentations/Simple-Made-Easy-QCon-Lon...</a>

I get something new out of this every time I watch it.