TITLE: Programming Language as Operating System
AUTHOR: Eugene Wallingford
DATE: March 27, 2013 12:46 PM
DESC: 
-----
BODY:
We are deep in the semester now, using Racket in our programming
languages course.  I was thinking recently about how little of
Racket's goodness we use in this course.  We use it primarily as
a souped-up R5RS Scheme and handy IDE.  Tomorrow we'll see some
of Racket's tools for creating new syntax, which will explore one
of the rich niches of the system my students haven't seen yet.

I'm thinking about ways to introduce a deeper understanding of
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2012-09.html#e2012-09-29T16_04_35.htm">
   The Racket Way</A>,
in which domain concepts are programming language constructs and
programming languages are extensible and composable.  But it goes
deeper.  Racket isn't just a language, or a set of languages.  It
is an integrated family of tools to support language creation and
use.  To provide all these services, Racket acts like an operating
system -- and gives you full programmatic access to the system.

(You can watch the video of Flatt's StrangeLoop talk "The Racket
Way"
<A HREF="http://www.infoq.com/presentations/Racket">
   at InfoQ</A>
-- and you should.)

The idea is bigger than Racket, of course.  Dan Ingalls expressed
this idea in his 1981 <EM>Byte</EM> article,
<A HREF="http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html">
   Design Principles Behind Smalltalk</A>:

<BLOCKQUOTE><EM>
<B>Operating System</B>: An operating system is a collection of
things that don't fit into a language.  There shouldn't be one.
</EM></BLOCKQUOTE>

Alan Kay talks often about this philosophy.  The divide between
programming language and operating system makes some things
more difficult for programmers, and complicates the languages
and tools we use.  It also creates a divide in the minds of
programmers and imposes unnecessary limitations on what
programmers think is possible.  One of things that appealed to
me in Flatt's StrangeLoop talk is that presented a vision of
programming without those limits.

There are implications of this philosophy, and costs.  Smalltalk
isn't just a language, with compilers and tools that you use at
your Unix prompt.  It's an image, and a virtual machine, and an
environment.  You don't use Smalltalk; you live inside it.

After you live in Smalltalk for a while, it feels strange to
step outside and use other languages.  More important, when you
live outside Smalltalk and use traditional languages and tools,
Smalltalk feels uncomfortable at best and foreboding at worst.
You don't learn Smalltalk; you assimilate.  -- At least that's
what it feels like to many programmers.

But the upside of the "programming language as operating system"
mindset you find in Smalltalk and Racket can be huge.

This philosophy generalizes beyond programming languages.  emacs
is a text editor that subsumes most everything else you do, if
you let it.  (Before I discovered Smalltalk in grad school, I
lived inside emacs for a couple of years.)

You can even take this down to the level of the programs we
write.  In a blog entry on
<A HREF="http://wingolog.org/archives/2010/02/14/sidelong-glimpses">
   delimited continuations</A>,
Andy Wingo talks about the control this construct gives the
programmer over how their programs work, saying:

<BLOCKQUOTE><EM>
It's as if you were implementing a shell in your program, as
if your program were an operating system for other programs.
</EM></BLOCKQUOTE>

When I keep seeing the same idea pop up in different places,
with a form that fits the niche, I'm inclined to think I am
seeing one of the Big Ideas of computer science.
-----