Slashdot Mirror
Programming Languages Will Become OSes
Anonymous Coward writes "A couple of months ago, at the Lightweight Languages Workshop 2002, Matthew Flat made a premise in his talk: Operating systems and programming languages are the same thing (at least 'mathematically speaking'). I find this interesting and has a lot of truth in it. Both OS and PL are platforms on which other programs run. Both are virtualizing machines. Both make it easier for people to write applications (by providing API, abstractions, frameworks, etc.)"
Emacs is Emacs Lisp.
Emacs is an Operating System.
Emacs Lisp is an Operating System.
QED
my TRS-80 had BASIC as the OS
FORTH was and still is such a combination. It's compact, easy to implement and incredibly fast and felxible.
Stick Men
Like java... I think a likely evolution will be towards a single VM that runs all your programs instead of the one VM per app generally used now. More and more of the process switching and memory management will be built into the VM's probably to the point one day where java VM's become operating systems in their own right and only need the underlying OS for drivers to talk to the hardware.
If any programming language/framework has a chance it will become an OS it is .NET.
And Java is half an OS already, it has its own threading moodel, has memory management etc. Though frankly I believe this paradigm of PLs becoming OSes will be first be seen on handhelds etc. Note that many Cellphones run Java etc. (though now sybian is more commoon).
.ACMD setaloiv siht gnidaeR
...the partitioning of computer environments into applications, OS, "drivers," "libraries," etc. etc. is arbitrary, cultural, traditional, etc. To some extent it's also based on modularity considerations, and to some extent on marketing/commercial considerations. There's no fundamental logic to "the way things are."
A few decades ago, MANY environments blurred the distinction between OS and language: FORTH, MUMPS, SMALLTALK, and, indeed, most early versions of BASIC, to name four.
The traditional textbook discussion of an OS ("provides four interfaces, to the filesystem, to devices, to applications, and to users") is just a discussion of what IBM evolved in the sixties or thereabouts.
Incidentally, the very name "operating system" indicates the original rationale and function of these pieces of software. They were intended to automate the functions that previously required the manual services of an "operator," thus increasing utilization and decreasing payroll.
Another example of the arbitrariness of the term "OS" is the way in which various applications programs are now considered to somehow be part of the OS. In Digital's glory days, these were sometimes referred to as "CUSPS"--Commonly Used System Programs. Is grep "part" of UNIX? Is Windows Explorer (not Internet Explorer, but Windows Explorer--the application that displays directory contents and that "start" button at the bottom of your screen--Windows' graphical "shell") part of Windows?
At one point Apple said Hypercard was "systems software." Perhaps iTunes is "part of" OS X?
"How to Do Nothing," kids activities, back in print!
Yes, and interestingly, the article isn't even really saying that OSes and programming languages are the same thing. What it is saying is that any programming language worth it's salt has the potential to become an OS and that it will probable eventually do so for security reasons. Then he tacks on "There will perhaps be new PL's designed with isolation as one of their main goals--or current PL's might be improved/redesigned--so hopefully this requirement of having a 'multiuser PL' will be fulfilled in the future." as his last line.
The bulk of his argument is sound and has convincing precedent in the examples you give(Micro, Spectrum, etc.) and I could add a few of my own, not to mention the modern example of Java. As for his ad hoc specualtion at the end that programming languages will eventually replace OSes. I'm prepared to call that bullshit until he presents some evidence. I don't see it happening, who wants to code on a machine that can only use one language?
Of course, the response is that new language will be written to run inside the OS-Language and that coders can work in either these sub-languages or the OS-level meta-language. But really how would this be any different than the current situation with many languages vs. assembler as meta-language only with an additional obfuscating level of go-between.
my two cents.
lysergically yours
You are closer to the truth that you suspect.
The original IBM PC's would start up with ROM BASIC if no other OS was present.
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
Argh, this paper starts with an interesting idea, that PLs are more like OSes then we realize it, provides some genesis for the idea, but FAILS to back it up..
All of his examples, the bulk of the paper, are examples of how the RUNTIME system restricts the PL. He talks about the runtime system security model and somehow this is supposed to extend to the definition of the programming language? No, this is not how it works. The runtime system, the sandbox or whatever you call it, is a restriction defined seperatly from the language itself. The JVM is defined seperatly from the Java language. That's why products like JET exist that can compile Java code to something other then bytecode. Because the runtime enviroment is not defined in the language. You don't have to have a security manager, like in perl, you don't have to support a trusted mode in your perl runtime. It's a feature of the runtime, not the language.
The runtime, by definition is like a mini-OS. Usually, a vm runtime (for perl, java, python, etc...) takes non-native instructions, parses them and translates them into some sort of binary instruction. Since there is no processor that can execute perl natively, this is how it works.
Neat idea, bad paper.
Systems architecture (and to a certain extent application architecture) revolves around creating "environments" where other applications operate, (note emphasis). Architectures provide services to these applications, which in turn may provide different services to yet more applications (components, web-based solutions, etc.). Thus you can argue that by sitting down and designing and implementing a specific or generic purpose architecture, you're creating a "mini-OS". That much is true. But the OS is simply a lower-level architecture than, say, Java or COM or .NET. It's a more complicated and extensive one, but one nonetheless. The stuff you do with a programming language (or as they like to be called these days - platforms) is essentially a higher-level abstraction than the real OS happens to be.
So we can argue then that we're moving towards the platform concept where things are interconnected via well-defined interfaces and entry points (that's your APIs) where the OS itself is just another component.
Take a look at SavaJe. It is a JVM that is also an OS.
The truly wise path to go is to define an OS/bytecode combination, so that (in a very LISP-like way) security is accomplished by "thought-controlling" programs rather than action-controlling (the MS/Linux model).
What I want to know is this: Is the LISP bytecode the best, or should a more modern one be used? JavaVM?
What about development platforms like .NET? These unifeid environments aim to resolve many programming languages, and resources in a unified bundle. This has been a long standing goal for many development environments. We've seen all kinds of Java and C++ wrappers emerge that allow integration into various other languages, platforms, and environments. That said, I think there is a alot to be said about how similar OSs and PLs really are.
Pick systems were a database, an OS, and a programming language, all in one. It was a very cool system to work in.
Modern programming languages can perform some of the safety features that operating systems provide. Many functional languages "can't go wrong". (meaning the compiler can prove a program does not access memory outside of its own space). Some languags like value Microsoft's Vault programming language can make sure an API is used properly. Check out Kernel Mode Linux for an example of how a "safe" scheme program can be speed up by executing in kernel space.
It's actually pretty easy to migrate your email to another client because Emacs will happily create mbox files. Fire up info on GNUS and read the bit about "Incorporating Old Mail" and simply do it in reverse.
The short but sweet synopsis is that you enter the group that you want to export, type 'M P b' to process mark all article, and then type 'B r' to respool those articles. When it asks for the backend to use choose 'nnmbox'.
Don't forget to make backups of your email first (I have had problems with really large groups).
As a side note have you tried some of the Vi-emulation modes in Emacs. Vim is pretty good stuff, but it doesn't do everything that Emacs does. Vi-style keystrokes on top of Emacs is the best of both worlds (IMHO).
"A single machine could have multiple languages co-existing for different tasks."
Just as quite a few computers 'round here have multiple OS's installed.
On this machine, I currently have 2 different installs of Linux, and one of Win2000. They are used for different things; one of the Linux instances is for my desktop machine - customisation, and my 'feel' is important. Another is for testing/playing with, while the windows install is for any apps I need which still aren't around on linux (practually none that I use these days actually).
I'd suggest that this kind of arrangement is analogous to having differnt languages for different purposes, and is quite common amongst computer hobbyists.
I'd also hope that performance, stablity/security and compatibility are important criteria when selecting programming languages as well as OS's!
- Chris
There are excellent reasons to go this route though. While I'm definitely no Microsoft lover, I do think .net is pretty cool. Even if figuring out what they mean by that is more than a tad confusing.
Of course in practice the distinction between language and OS has always been somewhat blurry. Take Unix. At what point to you separate Perl, gcc, and the shell from the OS? In a way, in the older versions of Unix it was even more pronounced. Using LaTex involved many shell scripts and custom programs and even writing in it was in effect programming.
Even early versions of LISP were their own OS and one could argue that UCSD Pascal was as well. (Especially the version for the old Apple II)
So this is hardly a new thing. The only time I think we can truly make an OS - language distinction is when people start trying to make languages portable and make it used for development. The move to do everything in C for all platforms in the late 80's is a great example of this. This lead to many companies using C instead of Pascal for development and also pushed ANSI C and then the C++ standards. Class libraries tended to be quite separate from the language. However lets be honest. All of this was more of a short blip in the history of languages rather than the typical situation.
Even going back to "prehistoric" times, when people wrote Fortran code with punch cards could they tell what was the program and what was the OS easily?
Inferno's not an OS/Language hybrid but it is a virtualised unix like OS that will run with identical interfaces, including GUI, on differing hardware & software combinations. It will run natively on some hardware [such as my IPAQ] and hosted elsewhere - such as Windows & Linux.
It was a project started before Java and shares many of it's aims but went that one step futher by retaining the concept of an OS where you can read and write files etc.
Dennis Ritchie talks about Inferno and other things
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
The article is an act of mental masturbation, and typically for such acts it takes one property of the unfortunate subject of such "research" and builds a whole theory based on it, regardless of its relevance and applicability.
Languages are supposed to be designed to allow a programmer to express the implementation of his design. The OS design is supposed to give the program implemented by a programmer means to perform various actions that the programs may need. Between those two things there are libraries that include implementations of various procedures that programs perform.
This clearly separates what is the environment common for all programs and carries no application programmer's ideas at all, what is designed specifically to be used by a programmer for his specific purpose, and what lies in between, and may be close to the specifics of application (say, SDL) or to be an interface to the OS (libc).
In this way VMs are OS-like components that run over the OS, and the fact that many VMs are tied to their languages does not mean that this is a good design. In my opinion the fact that there are ties between OS and language beyond straightforward "OS is written in a language" and "language operates within an OS" are what I call "noosphere pollution". It's true that many people when they develop a new OS or language want to make "The Grestest Program Ever" and spill their ideas into areas where they do not belong. This is at best misguided attempt to coerce others into their model of thinking, at worst an attempt to create a system so closed and convoluted inside that no one ever will be able to affect it, leaving the initial developer the only "true expert" in the area. And unless that developer has influence of Microsoft or at least Sun, usually the response is "Screw you, and your giant blob of code!" because it's not possible that developers will happen to agree with every single idea developed by a single person, or a small group of them, even if most of those ideas are sane (do you hear me, Pike?).
Good (or semi-good) operating systems are designed with a very clear separation between themselves and languages that are used. Nothing required Unix to be separate from C, yet if one looks at the system calls interface and libc he will see nothing that can tie the two together like siamese twins -- there is no builtin type in C that corresponds to any Unix internal structure -- no directories, files, sockets, inodes, etc, all those things are represented by language-neutral and OS-neutral integers, and only libc makes actual OS-specific primitives visible for the programmer. This is why Unix is used with many languages, and C is used with many OS, or without any OS at all.
This demonstrates the strength of the C and Unix designs, authors were confident enough that their ideas can stand on their own so they didn't add any hidden (and not-so-hidden) strings to trap the user in a messy OS-language symbiotic monster.
Later people started making giant libraries that LOOK like OS libraries but are tied to some environment that has nothing to do with OS, and tied to a language that they can't be separated from. This was a step back -- it wouldn't if those libraries were more modular, but one glance at monstrosity like MFC gives an idea how much Microsoft wanted "to rule them all". But no, that wasn't enough -- languages with ridiculously large and complex VMs, totally inaccessible from anything but themselves appeared, imitating the behavior of interpreted languages. Java, now C#, I am sure there will be more of this. But there is a difference -- perl has to have a complex interface inside because it is an interpreter and can't just call OS. Java chosen to have an interface deliberately different from anything else, and to build VM and libraries that implement the ideas of its creators and nothing else. And of course, control freak Microsoft didn't make anyone wait before it made its own version -- with some lip service about "multiple languages" that looks like "multiple languages as long as they have Microsoft object model rammed into the middle of them, or it will be a pure hell to use".
So IMO the "siamese twins" designs are inferior to clearly defined and well-designed interfaces, and are the realm of hacks and control freaks -- with some exceptions for interpreters and things like Forth that are specifically designed not to scale beyond systems where any full-blown OS is too much (Forth developers may take it as an insult, but I believe that it's a good thing that such a closed system stops scaling where its applicability ends).
Contrary to the popular belief, there indeed is no God.
So does this mean we are returning to the days where my Radio Shack TRS80 booted into basic? Maybe we can find a great way to store data on audio tapes next.
"Information wants to be expensive" - Stewart Brand, the same guy who said "Information wants to be free"
The VM for Perl called Parrot so far supports: Perl 6, Quick Basic, GW Basic, Python, Ruby, Java. :Perl 6 was the target language;
Python, Ruby were considered important add ons
Java allows the Parrot VM to be the main VM
The Basics were ported as a test of porting a language that Parrot was not designed to support (i.e. a test of how good a generic VM it is)
Mod parent up.
Seems too many people forget that "rooms, walls and controlled openings" are a good idea. The bigger the building the more important they become. Sure you can have one huge room and put everything in it, but you'll end up partitioning it anyway. And even then either you resort to separate rooms or accept that the furnishings and decorations will be inconsistent within a room.
Me: One man's impedance mismatch is another man's layer of abstraction.
It's more likely that someone will add yet another type of "room" than for things to merge together.
I am not convinced by the original article, but I do believe that we will move towards running multiple machines, operating systems or whatever they may be, at the same time.
:)
For example, one of my machines boots up with win2k. I can play games, my wife can run outlook etc. Then I have one or sometimes two vmware sessions running Linux. There I can do my programming, play around, and connect to work and run X against their servers. And my wife doesn't have to log out from her windows while I'm doing it. I can also access the linux subsystem from a Windows X terminal, and the filesystem as well, which in practice gives me an embedded linux kernel within my windows.
There are a lot of fun and practical things you can do with a setup like this, especially if you are a geek.