Design Principles Behind Smalltalk (1981)

&gt; The principle of good design can be restated for languages:<p>&gt; Uniform Metaphor: A language should be designed around a powerful metaphor that can be uniformly applied in all areas.<p>A key statement for our budding language designers on HN.<p>However they do go on to state that LISP is about linked structures, and APL is about arrays, which is wrong really - or at least does not do full justice to the ideas behind both.<p>Sending messages between independently acting &#x27;objects&#x27; sounds elegant and powerful, but in the large does not address (and perhaps exacerbates) the most critical problem facing software engineering - namely the control of complexity.

Just a tad opinionated :)<p><pre><code> Instead of a bit-grinding processor raping and plundering data structures, we have a universe of well-behaved objects that courteously ask each other to carry out their various desires … Examples of success in this area include LISP, which is built on the model of linked structures; APL, which is built on the model of arrays; and Smalltalk, which is built on the model of communicating objects. In each case, large applications are viewed in the same way as the fundamental units from which the system is built.</code></pre>

Related:<p><i>Design Principles Behind Smalltalk (1981)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31448395">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31448395</a> - May 2022 (82 comments)<p><i>The operating system: should there be one? (2013) [pdf]</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28440490">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28440490</a> - Sept 2021 (202 comments)<p><i>Design Principles Behind Smalltalk (1981)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23496800">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23496800</a> - June 2020 (87 comments)<p><i>Design Principles Behind Smalltalk (1981)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17825747">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17825747</a> - Aug 2018 (30 comments)<p><i>Design Principles Behind Smalltalk (1981)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13611222">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13611222</a> - Feb 2017 (53 comments)<p><i>Design Principles Behind Smalltalk (1981)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9689800">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9689800</a> - June 2015 (38 comments)<p><i>Design Principles Behind Smalltalk</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1643098">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1643098</a> - Aug 2010 (4 comments)

I think programming languages compose poorly. Monads and effects get nearer to problem we are trying to solve - tying specific behaviour to specific scenarios - but impose such as a high threshold of understanding that they are rarely used in practice.<p>If I want to take behaviour you&#x27;ve written and use it in my system I have to do lots of studying your APIs to work out how to represent my solution with your code and API.<p>I am inspired by message passing and Smalltalk but put off by the cache locality of object orientated programming. Making systems that compose is hard work.

&gt; The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone.<p>I have the sense that Bjarne Stroustrup and James Gosling were unaware of this document, or if they were, disagreed with it. It’s a shame they looked more to Simula for inspiration.<p>Back in the day, programming in Java, I always had the distinct feeling that the compiler was more important than me. Too much of my time was not spent creating. It was spent making the compiler happy. I’ve wondered what would have happened if Sun had Gosling build the JVM and someone else design the language (Bill Joy?). Would we have gotten a language that was designed for humans?