Comment by shalabhc | Hacker News Reader

Comment by shalabhc | Hacker News Reader

Parent Full thread

(Author here)

> Changing the word to something else doesn't actually make the problem easier to solve.

This is true, but what exactly is 'the problem' in the first place? Framing makes a difference. Do we assume we are designing 'units' that communicate with each other or are there other ways to think about the system?

Is the unit of design also the unit of update? What about cross unit parameters - if we want to change a parameter that affects multiple units, do we need to rebuild them and reinstall them in our network of units? Or can we have a projection of our system that shows this parameter as a single update-able cell? What if this parameter is derived (i.e. not something you fed in as a constant but something that represents emergent behavior)?

I'm imagining projectional editing of the system above, now can we consider the original 'units' just as one possible projection of the system - one lens we can view and update the system through? One view of the system (communicating units) doesn't have to be the primary view anymore. Can I project and 'emergent program' - a composition of various units, but only the slices that I'm interested in? Can I update this in place and affect system behavior?

I find thinking of these as systems helps me ask these questions, while thinking about 'programs' leads to different questions such as - are the 'statically typed', how do they communicate, and so on. It has more to do with the common connotations of the word 'program'. The concerns here are broader than 'standard ways of communicating' between individually designed units.

Framing is useful in politics, but I think the underlying limitation here isn't preconceived notions that you're trying to overcome but the inherent complexity of the system you're suggesting.

Say for instance you make the unit of design the unit of update. Then any breaking changes means the unit needs to support both old and new methods of access. This is often appropriate for something like a public API used by thousands of people. But if used at every resolution, it would add too much complexity and need for legacy handling of access patterns.

So if the unit of update is instead a self-contained ecosystem of components, then the components can all be simultaneously updated, reducing their internal complexity. The external interface should still probably be versioned.

And...well, you've just again wrapped up something in that self-contained ecosystem that could very well be called a "program." In fact, it could also be called an object oriented program: Each component is an object that has an API and hidden data.

I'm a fan of static typing, so I'd answer a firm yes to that question. How they communicate -- message passing seems the right paradigm in most situations. So the interesting (to me) solution would be to standardize static types over a message passing architecture. Something like Google's Protobuf? Or JSON with JSON Schemas? Who knows. Depends on the nature of the problem you're trying to solve.

And that gets to one final point: Most programmers aren't capable of thinking in big systemic terms like this. Probably 90% of developers are going to be restricted to operating within a component. I think this is why React and other web client component architectures are so popular today: They are great enablers of average developers (and, to be fair, can be high leverage for great developers as well -- at least up until the point where they get in the way).

Reply on news.ycombinator.com