>Though some of the folks associated with this project in the past may not know me, I have been a small part of it since it was first imagined. Marc deGroot and I had a long history.
>The idea for VR and Metatopia was originally devised in a Berkeley attic by Marc and me. Since Marc’s untimely death, the project has lied dormant. After I found out about Marcs death, and the existence of Metatopia I decided that it was high time I took an interest in what was originally my brain child. Yes, my brainchild. I did authorize Marc to pursue the concept with my complete blessing. Now, Grandpa is back in charge. It is in loving memory of a man I knew since I was barely a teenager, a man who first launched my career in computing, a man who was a friend, that I rededicate this project to Marc deGroot.
>Marc’s family has created a web site dedicated to his memory, and seeks to help those suffering with Bipolar and Manic Depressive disorders. I am no stranger to this debilitating disorder and urge you to donate to this fund.
And here is his patent on Meme, which has 45 citations, including Philip Rosedal's Distributed Simulation patent (who made Second Life and High Fidelity):
>Multi-user virtual reality system for simulating a three-dimensional environment
>Abstract: A computer-implemented multi-user virtual reality system that erects a networked virtual world for real time interaction amongst multiple participants. A computer-simulation of an animated world is network-distributed amongst participants, e.g., as a virtual world. The simulation accommodates multiple users whose computers are connected by a communications network. The users' computers need not be the same type of machine. Users can interact with one another and with the objects in the virtual world. The properties of objects in the virtual world, such as form, color, and behavior, are displayed on monitors and can be modified in real time while the simulation is running. Modifications to objects are stored and therefore persist, and can therefore bridge across computer system shutdowns and restarts.
Interesting criticism from David Cake and Gavin Bell. Fortunately now we benefit from nice IDEs and other tools for editing popular programming languages (but none I know of for FORTH or PostScript, but there are lots of applications that edit or write out JavaScript and JSON and WebAssembly, even built into every browser ;).
Before JavaScript was released on December 4, 1995, there actually was some disagreement about not just about which language to use, but whether a browser should include a Turing-complete programming language at all. Sun was pushing TCL as a contender, then RMS issued his fatwa against it, and Sun switched over to pushing Java (not because of RMS though ;).
From: "Gavin Bell" <%20(fwd)"gavin@krypton.engr.sgi.com>
Date: Fri, 24 Jun 1994 09:41:24 -0700
To: %20(fwd)"www-vrml@wired.com
Subject: Re: Meme
>Marc de Groot wrote:
>>Meme has certain features that I would want to see in any specification for
>>VRML. In particular, Meme allows the world designer to specify platform-
>>independent executable code for the object's behavior. Without this
>>ability, objects have relatively rigid, uninteresting behavior.
David Cake replied:
> Basically VRML browsers need to be basically include much of the function
> of a simple interpretive language, and hopefully both a basically object
> oriented one (personal preference, I guess), and one that is not too
> verbose (for efficient use of low bandwidth). In this it would function
> like most existing cross platform packages of various kinds (many database
> packages, for example).
[Gavin Bell replied:]
One of the things I really like about HTML is that it is reasonably
easy to write an editor that allows you to read in and then modify any
HTML file.
One of the things I really hate about PostScript is that is is really
hard to write an editor that can edit an arbitrary PostScript file.
Meme strikes me as more PostScript-like than HTML-like; it looks like
it would be easy to write applications that wrote out Meme files, but
it looks very difficult to write applications that provide a
user-friendly interface for editing Meme files.
Why you should not use Tcl. Richard Stallman, GNU Project.
As interest builds in extensible application programs and tools, and
some programmers are tempted to use Tcl, we should not forget the
lessons learned from the first widely used extensible text
editor--Emacs.
The principal lesson of Emacs is that a language for extensions should
not be a mere "extension language". It should be a real programming
language, designed for writing and maintaining substantial programs.
Because people will want to do that!
Extensions are often large, complex programs in their own right, and
the people who write them deserve the same facilities that other
programmers rely on.
The first Emacs used a string-processing language, TECO, which was
inadequate. We made it serve, but it kept getting in our way. It
made maintenance harder, and it made extensions harder to write.
Later Emacs implementations have used more powerful languages because
implementors learned from the problems of the first one.
Another lesson from Emacs is that the way to make sure an extension
facility is really flexible is to use it to write a large portion of
the ordinary released system. If you try to do that with Tcl, you
will encounter its limitations.
Tcl was not designed to be a serious programming language. It was
designed to be a "scripting language", on the assumption that a
"scripting language" need not try to be a real programming language.
So Tcl doesn't have the capabilities of one. It lacks arrays; it
lacks structures from which you can make linked lists. It fakes
having numbers, which works, but has to be slow. Tcl is ok for
writing small programs, but when you push it beyond that, it becomes
insufficient.
Tcl has a peculiar syntax that appeals to hackers because of its
simplicity. But Tcl syntax seems strange to most users. If Tcl does
become the "standard scripting language", users will curse it for
years--the way people curse Fortran, MSDOS, Unix shell syntax, and
other de facto standards they feel stuck with.
For these reasons, the GNU project is not going to use Tcl in GNU
software. Instead we want to provide two languages, similar in
semantics but with different syntaxes. One will be Lisp-like, and one
will have a more traditional algebraic syntax. Both will provide
useful data types such as structures and arrays. The former will
provide a simple syntax that hackers like; the latter will offer
non-hackers a syntax that they are more comfortable with.
Some people plan to use Tcl because they want to use Tk. Thankfully,
it is possible to use Tk without Tcl. A Scheme interpreter called STk
is already available. Please, if you want to use Tk, use it with STk,
not with Tcl. One place to get STk is from
ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
Around the time leading up to the TCL war, Lua was peacefully and quietly born in a manger at the Pontifical Catholic University of Rio de Janeiro, Brazil:
"In 1993, the only real contender was Tcl, which had been explicitly designed to be embedded into applications. However, Tcl had unfamiliar syntax, did not offer good support for data description, and ran only on Unix platforms. We did not consider LISP or Scheme because of their unfriendly syntax. Python was still in its infancy. In the free, do-it-yourself atmosphere that then reigned in Tecgraf, it was quite natural that we should try to develop our own scripting language ... Because many potential users of the language were not professional programmers, the language should avoid cryptic syntax and semantics. The implementation of the new language should be highly portable, because Tecgraf's clients had a very diverse collection of computer platforms. Finally, since we expected that other Tecgraf products would also need to embed a scripting language, the new language should follow the example of SOL and be provided as a library with a C API."
I don’t mean to taint Lua in any way, but I find it interesting that it was basically designed as FORTRAN script to manage simulations for oil and gas. In this regard, it shows even more great design in targeting your audience. I would have loved finding Lua in 1993! I don’t think I heard of it until 1998/9.
I want to say new ideas diffuse faster now, but they also face more competition so maybe the reach is ultimately the same? Now that I am less of a temporal bigot, I aggressively mine the past for great ideas that didn’t survive.
When considering how much of the web currently depends on non-free JavaScript, perhaps in hindsight it would have been better in terms of freedom to have gone with a less capable language?
>My Scheme library was initially called "Gel" until we discovered trademark issues. Then we renamed the project Guile at the suggestion of one of my co-workers because "guile" and "scheme" are close concepts and because "guile" sounds a bit like "Guy L.").
Also it was Sun, not RMS, who actually started the "TCL Wars" -- RMS was just responding to them:
>Mr. Ousterhout was hired by Sun (later he would spin off a Tcl-centric start-up). The R&D; team there developed a vision:
>Java would be the heavy-lifting extension language for browsers. The earliest notions of the "browser as platform" and "browser as Microsoft-killer" date back to this time. Tcl, Sun announced, was to become the "ubiquitous scripting language of the Internet". Yes, they really pimped that vision for a while. And it was "the buzz" in the Valley. It was that pronouncement from the then-intimidating Sun that led to the Tcl wars.
>Around the same time that Guile (then GEL) was readying itself for public release, another extension language was gaining in popularity, Tcl. Many developers found advantages in Tcl because of its shell-like syntax and its well-developed graphical widgets library, Tk. Also, at the time there was a large marketing push promoting Tcl as a "universal extension language".
>Richard Stallman, as the primary author of GNU Emacs, had a particular vision of what extension languages should be, and Tcl did not seem to him to be as capable as Emacs Lisp. He posted a criticism to the comp.lang.tcl newsgroup, sparking one of the internet's legendary flamewars. As part of these discussions, retrospectively dubbed the "Tcl Wars", he announced the Free Software Foundation's intent to promote Guile as the extension language for the GNU project.
>It is a common misconception that Guile was created as a reaction to Tcl. While it is true that the public announcement of Guile happened at the same time as the "Tcl wars", Guile was created out of a condition that existed outside the polemic. Indeed, the need for a powerful language to bridge the gap between extension of existing applications and a more fully dynamic programming environment is still with us today.
Scheme was inspired by Drew McDermott and Sussman's 1972 Conniver. Sussman and Hewitt also worked on Muddle (MDL), the implementation language of Zork!
>In 1971 Sussman, Drew McDermott, and Eugene Charniak had developed a system called Micro-Planner which was a partial and somewhat unsatisfactory implementation of Carl Hewitt's ambitious Planner project. Sussman and Hewitt worked together along with others on Muddle, later renamed MDL, an extended Lisp which formed a component of Hewitt's project. Drew McDermott, and Sussman in 1972 developed the Lisp-based language Conniver, which revised the use of automatic backtracking in Planner which they thought was unproductive. Hewitt was dubious that the "hairy control structure" in Conniver was a solution to the problems with Planner. Pat Hayes remarked: "Their [Sussman and McDermott] solution, to give the user access to the implementation primitives of Planner, is however, something of a retrograde step (what are Conniver's semantics?)"
Simplicity through accident:
>25 years later, in 1998, Sussman and Steele reflected that the minimalism of Scheme was not a conscious design goal, but rather the unintended outcome of the design process. "We were actually trying to build something complicated and discovered, serendipitously, that we had accidentally designed something that met all our goals but was much simpler than we had intended... we realized that the lambda calculus—a small, simple formalism—could serve as the core of a powerful and expressive programming language."
And for reference: This was more than a year before JavaScript was released on December 4, 1995. And a few months before RMS started The Great TCL War on September 23, 1994. The title of Official Scripting Language of the Web was still up for grabs.
From: marc@kg6kf.ampr.org (Marc de Groot - KG6KF)
Subject: Meme
To: www-vrml@wired.com
Date: Wed, 22 Jun 94 11:26:25 PDT
Hello. It's about time I introduced myself. I'm Marc de Groot, the founder
of Immersive Systems, Inc. in San Francisco.
I started ISI to sell Meme, which is a virtual world development
system. Meme is intended to create a single shared virtual universe on
the net.
ISI released the alpha version of Meme last month.
Meme stands for Multitasking Extensible Messaging Environment. Meme started
life as a programming language. Some "OS-level services" were added to the
system, and finally the messaging mechanism was added to allow virtual objects
to communicate. At this point, Meme is evolving into a communications
protocol.
I heartily agree with the statements that have been made on this mailing
list about net software: make something proprietary, and the net hackers will
write a free replacement which everyone will use.
I intended to make the protocol public later this year, after ISI had fulfilled
higher priority obligations, however the establishment of this list has
prompted me to put some preliminary information on the net at this time.
I have put up a WWW page for Immersive Systems. The URL is
http://remarque.berkeley.edu/~marc/home.html
>From the home page, you can read an overview of Meme, look at the programming
manual, and download a demo world to try on your own PC.
Meme has certain features that I would want to see in any specification for
VRML. In particular, Meme allows the world designer to specify platform-
independent executable code for the object's behavior. Without this
ability, objects have relatively rigid, uninteresting behavior.
That platform-independent code needs to load over the net with a minimum
of overhead, and needs to execute efficiently. Meme satisfies both of
these requirements.
That completes my thoughts for now. I will post in the future, as time
permits.
Marc de Groot
Immersive Systems, Inc.
immersive@kg6kf.ampr.org
[I'll quote some of the page here for people with sensitive eyes]
>Meme tm: Real VR for the Net!
>"A brilliant idea..." -Andries van Dam
>Meme tm was designed from the ground up for multi-user networked virtual worlds.
>Meme tm is a platform-independent standard for networked virtual reality.
>High performance. Self-contained. FAST real-time 3D. Easily customized for use with head-mounted displays, data gloves, and other VR peripherals.
>Meme tm is designed so it can run on memory-limited machines such as settop boxes and game consoles. Meme tm can also take full advantage of the most advanced graphics hardware.
>"This is what VRML 3.0 hopes to be." -Tony Parisi, VRML co-inventor
>Meme tm enables the construction of virtual worlds on the Internet.
>Fully interactive. Inhabitable by many users. Quickly constructed. Complex lifelike behavior. Easy to deploy.
>"Marc de Groot is a brilliant programmer." -Mark Pesce, VRML co-inventor
>Highly efficient virtual machine used by NASA and the aerospace industry.
Will run on any system that has a 3D rendering engine.
Portable to platforms with primitive or non-existent operating systems.
Really works identically on all platforms.
Runs in less than 500 kilobytes of memory.
Upwards of a million context switches per second on current-generation processors.
>"How the hell did you do that?" -unknown attendee, Web Interactive '96
[Click through for more praise for Meme, colorful images, and awesome 1994 web site design!]
>Meme TM--The Multitasking Extensible Messaging Environment
Meme TM is a software package for the development of virtual world applications.
>Worlds built with Meme TM can be inhabited by multiple users who are connected to a computer network. Meme TM virtual worlds distinguish themselves by providing rich object behavior, unlike menu-driven systems that offer a fixed set of choices.
>Meme TM is designed to be interoperable, that is, Meme TM worlds and objects will behave identically on any computer running Meme TM, irrespective of differences in the underlying hardware.
>Meme TM was conceived to enable the construction of a shared virtual universe for everyone on the Internet.
>what kind of software package is Meme TM?
>Meme TM does not easily fit into a well-known category. It incorporates elements of an operating system, an interactive development environment, and a programming language.
>Meme TM is an operating system [...]
>Meme TM is an interactive development environment [...]
>Meme TM is a programming language [...]
Meme Development System for Windows Product Specification:
[It's totally programmable in FORTH! What more is there to say? ;) So here's some code! ]
>Writing Meme TM code
>Writing code for use in a multi-user universe is an undertaking that requires some sophistication. Often, the programmer wants to try out an idea quickly, without concern for the demands of multi-user distributed programming.
>For instance, let's assume the programmer would like to spin a ball, all alone, in the virtual world. Meme TM makes it easy to animate such a scene. The following text is the actual code that implements a spinning ball, and is very similar to the spinning ball demonstration on the demo page. The backslash character (\) is used to delimit a comment to end-of-line.
>The comments assume that each line is being typed by hand at Meme TM's command prompt, with pauses between the lines to observe the effect on the displayed scene.
\ First we create an eyepoint with which we view the scene.
\ The eyepoint is initially positioned at the origin, looking down the
\ negative Z axis (away from the user).
Eye: eyepoint
\ Let's put the eyepoint at +20 on the Z axis. This moves the camera
\ away from the origin, towards the user.
10e0 eyepoint z!
\ We put a ball in the scene. It is created at the origin.
" sphere.rwx" Shape: ball
\ Up until now, the display has remained blank. To draw a single frame
\ on the display, we execute the meme "render".
render
\ There is now a ball on the display. Rather than type "render" each time
\ we want to draw a frame, let's start a background task that redisplays the
\ scene continuously.
background r \ Define a new task called "r".
begin \ Start of a looping structure
render \ Draw one frame
pause \ Switch to the next task
again \ Loop forever
; \ End definition
r wake \ Start execution of the rendering task.
\ Let's define another background task to make the ball spin.
background spin \ Define a new task called "spin".
begin \ Start of a looping structure
1e0 ball yaw+! \ Increment the yaw angle by one degree
pause \ Switch to the next task
again \ Loop forever
; \ End definition
spin wake \ Start execution of the spinning task
https://www.sfgate.com/news/article/DE-GROOT-Marc-2732584.ph...