
Rich Hickey: Simple Made Easy - kjbekkelund
http://www.infoq.com/presentations/Simple-Made-Easy
======
mattdeboard
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.

~~~
kjbekkelund
I'm also opposed to reposting, but I mention this talk to people all the time
and nearly none have seen it. Those who have, however, all agree that it is an
amazing (and eye-opening) talk. I just saw it again today for the first time
in half a year and realized how much it has actually changed how I develop
software.

~~~
kylebrown
I watched this a few months ago but don't remember much other than simple !=
easy. I thought I had taken notes, but turned out I had it confused with a Dan
Ingalls talk on OO from 1989 I watched around the same time (which I found
interesting enough to take notes).

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...](http://www.bestechvideos.com/2009/03/29/mountainwest-
rubyconf-2009-the-building-blocks-of-modularity)

~~~
Estragon
The simple vs easy concept is broader than data sharing. One example is perl,
which is quite easy to pick up but complects many things, like strings
representing numbers being silently coerced into numeric values.

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.

~~~
kylebrown
Thanks. This one is working: [http://confreaks.com/videos/77-mwrc2009-the-
building-blocks-...](http://confreaks.com/videos/77-mwrc2009-the-building-
blocks-of-modularity)

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.

------
ghotli
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.

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."

------
_sh
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.

[1] <http://web.mac.com/ben_moseley/frp/paper-v1_01.pdf>

~~~
brown9-2
Ugh, somehow in the 3 days since you've posted this the URL just returns a
default "MobileMe is closed" page.

~~~
_sh
There's this: <http://shaffner.us/cs/papers/tarpit.pdf>

------
skardan
I also recommend Rich's talk called hammock-driven development

<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.

------
gruseom
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.

But the stuff about how simplicity and easiness are not the same (at least in
the short run) is very good.

~~~
repsilat
"Coupling" and "complexity" are nouns, "complect" is a verb. Complect is to
complex as complicate is to complicated - It means "complexify" for those who
prefer archaisms to neologisms.

~~~
gruseom
"Couple" is of course a verb. There are other words people have long used for
this too. There's no need for obscure new jargon, and it's ironic that a talk
about simplicity would introduce any. It gives the wrong impression, because
these concepts are neither new nor difficult. What's difficult is building
systems that respect them.

~~~
richhickey
"Coupling" has always been a particularly weak word for the software problems
to which it's been applied, IMO. After all, when you connect 2 Legos together
you couple them.

"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 :)

~~~
gruseom
As far as how we use these words in software goes, I think "coupling" is just
fine. To me it means exactly what we're talking about: making things depend on
each other. "When you connect 2 Legos together you couple them" sounds off to
me. I'd say that's just what you don't do. Rather, you compose them.
Composition to me means putting together things that have no intrinsic
dependency and are just as easy to separate again.

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 :)

~~~
richhickey
> Surely we're not going to say we've "decomplected" them?

Simplified.

~~~
gruseom
But that has the same problem you mentioned about "complicate". It just means
"make simple", saying nothing more about how, nor about what it means to be
simple. Not all simplification is disentangling.

------
BadassFractal
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.

------
gamzer
Tip: If the video and the slides don't fit on your widescreen display, shrink
your browser window _horizontally_.

~~~
akkartik
Or click on 'horizontal' and then on 'fullscreen'.

~~~
vdm
And then click 'X' to close the meaningless countdown timer early.

------
spacemanaki
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.

[http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-
easy...](http://blip.tv/clojure/stuart-halloway-simplicity-ain-t-easy-4842694)

------
jgrodziski
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.

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

------
jamesaguilar
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.

~~~
dan00
The issue with languages like C++ is, that you can follow better programming
practices, but the compiler doesn't support you in the verification and
accordingly you can't trust that easily your code, which complicates the
reasoning about a system a lot.

Having properties like immutability and pureness in your language makes it lot
easier to trust your code and to reason about it.

~~~
bad_user
Clojure doesn't give you immutability guarantees, it just makes it harder to
chose otherwise, but on the other hand calling a Java method on some object is
just one special form away. I'm not saying Clojure does the wrong thing here
btw, but this thing you're talking about is a fallacy, 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.

~~~
dan00
"I'm not saying Clojure does the wrong thing here btw, but this thing you're
talking about is a fallacy ..."

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.

------
dan00
In a way dynamic typing is easy and static typing a la Haskell is pretty hard.

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.

------
abp
Has anyone seen this recording and the newer one [1]?

Is one of them _better_ in any form?

[http://www.infoq.com/presentations/Simple-Made-Easy-QCon-
Lon...](http://www.infoq.com/presentations/Simple-Made-Easy-QCon-London-2012)

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

