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.<p>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.<p>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.<p>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.
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.<p>Go learn Clojure.
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.<p>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.<p>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.<p>Clojure isn't simple -- it's basically a step up from assembler in how little it provides.<p>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.<p>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.<p>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.<p>I'd much rather see a language focus on readability, maintaince, and rapid prototyping than side effects.<p>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.
"talk-transcripts : Rich Hickey "<p>- Inside Transducers (11/2014)<p>- Transducers (09/2014)<p>- Implementation details of core.async Channels (06/2014)<p>- Design, Composition and Performance (11/2013)<p>- Clojure core.async Channels (09/2013)<p>- The Language of the System (11/2012)<p>- The Value of Values (07/2012)<p>- Reducers (06/2012)<p>- Simple Made Easy (9/2011)<p>- Hammock Driven Development (10/2010)<p>- Are we there yet? (09/2009)<p><a href="https://github.com/matthiasn/talk-transcripts/tree/master/Hickey_Rich" rel="nofollow">https://github.com/matthiasn/talk-transcripts/tree/master/Hi...</a>
I love Rich Hickey and I will watch any talk he ever gives. I believe I have seen them all at current.<p>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.
Carl Sassenrath is another programming language designer who as long been a proponent for <i>simplicity</i>.<p>Some links:<p>* <i>Definition of Simple</i> (2011) - <a href="http://www.rebol.com/article/0509.html" rel="nofollow">http://www.rebol.com/article/0509.html</a><p>* <i>Fight Software Complexity Pollution</i> (2010) - <a href="http://www.rebol.com/article/0497.html" rel="nofollow">http://www.rebol.com/article/0497.html</a><p>* <i>Contemplating Simplicity</i> (2005) - <a href="http://www.rebol.com/article/0127.html" rel="nofollow">http://www.rebol.com/article/0127.html</a>