Confreaks
8 HN recommenders · recommended in 20 months, 2015–2024
36:53 · 220K views · May 1, 2012
Rich Hickey's keynote at RailsConf 2012, a close sibling of his 'Simple Made Easy' talk. He distinguishes simple (not intertwined) from easy (familiar), and argues that software complexity comes from complecting things, with Rails-specific examples including large gem collections.
HN recommends it as an alternative or companion to 'Simple Made Easy', and quotes its ideas about simplicity, complexity and 'hairballs' in discussions of frameworks, JSON and data design.
20 comments from Hacker News
Related: the great and timeless talk called "Simplicity Matters" by Rich Hickey - this video (By the way, any talk by Rich Hickey is worth watching)
I'll let the parent answer you (though I have similar sentiments as someone with language implementation experience, and FWIW, I have professional experience with Go, Ruby, JavaScript, Clojure, C#, and I've used Haskell, F#, and much more in my free time). I will, however, point out that you're likely using a different definition of simple ("easily understood or done; presenting no difficulty. ") than is often used in technical circles ("composed of a single element; not compound"). Simplicity and ease are distinct, and one does not necessarily imply the other; it's not hard to find convoluted designs that feel easy due to familiarity, while a much smaller, consistent design will feel difficult because the concepts (while fewer in number) are foreign. Rich Hickey (creator of Clojure) gave a great talk on easy vs simple: this video Here's something familiar to most professional web developers: JavaScript. But it's also complicated: [LINK] Here's the spec: [LINK] And here's something unfamiliar and often considered difficult: lambda calculus. And yet it's very simple. Here's the entire definition of lambda expressions (lifted from Wikipedia): --- Lambda expressions are composed of: * variables v1, v2, ..., vn, ... * the abstraction symbols lambda 'λ' and dot '.' * parentheses ( ) The set of lambda expressions, Λ, can be defined inductively: 1. If x is a variable, then x ∈ Λ 2. If x is a variable and M ∈ Λ, then (λx.M) ∈ Λ 3. If M, N ∈ Λ, then (M N) ∈ Λ Instances of rule 2 are know
Prodcedural code can also be well compartmentalized and tested. I was also until recently quite convinced OOP was the only way to go, but I'm seeing signs everywhere that a lot of the design-problems I've met over the past few years are at least magnified by OOP. The abstraction promised by OOP is a good thing, however very few people are able to consistently make good, reusable and maintained abstractions. To the point where it becomes a weakness rather than a strength. I don't want a billion wrapper-objects that obfuscate my code, and makes the surface area of it bigger than it has to be. Often I struggle understanding code more because of how it was separated, than because of the complexity of what it actually does. I liked Rich Hickeys talk "Simple made Easy" [1] and "Brian Will: Why OOP is Bad" [2] [1]: this video [2]: [LINK]
another angle: while Clojure is a Lisp with its own distinct flavor it gives you … * a large community of practitioners and professionals (great for asking questions, finding collaborators, …) * easy access to libraries in the js/jvm/.net ecosystems * a style that relies more on data and transformations of data (illuminating simplicity) in any case: it is worth digging deeper, one thing that kept me away was not knowing where to start (analysis paralysis). in hindsight picking any Lisp would have been great (instead of postponing). Find a thread and start pulling :) Rich Hickey’s talks were a great entry point for me [LINK] e.g. this video (the “Simplicity Matters” keynote at Rails Conf 2012) edit: Land of Lisp is a great book as well
Clojure is by far the best programming language I've ever used. Rich Hickey's Sermons On The Mount changed the game of programming once and for all. With Clojure you could finally have your Lisp cake and eat it. Witness the sheer chutzpah of the guy when he basically told Ruby devs they were doing it wrong at Rails Conf in 2012 ( this video ).