Superficial Simplicity "For the last decade I’ve chased and wrestled with the ideal of “simple” software, but I’ve come to see it as a false summit and want to spend some ink on why in the hope that it can lead to a better understanding of simplicity and more intelligent conversations about complexity." https://arrdem.com/2022/07/04/superficial_simplicity/

Literally came here to post this. I think this tension is an important one. Simplicity (even in the Rich Hickey sense) isn't an absolute good. Nor do I think it is quite as clear cut objective as Rich thinks. And yet, I think an emphasis on simplicity has helped me tremendously in developing my own taste. Clojure's focus on simplicity has helped it be an incredibly productive tool. But it also introduces many frustrations (error messages, lack of java.lang.Function integration, etc). Other than moderation, how can we better articulate this view point? This distinction isn't quite the same one as worse is better. Are there any good articulations of this middle ground in a more detailed way?

There's some discussion of interface vs implementation complexity in the literature: https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch13s01.html The more recent https://vitalik.ca/general/2022/02/28/complexity.html is also in this vein. Overall, though, I find this tradition of writing to not be very actionable. Einstein said all that needed to be said: keep things as simple as possible but no simpler. Now everyone knows to try to keep things parsimonious. Slightly fewer people know to take the whole stack of dependencies into account when measuring complexity, though the recent focus on software supply chains helps here. For the most part we've accomplished what we can with broad generalizations. What remains is the centuries-long task of hill-climbing to simpler solutions in all the domains where software is eating the world.

It seems to me that in order for something to be successful as a catchy meme it must be compressed into a somewhat ambiguous bromide. So, you get things like "simple, not easy" that resonate with different people for different reasons, until a backlash forms among those who find problems with their particular interpretation of the phrase. 🤷‍♂️🏻

Ehh, not sure I agree. I think anyone embedded in the clojure world long enough has a very similar conception of what we summarize as “simple vs easy”. I don’t think there is a backlash against “their particular interpretation”. There is a real disagreement, not a linguistic one.

well, I found the linked piece did not make very much sense in the context of my understanding of what it means, and I count myself as fairly involved with the Clojure world, so...

Could that not be that the author didn't state things clearly or that you didn't understand what they intended to say rather than that they misunderstood the clojure simplicity doctrine? I wouldn't endorse what is in that blog post. I saw it as pointing in a direction rather than making a strong point. If we take your point about this article though, I'd ask, what counts as disagreement that is non-linguistic? Jonathan Blows approach to Jai and the games he writes are decidedly non-hickian. I think a clear case of disagreement. As far as I know, he has never heard Rich Hickey so can't have misunderstood him. The disagreement is one of actions and values rather than understanding. I find attractive bits in both of these approaches. I find that Rich is wrong about simple, in his sense, being objective. Are these disagreements or misunderstandings?

rather than that they misunderstood the clojure simplicity doctrine?

This suggests to me that you most assuredly did not understand what I was saying, anyway 😹

Hahaha. I mean it's seems we are doomed to not understand. For what it's worth, I assumed you'd take issue with that phrase. But what words should we use to summarize the clojure language, Rich's personal views and the clojure ecosystems relation to "simple"? How else are we supposed to describe the ascewing of certain features? The breaking of norms? The rethinking of best practices? Etc. All the things the clojure community does that separates it from other language communities?

It isn't that I "don't think he understood it", it's that it does not contain enough semantic content to stand alone and thus must (like nearly everything humans being say) be evaluated in some frame. The frame that he's using here leads him to analyze something different from what I think Hickey means in his own frame.

So that goes back to what I asked, what must one do to prove that they are actually disagreeing with what you think Rich means? Must they prove they think the same thing you think Rich means? I don't think the author even attempted to explicate Rich's views. Just pointed in that direction. My chosen frame was to assume understanding and interpret in light of that.

Again, "understanding" isn't the right frame for what I'm saying 😹

You said that the author misinterpreted Rich. I take that to mean he misunderstood Rich. I don't see a way to separate these things. My point has been that I don't think we should assume he misinterpreted. And my further meta-point is a frustration with this rhetorical move of claiming people's attempts at substantial disagreement to be merely semantic disagreements (eg misinterpretations). Claiming the author is backlashing against their own particular interpretation rather than disagreeing with Rich makes it very hard to know what counts as disagreement. I am sincerely asking, how can people signal true disagreement rather than misinterpretation? Jonathan Blow also takes an old school pragmatism that is directly opposite of Rich's. A dislike for GC. A belief that allocation vs initialization is a key important concept to allow in a language. A dislike for "fancy" data structure. A dislike for immutability, purity, etc. I don't think old school sensibility is where the disagreement lies. Nor in interface vs implementation. Rich's view against pattern matching for example does not seem to consistent in either of these. For what it's worth I know people who have worked directly with Rich who have said things similar to what I believe this blog post is getting at.

what tools effectively help users manage “complexity”, how and why.

The social norms of a community influence the complexity of solutions it comes up with far more than its tools. OP mentions Unix, but Unix wasn't just a tool, it was also a community with its own ethos and philosophy, the "Unix Way". The problem with Unix was not that the tools were simple in implementation (though they were). They worked fine for the social context they were designed for. The problem was that its success caused Unix to overflow out to communities that didn't share its social norms. Leading to lamentations like http://harmful.cat-v.org/cat-v The unsolved problem -- the unsolvable problem, IMO -- is how to keep communities from getting to Eternal September, where they overflow to newcomers and the culture fractures.

You said that the author misinterpreted Rich.

I most assuredly did not. When I say that each person has a particular interpretation, that does not mean that there's a platonic ideal somewhere that they're getting wrong. Does that help clarify what I'm saying? As for Blow's preferences, I doubt very much that Rich would disagree on those points in Blow's context of use. Rich has been quite clear that he designed Clojure for writing the kinds of programs he writes (again, frame/context). Many properties of Clojure that make writing correct programs easier come at a cost, and sometimes one cannot afford to pay those costs in a particular situation. These same concerns are also why the largest share of my own career output (counted in LoC) has been C + asm.

Does that help clarify what I'm saying?

Yes it does. But might I suggest that the words "misinterpretation" or "misunderstand" don't imply a platonic ideal. We can say that someone who claims "little red riding hood is an analogy about the USSR" has misinterpreted the text, without saying there is a platonic ideal of how to interpret little red riding hood. I don't think we are going to find agreement here. But I will just say, that from my interpretation of your words, you are short changing the author quite a bit. I don't think this is a backlash against a particular interpretation. I don't think it is a backlash of any sort. What I see reflected in the article is a struggle to strike a certain pragmatic balance and a view that the pragmatic balance might actually cause us to fall on the opposite side of the simplicity divide more often than not. In other words, that maybe there are far more cases where simplicity shouldn't be preferred over complexity. That simplicity is perhaps a much smaller part of the pie when making systems decisions. That tools offering simplicity may actual be moving the burden from the author, to the user in a bad way. I heard of a (non-public) system designed by Rich where users had exactly this problem. This system was, by the admissions of the users, incredibly simple, elegant, conceptually pure, etc. But it was way less usable than competing much more complex systems. From my understanding, this fact was not appreciated by Rich, for him the simplicity trumped.

I doubt very much that Rich would disagree on those points in Blow's context of use

My main point was that Blow does disagree with Rich, even given his context of use.

Well sure, but that feels like a degenerate solution (in the math sense)? When I wrote that I was thinking about the question you seeded this discussion with:

Other than moderation, how can we better articulate this view point? This distinction isn't quite the same one as worse is better. Are there any good articulations of this middle ground in a more detailed way?

Phrased as an answer to your question rather than a new question: to make systems that are as simple as possible but no simpler, first articulate what you want. The language to do that must come from the context of use. Christopher Alexander shows a particularly systematic way of doing that in Notes on the Synthesis of Form. His approach is too heavyweight for most situations, but I still find it enormously clarifying to think in his terms. Above all, what situations do you want to avoid? When we bluntly transplant a tool into a new context of use, we take on a whole lot of interface complexity and UX frustration. Based on those frustrations we try to post-mortem the issues with the tool and its implementation. But we're largely looking in the wrong place. It's like there's a level of source code for the context of use that never made it past transplant. It was in the air pre-transplant, but inevitably left behind during transplant. This is my best attempt so far at a more detailed picture of "complexity in moderation". It's not moderation at all, it's entropy. You lost the basis vectors under which the tool had minimum complexity. To my knowledge there's no way to reconstruct them once lost.

My main point was that Blow does disagree with Rich, even given his context of use.

It would be an indictment of Blow as an extremely immature person to suggest that because he only makes video games, and thus prefers tools optimized for making video games, that he also believes everyone should use video game-making tools to make everything else. Maybe that is what he thinks, but I would not be so uncharitable as to put those words in his mouth. What I'm saying is that I don't think the author of that piece and Rich are actually having the same conversation, so I can't really speak about their differences of opinion. If you don't think Rich makes pragmatic tradeoffs about complexity... well, I can only point out that he built his language on top of ~12M lines of somebody else's extremely gnarly C++ code in a pragmatic tradeoff. 🤷‍♂️🏻

I’m really trying to understand. It seems there are only two options, disagree and therefore be immature. Or think you are disagreeing, but you are actually having a different conversation. There must be a way to directly disagree without being immature.

Do you think "everyone should use my favorite tool no matter their context of use" is a mature opinion?

I never said that was Jonathan Blows view point. I just said he would disagree with Rich Hickey.

My main point was that Blow does disagree with Rich, even given his context of use.

As long as you're going to use Mr Blow as a sock puppet, can you clarify exactly in what way your imagined version of him disagrees with Hickey in Hickey's context of use?

Rich believes that uncontrolled mutable state is undesirable in many contexts of use that Blow would be fine with. Blow does not in general take issue with mutable state. He does not for example buy the argument from out of the tarpit that it is the root of much of our complexity.

At this stage I think I'd like to see your sock puppet Blow and your sock puppet Hickey really hash this out. 😹

Okay. How about Rich vs Alan Kay on data. (hacker news thread) Is that a real disagreement? A verbal one? A sign of immaturity?

I loved that conversation as an example of two smart people talking past each other, though I think Alan understood Rich much more than vice versa.

(https://news.ycombinator.com/item?id=11945722)

So are there any substantial disagreements you can think of? It seems from this conversation you think most things are mere verbal disagreements.

Here is a list of actual differences of opinion about how Clojure should best be implemented. Note that they are concrete things rather than handwaving about kernel languages (which Clojure most definitely is not).

I sincerely mean that I have enjoyed this conversation. It does help me understand better where you are coming from Jack. I do think there is a more charitable way to read that blog post. But your list of points is definitely a more concrete disagreement.

As a bit of a Blow follower, I can't help but take a turn at the sock puppet. 😉 Regarding GC, I can imagine him saying, "Well look, you don't need to do all this work if you know you're going to throw this all away every frame anyway." See also stack allocation and not closing a closure until you know that the closure needs closing. Getting a bit meta, Blow in particular and I think the many of the rest of us have both an "initial highly opinionated" reaction to things as well as a "considered, balanced nuanced" reaction. It's useful to distinguish visceral gut distaste from considered disagreement.

@wtaysom That's one of the funny things about Jai. It says "no GC" on the tin, but has at least three mechanisms (per-frame arena allocator, context-based allocation, temporary storage) that I would consider forms of GC. This leads me to suspect that he means "no form of GC that might cause a pause during rendering" (which is very reasonable in a game engine). In terms of your meta, I think people watching a Hickey or Blow video are receiving the polemic mode of rhetoric from someone who would provide quite different real and nuanced opinions in a candid discussion. It would be fun to see those two talk about what's good or bad in different situations. I'm betting there would be differences of opinion, but that they would be fewer and less severe than either's acolytes might expect.