Lambda the Ultimate

All the same, it's basically the same problems and tasks you'd have to complete if working on an OS on purpose. It's just a matter of what *has* to be implemented and what gets priority. In a language, it's not usually the ability for other languages hosted on the environment to get first-class status wrt to accessing the OS API. In an OS, it often is. Call me nuts, but I'd much rather run an OS with the power of systems like Common Lisp or Smalltalk than be confined to the silly little world of C.

While less so with Unix than with Smalltalk, &c, you are still "encouraged" to use C rather than another language. Inter op is always somewhat of an issue...

ICFP 99 Flatt, Findler, Krishnamurthi and Felleisen
Programming Languages as Operating Systems (or, Revenge of the Son of the Lisp Machine)
DVI (sans screen dump)   PDF   PS

From a system perspective, however, the line is fairly crisp. Every language runtime I can think of uses the services of an OS, because modern systems are built from well-defined layers of abstraction. Both a runtime and an OS implement the same kinds of service abstractions (e.g., open a file), but their implementations have different, and complementary, responsibilities. The OS abstraction is responsible for making sure that nobody above the OS layer needs to understand disk geometry, filesystem layout and semantics, and hardware drivers in order to establish a new "file" on disk. The language runtime is responsible for making sure that application programmers get an appropriate high-level semantics for creating and using that file.

It's all about division of labor and reduction of complexity. Sure, we could get rid of the OS and run the language runtime directly on the hardware, but are we really sure that we want to put the burden of low-level system semantics on language designers and compiler writers? Michael Vanier writes about "massive reinvention of the wheel" and I completely agree when he alludes to this being a bad thing.

Programming languages, IMHO, only look like operating systems when you view them from the application programmer's point of view. Looked at "from below" they're really quite different beasts, designed to provide different kinds of abstractions, and to complement, not compete with each other.

I would argue the opposite: language run times may grow to support OS-like features (see Flatt et al), but looked from above they play a completely different role by providing different kinds of abstractions and notations.

Or are we saying the same thing?!

Obviously, APIs are at the border between OS-like and PL level abstractions.

I definitely agree that language runtimes tend to grow to support OS-like features, and certainly I think there's a strong relationship between the richness of the application-level API provided by the runtime and how often direct OS services are required by the programmer.

Case in point: in C, I tend to make OS system calls all the time. In Java, I rarely ever think about needing to touch the system directly. Because the runtime is rich, I trust that I can use the standard libraries and the the JVM and standard libraries use OS services on my behalf.

I guess I tend to view the relationship of the OS and the language runtime as a necessary partnership of complementary functions. I wouldn't want an OS which mandated language semantics or data types for me....while on the other hand I don't think that language runtimes ought to concern themselves with figuring out the best way to implement threading on a given hardware architecture....

Does that make sense?

I think the "plugin" model for GC is a good idea, and it sort of fits with the layering concept I mentioned earlier.

My previous arguments aside, however, I do find myself paying less and less attention to the underlying OS. In the "old days" when I was writing TCP/UDP server code (RealAudio), I spent a lot of time understanding how the OS really "did" network I/O. I find nowadays with Java that I pay zero attention to this kind of low-level detail. Java is my environment, and the API docs are the spec for how it works.

What I've gained is the ability to work in a very standard fashion across operating systems, but what I've lost is the ability to efficiently use the server platform -- there's "waste" in the system since the code isn't really tailored for any specific operating environment anymore.

Lisp Machine operating systems have performed fine grained memory GC for almost 30 years. Now the JVM and the CLR are evolving toward this kind of OS.

Other examples of "almost an operating system": web servers, application servers (e.g. Tuxedo, EJB, Com+), even web *browsers* are almost an operating system. (i.e. why did MSFT want so much to kill Netscape? It was evolving toward an operating system above the various native host systems.)