"Simple Made Easy" - Rich Hickey (2011)

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]

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.

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

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

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