6 ms·

IMO, Smalltalk-the-system is best thought of as an OS, yes. (Remember how everyone ridiculed the idea of Smalltalk's images right up until virtual machines beca

by tonyg 5y ago

IMO, Smalltalk-the-system is best thought of as an OS, yes. (Remember how everyone ridiculed the idea of Smalltalk's images right up until virtual machines became a thing?) It has a runtime and a systems programming language, too: the Smalltalk VM, and Smalltalk-the-language. Analogously, Unix has its kernel and C, respectively. The global variables of Smalltalk are analogous to Unix files. Smalltalk processes to Unix processes. It's not a perfect analogy but I found it surprisingly useful once I stumbled across it. Preferable, though? Not sure. Certainly, as Marcel notes, a flat file system isn't the best idea; but then, is a hierarchical strict tree? (Related: https://eighty-twenty.org/2011/05/08/weaknesses-of-smalltalk-strengths-of-erlang https://eighty-twenty.org/2011/05/08/weaknesses-of-smalltalk..., https://eighty-twenty.org/2016/05/05/unix-is-incorrectly-factored https://eighty-twenty.org/2016/05/05/unix-is-incorrectly-fac...) I think you'd have to burn the disk packs (ie: neither Smalltalk nor Unix as they stand make a suitable foundation), but out of the ashes I think something largely based on Smalltalk taking into account lessons from the forty (!) years that followed it could definitely end up being preferable. Coming back to OP, and viewing Smalltalk as an operating system on equal footing with Unix: Different operating systems interact best via networks. Which neither Smalltalk-the-OS, Smalltalk-the-language, Unix-the-OS nor C-the-language support particularly well.

jrochkind1 5y ago
OK, so the OP says if smalltalk had worked with files better, maybe smalltalk on unix could have been a thing that would have changed history. Your response is... that's irrelevant because... smalltalk was really making the play to be the OS, not to work with OSs, and it works just fine with files on it's own terms, for that goal. Do I understand your argument correctly? OK, it's a perspective!
batman-farts 5y ago
I think this is a worthwhile perspective. Looking at Pharo 9.0 circa 2021, it’s still got its own classes for Kernel, Scheduler, etc.
- igouy 5y ago
  Which other programming language implementations have provided scheduling independent from the host OS? https://en.wikipedia.org/wiki/Green_threads https://en.wikipedia.org/wiki/Green_threads
- deleted 5y ago
  [deleted]
mpweiher 5y ago
> Smalltalk-the-system is best thought of as an OS That is the is that OP is lamenting, the fact that this attitude was a significant (not: sole) cause in Smalltalk's demise. He is talking about the ought, it shouldn't have been this way, and if it hadn't been this way it would have been a LOT better. Keep in mind that you can still build a pure Smalltalk OS on top of the Smalltalk that's not an OS, if you want to. > It's not a perfect analogy It is at best an analogy, and not a particularly good one at that, as whereas Smalltalk can function as an OS (you can port Squeak to bare metal fairly easily, for example), it isn't a very good at it, at least not when it comes to the functions OSes are expected to fulfil these days. And so the analogy stays at most an analogy, and breaks down even at that pretty quickly. It turns out that what OP was talking about was created, sort of: NeXTstep. Except it substituted Objective-C for Smalltalk. Heck, it even did messaging at the OS layer (Mach). > ...viewing Smalltalk as an operating system on equal footing with Unix... That is exactly the problem. > Different operating systems interact best via networks. And that turns out to be significantly more difficult than various languages interacting on the same box. > Which neither Smalltalk-the-OS, Smalltalk-the-language, Unix-the-OS nor C-the-language support particularly well. True. Objective-S supports REST servers and clients effectively at the language level. And filesystems and Unix pipes. http://objective.st/ http://objective.st/ And it doesn't insist on being the entire world.
- tonyg 5y ago
  > He is talking about the ought I think he's wrong, both about the "is" and about the "ought". The reason I posted originally, way upthread, was to respond to OP's claim of "Smalltalk's rejection of the file-system and command-line". I don't believe it rejected either thing. It has an internal file system, as discussed, but it also had and has perfectly reasonable support for reading and writing external, traditional files. And it has various kinds of command-line, as discussed. I don't think it was anything about Smalltalk's ability to handle JPEGs or email or NFS or even text files that was the problem. I don't believe that appeasing the Unix world is (or would have been) either necessary or sufficient for Smalltalk success. I think the success of Unix is path-dependent; a historical accident. It had momentum and Smalltalk didn't. It blows my mind that people still think Unixisms are somehow some kind of universal apex of computing [†]! I suppose there are, at some level, reasons for Smalltalk's relative lack of success; and while I don't know what they are, I don't think OP gives a good one. > [Interacting via networks] turns out to be significantly more difficult than various languages interacting on the same box. I... don't believe this to be the case. At all. In theory or practice. It has certainly not been my experience. > Objective-S supports [a bunch of Unix stuff] Sure, OK. So do a million other languages. What is, to my mind, special about Smalltalk is exactly that it takes the identity between programming language runtime and operating system seriously, and tries to flip the script: what if, instead of dumbing down our languages to fit our operating systems, we raised our ambitions about what an operating system could be, to fit our languages? Smalltalk as it stands is a poor operating system, of course. You're right that it doesn't come close to covering "the functions OSes are expected to fulfil these days". It is basically a time capsule of 1978. Semi-cooperative scheduling, Monitors and Semaphores for mutexing, flat file system, insufficient internal isolation/namespacing, poorly integrated networking. If even a small fraction of the energy put into making Unix cover those functions had been put into Smalltalk... well. We'll never know unless someone puts in the time. -- [†] "... an utterly insignificant little blue green planet whose ape-descended life forms are so amazingly primitive that they still think [Unix is] a pretty neat idea"

by tonyg 5y ago

jrochkind1 5y ago

OK, so the OP says if smalltalk had worked with files better, maybe smalltalk on unix could have been a thing that would have changed history. Your response is... that's irrelevant because... smalltalk was really making the play to be the OS, not to work with OSs, and it works just fine with files on it's own terms, for that goal. Do I understand your argument correctly? OK, it's a perspective!

batman-farts 5y ago

I think this is a worthwhile perspective. Looking at Pharo 9.0 circa 2021, it’s still got its own classes for Kernel, Scheduler, etc.

igouy 5y ago
Which other programming language implementations have provided scheduling independent from the host OS? https://en.wikipedia.org/wiki/Green_threads https://en.wikipedia.org/wiki/Green_threads
deleted 5y ago
[deleted]

mpweiher 5y ago

> Smalltalk-the-system is best thought of as an OS That is the is that OP is lamenting, the fact that this attitude was a significant (not: sole) cause in Smalltalk's demise. He is talking about the ought, it shouldn't have been this way, and if it hadn't been this way it would have been a LOT better. Keep in mind that you can still build a pure Smalltalk OS on top of the Smalltalk that's not an OS, if you want to. > It's not a perfect analogy It is at best an analogy, and not a particularly good one at that, as whereas Smalltalk can function as an OS (you can port Squeak to bare metal fairly easily, for example), it isn't a very good at it, at least not when it comes to the functions OSes are expected to fulfil these days. And so the analogy stays at most an analogy, and breaks down even at that pretty quickly. It turns out that what OP was talking about was created, sort of: NeXTstep. Except it substituted Objective-C for Smalltalk. Heck, it even did messaging at the OS layer (Mach). > ...viewing Smalltalk as an operating system on equal footing with Unix... That is exactly the problem. > Different operating systems interact best via networks. And that turns out to be significantly more difficult than various languages interacting on the same box. > Which neither Smalltalk-the-OS, Smalltalk-the-language, Unix-the-OS nor C-the-language support particularly well. True. Objective-S supports REST servers and clients effectively at the language level. And filesystems and Unix pipes. http://objective.st/ http://objective.st/ And it doesn't insist on being the entire world.

tonyg 5y ago
> He is talking about the ought I think he's wrong, both about the "is" and about the "ought". The reason I posted originally, way upthread, was to respond to OP's claim of "Smalltalk's rejection of the file-system and command-line". I don't believe it rejected either thing. It has an internal file system, as discussed, but it also had and has perfectly reasonable support for reading and writing external, traditional files. And it has various kinds of command-line, as discussed. I don't think it was anything about Smalltalk's ability to handle JPEGs or email or NFS or even text files that was the problem. I don't believe that appeasing the Unix world is (or would have been) either necessary or sufficient for Smalltalk success. I think the success of Unix is path-dependent; a historical accident. It had momentum and Smalltalk didn't. It blows my mind that people still think Unixisms are somehow some kind of universal apex of computing [†]! I suppose there are, at some level, reasons for Smalltalk's relative lack of success; and while I don't know what they are, I don't think OP gives a good one. > [Interacting via networks] turns out to be significantly more difficult than various languages interacting on the same box. I... don't believe this to be the case. At all. In theory or practice. It has certainly not been my experience. > Objective-S supports [a bunch of Unix stuff] Sure, OK. So do a million other languages. What is, to my mind, special about Smalltalk is exactly that it takes the identity between programming language runtime and operating system seriously, and tries to flip the script: what if, instead of dumbing down our languages to fit our operating systems, we raised our ambitions about what an operating system could be, to fit our languages? Smalltalk as it stands is a poor operating system, of course. You're right that it doesn't come close to covering "the functions OSes are expected to fulfil these days". It is basically a time capsule of 1978. Semi-cooperative scheduling, Monitors and Semaphores for mutexing, flat file system, insufficient internal isolation/namespacing, poorly integrated networking. If even a small fraction of the energy put into making Unix cover those functions had been put into Smalltalk... well. We'll never know unless someone puts in the time. -- [†] "... an utterly insignificant little blue green planet whose ape-descended life forms are so amazingly primitive that they still think [Unix is] a pretty neat idea"