
Simplicity Matters – Rich Hickey (2012) [video] - hharnisch
https://www.youtube.com/watch?v=rI8tNMsozo0
======
schneems
I was at this talk and I disagree with his fundamental statement that simple +
simple = simple. I program in Ruby one of the biggest problems beginners make
is not creating complex data structures where they are needed. Instead they
pass around hashes of hashes of hashes. Why? Hashes are simple, they're easy
to understand and work with. Unfortunately this initial simplicity introduces
unexpected complexity, things like deep dup and deep merge are now needed.
Every part of your system must now know the hash structure you're using and
often reproduce logic in many places like dealing with optional keys that may
be missing. By not isolating the complexity to one part of the app it must now
be shared by the entire app. simple + simple !(always)= simple.

If I had a time machine and could make one change in an open source project it
would be to go back and remove the design choice of putting using hashes as
internal config objects in Rails. It makes understanding all the possible edge
cases almost impossible unless you're really familiar with the project.

The second is the claim of speed that this "simplicity" buys you. I agree that
functional programming is extremely fast when it's parallelized and it's
extremely easy to make a functional program parallelizable. When we're dealing
with sequential tasks, mutating data is much faster than allocating new data
structures. I think clojure helps with the speed of allocating new immutable
structures by using copy on write strategies behind the scenes.

I think Rich is an extremely smart and very accomplished programmer. I think
functional programming is really good at some things, I don't feel like many
people talk about the things it's not good at. To me we if we're not embracing
and explore all a new concept/language/paradigm strengths and weaknesses,
we're not growing by being exposed to that thing.

~~~
jules
> Unfortunately this initial simplicity introduces unexpected complexity,
> things like deep dup and deep merge are now needed.

Not if your data structures are immutable, which is exactly what he is
advocating.

~~~
schneems
Excellent point, I honestly hadn't considered that. I've spent more time
dealing with functional programming than in actual languages with immutable
structures. Thanks for pointing that out.

I think my other point still stands, things like optional keys, or missing or
required keys still must be shared throughout the app. Everything that touches
that hash needs to know its structure.

~~~
lorddoig
Having to know the structure of a hash/map/dict is strictly superior to having
to know the methods and fields of an object. For any given task the two are
equivalent, except that one is easily modified/reused/passed to other callers
without creating an extremely brittle class hierarchy you're only going to
have to rearchitect when your requirements change. As an IBM researcher
looking at Watson waaaay before Watson actually existed: "OOP requires you to
treat _all_ extrinsic information as if it were intrinsic to the object
itself." This is tantamount to saying you must have a complete and consistent
programme design before you write a single line. Which is crazy (and probably
the reason UML exists.) But don't take my word for it, think it through, it's
the only conclusion you can reach, I think.

------
natrius
The simplicity culture is what drove me to Python, and the Clojure community's
simplicity culture is on a whole other level. It's not just the code and
syntax that need to be simple. The abstractions in the program need to be
simple as well, and Clojure gives you the tools to make simple abstractions
easy to build and understand.

Go learn Clojure.

~~~
erikpukinskis
> Clojure gives you the tools to make simple abstractions easy to build and
> understand.

I understand if you don't want to take the time, but I would love it if you
could you give an example of an abstraction that you can build in Closure that
you would consider "easy to understand", yet which couldn't be built just
with, say, anonymous functions, structs, arrays, and simple loops?

~~~
edgyswingset
I think it comes down to expressing your intent in terms of that intent rather
than confining it to imperative constructs. Pretty much any work on
collections of items is generally simpler and more in line with the semantics
of your intentions when working with Clojure or other functional languages or
structures, especially when parallel code is involved.

I'd say a specific example would be pmap. It's very difficult to parallelize
code as simply as pmap does without functional programming constructs.

~~~
erikpukinskis
Hm. I'm looking at the implementation[1] of pmap.... I don't fully understand
the implementation (can anyone point me to something that explains what rets
is? Googling "clojure rets" doesn't return anything useful) but it appears to
just be looping through the list and parcelling work out to multiple
processors. That seems like something simple enough to do in any language with
threads and function references, no?

I'll dig in some more though. Thanks for the reference.

[1]
[https://github.com/clojure/clojure/blob/master/src/clj/cloju...](https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6709)

~~~
edgyswingset
To me it comes down to what my intent with the code is.

I could write a few simple routines in Go that certain get the job done
without much code, but when I read the code I have to perform more mental
translation from how the code is written to what my intent was.

In contrast, pmap or other constructs such as PLINQ get the same work done
with less code that expresses my intent more clearly.

------
mpdehaan2
While simplicity may matter, I believe Clojure to be a poor example of it --
it's a lot of functions all thrown together in basically one namespace, with
poor error handling, and a tendancy to throw a 50 line traceback with a lot of
random symbols in it.

Clojure macros are the antithesis of simple, and the need to indent a scope
for every new variable actually fights against TDD in my experience.

I recently wrote a good chunk of a RESTful SQL-backed application in Python in
two days that took a team of 3 people in Clojure over 2 months to just get to
the basic level of library support one would expect from things like
sqlalchemy and flask.

Clojure isn't simple -- it's basically a step up from assembler in how little
it provides.

Simplicity is having all the power tools and being able to put them together
and be instantly productive, and to support programming in multiple paradigms.

While it's not the norm, I sometimes feel many FP purists spend so much time
debating purity and giving basic concepts complex names - when they could be
using something else and getting much more done.

Side effects aren't the devil and are sometimes neccessary to get real work
done. Bad code can be written in anything, and it just takes experience.

I'd much rather see a language focus on readability, maintaince, and rapid
prototyping than side effects.

Functional programming concepts have benefits - I love list comprehensions and
functools.partial in python is pretty neat, but when you can also have a
decent object system, and embrace imperative when steps are truly imperative,
you can get a whole lot more done.

~~~
Daishiman
It's unfortunate that you got downvoted, because while people may not agree
with this there is definitely something to this.

My approaches to Clojure have been seriously hampered by the fact that some of
the abstractions above those that are "simple" are remarkably complex, and
that the tools that surround the ecosystem are still pretty frail.

Macro bugs are certainly something that have scared me away for a while.

~~~
j-pb
Macros are for extending the language, I have never in 2 years of professional
clojure dev, used a single macro in problem domain code. I've written a few
libraries that are supposed to extend the language, but I've only used them
rarely there too, maybe under a dozen times.

~~~
Daishiman
Sure, but when there's bugs in the caller of macros I have to figure out what
exactly is going on, and that's where the rubber meets the road.

------
pella
"talk-transcripts : Rich Hickey "

\- Inside Transducers (11/2014)

\- Transducers (09/2014)

\- Implementation details of core.async Channels (06/2014)

\- Design, Composition and Performance (11/2013)

\- Clojure core.async Channels (09/2013)

\- The Language of the System (11/2012)

\- The Value of Values (07/2012)

\- Reducers (06/2012)

\- Simple Made Easy (9/2011)

\- Hammock Driven Development (10/2010)

\- Are we there yet? (09/2009)

[https://github.com/matthiasn/talk-
transcripts/tree/master/Hi...](https://github.com/matthiasn/talk-
transcripts/tree/master/Hickey_Rich)

------
serve_yay
I love Rich Hickey and I will watch any talk he ever gives. I believe I have
seen them all at current.

Here's what drives me nuts about this one, though - it gets passed around a
lot where I work, and people say how strongly they agree with him. There are
real, concrete things he claims are not simple here! Things like for loops.
And these people I'm talking about, they say they love this talk and then they
say they love for loops. Really! I don't get it.

~~~
vezzy-fnord
It's one thing to recognize simplicity versus ease of use, it's a wholly
different thing to apply it. Ease of use is what is most trivially observable
by an end user. Actually understanding the nature of the problem domain and
properly evaluating architectures beyond making sweeping inferences from what
the interface looks like, that is significantly more difficult. Despite all
the lip service that gets payed towards simplicity, most people do not want it
and it will be met by derision and scorn if the simple solution imposes a
higher learning curve or does not make policy and integration decisions for
the user. Especially considering the culture of coding bootcamps, DevOps, "get
shit done" and "move fast and break things" by and large promotes an anti-
intellectualism that is in stark opposition to deeply evaluating problem
domains so you can come up with simple solutions.

~~~
serve_yay
Right, and so what you get is people saying something is "simple" when what
they really mean is that they like it. Which is of course not Hickey's fault,
it just irks me for some reason.

------
draegtun
Carl Sassenrath is another programming language designer who as long been a
proponent for _simplicity_.

Some links:

* _Definition of Simple_ (2011) - [http://www.rebol.com/article/0509.html](http://www.rebol.com/article/0509.html)

* _Fight Software Complexity Pollution_ (2010) - [http://www.rebol.com/article/0497.html](http://www.rebol.com/article/0497.html)

* _Contemplating Simplicity_ (2005) - [http://www.rebol.com/article/0127.html](http://www.rebol.com/article/0127.html)

