Philosophical musings: interpreting models

[Jim Little]

shapj@us.ibm.com wrote:
> 
> This conversation is a bit silly.  There are both low-level and high-level
> problems in operating systems.  There are times when a single body of code must
> address both.  One wants neither a low-level nor a high-level language, but
> rather a language that meets the requirements.  Relative to *current* languages
> this means a language that has low-level primitives but is highly extensible.
> LISP is one candidate.  OCAML is a much better one (type safety), and lately has
> been running very efficiently.

I completely agree that user-defined abstraction is critical when
creating complex systems.  As you say, operating systems (or any other
complex software system) consist of both high and low-level elements, so
your programming system must allow you to work at both a high and low
level.  I.e., give you low-level primitives and allow you to create
high-level abstractions.

Lisp is the poster child of lambda abstraction, but there's other kinds
of abstraction.  In particular, I'm creating a programming system,
Prism, which focuses on "domain" abstraction.  Domain abstraction
abstracts a system by providing entirely new ways to describe it.  This
is contrasted with "system" abstraction (of which lambda abstraction is
a subset), which abstracts a system by allowing a single component to
stand in for multiple components.

We've been using domain abstraction for a long time now in the form of
computer languages.  But to my knowledge, we've never had USER-DEFINED
domain abstraction.  Prism is my attempt to enable user-defined domain
abstraction.  My goals for Prism are to allow small new languages to be
easily created, and for such languages to seamlessly interoperate.

So, you see, I completely agree with you about the necessity of a
programming system supporting both high and low-level components.  I'm
just looking at a different way of doing so.  My "Philosophical musings"
posts are rough-hewn, off-the-cuff explorations of that direction.


> Straightjackets are necessary for people who don't think well.  Operating
> systems are complex and require careful thought.  People who require
> straightjackets therefore do not build operating systems well, regardless of the
> presence or absence of straightjackets.

I completely disagree.  As you say, operating systems (or almost any
software system) are complex... so we need all the help we can get! 
Language features can reduce that complexity.  Would you consider
automatic garbage collection a straight-jacket?  In some cases, it is,
but when you don't need absolute control over memory allocation, it's a
huge boon, resulting in decreased complexity, faster development, and
fewer bugs.

There's a limit to the amount of complexity we can productively deal
with, and everybody makes mistakes.  The more we can do to reduce the
complexity of software systems, and the more we can do to automatically
catch errors, the better.  In my opinion, "straight-jackets" --
highly-abstracted languages with strict semantics checking -- are
exactly the way to accomplish this.*

Jim Little
jiml@inconnect.com


*Provided they interoperate, and in conjuction with lower-level
languages when simplicity must be traded for control.