Design Principles Behind Smalltalk (1981)(cs.virginia.edu) |
Design Principles Behind Smalltalk (1981)(cs.virginia.edu) |
> Uniform Metaphor: A language should be designed around a powerful metaphor that can be uniformly applied in all areas.
A key statement for our budding language designers on HN.
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.
Sending messages between independently acting 'objects' 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.
I found that message passing is an elegant approach to have interoperability on a very basic level. But when protocols and interactions between objects get more complex, it becomes more difficult retain control and comprehension of the evolving system, thus fundamentally better approaches and methods are needed than what is present in a typical Smalltalk system.
You might be interested in watching Alan Kay's seminar on object-oriented programming, in which he sketches some ideas on how to modularize an OO system, notably, using a kind of specification language to describe the functions/needs of components and letting the underlying system figure out how to hook them up and deliver messages automatically (as opposed to the direct message passing style in traditional Smalltalks). The relevant part can be found here [1], but I found the entire talk worth watching, since a whole set of issues with OOP and Smalltalk (difficulties in finding and reusing components, weak generality) is being touched upon.
Unfortunately, as far as I know, none of the critical ideas have been crystallized into a new kind of Smalltalk - which would be more focused on working on sets of components instead of individual objects/classes (or paraphrasing Alan Kay, making "tissues").
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.Design Principles Behind Smalltalk (1981) - https://news.ycombinator.com/item?id=31448395 - May 2022 (82 comments)
The operating system: should there be one? (2013) [pdf] - https://news.ycombinator.com/item?id=28440490 - Sept 2021 (202 comments)
Design Principles Behind Smalltalk (1981) - https://news.ycombinator.com/item?id=23496800 - June 2020 (87 comments)
Design Principles Behind Smalltalk (1981) - https://news.ycombinator.com/item?id=17825747 - Aug 2018 (30 comments)
Design Principles Behind Smalltalk (1981) - https://news.ycombinator.com/item?id=13611222 - Feb 2017 (53 comments)
Design Principles Behind Smalltalk (1981) - https://news.ycombinator.com/item?id=9689800 - June 2015 (38 comments)
Design Principles Behind Smalltalk - https://news.ycombinator.com/item?id=1643098 - Aug 2010 (4 comments)
If I want to take behaviour you'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.
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.
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.
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?
I’ve seen this happen to some colleagues, and it has happened to me as well, not only with java.
It’s really… a skill issue. In most cases the user hadn’t read the documentation well if at all, or is trying to write in language X while thinking in language Y. It’s really your issue if you’re misusing the language and the compiler.