"Simple Made Easy" - Rich Hickey (2011)

"Simple made Easy" is a nice add-on, the first half is the philosophical part and a classic. ▶ this video

in “Mythical Man Month” · View on HN

I think Rich Hickey's talk about simple is great for defining these terms (literally). He describes how the roots of "simplex" mean single braid, which compares to the twisting & coupling with complexity; an apt visual for software development. He also differentiates simple/complex from easy/hard, which is important. ▶ this video

in “Nobody Gets Promoted for Simplicity” · View on HN

I think LLMs have made a lot of developers forget the lessons in "Simple Made Easy": ▶ this video LLMs seem to be really good at reproducing the classic Ball of Mud, that can't really be refactored or understood. There's a lot of power in creating simple components that interact with other simple components to produce complex functionality. While each component is easy to understand and debug and predict its performance. The trick is to figure out how to decompose your complex problem into these simple components and their interactions. I suppose once LLMs get really good at that skill, will be when we really won't need developers any more.

in “I'm dialing back my LLM usage” · View on HN

> They just don’t get it. What comprises a good presentation. I take it one could argue between what's a presentation and a talk but to me one of the very best presentation I've seen is Rich Hickey presenting Clojure. Then there's "Simple made easy" considered by many to be one of the greatest ever: ▶ this video There are many bullet points: but he'll go through each them and only show the next bullet point once he's done with the previous one. He even kids about a made up graph on one of the slide. I think that what makes a good presentation depends a lot on what's being presented.

in “Figma Slides Is a Beautiful Disaster” · View on HN

I know this gets shared all the time, but in case anybody in this thread hasn’t seen the rich hickey talk: ▶ this video

in “Zig's (.{}){} Syntax” · View on HN

A simple system is built so that not many parts are intertwined and hard to understand how it is built. A easy system might be very complexly built, but presents and easy interface for you to use. If complex it would be hard to understand how it is built and how to modify. Basically simple describes how the system is built, while easy describes how much you need to know to use it. They are orthogonal, so a system can be both complex and easy, both simple and hard. See ▶ this video

in “Show HN: I built a backend so simple that it fits in a YAML file” · View on HN

Keeping track of all that state in one’s head is hard. I think because of the limitations of FP it’s much easier for new programmers to reason about programs and honestly, learn to program. New developers don’t have to micromanage the computer, the way that the would with an imperative lang. For example, SQL isn’t FP, but think about the number of business analysts whose lives would be more difficult if the had to write imperative programs to fetch data from some sort of data store. I think what in comes down to is simple vs easy. Imperative programming in the very very beginning is easy, buts not simple. Because there’s all this implicit state in your program, as the program grows it becomes very very complex. It’s no longer simple. There’s this really great talk about this idea by rich hickey, the creator of clojure, that dives into this in detail. ▶ this video

in “Teach yourself Computer Science functionally” · View on HN

Obligatory Simple Made Easy link: ▶ this video Simple is a matter of intuition, and that can't be transmitted to others easily, or with a single class or book. At one particular job we got punished by the business for calling things 'easy' when what we mean is that we understand the problem and all of the steps are (mostly) known. Our boss coached the hell out of us to say 'straightforward' when we meant 'understood', instead of using 'easy' as an antonym for 'quagmire' or 'scary'.

in “Do the Simplest Thing That Can Possibly Work (2004)” · View on HN

I would argue that nowadays the libraries and frameworks are more to blame than the languages. We aren't creating the right elegant DSLs. But more importantly we're still expecting people to inherit from library classes — perhaps multiple levels deep — to swap functionality in and out. We could just use functions as first-class objects but instead we have to understand this unnatural intermingling of code and data that's based on "modeling" a supposed concept in the problem domain (rather than the solution domain) that barely makes any sense in and of itself. Like Rich Hickey explained ( ▶ this video ), things become complex because you complect them. You can get a lot of APL / LISP feeling out of carefully written Python or JavaScript. Not the metaprogramming stuff, sure. But a lot of that in LISP depends on homoiconicity, which is one of the biggest things making the language "not usable by average developers".

in “Solving the Wrong Problem” · View on HN

Haha. But I thought Rich Hickey was making the simple point that don't intertwine things than can be kept separate! P.S: For those wondering what this refers to, here is his talk: ▶ this video

in “The Grug Brained Developer (2022)” · View on HN

Rich Hickey is famous for talking about easy vs. simple/complex and essential vs. incidental complexity. “Simple Made Easy”: ▶ this video

in “Working on complex systems: What I learned working at Google” · View on HN

Complexity: things twisted together. You can count the things, and count the twists. When a set of things has fewer twists (or even knots) than another set of things, it's simpler. When you pull on something, if it's attached to other things by twists, you are dealing with complexity. When you intentionally entwine things, you are creating complexity. You might say you are "complecting" things together, and once done they are "complected" together. This is relevant from the smallest details of programming like state (being a more complex twist of value and time, compared to simpler immutable values that are timeless) to the largest issues of modularity (being a property of systems composed of smaller things; when you can disconnect such things without needing to untwist them from each other, you have achieved a simpler design). This is separate from being easy or hard, though one could assert that a simpler system will tend to be easier to change, because you don't necessarily have to deal with as many things twisted together at the same time. But this isn't a given, because we programmers learn and get better at complex things such that they can feel quite easy, and we also love making tools to try and wrangle sources of complexity, either those inherent to a problem domain, or those we unnecessarily inflict on ourselves, and it can be quite easy to make changes to really complex systems once you've learned some of these tools. Complex things can also be very helpful from ti

in “Clean Code vs. A Philosophy Of Software Design” · View on HN

That is what you get when people reinvent the wheel and lifetimes/ scopes are implicit. Docker could've used something like JSON5 [0] for their configuration format to make the lifetimes explicit. Another time when easy won over simple. [1] [0] [link] [1] ▶ this video

in “Using ARG in a Dockerfile – beware the gotcha” · View on HN

Building user experiences is inherently some of the most difficult software engineering there is. It's not difficult because the existing tools are poorly made (though most of them are), it's difficult because the core problem is extremely complex (in the Rich Hickey [1] sense of the word, e.g., braided, intertwined, complected, etc.). In order to build a user experience, we start with some information that can often (though certainly not always) appear both simple and easy (i.e., unbraided and comprehensible). But then we must create a projection of that information onto a 2D (or 3D) plane and manage it's changing state over time. This is where everything falls apart. We're usually trying to manage a very wide, very deep, loosely defined tree of state and we're trying to reflect an arbitrary number of user interactions and mutations instantly, and over time. Exactly zero of our tools (programming languages, UI toolkits, Operating Systems, etc.) have strong support for managing change-over-time in a way that makes this type of problem fast, stable or enjoyable to present, use, verify or mutate. I love that the OP showed the triangle of Performance, Adaptability and Velocity. I've been framing a similar concept with teams since 2011 which I refer to as, "Fast, Stable and Delightful." It's my thesis that we need to balance these three requirements in both our activities and in the output that we produce. This balance is incredibly difficult to achieve and harder still to mainta

in “Digital Audio Workstation Front End Development Struggles” · View on HN