Languages Are Operating Systems

This page presents a powerful ideal. As with any model, it is not the only reasonable view; if you are a implementing experimental operating system ideas that must work with a variety of languages, then this point of view doesn't happen to apply. But if you're evaluating or designing languages, then the below may well apply.

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 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 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 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