PL for interactive simulation

Seasonal greetings to everybody, I am back from my vacation, and have a new urge to program and probably learn some new language in the process :-)

I am looking for a PL for programming an interactive simulation - not really a game, but a simple world with moving agents which can be influenced by the user (ask your children about hatching norns to get an idea :-) ).

The PL should probably actively support concurrency, pickling/unpickling, have good libraries for graphics/mouse/sound, and be reasonably fashionable.

I am currently hesitating between Erlang and Alice, any ideas?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


The PL should probably actively support concurrency, pickling/unpickling, have good libraries for graphics/mouse/sound...

Ahh... it's obvious: Tcl/Tk! Oh, wait...

... and be reasonably fashionable.


Massive concurrency?

I am affraid (most?) Tcl implementations use native (OS) threads and thus cannot provide the same scale of concurrency as Erlang (10E5 processes on a cheap hardware). Also, Erlang is (or tries to be?) referentially transparent, while Tcl uses (or used to use last time I checked) shared state.

I still have to investigate the level of Erlang libraries, but its core capabilities seem to dominate those of Tcl (for my particular purpose).


Well, it was mostly a joke. Tcl has native threads as you point out. However, I'm not sure how used they are. Most applications just use the event loop, and the default builds of Tcl (except on Mac OS X) are non-threaded. I haven't played much with Erlang. 10E5 processes sounds impressive, but is massive concurrency a goal in and of itself? On a single processor, does it really buy you much over an event loop? As for shared-state, I'm not sure what you mean: Tcl's threading model is strictly one thread per interpreter, with communication via message-passing (evaluating a script in a different thread/interp either directly or asynchronously via the event loop). I think there are facilities for shared variables, but I haven't actually used Tcl's threads much.

Your other requirements were pickling, and libraries for graphics/sound etc. If pickling is another name for serialisation, then this is generally a non-issue in Tcl, with all values having a string representation. Mutable objects as provided in many extensions, or built on top of the namespace mechanism need special treatment, but it's generally pretty simple. There are numerous Tcl extensions to provide access to sound and graphics capabilities, but you may need to track them down first, depending on how exotic you want.

Tcl as a language is unlikely to win much praise on LtU, as it's not particularly elegant from a theoretical point of view. However, it has a lot of well-engineered libraries. Somewhere.

Naturality, not performance

On a single processor, does it really buy you much over an event loop?
Having zillions of processes definitely does not buy much performance, but for some applications it is a very natural model of the domain.

Tcl's threading model is strictly one thread per interpreter, with communication via message-passing
What about multiple assignments to the same variable by the same thread? Or is Erlang more like SML than like Haskell in this regard... I have to check...

Regarding graphics - I just found this site: - look for "Powered by Erlang". I am definitely leaning towards this language.

Alice who?

I am currently hesitating between Erlang and Alice, any ideas?

Are you thinking of Alice the SML derivative, or Alice the 3D authoring system which is implemented so cutely in Squeak Alice? The latter seems like it might be a good fit for what you're asking for. It also addresses the fashionability aspect, with the ability to create worlds that can be viewed in a web browser, using the Alice plugin.

Also, depending on the ages and/or gullibility of the children in question, you might be able to convince them that Squeak Alice's drumming bunny is a norn of some kind, and thus avoid having to model your own characters...

The squeaky one

...though the MLish one is tempting me as well, I always wanted to play with all those transients...

Squeak environment won my heart immediately after downloading, but for some reason I cannot persuade myself to learn a Smalltalk derivative (I must have some typing complex). Are types incompatible with fun?...

Calvin & Hobbes vs. static typing

Are types incompatible with fun?...

Well, statically-typed programs are less fun, sure! This is clearly explained by the world's most acknowledged computer scientist in this article.

To continue the theme, you cannot play Calvinball in a statically typed language. OTOH, many programs in dynamically typed languages end up resembling a game of Calvinball without their authors even trying...

Concurrency, Libraries, Dynamic Types, Interactive, Fashionable

Sure sounds like Oz to me.

Erlang has an SDL binding.

Available here. However, it's a one-man project with little documentation. Or you could use the included gs library.

Oz on the other hand, seem to be limited to good old tk -- but its Qtk seems interesting.

Hatching Norns

Speaking of hatching Norns, Steve Grand, original Creatures author, has involved in a new world simulation project:

"The general idea is to create a large-scale, internet-based, 3D virtual world into which schoolchildren can place creatures that they've constructed themselves."


This looks exactly like what I have in mind.
I wonder, if my employer will approve my secondment to Nesta :-)

Creatures is an image based programming language

I'm not sure how much you know about the Creatures games but it's actually quite a sophisticated little engine. It is basically a VM for a programming language called CAOS (Creatures agent object script). It runs many thousands of concurrent 'agents'. Each plant, animal, toy and creature in the world is one of those agents.

The agents themselves are event driven, can respond to things like 'push', 'pull', etc. It has environmental simulations built in (air pressure, temperature, wind, etc), all written in CAOS.

The Norns themselves are described in a 'genetic' description language and fully editable with a neural net for the brain.

You can drop into a REPL from the game itself with a keystroke (which I can't recall off the top of my head) and program directly in CAOS, adding new objects, etc. You can even get an HTML help file for the CAOS language from the REPL.

Some of the details on the genetic system and programatic interface I've described at

It would technically be possible to re-write an entire new game using the Creatures 3 engine that you get from the Creatures released game.

Is it a game or is it a programming system?

CAOS is a DSL, Creatures are RT+app

I'm not sure how much you know about the Creatures games
I happened to visit your site before I posted the question on LtU :) And the reason for that was I get my hands on an old CD of Creatures 2.

Is it a game or is it a programming system?
I would say that CAOS is a DSL, Crearures game is a complete runtime for that DSL bundled with a specific application written in this DSL (which can be customized by end user).

Not to diminish the value of Creatures and CAOS, I do not see real necessity for a DSL here. I believe much more hackers would be attracted if instead of being a DSL, CAOS would be just a library for some popular language (Scheme, Python, Lua, ..., Erlang, Alice :-) ). Am I missing some aspect of CAOS that required a new language? Except that at the time of the first game version (1996) open source movement was still young? IFAIK, Python was GPLed since 1991.

I would love to see more comments on the design decisions of Creatures, the game was indeed ground-breaking!

History of CAOS

Hello! I worked on Creatures 3 and Docking Station, so know a bit about the history of CAOS. The reasons you give for it using a new language are correct. In Creatures 1, it was just a very simple state machine. The four-character commands were longwords which were quickly looked up. The game ran on a 486.

Yes, Python and Perl existed, but open source wasn't very mainstream, none of the games makers would have known about it or been comfortable with it. And they would have been considered very large at the time to embed with a game.

Creatures 2 and Creatures 3 evolved from Creatures codebase, and kept the same language, despite substantial changes, including having a proper virtual machine.

In more recent projects by the makers of Creatures, such as Bamzooki, we used Lua. These days Lua is extremely popular amongst games makers, I've heard of many places which are using it.

Nice Toy!

In more recent projects by the makers of Creatures, such as Bamzooki

The editor feels great! Bamzooki reminded me of one project of mine (let's call it X). The differences are:

  1. X's body parts had less "hot spots" for connecting them (at most 3, IIRC), had fixed sizes, and in general tended to feel more RISCy - the reason for that revealed later
  2. X's hot spots were rigid = 0DOF (as opposed to 3DOF of Bamzooki), but some parts had internal DOFs ("joints")
  3. X had active body parts - "muscles", "receptors", "emmitters", and "neurons", forming parallel, neural and chemical graphs in addition to mechanical one
  4. X had no editor; instead, previously described phenotype evolved from genotype by means of kind of Interaction Net. To ensure any mutated genotype is correct, I employed some dirty tricks - now I would think of a simple type system. RISCy nature helped to ensure random mutations lead to not too ugly bodies.
  5. Plans were to make the critters to compete for survival, but I get so interested in cellular biology and molecular chemistry, and the simulation system was so painfully slow and buggy, that I let it die. Given the current abundance of OpenSource constraint solvers and improved CPU and 3D hardware, it might be worth to revive the X....

And, of course, JoCaml

I am currently hesitating between Erlang and Alice

For some reason I forgot about JoCaml. Is it alive, by the way?


Based on Lua. It doesn't really have the simulation constructs you are looking for, but it's interesting nonetheless.



Smalltalk/Squeak based, with a focus on collaboration in a 3D environment.