Slashdot Mirror
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.
Why isn't Lua considered? Everytime I see Guile brought up as a possible extension language, the project in question always settles on Lua or Python. (Python being the poorer choice because it is not designed to be an extension (scripting) language.)
"Finally, we have the lifespan issue. If GNU had chosen Tcl because it was popular, we would have a mass of dead code"
If Tcl had been used it may well have been alive I guess. I suppose it is Turing complete.
Because Scheme is already a Lisp.
Perhaps if GNU had adopted TCL, then it would have stayed popular. Or what if GNU had provided a common backbone for extension so then it would be easy to plug in scripting languages (perhaps at run time)?
The simple fact is that paren languages are a really had sell outside of their niche. There is a hardcore who loves them, but the majority do not. Scheme is like the cilantro of languages -- you love it, or you hate it, but there isn't much of a middle ground. The Guile folk made all kinds of promises back in the day of supporting lots of syntaxes, but like Hurd what has come out has been very late, or comes no where near expectations.
And of course the fact that Emacs still hasn't adopted it, isn't a ringing endorsement either.
So give up on a single fixed scripting language, and provide an extension architecture so lots of options can be used... including Guile
What do you know I wrote a novel
It is, "Just another paradigm changer" (JAPC). These sorts of articles come out all the time (see the recent OPA article). Basically, this term is to be used when another invested developer harks a new or underused language that will change the way most developers code. The problem is, most ignore some big hurdles in adoption:
1. Saturation. If there are already established tools that do more-or-less the same thing, then there is little incentive for developers to learn something different (often radically) for no tangible gains.
2. Non-problems: Developers often get excited by "problems" that don't exist outside of their niche or mind, and then develope something to solve it. While this might work in the niche, it rarely works in the general case (thoguh there are a few notable exceptions).
while(1) attack(People.Sandy);
Emacs is a great development environment. It just lacks a good text editor.
They have a kernel. If you're referring to GNU HURD, that's been deprioritized because as Mr. Stallman wrote in a Reddit interview, "Linux works ok as a kernel." Linux is one of many third-party components of a GNU system.
Why would anyone write it like that? You use line breaks and indentation to convey structure, just like you do when you write in any other language.
As an extension language, something like ANSI Common Lisp would have been an extremely bloated language. As a general purpose language, it is fine though. On the other hand, Scheme is lightweight enough to be linked as a library to any application, even running in the most constrained environment.
cpghost at Cordula's Web.
No sarcasm meant, does this issue matter to more than a handful of people?
Will it matter once all of the "once ___ are done"s or will the tech world have moved onto other things?
function Besides() { a(); few(); hardcore(); function geeks() {people(function hate(){shit(); that(looks()); like ((this();));})}}
I think that's harder to read.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Using some obscure (even if well suited) language just narrows that void even more
If you don't like the parenthesized S-expression syntax commonly associated with Guile, use M-expressions. Guile supports a curly-bracket syntax called ECMAScript, as the summary points out. You already have thousands of web developers using JavaScript and ActionScript, both of which are based on ECMAScript.
It's still a lot harder to read something like (plus 7 (minus 4 5) (some-function (* my-var 3))) than to read 7 + (4 - 5) + some_function(3 * my_var). It's also easier to read while(x 3) than it is to read the crazy Lisp syntax for do-loops, which appears to be a list of a variety of values, variables, conditions, all compacted into one statement, with no differentiation, syntactically, between the different arguments to the loop structure. Indentation and line breaks only help so much. Having actual syntax helps a lot more.
it's a passable operating system too, but yeah lacks a decent editor
In the rather unixy context in which GNU software tends to operate(historically, yes, there is the strong lisp-derived strain; most prominently holding out in Emacs; but today's incarnations generally show up as the userland tools of a unix or unixlike system) the niche for extension languages is arguably even a bit narrower:
They have to address problems of interest to people technical enough to write them; but not technical or interested enough to modify the program(as you note); but they also have to address problems in programs that are sufficiently monolithic that you would use the program's internal extension language, rather than hacking together a bash script that stitches together a bunch of common utility programs. In a context where command line users are largely an afterthought, or a workflow situation that makes heavy use of big, monolithic, programs with minimally useful command line invocations, extension languages are the 'glue logic' you get(observe your local Office guru's bludgeoning about of VBscript, or some photo-pro's slightly alarming Photoshop batch processing abilities); but the unix 'flavor' has historically been that the shell, rather than the program extension language, has been the tool of choice for bodging jobs too big to tackle manually but to small to be worth delving into the guts of the programs themselves.
Unlambda would a better choice in my opinion, it has all the features and none of the cumbersome syntax.
Lisp is but a remnant of an age with far too much LSD and Napalm.
you have the wrong form, your parenthesization is all wrong and you have two useless conjunction:
(Beside
(few (hardcore geek))
(hate people (look shit (like this)))
)
Jehovah be praised, Oracle was not selected
I generally subscribe to the idea that if something is good, it will become popular all on it's own.
16 years later and no one has heard of it.. not good.
There are of of course exceptions, where something is so far ahead of its time that no one appreciates it, or where something is never given a fair shake ... but I think guile falls under neither group. It was a nice idea, but let it die and use javascript/lua/python/whatever ..
Yes, that's MUCH better /sarcasm.
Compared to the mainstream of Java/C++, JavaScript's prototype-based OO is pretty strange.
People put up with language weirdness for two reasons:
* It's the only game in town (JavaScript and browser extension, Emacs Lisp, tcl/tk and X GUIs)
* It has something you really need/want (Lisp macros, Java JVM, C++ low-level access)
Neither of those can really be used to drive a universal GNU extension language. Wishing for it is like wishing for something to displace the x86 architecture.
To a Lisp hacker, XML is S-expressions in drag.
What I don't understand—admittedly, as a non-programmer—is why they don't just say "From now on, Emacs Lisp is the GNU extension language." Or, alternatively, that Guile continues to be the GNU extension language, but that as of Emacs 26 (or whatever version), Emacs Lisp will conform to the Guile specification.
Having both just seems like splitting resources to no good end to me.
It is all part of our (the vim users) evil plans to continue to subvert and destroy emacs. Enjoy your differently-abled extensible languages suckers!
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
They didn't choose Tcl because that would have required making a decision. The whole GNU community is plagued by indecision or "we can't do it this way because it's not perfect". So after 30 years, no kernel. Hell RMS will be dead before they release hurd one dot zero. Even a herd needs a leader.
We show geeks how to get their dream girl at EyesOfOdessa.com
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.
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
It is only harder for you.
If you had 18 fingers, six on each of three hands, dividing by 3, 6 and 18 would be trivial for you.
As you have 10 fingers, five on each of two hands, dividing by 2, 5 and 10 is trivial for you.
It is not that dividing by 10 is any harder or easier than dividing by 18, but as an animal with 10 digits that evolved counting with those digits, you find a base 10 number system familiar and dividing by the base of that number system is easy for you.
Dividing by 10 is not just inherently easy, just easy for humans spending a lifetime working in decimal.
Reading LISP is hard for you because you have been trained in a different standard syntax common to most other programming languages. LISP was one of the first languages I learned and I find its syntax far more readable than that of "normal" languages.
(+ 1 2 3 4 5 6 7 8 9 10) is much more obvious to me than 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10.
I know I am adding, why do I need to show that operator 10 times when one operator will do?
</LISP RANT>
When your extension language is 10 to 100 times larger than your application that uses it, then it has sort of lost sight of the concept of what an extension language is. An extension language that can be used to write other extension languages just seems weird. If this can happen because of the side effect of nice features then this is ok, but when this becomes the goal of the language then it's broken.
After all why don't we just claim that "C" is an extension language? After all you can implement Lua and Prologue in C and then just compile that into your application and you're done. If you're an extension language then there are certain things that should be the priority in the design: such as being smaller than the application it extends.
Lua I think does quite a lot of this absolutely right. It's extremely small, and is used even in embedded systems, but useful enough for giant applications. It is easy to adapt an existing application to using Lua even if it wasn't designed to have an extension language; lua can call your functions, your functions can all lua, you don't have to use or be a slave to lua's main processing loop, etc. The fact that Lua is an extremely powerful programming language in itself is a side effect of trying to keep the language simple and it wasn't the goal of the Lua design. The reason Guile is a ugly is because it's trying too hard to be a powerful programming language as its main goal and has no goal of being small and simple.
I'm reminded of an old joke. In the former Soviet Union, an operative was talking to his boss. The boss asked the operative if they were able to learn anything from the intercepted transmission of U.S. missile control software. The operative informed him that they had only managed to capture the last two pages, and although they didn't know anything about the code, they knew what language it was written in. The boss asked him how he knew what language it was written in, whereupon the operative told him it was written in either LISP or Scheme, and then showed him the paper, which contained an entire page of:
)))))))))))))))))
Check out my sci-fi/humor trilogy at PatriotsBooks.
Well, let's see. Gnu Guile is a Scheme interpreter. Scheme is a functional language--although most implementations, and I assume Guile is one of them, aren't pure functional--which implies a lot of nice features, possibly including heavily parallelism, ready portability and modifiability of functions while the program/scrip is running, and a design that lends itself to support of garbage collection and protection from all sorts of security issues. C lacks about every part of that in exchange for more raw access and a design that's more vulnerable to potential bugs/abuse by others--admittedly a large part of that is an implementation detail, but it's a very consistent implementation detail.
As for the whole point of implementing languages in other languages, that's an inherent part of most any language you're likely to see. It's just that Lisp/Scheme (and almost certainly a few other languages) can do it more readily as an inherent part of the language. If there's one lesson I was actually taught is that sometimes the best choice in designing something is to make a sublanguage specific for a task instead of hand-coding everything down. Since the whole point of GNU Guile was to be that generic sublanguage for most such tasks, it'd make sense they'd further want GNU Guile to further support the development of a subsublanguage when GNU Guile was just too generic for some tasks. In essense, if a Lua-like language was better for some things, just make a small Lua-like macro overlay and write in the Lua-like language. That's probably a lot better than trying to hack Lua, Python, or whatever into all the GNU-specific things one needs. Of course, that assumes enough knowledge about Lisp/Scheme to whip up the few macros needed, and I think that's the real crux of the issue.
Eurohacker European paranoia, gun rights, and h
One thing I'll note is that MIT MACLisp had a functional compiler that compiled all the way down to machine code before most of Slashdot's readers were born. The original MIT Multics Emacs was written in MACLisp, I looked at the resulting ALM (Assembly Language Multics) from the compilation process for a few functions just to see how well it compiled, and it was pretty close to the output I saw from the PL/1 compiler, which had an excellent optimizer for that era. There's nothing inherent about Lisp that makes it impossible to compile and optimize, Bernie Greenberg and David A. Moon certainly proved that.
That said, I'm of the opinion that the age of extension languages embedded into applications is over. The extension language paradigm explicitly limits the extension language to manipulating a single application, when what we have open on our modern desktop is dozens of applications and we'd like to create something new from all of them. What is needed, instead, is a universal interface exported by applications to use to script applications. Think Windows PowerShell rather than Emacs Lisp -- the shell lives outside the application and calls a defined application API to perform actions. SOAP/XML-RPC/REST are far more important to the future of scriptability than some archaic concept from the 1960s and 1970's, if I implement one of those interfaces to the core functionality of my application I can write my extensions in *anything* -- Perl, Java, Python, you name it. The problem of course is that SOAP/XML-RPC/REST are also horrendously inefficient, surely we can do better than marshalling and demarshalling everything to/from XML or JSON. Still, I present this as a conceptual thought -- though I might point out that the Amiga *almost* managed something similar with AREXX (theoretically it was possible to use the "AREXX port" to control Amiga applications from other scripting languages, though it was rarely done).
Send mail here if you want to reach me.
Until recently (moved to a new city), I was a volunteer at my old elementary school. Their gifted and talented math program had been shut down due to budget cuts: the teachers tried to compensate by getting professional mathematicians in to talk to the kids who should've been in gifted math programs. My role was simple: get fourth graders involved in math.
Each year on our first day together I'd use the LISP notation. I'd ask them, "if I told you to add the numbers one to ten together and multiply the result by fifteen, how would you write that down? Not the answer, but what I told you to do?"
They usually came up with 1+2+3+4+5+6+7+8+9+10*15. This got us into talking about precedence and order of operations and everything else. Their eyes would spin. So, multiply before add, but divide and multiply are co-equal operators and you do them in linear left-to-right order, unless grouped by parenthesis, and...
"You know, this is pretty stupid, isn't it?" I'd ask them. "It's too hard. How are we supposed to keep track of all that? Who came up with this, anyway?"
I'd then write, (* 15 (+ 1 2 3 4 5 6 7 8 9 10)).
Not once, not ever, did it take a class of fourth graders more than five minutes of using this syntax to realize it was so much better than the 'traditional' syntax. It let us communicate clearly about what we were doing and in what order. On top of it, it looks kind of weird and exotic, and kids love writing in codes -- the fourth graders took to it like ducks to water. It was something that neither their classmates nor their teacher understood, and a professional mathematician told them, "yes, this really is how a lot of us in the field prefer to write things."