[HN Gopher] Design Principles Behind Smalltalk (1981)
___________________________________________________________________
Design Principles Behind Smalltalk (1981)
Author : rodrigosetti
Score : 67 points
Date : 2023-12-31 03:36 UTC (19 hours ago)
(HTM) web link (www.cs.virginia.edu)
(TXT) w3m dump (www.cs.virginia.edu)
| transpute wrote:
| Just a tad opinionated :) 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.
| m463 wrote:
| well it was 1981, with smalltalk coming from 1972, so it was
| quite a bit different, advanced even. (although the prose was
| ... not)
| dang wrote:
| Related:
|
| _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)
| dimal wrote:
| > The purpose of the Smalltalk project is to provide computer
| support for the creative spirit in everyone.
|
| 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?
| mst wrote:
| Bear in mind that the Java design was only half done when it
| got shipped - I would love to see what both Java and JavaScript
| would have been if their creators had been given the time to
| actually finish their respective designs.
| mlajtos wrote:
| For JavaScript it is ES1995.
|
| https://github.com/mlajtos/es1995
| znpy wrote:
| > Too much of my time was not spent creating. It was spent
| making the compiler happy.
|
| 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.
| somewhereoutth wrote:
| > The principle of good design can be restated for languages:
|
| > 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.
| patterns wrote:
| I think this is a fair assessment. I agree that Smalltalk is by
| far not a complete solution to the problem of building and
| maintaining complex system but "only" an attempt.
|
| 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").
|
| [1] https://www.youtube.com/watch?v=QjJaFG63Hlo&t=5775s
| samsquire wrote:
| 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.
|
| 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.
___________________________________________________________________
(page generated 2023-12-31 23:03 UTC)