Rails Conf 2012 Keynote: Simplicity Matters by Rich Hickey

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)

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

Rich Hickey - "simple made easy" ▶ this video Rob Pike - "concurrency is not parallelism" link Uncle Bob Martin - "future of programming" link Martin Kleppmann - "transactions: myths, surprises and opportunities" link Simon Brown - "software architecture vs code" link

The blog post barely gets into the idea of what simplicity means in programming. If you have any interest in the topic, I recommend Rich Hickey talk "Simplicity matters" ▶ this video My personal favorite is: Living with complexity 2010 by Don Norman (Author of Design of everyday things) link

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

Very interesting related talk about complecting things - "Simple Made Easy" - by Rich Hickey, inventor of Clojure: link If you're a Ruby person, maybe watch this version instead, since it's almost the same talk but for a Rails Conference, with a few references: ▶ this video

>> This is a lot like schemaless databases. The flexibility of not having to fully specify the full schema does not mean that you don't benefit from specifying parts of it? Indeed, if you are indexing things, you have to specify those parts. But it is hard to argue with a straight face that schemaless tools don't have some strong benefits. This is very similar to what Rich Hickey argued in "Simplicity Matters": ▶ this video Basically when you use a hash / JavaScript-style object rather than a fixed struct definition for your data (which amounts to a schema- less database in aggregate) Easy addition of new properties Co-existence of different versions of objects (newer objects will typically have more properties) Introspection of properties and validation rules / reflection

If what you're comfortable with is Spring or Drupal or Rails and those work for your use case then more power to you At the same time it's true there are products like roam research that are fundamentally harder to achieve in a cookie cutter environment This talk kind of eludes to why that is ▶ this video but it's worth learning there's many mature pieces of tech in this community that are astounding If you need boring.lib then reach into Java/JavaScript with the easiest interop I've ever used

> much as you call property setters or getters in OOP languages Good design is obvious and orthogonal[1]. If you write setters in an OOP language in such a way that they do surprising things, i.e. not just setting a value, then I would call that bad design. > which is good for loose coupling, modularity, etc. What do you gain by using triggers in this case? All you get is mental overhead, because whenever you use DML you have to keep in mind that there might be a trigger hiding somewhere that does strange things. If you call a procedure instead, you make it clear that you want to do more than just a simple update or insert. > [...] it is possible for the method call to make use of concurrency and parallelism constructs [...] to do a unknown number of things in an unknown order Why would I want this? I want my code simple[2], stupid and obvious, and not convoluted, clever and surprising[3]. [1] link [2] ▶ this video [3] link

Never seen the term 'plectics' before. Definitely seems like a source of inspiration for Rich Hickey's famous talk: ▶ this video