3 ms·

“Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one.” — Daniel Ingalls “Design Principals Be

“Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one.” — Daniel Ingalls “Design Principals Behind Smalltalk” [0] Learning the Smalltalk “world”/vm is an essential part of learning Smalltalk the language. Many people are initially put off by this but if you try to find a “Smalltalk without a Smalltalk-specific IDE” you are missing out on an enormous part of what Smalltalk is. 0. https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

JulianMorrison 7y ago
That feels like a sentiment from gentler, single-user time. Unless Smalltalk has grown some serious security chops in the interim.
- cbdumas 7y ago
  I disagree, a system implemented at the language level this way can in principle provide far stronger security guarantees than a typical operating system. Security issues can still come up obviously but they could essentially be isolated to the language runtime.
  - JulianMorrison 7y ago
    And then you're getting into things like capability-passing languages, but Smalltalk is not that.
    - true_religion 7y ago
      Bear in mind, it’s Ben about a decade since I last used Smalltalk, but at the time there was a web framework called Seaside based completely on using stored closures instead of normal Ajax. Digging into the code, I found that the VM just gives a code block access to all top level objects by default, but that isn’t a requirement. You can instantiate your own “global” and run the block within that. Back then I believe it was being used because old closures needed to see old top level class objects that might have been changed in the meanwhile. So you can use this to sandbox functions. I would imagine it isn’t perfect, but it could be made so.
rektide 7y ago
It's kind of amazing to me how few how little our work has been in developing "extras", general services, between language & user. The os has become a passive tool to run stuff on, but once it was an involved middle layer that the user might be tapping throughout their use, with the os & user capable of understanding exposing & controlling some of the items in the program space. Now the program is more of a blind space to the os, doing it's own thing. Adjusting a program's volume & resizing it's window is all the interaction most users project from os space into program space. More general systems research please!
- skore 7y ago
  The frustrating thing is - the more you learn about what the OS can do, the more you realize that many programming languages and the applications written in them quite often reimplement large parts of the OS for an astonishingly large portion of their codebase. That isolates developers from learning about the OS in the first place. (They always end up needing to learn about it, anyhow, so it's a bit futile. Now, however, they feel smug about it and pretend like they shouldn't need to learn all this OS stuff.) I guess developers always implement their own ignorance to a certain degree (and how could they not!? except, you know, spending more time learning their craft). What they don't know the OS can do, they will recreate - often poorly - in their own software. It does get rather comical and the various frameworks that you can subscribe to in modern programming languages repeat the concept, just that now, you're reimplementing things that the language can already do, but in the framework. My favorite example is the various kinds of "service" patterns, like dependency injection - in many instances that I've seen, you could boil most of its use down to simple function calls. But since global functions are ew, you instead create a service that you inject and then call a method in. Boom, the gods of OOP are happy and nobody is allowed to say: "Wait a minute, if I take a few steps back and squint a little, what you're doing looks surprisingly similar to a global function call." (And yes, I know, DI is supposed to be about overriding functions, yada yada very few people actually do that and it's often such an organizational hassle with downstream problems that projects eventually resort to put up conventions from doing that most of the time. Anyways - tell that to the people that I've seen implement, I kid you not, a CamelCaseService.)
ProfHewitt 7y ago
Ingalls was completely correct: It should be Actors all the way down (and Actor Systems all the way up). Soon there will be packages with millions of Actor cores for quadrillions of Actors. Operating systems, e.g. Linux, will be inadequate for Reusable Sacalable Intelligent Systems. See the following: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114

JulianMorrison 7y ago

That feels like a sentiment from gentler, single-user time. Unless Smalltalk has grown some serious security chops in the interim.

cbdumas 7y ago
I disagree, a system implemented at the language level this way can in principle provide far stronger security guarantees than a typical operating system. Security issues can still come up obviously but they could essentially be isolated to the language runtime.
- JulianMorrison 7y ago
  And then you're getting into things like capability-passing languages, but Smalltalk is not that.
  - true_religion 7y ago
    Bear in mind, it’s Ben about a decade since I last used Smalltalk, but at the time there was a web framework called Seaside based completely on using stored closures instead of normal Ajax. Digging into the code, I found that the VM just gives a code block access to all top level objects by default, but that isn’t a requirement. You can instantiate your own “global” and run the block within that. Back then I believe it was being used because old closures needed to see old top level class objects that might have been changed in the meanwhile. So you can use this to sandbox functions. I would imagine it isn’t perfect, but it could be made so.

rektide 7y ago

It's kind of amazing to me how few how little our work has been in developing "extras", general services, between language & user. The os has become a passive tool to run stuff on, but once it was an involved middle layer that the user might be tapping throughout their use, with the os & user capable of understanding exposing & controlling some of the items in the program space. Now the program is more of a blind space to the os, doing it's own thing. Adjusting a program's volume & resizing it's window is all the interaction most users project from os space into program space. More general systems research please!

skore 7y ago
The frustrating thing is - the more you learn about what the OS can do, the more you realize that many programming languages and the applications written in them quite often reimplement large parts of the OS for an astonishingly large portion of their codebase. That isolates developers from learning about the OS in the first place. (They always end up needing to learn about it, anyhow, so it's a bit futile. Now, however, they feel smug about it and pretend like they shouldn't need to learn all this OS stuff.) I guess developers always implement their own ignorance to a certain degree (and how could they not!? except, you know, spending more time learning their craft). What they don't know the OS can do, they will recreate - often poorly - in their own software. It does get rather comical and the various frameworks that you can subscribe to in modern programming languages repeat the concept, just that now, you're reimplementing things that the language can already do, but in the framework. My favorite example is the various kinds of "service" patterns, like dependency injection - in many instances that I've seen, you could boil most of its use down to simple function calls. But since global functions are ew, you instead create a service that you inject and then call a method in. Boom, the gods of OOP are happy and nobody is allowed to say: "Wait a minute, if I take a few steps back and squint a little, what you're doing looks surprisingly similar to a global function call." (And yes, I know, DI is supposed to be about overriding functions, yada yada very few people actually do that and it's often such an organizational hassle with downstream problems that projects eventually resort to put up conventions from doing that most of the time. Anyways - tell that to the people that I've seen implement, I kid you not, a CamelCaseService.)

ProfHewitt 7y ago

Ingalls was completely correct: It should be Actors all the way down (and Actor Systems all the way up). Soon there will be packages with millions of Actor cores for quadrillions of Actors. Operating systems, e.g. Linux, will be inadequate for Reusable Sacalable Intelligent Systems. See the following: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114