Are you saying that building the consensus towards the thinking of "reality and being" will be hard…
Fagner Brack

Are you saying that building the consensus towards the thinking of “reality and being” will be hard because most people are average programmers? If not, can you please elaborate?

Sure, sorry for being a bit obtuse. The bell curve I mention is not in reference to a programmer’s experience, skill, or expertise, merely a situation wherein we have such a validated consensus amongst such a large group of developers that we’ve achieved normalized distribution. I’m a firm believer in the egalitarian potential of the sorts of mental models offered in the post.

Rather, I meant to draw comparison to a more Brooks-ian depiction of outside market forces forcing alignment through tooling, and that with the current state of product development being such a seller’s market — for the developer — it can be difficult to find the incentive to sort the principled wheat from the practiced chaff, so to speak.

I think we can in fact espouse these better principles such that they’re tractable, but I often lament the inertia I feel it will take to overcome the current direction.

Can you elaborate on what you mean by the “fundamental misunderstanding of the problem”? Which problem specifically are you referring to?

I suppose it’s the same problem that functional programming is attempting to salve — specifically within the product domain — with such a massive cultural shift to the paradigm in the recent years. To be fair, it’s not a well-defined problem, which is why I’ve only really come up with a set of inferences.

Is the problem fundamentally that we need immutable data structures, or that immutability by default is better? Surely not, since we can leverage semiotics and identity in constructing the relationships between our categories/objects in order to inform our structures, which are just as principled as affirming an immutable principle in the handling of data structures.

Is it that we need to pass behavior in a tractable format, facilitated by the intrinsic surfaces/contexts our DSL is providing? Well, that’s certainly *useful*, but simply passing around an executable context via any particular method doesn’t strike me as key differentiator worthy of such a massive shift in product.

A lot of these are positioned as “better” ways of programming, but they’ve always seemed to glorify mechanism to me and don’t fully illuminate the causal properties, so I tend to wax poetic about the possible reasons :). I also have a hard time simply attributing the shift to some sort of undecomposable Zeitgeist that ebbs and flows through time.

Again, really appreciate the post. Cheers.