Sixteen Years Later: GNU Still Needs An Extension Language

Fresh from the 2011 GNU Hackers Meeting, Andy Wingo has written a long piece on the status of Guile Scheme, the woefully underutilized official user extension language of GNU. Wingo argues that Guile is the best choice for extension in GNU given the ability of Scheme to adapt to change over time. Presented with using e.g. Javascript instead of Scheme for its popularity: 'We should also consider the costs of using hastily designed languages. JavaScript has some crazy bad stuff, like with, var hoisting, a poor numeric model, dynamic this scoping, lack of modularity regarding binding lookup ... Finally, we have the lifespan issue. If GNU had chosen Tcl because it was popular, we would have a mass of dead code' (it should be noted that Guile does partially support Javascript syntax). With the proliferation of Firefox extensions, Greasemonkey, etc. it is clear there is a large set of power users who want to modify the programs they use without spending years becoming skilled programmers. Perhaps after Emacs has been ported to Guile the philosophy of user extensibility will spread to other parts of the GNU system.

Re:GNU/Linux

[rubycodez]

hahaha - what a cop-out. that's a nice mealy-mouthed way to say they totally and utterly failed to produce a viable kernel after decades of farting around. Let's face it, a task that requires real world engineering ability rather than ivory tower theory and navel-gazing is always beyond RMS and his close cohorts. Even the gcc would have been dead had not the engineering types rescued it (egc history)

Re:I'm coining a new term:

[Z8]

Exactly, lisp was chosen for several related reasons, none of which are relevant:

1. Language Neutrality: The idea here is that users could program in whatever language they wanted. Unfortunately this never panned out because it requires the huge programming task of writing a translator from every languange into scheme. They should have known from the beginning that writing and maintaining all this code was unrealistic.
2. Macros: Yes, Lisp is very elegant, you can define your own syntax! But how many people need to write new unheard of forms of flow control in an extension language? And need to do it so often that Lisp's elegance at doing this would pay off?
3. Other CS Prof features: Yes, Lisp is usually tail recursive, so you can build stuff like coroutines. Again, how many people need coroutines when scripting GnuCash? And you can do coroutines in other languages, it just 10% less elegant (for instance, in Python you need a trampoline).

So basically their decision was optimized on all the wrong criteria. Instead it should have been optimized on:

1. Ease of use: Can user, who may not be a professional programmer, look at an example, vaguely understand how it works, and modify it slightly? This is possible with Python probably, but not with Lisp.
2. Community: How many programmers are already using it and what are its prospects for the future? GNU even further splintered the notoriously fragmented Scheme community when they chose to make their own scheme implementation instead of using one of the many very functional pre-existing Scheme implementations, several of which were explicitly designed as extension languages.
3. Efficient use of resources: If they had chosen Python or Lua they could have leveraged the existing work put into those languages as well as all the future work that would be done by those communities. Instead they decided to reinvent the wheel and develop their own Scheme implementation, almost from scratch (yes I know it forked from SIOD).

Re:Lua?

[gmueckl]

Well, as someone who tried to embed Lua and CPython I found the embedding interface in Lua much, much easier to use than CPython's for simple use cases. However, if you are able to deal with the complexities and effort to get it running, CPython seems to be much more flexible and thus better suited for complex interfaces to the scripting environment.

Jython, on the other hand, is dead simple to integrate: for the most part you just have to drop it in and it exports all public classes and methods automatically. No glue code required.

Re:No Sarcasm: Do People Care?

[DdJ]

Done right, an extension language that exposes the right interfaces in the right ways could be to GNU software what AppleScript is to Apple software. And that support is what makes Automator work.

To elaborate: the extension language for Macintosh GUI programs isn't built into those programs. They're built keeping it in mind, but it's not built into them. Instead, they essentially expose verbs and nouns (via a "dictionary") that a shared extension language framework then leverages. Some they define themselves (like the way iTunes defines what a "track" is), and some are defined according to standard conventions (like the definition of what a "window" or "menu" is). It's all typed and stuff too.

(In principle, more than one language could take advantage of that stuff, and the frameworks in fact lay the groundwork for that. In practice, nobody actually uses a language other than AppleScript with this stuff, which is kinda too bad. If you're on a mac and want to know what the hell kind of nonsense I'm raving about, read the man page for or output from the "osalang" command-line program.)

The result is incredibly Unix-y in fundamental philosophy, even if it doesn't seem so in detail: you can write scripts that string together small special-purpose programs to do large complex tasks -- and I'm talking about GUI programs, not just command-line utilities.

I make very powerful use of this myself sometimes, just as I've made very powerful use of shell scripting to bind small special-purpose command-line programs together since the 1980s. It's niiiice.

Re:NIHS

[metamatic]

Not Invented Here Syndrome is why they didn't use Tcl either (which is still being actively developed).

Tcl being a joke of a language is why they didn't use Tcl; see Stallman's original explanation [vanderburg.org].