Lambda the Ultimate

inactiveTopic Programming languages will become OSs
started 1/17/2003; 3:44:59 PM - last post 1/19/2003; 7:59:44 PM
Michael Vanier - Programming languages will become OSs  blueArrow
1/17/2003; 3:44:59 PM (reads: 1795, responses: 12)
Programming languages will become OSs
An interesting thread on Slashdot. What do LtU readers think? Personally, I think that the problem with this idea is that OSs represent precisely those aspects of the programming environment which are easily made to be independent of a particular programming language. The idea of "programming language as OS" either implies that there will only be one uber-programming language (which to me is clearly a Bad Thing), or that there will be massive reinvention of the wheel as different languages re-implement the same functionality. OTOH if it were easy for different languages to interoperate (as supposedly is the case in .NET) then the problem goes away; however, then you've just redefined "operating system" to be the APIs for the system.
Posted to general by Michael Vanier on 1/17/03; 3:47:44 PM

rev - Re: Programming languages will become OSs  blueArrow
1/18/2003; 1:01:28 AM (reads: 1083, responses: 1)
Sure, PLs may "become" OSes in the future for those without the wisdom to look to the past. Plenty of programming environments have blurred the line between programming language and operating system. Smalltalk, Forth, Oberon and the Lisp Machine are pretty huge examples. And yes, there can be big problems with interop between the language/OS and anything else, but the problems can be solved. After all, Unix was written in C, but with a little work, other languages have access to the OS API. Likewise, with the Lisp Machine, you could run C and Fortran apps. With Squeak Smalltalk, for example, one can run stuff compiled from many language by using the C FFI or a Plugin. While not the same, it would be relatively straight forward to have the ability for the Squeak system itself to run apps written in another language. Or, you could just have these compilers compile to Squeak bytecode.

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

Ehud Lamm - Re: Programming languages will become OSs  blueArrow
1/18/2003; 3:44:15 AM (reads: 1099, responses: 0)
re PL vs. OS, see:

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

Mark Madsen - Re: Programming languages will become OSs  blueArrow
1/18/2003; 10:38:44 AM (reads: 1034, responses: 2)
Frankly, I think the "blurriness" of the line between an OS and a language runtime depends on what you're examining. From the application API point of view, the line can be quite blurry. For example, opening a file is done by making an API call, and it's nearly impossible to tell from the application's standpoint what mix of runtime and OS services are involved in executing this task. Nor should the application programmer need to care.

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.

Ehud Lamm - Re: Programming languages will become OSs  blueArrow
1/18/2003; 11:04:48 AM (reads: 1060, responses: 0)
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.

Mark Madsen - Re: Programming languages will become OSs  blueArrow
1/18/2003; 11:14:18 AM (reads: 1021, responses: 1)
If we're not saying exactly the same thing, it's pretty close!

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?

Michael Vanier - Re: Programming languages will become OSs  blueArrow
1/18/2003; 3:59:47 PM (reads: 975, responses: 0)
One interesting example of a blurry area is garbage collection. Since so many languages use GC, I've wondered for a long time why GC wasn't an OS service. I posted to the LL1 mailing list, and it turns out that this is an old dream that many people have had, but the reality is that in order to get the best performance a GC has to be tailored to a language. IOW the optimal GC for (say) java might have very different characteristics than one for (say) lisp or haskell. So this is *not* part of the OS, but rather is part of the language runtime. I still think that you can imagine a generic GC that has various hooks in it so that different runtimes can re-use most of the same code, but since you'd still be instantiating different GCs for each language, it's still a feature of the runtime and not the OS.

Mark Madsen - Re: Programming languages will become OSs  blueArrow
1/18/2003; 4:33:27 PM (reads: 976, responses: 0)
GC is a great example of something that needs to be part of the runtime, agreed. On the other side of the fence, I tend to regard threading as something that should be part of the OS layer and simply exposed to the runtime, since threading is best done with intimate knowledge of the OS internals and the hardware (i.e., memory management and page tables, etc).

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.

Patrick Logan - Re: Programming languages will become OSs  blueArrow
1/18/2003; 8:44:55 PM (reads: 948, responses: 0)
Operating systems have done "GC" for ages: recovering process resources when a process dies.

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

Ehud Lamm - Re: Programming languages will become OSs  blueArrow
1/19/2003; 2:50:39 AM (reads: 947, responses: 0)
Yes, I think our points of view are quite close, if not identical.

Michael Vanier - Re: Programming languages will become OSs  blueArrow
1/19/2003; 2:23:59 PM (reads: 862, responses: 1)
The interesting issue wrt GC is whether one GC is truly appropriate for multiple languages. The Lisp machine was designed to run lisp, so it doesn't address this issue. The CLR is much more interesting in this context; it was designed first and foremost to run Microsoft languages (C#, managed C++, VB). However, Microsoft also consulted designers of functional languages (scheme, ML, Haskell). I wonder how a GC which is optimal for C# will work for ML, which typically does a lot more small object allocations (e.g. closures for partial function applications).

water - Re: Programming languages will become OSs  blueArrow
1/19/2003; 7:59:44 PM (reads: 872, responses: 0)
Actually, the Lisp machine was designed to run several different languages, and had hooks for providing many different garbage-collection mechanisms, including region-based allocation and de-allocation which was essentially a set of variations on manual allocation. And those hooks were used quite a bit in practice, since in the 1980's, a lot of the newer collection routines were still being developed, which meant that the older routines were often forgone for manually-managed regions. Of course this is always a good idea, but even then it was attractive.