8 ms·

Simplicity Matters – Rich Hickey (2012) [video]

126 points by hharnisch 11y ago

natrius 11y ago
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.
- atom-morgan 11y ago
  I just started BraveClojure today. I've said "next week" enough times. http://www.braveclojure.com/ http://www.braveclojure.com/
- dustingetz 11y ago
  Yeah, Python : 1999 :: Clojure : 2015 edit: state of adoption and perceived coolness, not birth year. Coincidentally, Python 1.0 released in 1994 and Clojure 1.0 was released in 2009, and both had a couple years of unstable releases predating 1.0
  - jeremiep 11y ago
    Clojure is actually from 2006 after two years of planning and development.
    - aaron-lebo 11y ago
      Yeah, but Python is not from 1999, so they were referencing something else: either personal adoption or language take-off.
- agumonkey 11y ago
  Many choices are 'sacrifices' that bring so much simplicity. Syntax, persistent data structures, ... I hope I can jump back to clojure soon.
- davexunit 11y ago
  Or learn another Lisp. I recommend Guile Scheme and Racket.
  - aaron-lebo 11y ago
    You may get just as much pedagogical advantage from learning one of those, but Clojure will be much more practical with its JVM base. Besides, I know lispers hate the idea, and it may not even be necessary, but uniting behind a single good-enough lisp like Clojure will reap more rewards then advocating for multiple (while still good) Scheme implementations.
    - davexunit 11y ago
      Here we go again with the "any Lisp that isn't Clojure isn't practical" argument. I disagree. Guile and Racket are plenty practical, and both have dynamic FFIs to any C library you want so I couldn't care less about using Java and its terrible VM boot time and build systems. I'm not interested in "good enough" when I've already been using something better for years.
      - siavosh 11y ago
        Curious if you could tell us more about what you've worked on with Guile/Racket in a production environment?
        davexunit 11y ago
        I'm not the persuasive person that convince the bosses to use Scheme, so I don't have a triumphant success story, but some minor victories. I'm one of the core developers of GNU Guix (a package manager, distro, and associated set of tools) that recently was deployed successfully in a large production HPC cluster in Germany, which I think is a pretty nice achievement. At work, I use Guix and an init system called DMD (also written in Guile) a lot for development, and I'm trying to slowly work them into production via Docker. It's an uphill battle to advocate for something that isn't the status quo, so I'm proud of the little victories.
- erikpukinskis 11y ago
  > 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 11y ago
    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 11y ago
      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/clojure/core.clj#L6709 https://github.com/clojure/clojure/blob/master/src/clj/cloju...
      - hellofunk 11y ago
        in this code, "rets" is a local variable used in that function, which is why it wouldn't show up anywhere in google. it's just a variable name.
      - edgyswingset 11y ago
        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.
schneems 11y ago
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 11y ago
  > 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.
  - hellofunk 11y ago
    Exactly; the whole idea of "deep dup" doesn't even exist in Clojure. It's a non-issue. Some languages go so far as to encourage actually serializing and then reading back in a data structure as a form of doing a deep duplication! (I've done this in Objective-C, based on advice in popular books.) This is an extreme example of the pitfalls of mutable data in many circumstances.
serve_yay 11y ago
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 11y ago
  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 11y ago
    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.
- tikhonj 11y ago
  It's perfectly reasonable to agree wholeheartedly with his core idea (easy vs simple) but disagree with his particular pronouncements on what is and isn't simple. Which could involve for loops. Now, personally, I don't have much to say about for loops one way or the other. But I do disagree with him on types, which can be far less complex than he intimates. System F, say, which largely covers F#, OCaml and Haskell, can be completely defined as a handful of self-evident rules. A single page for both checking and inference, if in somewhat dense notation. That's not complex at all, especially since it follows fairly naturally from the way the lambda calculus works even without types. To me, that seems like a perfectly consistent view. Nothing forces you to take everything he says or leave it: you can find it accurate piecemeal. Take the mental framework but apply it with your own knowledge and experience and you could very well come up with your own conclusions. Seems like the perfect way to use ideas like this.
mpdehaan2 11y ago
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.
- deleted 11y ago
  [deleted]
- Daishiman 11y ago
  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 11y ago
    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.
pella 11y ago
"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/Hickey_Rich https://github.com/matthiasn/talk-transcripts/tree/master/Hi...
draegtun 11y ago
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

126 points by hharnisch 11y ago

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.

atom-morgan 11y ago
I just started BraveClojure today. I've said "next week" enough times. http://www.braveclojure.com/ http://www.braveclojure.com/
dustingetz 11y ago
Yeah, Python : 1999 :: Clojure : 2015 edit: state of adoption and perceived coolness, not birth year. Coincidentally, Python 1.0 released in 1994 and Clojure 1.0 was released in 2009, and both had a couple years of unstable releases predating 1.0
- jeremiep 11y ago
  Clojure is actually from 2006 after two years of planning and development.
  - aaron-lebo 11y ago
    Yeah, but Python is not from 1999, so they were referencing something else: either personal adoption or language take-off.
agumonkey 11y ago
Many choices are 'sacrifices' that bring so much simplicity. Syntax, persistent data structures, ... I hope I can jump back to clojure soon.
davexunit 11y ago
Or learn another Lisp. I recommend Guile Scheme and Racket.
- aaron-lebo 11y ago
  You may get just as much pedagogical advantage from learning one of those, but Clojure will be much more practical with its JVM base. Besides, I know lispers hate the idea, and it may not even be necessary, but uniting behind a single good-enough lisp like Clojure will reap more rewards then advocating for multiple (while still good) Scheme implementations.
  - davexunit 11y ago
    Here we go again with the "any Lisp that isn't Clojure isn't practical" argument. I disagree. Guile and Racket are plenty practical, and both have dynamic FFIs to any C library you want so I couldn't care less about using Java and its terrible VM boot time and build systems. I'm not interested in "good enough" when I've already been using something better for years.
    - siavosh 11y ago
      Curious if you could tell us more about what you've worked on with Guile/Racket in a production environment?
      - davexunit 11y ago
        I'm not the persuasive person that convince the bosses to use Scheme, so I don't have a triumphant success story, but some minor victories. I'm one of the core developers of GNU Guix (a package manager, distro, and associated set of tools) that recently was deployed successfully in a large production HPC cluster in Germany, which I think is a pretty nice achievement. At work, I use Guix and an init system called DMD (also written in Guile) a lot for development, and I'm trying to slowly work them into production via Docker. It's an uphill battle to advocate for something that isn't the status quo, so I'm proud of the little victories.
erikpukinskis 11y ago
> 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 11y ago
  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 11y ago
    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/clojure/core.clj#L6709 https://github.com/clojure/clojure/blob/master/src/clj/cloju...
    - hellofunk 11y ago
      in this code, "rets" is a local variable used in that function, which is why it wouldn't show up anywhere in google. it's just a variable name.
    - edgyswingset 11y ago
      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.

schneems 11y ago

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 11y ago
> 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.
- hellofunk 11y ago
  Exactly; the whole idea of "deep dup" doesn't even exist in Clojure. It's a non-issue. Some languages go so far as to encourage actually serializing and then reading back in a data structure as a form of doing a deep duplication! (I've done this in Objective-C, based on advice in popular books.) This is an extreme example of the pitfalls of mutable data in many circumstances.

serve_yay 11y ago

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 11y ago
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 11y ago
  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.
tikhonj 11y ago
It's perfectly reasonable to agree wholeheartedly with his core idea (easy vs simple) but disagree with his particular pronouncements on what is and isn't simple. Which could involve for loops. Now, personally, I don't have much to say about for loops one way or the other. But I do disagree with him on types, which can be far less complex than he intimates. System F, say, which largely covers F#, OCaml and Haskell, can be completely defined as a handful of self-evident rules. A single page for both checking and inference, if in somewhat dense notation. That's not complex at all, especially since it follows fairly naturally from the way the lambda calculus works even without types. To me, that seems like a perfectly consistent view. Nothing forces you to take everything he says or leave it: you can find it accurate piecemeal. Take the mental framework but apply it with your own knowledge and experience and you could very well come up with your own conclusions. Seems like the perfect way to use ideas like this.

mpdehaan2 11y ago

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.

deleted 11y ago
[deleted]
Daishiman 11y ago
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 11y ago
  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.

pella 11y ago

"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/Hickey_Rich https://github.com/matthiasn/talk-transcripts/tree/master/Hi...

draegtun 11y ago

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