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.)"

Lisp

[Anonymous Coward]

Seems to me that this is old hat. Lisp has been an OS since the 60's. We just don't feel the need (often) to call it that.

Oberon anybody?

[sofist]

Just remember the past. Oberon was an OS an a PL at the same time and I think most of the readers didn't ever heard about it...

Behind the times?

[Mordant]

I guess Mr. Flat (what a name!) hasn't ever heard of the LISP Machine. [uni-hamburg.de].

Re:Oberon anybody?

[CoolVibe]

Oberon? Smalltalk! Now there's something you could turn into an OS.

Although, Oberon is not the past. It's still being actively developed, in both it's OS and PL incarnation.

Re:Lisp

[Anonymous Coward]

I use Lisp frequently. It is not an OS. It is an interpreter. There is a huge difference. If still not convinced, take a look at the source for GCL and the Linux kernel.

Re:what I want

[Xiarcel]

Have you seen The Tunes Project? [tunes.org]. It sound like what you claim to want, even if it's still a work in progress...

Re:Lisp

[Anonymous Coward]

Don't spread misinformation. Lisp is often interpreted, but in production use it is always compiled. GCL, for instance, is most assuredly a compiler.

The point is not that the code to a Lisp compiler is anything like the code to an operating system; rather, it is that each advanced programming language provides its own set of high-level abstractions for what are traditionally OS-level services.

Re:JavaOS

[trailerparkcassanova]

Ajile Systems JEMCore and there are others.

Rational R1000 - Ada 83 as an OS

[rwsorden]

Back in the mid-90's, I worked for Computer Sciences Corp. (CSC) [csc.com] on a project that used the very-cool Rational R1000 [cmu.edu] platform for development and source-code control. In summary, the R1000 was a custom Ada-oriented development platform (even the hardware was custom-made, I believe). The operating system was fully implemented in Ada and featured a "command prompt" that required you to write snippets of Ada code (expressed as anonymous blocks) instead of shell commands. All errors were thrown as Ada exceptions. The "command prompt" editor even featured code completion and had a built-in debugger. It was even possible to auto-generate custom DOD-STD-2167A design documents (SDDs, IDDs, etc.) by embedding specialized comments in your Ada code (ala Javadoc) and using the built-in document generation modules. It was definitely cool for its time!

Re:Going Forth?

[Alex Belits]

What is the standard C library except an API specification to an OS?

Standard C library is not a standard library of C language for Unix, it's a standard library of the Unix system that is used with C language (and every other language on Unix). Of course, for applications portability purpose it was ported to other systems, however it's still not really a part of the language design -- say, variable arguments list is a part of C design, but [v[s[n]]]printf strictly speaking isn't.

Re:A Microprocessor *IS* a language Interpreter

[Detritus]

What is the real instruction set? The processor's user-visible instruction set may be implemented in random logic, FPGAs, microcode, traps to machine code or some combination of the above. There can be more than one level of microcode. Some processors have a writable-control-store, allowing the manufacturer and/or user to change/enlarge the processor's microcode and instruction set. Western Digital used to make a multi-chip CPU that could be a DEC LSI-11 or an UCSD Pascal p-Machine by changing the control ROMs. On an IBM mainframe, an operating system call may be implemented in machine code, microcode or hardware, depending on which model you have.

Re:Use Emacs

[Jason Earl]

Assuming you are on a Linux box with Emacs (and info) properly installed you might be able to simply type 'info viper'. The info file included with viper is pretty darn good.

Or you can just start up Emacs and type M-x viper-mode. viper-mode has a start-up message that is pretty handy, it should get you started without too much trouble. If you set the viper-expert-level variable low enough Emacs will act just like vi.

If you are really interested in using Emacs, however, I would suggest learning to use Emacs' built in info browser. There is a ton of functionality built into Emacs that is not immediately apparent. I have been using Emacs for years now, and I still find amazing new functionality on a regular basis. Time spent reading the documentation will pay for itself quickly.

Re:I'd like to point out...

[voodoo1man]

Huh?

By Lisp (no, it's not spelled all uppercase anymore) bytecode, do you mean Lisp Machine microcode? Because aside from that (and it wasn't even a standard), there is no such thing as "the Lisp bytecode." If that's what you mean, then the processor microcode won't do you any good as it's not any different from writing assembler.

If, like you state in your second paragraph, you just want a VM sitting on top of the OS executing all the code, go buy some .Net or something. Then come back in a couple of years once everyone's realized the "thing" is incredibly slow*, and doesn't really do anything security-wise.

Also, it's "funny" you mention that programming languages and OSes shouldn't be mixed, and then talk about Lisp. Have you actually used a Lisp environment in the past 20 years? The philosophy that the language is the OS (at least from the application's and the editor's point of view) is the pervasive paradigm for Lisp coding - and not only does it work, but it is also incredibly useful and efficient.

* There is no such thing as the perfect (or even best) universal VM - the fact that different hardware architectures as well as different languages exist now and evolve at a rapid pace prevent it from existing.