8/18/2015 Languages Are Operating Systems

Languages Are Operating Systems

Some languages were specifically designed to be operating systems (see LanguageIsAnOs). Whether or not that's
the case, all [general-purpose] languages should be evaluated on that basis. A language that makes up a bad
operating system is simply a bad language.

Can we say "...all *general purpose* languages should be evaluated on that basis" here
instead? -- StevenShaw --Done

An operating system is a collection of things that don't fit into a language. There shouldn't be one. --
DanIngalls

That's only true until one has made the PerfectSystem, where the Application and the OperatingSystem are
One.

(from http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html)

The greatest open secret in computer science.

The converse, that operating systems are languages is widely known. Where does an OS designer get inspiration
from if not from various languages? This is especially true in the case of functional languages. (Damn those bastards,
always twenty years ahead of the rest of us.)

But how could a language designer get inspiration from an OS? After all, OSes are written in languages! However,
they have many features which languages don't attempt to provide. Chief among them is security (don't anyone dare
to bring up Java! GRRR).

So if languages are operating systems, then what kind of operating system is SmalltalkLanguage? Well, Smalltalk
has absolutely no security, protection or access control. Smalltalk is DOS. See SmalltalkSecurity.

And what kind of OS are C/C++ and the other non-interactive languages? The useless clunky batch processing
ones!

Non-interactive?

Non-incremental. Non-interpreted.

While a suitably-capable language might be all the machine abstraction you need, keeping the two concerns
separate strikes me as a fundamentally better idea. Modularity and all that. And the marketplace seems to agree (for

http://c2.com/cgi/wiki?LanguagesAreOperatingSystems 1/4
8/18/2015 Languages Are Operating Systems

now at least).

OSes need the ability to support multiple languages. On my PC running LinuxOperatingSystem at home (replace
with Windows if you prefer) I can run software in any language I like--C/C++, Lisp, Java, Smalltalk, Perl, Python,
Fortran, Ruby, whatever. All languages of importance have been ported to either platform. What's more, I can mix
and match applications written in these different languages as I like--and even have applications with portions
written in different languages (AlternateHardAndSoftLayers). Any language that functions as an OS would have to
allow free commingling with other languages.

The situation which has long existed with C/C++, where the language and standard libraries fail to abstract a
reasonable subset of the capabilities of a modern operating system (no networking; no concurrency, multithreading,
or synchronization; only rudimentary and simple I/O; no sound, graphics, or multimedia support; minimal user-
interface support (no windowing system; no support for input devices other than a "terminal); no inter-process
communication; etc.) is deplorable. However, replacing the current state of affairs with a
PinkyAndTheBrainLanguage is doomed to fail--indeed, the rotting corpses of several such beasts line the highways
of computer science.

I agree that languages and operating systems could be unified. They both serve the purpose of abstracting the
underlying machine, and a providing a sane(r) programming model. And maybe in the future, once the body of
knowledge in both domains as become static, they will be. But for now--I see little end user (or developer) benefit
for running Java or Lisp or Smalltalk as my operating system. The beneficiaries of such a notion mostly seem to be
the advocates of the language in question.

--ScottJohnson

Being able to run programs in other languages in your language/OS is one of the desiderata described above
(ExoKernel and all that).

I can do that today. ExoKernels might be a cool way to design an OS. But I detect a whiff of
SuperlativeSmell? about the technology.

As for the "choice of the marketplace", the only disproof I need is to point to Unix and Windows.

What's wrong with Unix and Windows? While they may both suck :), they're both better than a hypothetical
OS that doesn't exist, or a prototype OS that fulfills 10% of its requirements. Producing a list of
ThingsAnOperatingSystemShouldDo?, and then showing how current OS's don't measure up--is an
interesting exercise. However, until a production-ready OS which does do those things is available, it's not
an argument for abandoning what we currently have.

I'd love to have an OS better than what we have today.

Second hand Lisp machines aren't that hard to find.

QuestForThePerfectLanguage = QuestForThePerfectOs??

I think the idea of Languages Are Operating Systems misses the point of operating systems.

Operating systems provide capabilities uses by languages and language libraries. Operating systems provide such
details as drivers and file systems, multitasking and task scheduling, program loaders, and user interfaces. Try

http://c2.com/cgi/wiki?LanguagesAreOperatingSystems 2/4
8/18/2015 Languages Are Operating Systems

porting a program from MS-Windows to XWindows and see how many OS differences there are despite a
common language.

A language provides a filter through which parts of the Operating System can be called, but it does not supersede
the Operating System.

Drivers are a kludge. Hardware should directly tell applications how to use them. File systems aren't so great,
either...they're an assumption left over from C and Unix that most accept as mandatory, but are really just a lousy
half-attempt at (part of) a database. Multitasking can be done without a separate OS, as can task scheduling.
Program loaders and user interfaces? Look at Java. It doesn't need an OS outside the language to do those things.
(Typically it will run on top of another OS, but not necessarily.) Neither does Forth (and it as often as not runs on
the bare hardware). So you see, the idea of LanguagesAre? OperatingSystems isn't actually missing any points. It's
just that so many of us have lived within certain constraints for so long - the "necessity" of operating systems
(separate and distinct from the languages that run on/within them) - that we've come to assume that the cage we've
lived in for so long is the whole world, and it's not. I'm not saying that we should immediately get rid of all OSes as
we know them, but we should definitely should toss out the notion that they are something that we cannot live
without.

LanguagesAreOperatingSystems is an illusion. Inside a language, you have library calls that call the operating system
services. From the programmer perspective, these library calls look like the operating system API, but they aren't.
The illusion is even stronger when the langage has features like interactivity and self-compilation. But if you consider
programming langages themselves, without their libraries, the illusion vanishes, because a langage is just a way to a
compiler, not to a computer.

I can see where you're coming from with your objection, but I can't fully agree. It would, perhaps, be more
correct to say that LanguageRuntimesAreOperatingSystems?; however, your argument seems to hinge upon
the fact that implementations for a language to run upon another OS require support from the OS. It'd be
more accurate to say that they require support from the machine, and that the existence of the OS requires
communicating through it to get to the machine - an implementation-detail for the library calls, not a
requirement. A library could just as easily be designed to operate upon bare metal, just like native code
from the compiler is often built to run upon bare metal. Whole virtual machines support such things as
JavaLanguage, MozartLanguage?, and SmalltalkLanguage, and it isn't too difficult to take these virtual
machines and merge them into bare-metal along with their library-provided services. A virtual machine is
certainly an OS.

Where it grows weak is for some languages, like C/C++, that don't have very good models for multi-process
activity or resource management (except memory) as part of the language. Those are the sorts of thing that
make some languages more or less like operating systems than others.

Some languages and their runtimes were designed to be the OS. OberonOperatingSystem, ForthLanguage and
ColorForth spring to mind. Other language runtimes have been adapted to run on the bare metal and provide OS
services, such as HaskellLanguage's House (http://programatica.cs.pdx.edu/House/).

This idea first popped into my mind when I was using Ruby a few years ago, and was coming to terms with how
Gems worked. I was specifically warned in a certain book (I can't remember the name off the top of my head) that I
should not use a package management system to install Ruby--and that, indeed, this is even a particular bone of
contention with Debian system maintainers--because package managers weren't very good at keeping up with the
http://c2.com/cgi/wiki?LanguagesAreOperatingSystems 3/4
8/18/2015 Languages Are Operating Systems

latest Ruby installments, and they weren't very good at handling multiple versions of Ruby (often necessary to
maintain legacy code). Thus, you have a computer language with its own packaging system! I later learned how to
use PythonLanguage's Pip, and CommonLisp's QuickLisp; the general trend nowadays is for languages to come
with their own packaging systems of one form or another...

And as I thought about it more, I realized that computer languages are abstractions over the operating system to do
what the operating system is supposed to do: capture input, save or display output, and so forth. It's not that much
of a stretch to imagine writing all those abstractions in the language of your choice, rather than use the OS
abstractions...and if you do this, you have a language that can run on bare metal! Hence, it literally becomes an
operating system. (Admittedly, it's a bit more of a stretch to actually write this abstraction...but that's more an issue
of practicality, over possibility.) I also realized that the Operating Systems we use now are mostly C functions (some
of which may be written in Assembler, fully or in part) that handle the bare metal stuff; when you consider that the
way to extend CeeLanguage is to write functions, it is safe to conclude that our Operating Systems are literally just
extensions to C--in other words, CeeLanguage (or perhaps a more recent variant, such as ObjectiveCee or
CeePlusPlus) is the Operating System of choice these days. --Alpheus

CategoryOperatingSystem CategoryProgrammingLanguage LordOfTheOses

View edit of February 16, 2014 or FindPage with title or text search

http://c2.com/cgi/wiki?LanguagesAreOperatingSystems 4/4