BA mtg, Language support (

Brian Behlendorf (
Wed, 13 Jul 1994 16:51:39 -0700 (PDT)

Thomas, this was when mail to you was bouncing... should be fine now.
I'd love to meet sometime early next week and can make the results of
this meeting available via our web pages, too.

Date: Mon, 11 Jul 1994 10:33:18 -0700
From: (Thomas Churchill)
Subject: BA mtg, Language support

Hey Gang:

I've noticed that quite a few of the participants of this list are
from the SF Bay Area.

I'm wondering if maybe we can all get together sometime and exchange
ideas? I think we could probably move things forward a little faster
that way. For those outside the Bay Area, like Florida, and who are
too lazy to drive ;-), I'd be glad to tape & digitize the proceedings
and make the .au files available on our anonymous FTP server... For
the curious, I'm imagining something pretty informal.

The VRML discussion so far has focused around a scene description
language - and the initial proposals we've seen put forth reflect that.
Inventor, Labyrinth, Manchester Scene Description Language, etc. All,
that is, except one: MEME. Meme differs significantly in that, where
scene description languages are static "snapshots" of reality, MEME
supports the definition of dynamic scenes, via an integral programming
language. The importance of this cannot be underestimated. It makes
possible clocks with hands that move, ceiling fans that rotate, cars
that drive, etc., all without network communication.

HTML documents ARE, generally, static. VRML documents SHOULD BE,
generally, dynamic. I believe part of the initial specification should
require some kind of scripting ability. I'm not so sure, however, that
the MEME language is it, however. To my mind, the language should
fulfill these criteria:

1) Interpreted.
Basically required. Many objects, with definitions from many hosts,
will be executing simultaneously on the client machine.

2) Standard, if possible.
It's always easier to get people to use something they are familiar
with than invent a new language. Besides, we could leverage the
work of others and not have to re-invent the wheel.

3) Easily implementable and/or Fairly portable
Small is beautiful. [ Like UNIX (used to be) ]

4) Object Oriented
Not necessary, but Would be nice.

Languages I might like for this (LISP, Forth), I know others probably
wouldn't. Languages I think others might like (TCL) cause me some concern
over performance. As we speak, however, TCL is available for most major
platforms, is interpreted, and most people either know it or can learn
it within a few hours. While the MEME language fulfills points 1 and
(possibly) 3, I think it may be just a little too different for most
people, and I am not convinced that it's domain specific features are
so powerful that they justify a new language. (Though I can see why
the designers did)


1 3 5 Thomas Churchill (KC5GAU) Voice: 408.433.1516
|_|_| Software Technology Center Fax: 408.433.1448
| | | NEC Systems Laboratory
2 4 R Western Division - San Jose, CA Email: