11 ms·

Design Principles Behind Smalltalk (1981)

194 points by joubert 6y ago

d3ckard 6y ago
Very interesting read, though it hurts me to see optimism in this paper mostly unwarranted from today’s perspective.
- shawnz 6y ago
  Was it unwarranted? > While the presentation frequently touches on Smalltalk "motherhood", the principles themselves are more general and should prove useful in evaluating other systems and in guiding future work. Indeed the principles of Smalltalk went on to guide the design of many future languages
jasim 6y ago
If you're tired of hearing about the virtues of Smalltalk (like I was at one point) and ask "if it is so good, why isn't it popular?", then watch @deech's talk (Aditya Siram) - "What FP can learn from SmallTalk" - https://www.youtube.com/watch?v=baxtyeFVn3w https://www.youtube.com/watch?v=baxtyeFVn3w I think it is the most accessible explanation of the marvel of Smalltalk, for those who were not lucky to work with it during the late 80-90s. Also I think Ruby is the mainstream language that is closest to Smalltalk today, with the idea that everything is an object and late-binding as much as possible. One thing I can't help point out is that Smalltalk / Alan Kay's vision of interconnected objects forming a recursive computing system is not the only "true" vision of OO out there. From Simula thru C++ and then Java and C# also are object-oriented (or class-oriented for those who care about the distinction), but they are statically typed. It is also OO because OO is a word, not a mathematical definition, and when people talk about OO, there is enough similarity between all these variations that we consider all of them to be in the same camp. Plus with the growing move towards strict static typing even in interpreted languages, which I think is driven by actual industry needs and programmer preferences than external marketing, it is becoming a disservice to think of statically typed OO languages as being somehow inferior to the true ideal of object-oriented programming.
- nextos 6y ago
  Ruby is a joy to use and relatively close to Smalltalk in many many ways. I wish Ruby had taken Python's spot. When Rails exploded ~2006, I thought it'd become a mainstream language. But sadly it has never been very popular for non-web things, if we exclude Japan. One reason is probably that the standard Ruby implementation (MRI) was really slow till recently. Smalltalk, on the other hand, had extremely good VMs that served as embryo for the JVM. I've used Ruby for many big projects (but never used Rails!) and it has scaled really well for large and exotic things such as abstract interpreters.
  - codetrotter 6y ago
    Speaking of Ruby, there is this book that I read a few years ago (five years ago, in fact – time flies), that was using Ruby when explaining the things it was talking about. Personally I don’t use Ruby and prefer Python instead, but the book was very enjoyable nonetheless so I would recommend that book to anyone, even to people like me who don’t really like Ruby in general and don’t really want to read or write Ruby in general. Stuart, T., 2013. Understanding Computation: From Simple Machines To Impossible Programs. O’Reilly. Book website: https://computationbook.com/ https://computationbook.com/
    - joshhogg 6y ago
      This books looks super interesting. Did you find any of it applicable to particular problems you are working on or was it good general knowledge?
      - codetrotter 6y ago
        As good general knowledge yes
    - AdieuToLogic 6y ago
      Another good "non-rails" Ruby book is "Enterprise Integration with Ruby"[0]. Unfortunately, it's a bit dated (2006), so I am sure some of what Schmidt details is no longer supported/valid. Still, a cool book IMHO. 0 - https://www.amazon.com/Enterprise-Integration-Ruby-Maik-Schmidt/dp/0976694069 https://www.amazon.com/Enterprise-Integration-Ruby-Maik-Schm...
madmaniak 6y ago
Principle 1 "If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual." Globally we go in every aspect against this principle going into narrow specialisations. Such a movement is made on a purpose by the flow of money of central printers/powers, and the result is according to the principle - luck of creative spirit of single individuals. The tools which we are learning and the way we are trained is against creativity. In last 10y perspective is visible how the industry is mislead in wrong directions by the biggest players. So don't ask why we don't use Smalltak-like technology in 40y.
- coliveira 6y ago
  To expand on your comment, the reason why we don't use simple and understandable tools like Smalltalk is that the industry is not interested on this kind of simplicity. For them it is much better to pay thousands of people to work on different, unrelated things and them put these things together at all levels: hardware, OS, software, etc. The resulting system is impossible to understand by a single person, and works only because of the continuous struggle of thousands of people to make it work. But this is positive for the industry behind this architecture: every year they will create new components to fix flaws, introduce new ones, and keep the wheel of the technology industry running.
- carapace 6y ago
  VPRI (Alan Kay's research institute) had a project called STEPS that's worth looking into. "From the desktop to the metal in 20,000 lines of code." They pretty much did it.
mucholove 6y ago
The best Smalltalk is Objective-Smalltalk. It's a beautiful way to go up and down the ladder of inference. Basically—Objective-Smalltalk is based on Objective-C which is a superset of C. It's like having the two worlds coming together at the same time. Does it miss some of the beauty of a totally integrated system like Squeak? Sure. But that's kind of the beauty too. Can we make an Objective-Smalltalk takeover? http://objective.st http://objective.st
- cxr 6y ago
  I was recently re-watching the old demo of 280 North's Atlas, an Interface Builder-inspired tool. And when I think about it, it also seems a little strange that object lovers and all today's disaffected Mac fans could pick up the pieces of GNUStep and start building out a usable replacement for themselves as a reaction against the deterioration and inevitable demise of the Mac, but that isn't materializing. There's something, I think, in the Mac developer psyche that says they're responsible for building their own discrete little apps and doing a lot of polishing on them, but they're completely uninvolved in shaping or otherwise working on the environment/platform itself. This is the difference between Mac folks and Smalltalkers. https://vimeo.com/11486446 https://vimeo.com/11486446
  - mucholove 6y ago
    Necessity is the mother of invention! If the demise of the Mac / Cocoa API's is nigh—expect there to be some work on it. This guy is doing some interesting work: https://mulle-objc.github.io https://mulle-objc.github.io One more factor: my guess is that GNUstep picked the LGPL—which although more permissive than the GPL—turns away the money / status seeking Mac folks.
    - cxr 6y ago
      GNUstep being LGPL has as much adverse impact on developers as Apple's implementation being proprietary. (I.e., none.) It's the _LGPL_ after all, not the GPL. GNUstep has also moved to GitHub and seems to favor the the MIT license nowadays where possible (e.g., libobjc2)[1][2]. 1. https://github.com/gnustep/libobjc2 https://github.com/gnustep/libobjc2 2. http://etoileos.com/dev/licensing/ http://etoileos.com/dev/licensing/
ChrisMarshallNY 6y ago
Smalltalk became Objective-C. Objective-C has informed Swift. Long live Smalltalk.
- ibiza 6y ago
  Each link in this lineage is tenuous. Objective-C took Smalltalk's call syntax, its class def (in a sense?), and its late fn binding, but little else. It certainly didn't take what made Smalltalk, Smalltalk. Full disclosure: I really like both languages. I struggle to find the mapping between Objective-C and Swift, other than "same company" and must preserve backwards compatibility. Smalltalk became Squeak. Long live Squeak. :)
  - ChrisMarshallNY 6y ago
    I think that Swift got a lot of its "philosophical" structure from ObjC. After Swift was released, I understood why ObjC 2.0 was written the way that it was. It was modified to allow the standard libraries and SDKs to transition to Swift. I remember coming from C++ (CodeWarrior/PowerPlant), and encountering ObjC, and going "Whiskey Tango Foxtrot?". After a while, though, I got used to it, and actually started to enjoy ObjC, in a way that C++ never got me. I enjoy Swift, even more. After years of writing code in languages I didn't really like (C++/PHP), Swift is something that I actually enjoy. I suspect that Smalltalk, and its affect, are responsible for the "enjoyment" factor of Swift. I consider most of the lineage to be "in spirit," more than "in detail." It's quite easy to shoot holes, if we get particular.
- superdisk 6y ago
  Swift basically stripped out what was left of Smalltalk from Objective C.
- wool_gather 6y ago
  If Swift didn't have a non-negotiable -- because of its deployment on Apple platforms -- requirement for strong interop with ObjC, I firmly believe it would have been even more like Rust than it already is. The flexibility that's enabled directly by ObjC's simplicity is just not a goal for Swift.
saadalem 6y ago
What if all Smalltalk objects had an URL? It could provide simple (and complex) network services to any computer on the Internet. There is a profound lack of ambition around software and Operating Systems.
- tgbugs 6y ago
  Work on this has been done. See Polymorphic Identifiers: Uniform Resource Access in Objective-Smalltalk [1]. 1. https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...
  - mpweiher 6y ago
    In fact, the Objective-Smalltalk site (http://objective.st http://objective.st) is served by an Objective-Smalltalk web server, with the incoming URLs converted the PIs and then dispatched via nested Storage Combinators. ( https://dl.acm.org/doi/10.1145/3359591.3359729 https://dl.acm.org/doi/10.1145/3359591.3359729). :-)
coliveira 6y ago
Smalltalk can be described concisely as a graphical UNIX: a small set of computational mechanisms, designed to be general and interoperate for the construction of larger systems. Unfortunately, the GUI industry was inspired but never decided to use smalltalk itself as its foundation since C/UNIX already existed, providing higher performance for the hardware available at the time.
- mpweiher 6y ago
  > Smalltalk can be described concisely as a graphical UNIX Or Unix as a closet Smalltalk... "Liberating the Smalltalk lurking in C and Unix" by Stephen Kell https://www.youtube.com/watch?v=LwicN2u6Dro https://www.youtube.com/watch?v=LwicN2u6Dro
jbverschoor 6y ago
What I miss these days is interaction with applications. Yes, rest-APIs are fun and all. And both Apple and Microsoft have their component model out there, but other developers don’t take the time. That, combined with the Superbad tools of patching things together make it almost useless these days. It’s unfortunate, because there’s so much you can do with good interoperability.
e12e 6y ago
Always thought the ideas behind lively kernel was interesting - web browser/js engine as the run time, webdav as the persistence layer. https://lively-kernel.org/ https://lively-kernel.org/ Looks like they are on the third iteration now: https://github.com/LivelyKernel/lively4-core https://github.com/LivelyKernel/lively4-core https://lively-kernel.org/lively4/lively4-core/start.html https://lively-kernel.org/lively4/lively4-core/start.html Apparently now using git for persistence.
Viliam1234 6y ago
> No component in a complex system should depend on the internal details of any other component. Unfortunately, the internal details of other components are important for performance. It is not enough to know that something is e.g. an ordered collection; I also need to know whether accessing items randomly has an O(1) or O(n) cost. Increasing the complexity from linear to quadratic is not a minor detail that a faster processor would solve. But when you start caring about performance, suddenly you don't deal with ordered collections, but with arrays, linked lists, red-black trees, and whatever. Then you also get unspecified ordered collections returned from other modules, and you wonder whether it is okay to use them as they are, or whether you should pay a one-time price to convert them to a more efficient collection. And somewhere, a new programmer is crying: "I just wanted to create a list containing dozen numbers, why do I have to deal with all this complexity?"
- deleted 6y ago
  [deleted]
PeterStuer 6y ago
I liked Smalltalk for some aspects, but I never liked the 'Message to Object' restriction. It dispatches based on the receiver's Class. I always preferred the Generic Functions of CLOS, that allows capturing the semantics of an operation outside the stranglehold of the Single Object pattern.
- jecel 6y ago
  If you don't mind dealing with dead projects, you might enjoy Slate as a Smalltalk with multimethods: https://github.com/briantrice/slate-language https://github.com/briantrice/slate-language
codr7 6y ago
To me Smalltalk has the same kind of beauty to it as C, it's pure and simple. They both allow me to keep the entire language in my head, which means I can spend all my energy on solving real problems. And the interactivity is awesome once you wrap your head around it. If you haven't experienced it, you most likely won't see the point since you assume much of what it enables is impossible. I'm still not sold on the image-based dev cycle, Common Lisp allows the same level of interactivity and even more power without giving up files. They killed it by trying to keep selling it for profit at a time when free alternatives started appearing.
johndoe42377 6y ago
Boy, I love this stuff. Two subtle but necessary and principal clarifications. 1. A reference is not "from that time on". The notion of time must be irrelevant here. The reference is immutable until the process (scope) ends, not in time, just ends. 2. Objects are unnecessary. References and the abstraction principle are necessary and sufficient. Duck-typing is abstraction without an object. This is what Haskell type-classes captured - to be a _____ is to be able to ______. Greeks and Platonism plagued OO minds.
mlang23 6y ago
I have never worked with a true Smalltalk. However, I am using a Smalltalk-inspired language pretty extensively, SuperCollider. I never really dived into a comparison, since I am lacking real Smalltalk knowledge. However, I'd be interested what someone who knows both languages things about SC compared to Smalltalk.
- escales 6y ago
  As a specialised music-programming language and audio server, Supercollider outclasses Smalltalk — and most, if not all, other music computing systems. As a high-productivity general-purpose programming language, Smalltalk is considerably more sophisticated and capable. Supercollider has two distinct components – a backend software synthesizer (audio server) and a frontend combining an IDE and an interpreted language which draws strongly on Smalltalk, but is written in a C-like syntax. The front and back ends (typically, but not always, running on the same machine) communicate using the lightweight OSC protocol. It is perfectly possible to use Smalltalk or indeed any other language as an alternative front end to Supercollider audio synthesis engine. The Supercollider language (sclang) mirrors Smalltalk very closely in some respects, but also has major differences. As in Smalltalk, Supercollider has a metaclass structure and closures which are used to implement control structures. Supercollider makes extensive use of continuations to flexibly sequence musical materials, but is file-based rather than image-based. Smalltalk has far more sophisticated support for refactoring, debugging and programming. For example, it is possible to inspect, manipulate and restart using live objects in the stack after any exception. Smalltalk has a much simpler syntax, a rich IDE, and a wide variety of specialised tools for browsing, refactoring and inspection. In Smalltalk, the complete source code for the whole system is available at all times. Smalltalk has powerful and well documented tools for reflection and modifying the system or changing the model of computation (such as selectively modifying the doNotUnderstand method - though in fairness this is also technically possible in Supercollider). More generally, Smalltalk parsimoniously exploits a small number of principles with ruthless consistency and clarity, making it relatively easy to learn, understand, and if desired modify, any part of the system. Supercollider has a different aim, to provide the maximum power and flexibility for carrying out music purposes to the highest quality. This sometimes leads to trade-offs between clarity and power, and some frameworks whose details are hard to understand. In their contrasting ways, both are outstandingly engineered, seminal languages.
boshomi 6y ago
Memento from Internet Archive as of 2007-01-01 16:04:21 http://web.archive.org/web/20070101160421/http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html http://web.archive.org/web/20070101160421/http://users.ipa.n...

194 points by joubert 6y ago

d3ckard 6y ago

Very interesting read, though it hurts me to see optimism in this paper mostly unwarranted from today’s perspective.

shawnz 6y ago
Was it unwarranted? > While the presentation frequently touches on Smalltalk "motherhood", the principles themselves are more general and should prove useful in evaluating other systems and in guiding future work. Indeed the principles of Smalltalk went on to guide the design of many future languages

jasim 6y ago

If you're tired of hearing about the virtues of Smalltalk (like I was at one point) and ask "if it is so good, why isn't it popular?", then watch @deech's talk (Aditya Siram) - "What FP can learn from SmallTalk" - https://www.youtube.com/watch?v=baxtyeFVn3w https://www.youtube.com/watch?v=baxtyeFVn3w I think it is the most accessible explanation of the marvel of Smalltalk, for those who were not lucky to work with it during the late 80-90s. Also I think Ruby is the mainstream language that is closest to Smalltalk today, with the idea that everything is an object and late-binding as much as possible. One thing I can't help point out is that Smalltalk / Alan Kay's vision of interconnected objects forming a recursive computing system is not the only "true" vision of OO out there. From Simula thru C++ and then Java and C# also are object-oriented (or class-oriented for those who care about the distinction), but they are statically typed. It is also OO because OO is a word, not a mathematical definition, and when people talk about OO, there is enough similarity between all these variations that we consider all of them to be in the same camp. Plus with the growing move towards strict static typing even in interpreted languages, which I think is driven by actual industry needs and programmer preferences than external marketing, it is becoming a disservice to think of statically typed OO languages as being somehow inferior to the true ideal of object-oriented programming.

nextos 6y ago
Ruby is a joy to use and relatively close to Smalltalk in many many ways. I wish Ruby had taken Python's spot. When Rails exploded ~2006, I thought it'd become a mainstream language. But sadly it has never been very popular for non-web things, if we exclude Japan. One reason is probably that the standard Ruby implementation (MRI) was really slow till recently. Smalltalk, on the other hand, had extremely good VMs that served as embryo for the JVM. I've used Ruby for many big projects (but never used Rails!) and it has scaled really well for large and exotic things such as abstract interpreters.
- codetrotter 6y ago
  Speaking of Ruby, there is this book that I read a few years ago (five years ago, in fact – time flies), that was using Ruby when explaining the things it was talking about. Personally I don’t use Ruby and prefer Python instead, but the book was very enjoyable nonetheless so I would recommend that book to anyone, even to people like me who don’t really like Ruby in general and don’t really want to read or write Ruby in general. Stuart, T., 2013. Understanding Computation: From Simple Machines To Impossible Programs. O’Reilly. Book website: https://computationbook.com/ https://computationbook.com/
  - joshhogg 6y ago
    This books looks super interesting. Did you find any of it applicable to particular problems you are working on or was it good general knowledge?
    - codetrotter 6y ago
      As good general knowledge yes
  - AdieuToLogic 6y ago
    Another good "non-rails" Ruby book is "Enterprise Integration with Ruby"[0]. Unfortunately, it's a bit dated (2006), so I am sure some of what Schmidt details is no longer supported/valid. Still, a cool book IMHO. 0 - https://www.amazon.com/Enterprise-Integration-Ruby-Maik-Schmidt/dp/0976694069 https://www.amazon.com/Enterprise-Integration-Ruby-Maik-Schm...

madmaniak 6y ago

Principle 1 "If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual." Globally we go in every aspect against this principle going into narrow specialisations. Such a movement is made on a purpose by the flow of money of central printers/powers, and the result is according to the principle - luck of creative spirit of single individuals. The tools which we are learning and the way we are trained is against creativity. In last 10y perspective is visible how the industry is mislead in wrong directions by the biggest players. So don't ask why we don't use Smalltak-like technology in 40y.

coliveira 6y ago
To expand on your comment, the reason why we don't use simple and understandable tools like Smalltalk is that the industry is not interested on this kind of simplicity. For them it is much better to pay thousands of people to work on different, unrelated things and them put these things together at all levels: hardware, OS, software, etc. The resulting system is impossible to understand by a single person, and works only because of the continuous struggle of thousands of people to make it work. But this is positive for the industry behind this architecture: every year they will create new components to fix flaws, introduce new ones, and keep the wheel of the technology industry running.
carapace 6y ago
VPRI (Alan Kay's research institute) had a project called STEPS that's worth looking into. "From the desktop to the metal in 20,000 lines of code." They pretty much did it.

mucholove 6y ago

The best Smalltalk is Objective-Smalltalk. It's a beautiful way to go up and down the ladder of inference. Basically—Objective-Smalltalk is based on Objective-C which is a superset of C. It's like having the two worlds coming together at the same time. Does it miss some of the beauty of a totally integrated system like Squeak? Sure. But that's kind of the beauty too. Can we make an Objective-Smalltalk takeover? http://objective.st http://objective.st

cxr 6y ago
I was recently re-watching the old demo of 280 North's Atlas, an Interface Builder-inspired tool. And when I think about it, it also seems a little strange that object lovers and all today's disaffected Mac fans could pick up the pieces of GNUStep and start building out a usable replacement for themselves as a reaction against the deterioration and inevitable demise of the Mac, but that isn't materializing. There's something, I think, in the Mac developer psyche that says they're responsible for building their own discrete little apps and doing a lot of polishing on them, but they're completely uninvolved in shaping or otherwise working on the environment/platform itself. This is the difference between Mac folks and Smalltalkers. https://vimeo.com/11486446 https://vimeo.com/11486446
- mucholove 6y ago
  Necessity is the mother of invention! If the demise of the Mac / Cocoa API's is nigh—expect there to be some work on it. This guy is doing some interesting work: https://mulle-objc.github.io https://mulle-objc.github.io One more factor: my guess is that GNUstep picked the LGPL—which although more permissive than the GPL—turns away the money / status seeking Mac folks.
  - cxr 6y ago
    GNUstep being LGPL has as much adverse impact on developers as Apple's implementation being proprietary. (I.e., none.) It's the _LGPL_ after all, not the GPL. GNUstep has also moved to GitHub and seems to favor the the MIT license nowadays where possible (e.g., libobjc2)[1][2]. 1. https://github.com/gnustep/libobjc2 https://github.com/gnustep/libobjc2 2. http://etoileos.com/dev/licensing/ http://etoileos.com/dev/licensing/

ChrisMarshallNY 6y ago

Smalltalk became Objective-C. Objective-C has informed Swift. Long live Smalltalk.

ibiza 6y ago
Each link in this lineage is tenuous. Objective-C took Smalltalk's call syntax, its class def (in a sense?), and its late fn binding, but little else. It certainly didn't take what made Smalltalk, Smalltalk. Full disclosure: I really like both languages. I struggle to find the mapping between Objective-C and Swift, other than "same company" and must preserve backwards compatibility. Smalltalk became Squeak. Long live Squeak. :)
- ChrisMarshallNY 6y ago
  I think that Swift got a lot of its "philosophical" structure from ObjC. After Swift was released, I understood why ObjC 2.0 was written the way that it was. It was modified to allow the standard libraries and SDKs to transition to Swift. I remember coming from C++ (CodeWarrior/PowerPlant), and encountering ObjC, and going "Whiskey Tango Foxtrot?". After a while, though, I got used to it, and actually started to enjoy ObjC, in a way that C++ never got me. I enjoy Swift, even more. After years of writing code in languages I didn't really like (C++/PHP), Swift is something that I actually enjoy. I suspect that Smalltalk, and its affect, are responsible for the "enjoyment" factor of Swift. I consider most of the lineage to be "in spirit," more than "in detail." It's quite easy to shoot holes, if we get particular.
superdisk 6y ago
Swift basically stripped out what was left of Smalltalk from Objective C.
wool_gather 6y ago
If Swift didn't have a non-negotiable -- because of its deployment on Apple platforms -- requirement for strong interop with ObjC, I firmly believe it would have been even more like Rust than it already is. The flexibility that's enabled directly by ObjC's simplicity is just not a goal for Swift.

saadalem 6y ago

What if all Smalltalk objects had an URL? It could provide simple (and complex) network services to any computer on the Internet. There is a profound lack of ambition around software and Operating Systems.

tgbugs 6y ago
Work on this has been done. See Polymorphic Identifiers: Uniform Resource Access in Objective-Smalltalk [1]. 1. https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...
- mpweiher 6y ago
  In fact, the Objective-Smalltalk site (http://objective.st http://objective.st) is served by an Objective-Smalltalk web server, with the incoming URLs converted the PIs and then dispatched via nested Storage Combinators. ( https://dl.acm.org/doi/10.1145/3359591.3359729 https://dl.acm.org/doi/10.1145/3359591.3359729). :-)

coliveira 6y ago

Smalltalk can be described concisely as a graphical UNIX: a small set of computational mechanisms, designed to be general and interoperate for the construction of larger systems. Unfortunately, the GUI industry was inspired but never decided to use smalltalk itself as its foundation since C/UNIX already existed, providing higher performance for the hardware available at the time.

mpweiher 6y ago
> Smalltalk can be described concisely as a graphical UNIX Or Unix as a closet Smalltalk... "Liberating the Smalltalk lurking in C and Unix" by Stephen Kell https://www.youtube.com/watch?v=LwicN2u6Dro https://www.youtube.com/watch?v=LwicN2u6Dro

jbverschoor 6y ago

What I miss these days is interaction with applications. Yes, rest-APIs are fun and all. And both Apple and Microsoft have their component model out there, but other developers don’t take the time. That, combined with the Superbad tools of patching things together make it almost useless these days. It’s unfortunate, because there’s so much you can do with good interoperability.

e12e 6y ago

Always thought the ideas behind lively kernel was interesting - web browser/js engine as the run time, webdav as the persistence layer. https://lively-kernel.org/ https://lively-kernel.org/ Looks like they are on the third iteration now: https://github.com/LivelyKernel/lively4-core https://github.com/LivelyKernel/lively4-core https://lively-kernel.org/lively4/lively4-core/start.html https://lively-kernel.org/lively4/lively4-core/start.html Apparently now using git for persistence.

Viliam1234 6y ago

> No component in a complex system should depend on the internal details of any other component. Unfortunately, the internal details of other components are important for performance. It is not enough to know that something is e.g. an ordered collection; I also need to know whether accessing items randomly has an O(1) or O(n) cost. Increasing the complexity from linear to quadratic is not a minor detail that a faster processor would solve. But when you start caring about performance, suddenly you don't deal with ordered collections, but with arrays, linked lists, red-black trees, and whatever. Then you also get unspecified ordered collections returned from other modules, and you wonder whether it is okay to use them as they are, or whether you should pay a one-time price to convert them to a more efficient collection. And somewhere, a new programmer is crying: "I just wanted to create a list containing dozen numbers, why do I have to deal with all this complexity?"

deleted 6y ago
[deleted]

PeterStuer 6y ago

I liked Smalltalk for some aspects, but I never liked the 'Message to Object' restriction. It dispatches based on the receiver's Class. I always preferred the Generic Functions of CLOS, that allows capturing the semantics of an operation outside the stranglehold of the Single Object pattern.

jecel 6y ago
If you don't mind dealing with dead projects, you might enjoy Slate as a Smalltalk with multimethods: https://github.com/briantrice/slate-language https://github.com/briantrice/slate-language

codr7 6y ago

To me Smalltalk has the same kind of beauty to it as C, it's pure and simple. They both allow me to keep the entire language in my head, which means I can spend all my energy on solving real problems. And the interactivity is awesome once you wrap your head around it. If you haven't experienced it, you most likely won't see the point since you assume much of what it enables is impossible. I'm still not sold on the image-based dev cycle, Common Lisp allows the same level of interactivity and even more power without giving up files. They killed it by trying to keep selling it for profit at a time when free alternatives started appearing.

johndoe42377 6y ago

Boy, I love this stuff. Two subtle but necessary and principal clarifications. 1. A reference is not "from that time on". The notion of time must be irrelevant here. The reference is immutable until the process (scope) ends, not in time, just ends. 2. Objects are unnecessary. References and the abstraction principle are necessary and sufficient. Duck-typing is abstraction without an object. This is what Haskell type-classes captured - to be a _____ is to be able to ______. Greeks and Platonism plagued OO minds.

mlang23 6y ago

I have never worked with a true Smalltalk. However, I am using a Smalltalk-inspired language pretty extensively, SuperCollider. I never really dived into a comparison, since I am lacking real Smalltalk knowledge. However, I'd be interested what someone who knows both languages things about SC compared to Smalltalk.

escales 6y ago
As a specialised music-programming language and audio server, Supercollider outclasses Smalltalk — and most, if not all, other music computing systems. As a high-productivity general-purpose programming language, Smalltalk is considerably more sophisticated and capable. Supercollider has two distinct components – a backend software synthesizer (audio server) and a frontend combining an IDE and an interpreted language which draws strongly on Smalltalk, but is written in a C-like syntax. The front and back ends (typically, but not always, running on the same machine) communicate using the lightweight OSC protocol. It is perfectly possible to use Smalltalk or indeed any other language as an alternative front end to Supercollider audio synthesis engine. The Supercollider language (sclang) mirrors Smalltalk very closely in some respects, but also has major differences. As in Smalltalk, Supercollider has a metaclass structure and closures which are used to implement control structures. Supercollider makes extensive use of continuations to flexibly sequence musical materials, but is file-based rather than image-based. Smalltalk has far more sophisticated support for refactoring, debugging and programming. For example, it is possible to inspect, manipulate and restart using live objects in the stack after any exception. Smalltalk has a much simpler syntax, a rich IDE, and a wide variety of specialised tools for browsing, refactoring and inspection. In Smalltalk, the complete source code for the whole system is available at all times. Smalltalk has powerful and well documented tools for reflection and modifying the system or changing the model of computation (such as selectively modifying the doNotUnderstand method - though in fairness this is also technically possible in Supercollider). More generally, Smalltalk parsimoniously exploits a small number of principles with ruthless consistency and clarity, making it relatively easy to learn, understand, and if desired modify, any part of the system. Supercollider has a different aim, to provide the maximum power and flexibility for carrying out music purposes to the highest quality. This sometimes leads to trade-offs between clarity and power, and some frameworks whose details are hard to understand. In their contrasting ways, both are outstandingly engineered, seminal languages.

boshomi 6y ago

Memento from Internet Archive as of 2007-01-01 16:04:21 http://web.archive.org/web/20070101160421/http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html http://web.archive.org/web/20070101160421/http://users.ipa.n...