When GNOME first started out, there was much talk of using Guile as an
embedded language. The concept was similar to the architecture of
Emacs, Firefox, or all the
games using Lua (such as World of Warcraft).
I would define an “embedded” language as one that doesn’t come
with a platform. It’s small and easy to glue together with an app
written in C or C++. It uses the same platform as the app. If the
platform has an introspection capability like XPCOM or
GObject-Introspection, then the platform can be exported to the
embedded language in an automated way.
At some point, and I was one of the people to blame for this, we
changed the focus of the Linux language discussion to grand unified
schemes involving component technologies and virtual machines. The
result is that too much desktop stuff is still written in C.
A “C/C++ core plus embeddable language” architecture for an
application has many pragmatic advantages.
Higher layers of code such as UI code are so much easier in a
dynamic “scripting” language.
Proven to be practical and scalable for huge apps such as Firefox and
- No platform silos. In a GNOME app, the embeddable language uses
GIO, GTK+, GStreamer, Clutter, or whatever you are using — it does not
have its own http stack and everything else.
You can choose to write each part of the app in the easiest language;
some stuff is easier in C/C++.
Sandboxable / well-modularized. The interpreter is generally an object
that can be destroyed; no heavy language runtime or VM takes over the
Embeddable languages don’t seem to create a huge jump in memory
footprint, for whatever reason, so they are still sensible for
“swarm of many processes” environments like GNOME and KDE that
multiply any per-process overhead by a significant factor.
(There are advantages to the heavier full-platform languages also, but
I’m guessing everyone knows them already so I won’t make a list.)
realize at first that SpiderMonkey has no dependencies; it is not tied
up with the rest of the Mozilla platform (XPCOM, etc.), it’s completely
There are some problems right now, for example there’s no standard
packaging and .pc file for jsapi.h/libmozjs.so, so it’s hard to make
an app build on multiple distributions unless you suck in an internal
copy of the library.
truly usable; most notably, some kind of module system. I’m not sure
SpiderMonkey itself should have that though — it starts to
define a platform and make the language “not embedded”. Maybe modules
are introduced by higher layers (in fact xulrunner adds
module system if you use the whole xulrunner platform).
I don’t mean this as a SpiderMonkey advocacy post, though we’re using
engine, Guile, Lua, Tcl, etc.
My main point: the “C/C++ core plus embedded scripting” architecture
is a very smart way to write an app, and doesn’t have some of the real
downsides of heavier platforms.
(This post was originally found at http://log.ometer.com/2008–08.html#25)