3 ms·

The D3-specific changes look really cool. But I'm dissatisfied with the generalizations being proposed. We've heard before that programs are intended for human

The D3-specific changes look really cool. But I'm dissatisfied with the generalizations being proposed. We've heard before that programs are intended for humans to comprehend and only secondarily for computers to run. We've heard that programming interfaces are user interfaces. We've heard many many many attempts at distilling experience into maxims for others to follow. And yet those vague 'others' never follow said maxims. What we tend not to track down is the reason why software is the way it is. We're warmer when we say the culprit is social rather than technical, but even that's not quite accurate. The culprit is political. Users of a piece of software aren't all the same. They can be segmented in many many ways, but I'll focus on one: people upgrading from D3 v3.0 and those coming straight to D3 v4.0. There's a tension between the needs of these segments that is identical to class warfare: every change to the API improves the life of the latter but adds an inconvenience to the former when upgrading. It's quite possible that D3 has done a good job addressing this tension with semantic versioning, and by being a tool rather than a service that users can upgrade on their own schedule. But this tension and the ways we choose to address it is by far the bottleneck in general. Most tools atrophy and fail to adapt to changing environments because they get captured [1] by existing users to the detriment of new users, and eventually to the detriment of everyone. Repeat after me: compatibility is the mind killer. At least when we are building software for other programmers rather than end-users, we need a new social contract that allows newcomers and upgraders to coexist more peacefully and sustainably. [1] https://en.wikipedia.org/wiki/Regulatory_capture https://en.wikipedia.org/wiki/Regulatory_capture

laughinghan 11y ago
> What we tend not to track down is the reason why software is the way it is. The rest of your comment goes in a different direction, but still, you might be interested in the Big Ball of Mud essay: > While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture. http://www.laputan.org/mud/ http://www.laputan.org/mud/
- akkartik 11y ago
  Thanks; it was good to reread those patterns. I wonder how the trajectory of say a life stage like http://www.laputan.org/lifecycle/lifecycle.html#Consolidate http://www.laputan.org/lifecycle/lifecycle.html#Consolidate is affected if some or all of the people responsible for previous stages left in the interim.
pron 11y ago
> compatibility is the mind killer One of the main (logical, reasonable, and real) requirements of most software systems is building and maintaining them under budget. When you disregard compatibility in the name of progress you make a decision on behalf of all of your users: that whatever added functionality or increased elegance or consistency your product now provides, it is more important than their budget requirement. For most of your users, that decision is simply wrong.
- akkartik 11y ago
  You're right that it provides benefits. That's why I phrased it as a tension. So when I attack it I'm talking about looking for alternatives with all the same benefits and more. As a concrete proposal, here's something I wrote a couple of days ago: https://github.com/akkartik/mu/blob/14d3dacc4d/Readme.md https://github.com/akkartik/mu/blob/14d3dacc4d/Readme.md. I deleted it yesterday because a Readme feels like the wrong place for it, but it's still useful as an elaboration of my current thinking.

laughinghan 11y ago

> What we tend not to track down is the reason why software is the way it is. The rest of your comment goes in a different direction, but still, you might be interested in the Big Ball of Mud essay: > While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture. http://www.laputan.org/mud/ http://www.laputan.org/mud/

akkartik 11y ago
Thanks; it was good to reread those patterns. I wonder how the trajectory of say a life stage like http://www.laputan.org/lifecycle/lifecycle.html#Consolidate http://www.laputan.org/lifecycle/lifecycle.html#Consolidate is affected if some or all of the people responsible for previous stages left in the interim.

pron 11y ago

> compatibility is the mind killer One of the main (logical, reasonable, and real) requirements of most software systems is building and maintaining them under budget. When you disregard compatibility in the name of progress you make a decision on behalf of all of your users: that whatever added functionality or increased elegance or consistency your product now provides, it is more important than their budget requirement. For most of your users, that decision is simply wrong.

akkartik 11y ago
You're right that it provides benefits. That's why I phrased it as a tension. So when I attack it I'm talking about looking for alternatives with all the same benefits and more. As a concrete proposal, here's something I wrote a couple of days ago: https://github.com/akkartik/mu/blob/14d3dacc4d/Readme.md https://github.com/akkartik/mu/blob/14d3dacc4d/Readme.md. I deleted it yesterday because a Readme feels like the wrong place for it, but it's still useful as an elaboration of my current thinking.