Systems, not Programs
This felt to me like a roundabout way of saying &quot;we should think more about design!&quot;<p>I _agree_ that we should think more about systems design. And I _agree_ that the individual &quot;units&quot; that we&#x27;re designing would benefit from standard ways of communicating with each other.<p>The entire thing about &quot;let&#x27;s not call it a program!&quot; feels like a distraction from the core point, though. I guess I don&#x27;t really believe that calling the &quot;unit of software development that I&#x27;m currently working on&quot; a program harms it or limits it in any way.<p>Even in the article, the author talks about isolated spaces:<p>&gt;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.<p>...and so, poof, we now have a unit of software that could easily be called a &quot;program.&quot; A program that contains multiple layers of inner program, but there&#x27;s nothing about the word &quot;program&quot; that limits how it can be applied.<p>So I think 95% of this article is philosophical semantic gymnastics.  There&#x27;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.<p>Changing the word to something else doesn&#x27;t actually make the problem easier to solve.