Comment by SomeCallMeTim | Hacker News Reader

Comment by SomeCallMeTim | Hacker News Reader

This felt to me like a roundabout way of saying "we should think more about design!"

I _agree_ that we should think more about systems design. And I _agree_ that the individual "units" that we're designing would benefit from standard ways of communicating with each other.

The entire thing about "let's not call it a program!" feels like a distraction from the core point, though. I guess I don't really believe that calling the "unit of software development that I'm currently working on" a program harms it or limits it in any way.

Even in the article, the author talks about isolated spaces:

>While the Smalltalk model holds a large number of objects in a single ‘space’ - we could imagine a system where each object has internal space which holds a cluster of inner objects, and so on.

...and so, poof, we now have a unit of software that could easily be called a "program." A program that contains multiple layers of inner program, but there's nothing about the word "program" that limits how it can be applied.

So I think 95% of this article is philosophical semantic gymnastics. There's a seed of an interesting idea -- software would benefit from the ability to connect its pieces more flexibly -- but without an actionable hint as to how to _get_ there, this is just a pointless intellectual exercise.

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

(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).

Agreed. Systems and programs are basically the same thing, anyway. Anything you can say about a program, you can say about a system, and vice versa. The big difference is, you instrument a program, but you do not instrument a system. The system just exhibits the properties of the interaction of the programs, and expresses effects on them.

A comparison would be a computer system is like a biological ecosystem, whereas a program is like an individual biological entity. Much like biological systems, computer systems and programs are made up of small similar pieces that have defined functionality, and their interactions result in a system. Microbiology results in macrobiological systems, and macrobio results in ecosystems, etc. Program, system, whatever; it's turtles all the way down.

Also, this:

> we can also consider replacing the write-then-run program idea [..] with an incremental model where the programmer successively provides more detail about the desired behavior and a constraint solving system refines the behavior

So, like, test-driven Agile programming?

> The big difference is, you instrument a program, but you do not instrument a system.

We do instrument systems, consider strace or https://zipkin.io/

> A comparison would be a computer system is like a biological ecosystem.

Excellent analogy and one that I really like. What are the 'programs of biology'? One way of decomposing this is 'spacial' - e.g. a cell is a program, a limb or an organ is another larger one etc. But what about the nervous system, circulatory system, etc.? Aren't they useful perspectives but they span different units in the spacial decomposition. Can I view and modify them directly? What about updates - consider attaching another limb vs changing the electrical conductivity of neurons - while preserving some consistency and enforcing constraints.

Reply on news.ycombinator.com