Rails Conf 2012 Keynote: Simplicity Matters by Rich Hickey

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]

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

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

Complication kills, not complexity. Complex systems are made up of simple independent pieces. Those pieces work together naturally often leading to new behaviors. Because they are independent, they can also adapt easily to changes in the environment. Complication is different. Complicated systems have dependencies that are more tightly bound together. Because of this, they can't adapt as easily to environmental changes. Consequentially, this creates conflict between system and environment that can often be destructive or violent. Or at least that's my social hypothesis. I based my idea on the Rich Hickey "Simple vs. Easy" talk on software complexity. I think his ideas could be generalized to societies as well. [this video]

Rich Hickey has a good point in his Rails Conf 2012 "Simplicity Matters" talk[0] - json is just more simple than xml, as it clearly states which parts are maps and which are sequences. Xml has an inherent, implicit order in everything, due to its history as a document markup language. If you think xml through the lens of jsx pragma style transformation, xml element and it's attributes are more or less a (typed) map. Similarly element's children is an (ordered) sequence. Where as in json you can have maps inside maps, in xml you always have to wrap maps inside an ordered sequence, as maps can only be passed to element as its children. You can totally use xml without paying attention to the order, but the order is still there, complicating things. [0] Rails Conf 2012 Keynote: Simplicity Matters by Rich Hickey - [this video]

> 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]

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