

Programming language as operating system (2013) - dgellow
http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2013-03.html#e2013-03-27T12_46_03.htm

======
magpi3
A big issue I have with this "middleware as operating system" approach is that
it invites, somewhat perversely in my opinion, throwing out your existing
tools and replacing them with very, very, very similar ones that are better
fits your new the middleware's paradigms. The whole "never have to leave
Smalltalk", "never have to leave Emacs" etc. mentality means that everything
has to be rewritten in your new middleware of choice... just so that you never
have to leave it.

~~~
moonchrome
Except the OS has a huge amount of overhead. The whole reason why the "event
driven IO", callback mess, etc. is a thing is because of the costs of native
OS threads. If you don't need the things OS provides (like process isolation
when running a single process server) then you're paying a _heavy_ cost.

The thing about IT is that it has evolved over decades and as the layers were
added to the stack on top of each other so many legacy design decisions are
now rooted deep in to the stack - if you can blow away the whole thing and
start from scratch you can get huge benefits for free. For example ZFS did the
same thing with filesystems and they got many things for free just out of
reexamining the initial assumptions that lead to the modern filesystems and
re-evaluating them in a modern context.

Getting rid of the OS is likely impractical for most things but it can
probably net you big wins in specific scenarios.

~~~
taeric
This is borderline crazy, though. The OS can have a lot of overhead, true.
More likely, asking your computer to do a ton of different things is the
actual overhead that is killing you.

That is, not only is "getting rid of the OS" likely impractical, you are
likely to see vast improvements by simply reducing the amount of tasks a given
computer is being asked to do. The gains from eliminating the OS,
specifically, probably pale to the gains from just not doing as many varied
things in the first place.

~~~
moonchrome
It's not just about misusing the features - the person writing the OS made a
bunch of trade offs in both design and implementation, and while those trade-
offs might be the best for the scenario where they were made in (and they
don't even have to be) it might not fit your scenario, sometimes you can get
huge and easy (well the pain will come from remaking the parts of the stack
you needed) gains if you can go down the stack and replace those wrong
assumptions.

------
jamii
Some more ideas in this vein (on the implementation side, at least):

Running the language runtime directly on top of Xen
([http://nymote.org/software/mirage/](http://nymote.org/software/mirage/),
[http://corp.galois.com/halvm](http://corp.galois.com/halvm),
[http://erlangonxen.org/](http://erlangonxen.org/) etc)

Replacing OS memory protection with a memory-safe VM
([https://news.ycombinator.com/item?id=7605687](https://news.ycombinator.com/item?id=7605687))

Using hardware virtualisation to reduce the costs of OS protection between
processes
([http://arrakis.cs.washington.edu/](http://arrakis.cs.washington.edu/))

While second is only speculative, Mirage has already demonstrated some fairly
respectable performance improvements by simplifying virtual memory management.

~~~
aurelianito
I think that is worth to also mention SqueakNOS, the squeak derivative that
does not require an OS.
[http://squeaknos.sourceforge.net](http://squeaknos.sourceforge.net)

------
tailrecursion
In the 60s, operating systems were designed in a world where the person
running the program was the same as the person who wrote the program. Today
many of the security or privacy schemes start by making a distinction between
the programmer and the user.

Besides sharing or "abstracting" the pieces of hardware that the app wants to
control -- as VMWare or a hypervisor might do -- the operating system has one
additional important role, which is to function as an agent for the user.

The apps, written by various persons, are running on a computer that belongs
to the user. The operating system keeps control of the computer -- the user's
computer -- in the user's hands, and keeps it from being "taken over" by the
apps.

This role or function of the operating system can certainly be subsumed by a
programming language / environment like Smalltalk or Java, but the idea of an
operating system has a purpose that directly reflects the different interests,
goals, or priorities of distinct entities interacting inside the machine.

Usually the master control program is seen as being against the users, but I'm
casting it as a good guy. I think that the promise of the operating system is
that it can be a good guy (for the user), even if real examples tend to fail
at that job.

~~~
Dewie
> The apps, written by various persons, are running on a computer that belongs
> to the user. The operating system keeps control of the computer -- the
> user's computer -- in the user's hands, and keeps it from being "taken over"
> by the apps.

I wonder if this can be mitigated - at least in some cases - with more
disciplined and limited tools/apps.

To my knowledge, there are few programming languages that have purposefully
restricted their expressiveness in order to increase how much can be proved
about them. Given that "all" of them are as expressive as a programming
language can be in the physical world (at least according to researchers'
current knowledge), there are no non-trivial properties that can be proven
about them, in the general case. In that sense, it inspires a wild-west
approach - the OS can not know anything with certainty about an arbitrary app
it has not run yet. So its only option - for an arbitrary program - is to try
to run it and try to shield itself from whatever mischief it might do at
runtime. Given this inherent and general uncertainty, creating heuristics for
programming language/machine code analysis might not be high up on the
priority list (if at all).

But if expressiveness is limited, there are more properties that can be
_definitely_ decided before running the program. Maybe it is possible to prove
that a program will never try to access memory outside of whatever is assigned
to it? This might be too difficult (in practice) to prove for a low-level
language. But there certainly are languages that won't let you access memory
outside of its process - java, for example, will throw an exception when the
index is out of bounds. For example, languages like java could provide a proof
to the OS that it will never try to access memory that it does not own? Then
maybe the OS could eliminate whatever checks for illegal access of memory,
since it has a proof that that kind of thing will not happen.

~~~
louthy
.NET has code access security, which is even finer grained than just memory
access restrictions:

[http://msdn.microsoft.com/en-
us/library/33tceax8(v=vs.110).a...](http://msdn.microsoft.com/en-
us/library/33tceax8\(v=vs.110\).aspx)

[http://msdn.microsoft.com/en-
GB/library/930b76w0(v=vs.90).as...](http://msdn.microsoft.com/en-
GB/library/930b76w0\(v=vs.90\).aspx)

------
axanoeychron
This makes me think of TempleOS.

TempleOS [1] 'shell' operates as a programming environment - what you write is
compiled and inserted into the same process that the OS is running as. It's a
single address space.

[1]
[http://www.templeos.org/Wb/Accts/TS/Wb2/TempleOS.html](http://www.templeos.org/Wb/Accts/TS/Wb2/TempleOS.html)

~~~
jacquesm
Most repl based environments that allow compilation do something like this.

------
waterlesscloud
Funny the quote is from a 1981 issue of Byte. My first thought on reading the
headline was "You mean like BASIC on the old 8-bit computers?"

~~~
david927
This is the quote you're referring to: _An operating system is a collection of
things that don 't fit into a language. There shouldn't be one._

I couldn't agree more. It's our languages that are wrong, not this statement.

~~~
taeric
I don't follow. Either that, or I don't agree. Not sure which.

I'm perfectly happy having multiple languages that are suited to different
needs. Sure, I've been lured before by "one language to rule them all" style
attempts at breaking this idea. I have been burned more than I've been helped
by these forays. And I say this as a strong fan of lisp. A language basically
designed to internalize other languages. For lunch.

(Of course, I think these are not really incompatible. When writing lisp, I've
found that you are so constrained in the syntax of lisp, that eventually it
almost disappears and you start seeing the language of what it is you are
doing, instead.)

That said, I think the problem comes down to orthogonal changes. Simply put,
when you have a language that is specifically used for one thing, effort can
be placed into making sure it does that very well, at the expense of other
things it could be used to do. Contrast with the languages that are designed
to do anything, where you quickly find that in order to really get what you
want, you have to write in very different idioms for different goals.
Essentially finding that the same language is not.

Would be akin to using a band saw to make an intricately carved figurine.
Sure, it is doable, but probably more effort than it is worth for a person.
"Right" tools for the right job and all of that.

~~~
kd0amg
_Would be akin to using a band saw to make an intricately carved figurine.
Sure, it is doable, but probably more effort than it is worth for a person.
"Right" tools for the right job and all of that._

After that, I can't resist linking this:

[http://www.dailymotion.com/video/xoe7yc_whitetail-365-seriou...](http://www.dailymotion.com/video/xoe7yc_whitetail-365-serious-
bandsaw-skills_sport)

It probably helps the analogy that even though I saw every movement he made, I
had no clue what he was making until I saw the actual product.

~~~
taeric
Thanks for posting! I was thinking of that video, but couldn't find it when I
wrote my post.

------
ChuckMcM
I disagree strongly with this, and I disagreed in 1981 as well :-) I feel that
if the programming language is your operating system then you're doing it
wrong because programming languages are fundamentally verbs to express
computation, not to express resource management. Of course it won't surprise
anyone that I'm also a big fan of interface contracts and being explicit about
the invariants the use/require. Early in its life (and much to the chagrin of
the Smalltalk community[1]) Java was a "single system image" language,
basically Java all the way down. And that concept worked well on
embedded/appliance applications but was a poor fit for multi-function/purpose
platforms.

[1] I was looking at real estate in 1998 and the old ParcPlace systems
buildings were up for lease, in one of the offices was a whiteboard labelled
'Adele's whiteboard' and on it in dried white board ink was 'Java subsumes
Smalltalk' and under it was written in another hand 'and the world weeps.' I
expect Smalltalk to outlive Java though.

~~~
tonyg
> if the programming language is your operating system then you're doing it
> wrong because programming languages are fundamentally verbs to express
> computation, not to express resource management.

But then how do you express mechanisms and policies for resource management?
Would it be in some kind of... language?

------
leephillips
The first high-level (meaning higher level than assembly) language, Fortran,
took total control of the computer when the "Fortran programming system" was
loaded to run a Fortran program. There was no operating system. This was in
the early 1950s.

~~~
Everlag
Its incredible to think that Fortran is alive and actually improving! Browsing
the wikipedia article(I've not yet dived in too deeply) you find features like
easy concurrency that one would expect in Go being added to a language whose
closeness to C-like syntax enters uncanny valley.

------
philippeback
Check out Pharo 3, just released.

[http://pharo.org](http://pharo.org)

That's not '81 Smalltalk, it is the 2014 version!

------
gaius
_Operating System: An operating system is a collection of things that don 't
fit into a language. There shouldn't be one._

Not true. An OS is the things that are common to all languages or
applications.

~~~
shasta
That can't be the right definition. Not all applications need to use files,
for example.

~~~
AceJohnny2
Well, the application certainly _starts_ from a file...

~~~
vertex-four
Not true; it's perfectly reasonable to think of an OS which executes programs
downloaded from a remote system which never touch a file.

~~~
gaius
Everything is a file in Unix as you know perfectly well!

~~~
notduncansmith
I've heard Plan9 described this way, with the Unix counterpart being
"everything is a stream" (not exactly true either).

~~~
marcosdumay
"Everything is a file" is the Unix moto. But it does not do justice to that
phrase. Unix has several things that aren't files (sockets are the most
annoying), and a few files that are so special that they could as well have
another name (like pid files).

Plan9 is an evolution of Unix that turn more things into files. Sockets, for
example, are.

~~~
gizmo686
Sockets are files.

~~~
marcosdumay
Unix sockets are files. But I can't create a connection to Google at the
filesystem.

------
reirob
read the title and thought: "We had this already... It was called Smalltalk"

