Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix Programming

Sixteen Years Later: GNU Still Needs An Extension Language 425

Posted by Unknown Lamer from the one-of-us-one-of-us dept.
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.
This discussion has been archived. No new comments can be posted.

Sixteen Years Later: GNU Still Needs An Extension Language More

Sixteen Years Later: GNU Still Needs An Extension Language

Comments Filter:
  • 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.)

    • Guile is working on Lua support.

      • Re:Lua? (Score:4, Funny)

        by jockm ( 233372 ) on Wednesday August 31, 2011 @10:39AM (#37265136) Homepage

        Working on being the core term. Not have, not encouraging people to use, not bragging about compatibility, but working on. Wake me when it is ready, like their JavaScript support. It will make a nice break from waiting on Hurd.

      • Re:Lua? (Score:5, Insightful)

        by SerpentMage ( 13390 ) on Wednesday August 31, 2011 @11:31AM (#37265768)

        Here is an idea instead of adding Lua support, I don't know, USE LUA... Wow what a concept!

        This is what gets me with the GNU team. Instead of actually reusing what other people develop they rather stick to their own little ivory tower and get very little done. I am being serious here.

        I appreciate the work that the original GNU people did about two decades ago. It was needed. But for crying out loud these people remind of an older generation that does certain things because well that is how they did it two decades ago. And if it was good enough then, then gosh darn it, it's good enough today...

    • (Not trying to flame or confront, just curious)
      What about Python makes it unsuitable as an extension language?

      • Re: (Score:3)

        by mmcuh ( 1088773 )
        Last time I looked at the C API for Python it was beyond horrible. Boost.Python improves on it quite a bit, but it still not anywhere near "nice".

      • Re:Lua? (Score:4, Interesting)

        by gmueckl ( 950314 ) on Wednesday August 31, 2011 @12:52PM (#37266836)

        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:Lua? (Score:4, Informative)

        by impaledsunset ( 1337701 ) on Wednesday August 31, 2011 @12:58PM (#37266914)

        CPython can't be sandboxed.

    • Re: (Score:2)

      by TypoNAM ( 695420 )

      Python being the poorer choice because it is not designed to be an extension (scripting) language.

      Well somebody needs to tell CCP of Eve-Online they're doing it wrong, same goes for Stackless Python project, and the authors who wrote the official Python documentation that they were wrong to document Embedding Python in Another Application [python.org]. Because batrick on Slashdot said it wasn't designed for that...

    • Hell yeah! Lua is an extremely capable embedded language, quite fast and easy to code for, while being flexible. It's also open, and there's plenty of documentation lying around.

      My second choice would be Python, but I'd love to live in a world where a lot more things can be done through Lua.

  • Lisp? (Score:2)

    by Hatta ( 162192 )

    Why not?

    • Because Scheme is already a Lisp.

      • Re: (Score:2)

        by Hatta ( 162192 )

        Oh, I didn't know that. Is it very different from emacs lisp? It would make sense to stick with one extension language.

        • Comment removed based on user account deletion

          • Re:Lisp? (Score:4, Informative)

            by snowgirl ( 978879 ) on Wednesday August 31, 2011 @11:42AM (#37265888) Journal

            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!

        • scheme is better define than emacs lisp.
          Scheme is based on the Revised 6 Report on the Algorithmic Language Scheme. It is a formal specification of what a minimal implementation of scheme should offer.
          Emac lisp is based on whatever emac lisp can run, it is a bastardize old school lisp mixed with common lisp, sprikled with a bit of scheme and a dash of weird smelling stuff.

      • Re: (Score:2)

        by Creepy ( 93888 )

        Not quite - Scheme is more a subset of lisp with a few different features and a much smaller standard library.

        I personally hate them both because (over(use(and(need(for(lots(of(parens(without(format(requirements)(drives me))))(crazy))))).

        • LISP: Lost In Stupid Parentheses

        • Re: (Score:2)

          by gtall ( 79522 )

          More to the point, LISP is dynamically scoped and Scheme is statically scoped. And if you do not understand the difference, then you are much too young.

      • Re: (Score:2, Funny)

        by Anonymous Coward
        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.

        • Lisp is but a remnant of an age with far too much LSD and Napalm.

          You don't see such a juxtaposition in common use. I, however, greatly approve.

    • Re: (Score:3)

      by cpghost ( 719344 )
      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.

  • Usage predicts lifespan (Score:3)

    by G3ckoG33k ( 647276 ) on Wednesday August 31, 2011 @10:33AM (#37265064)

    "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.

    • So is brainfuck.

    • Maybe the GNU project should be called "Linux/GNU".

  • The port of emacs to guile is a breakthrough.

  • Poor planning and bad arguments (Score:3)

    by jockm ( 233372 ) on Wednesday August 31, 2011 @10:35AM (#37265094) Homepage

    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

    • Scheme and other lisp-like languages really are given a bad rap in some cases. I remember reading about someone working on a webpage offering various services (like slashdot, or facebook, etc), and while their competitors all went with C++ (yeah, they did a lot of that back in the day) or something else a little clunky. Meanwhile, this webpage chose to do everything in Scheme, or other lisp-like language (LLL?) and as a result any time their competitors rolled out a new feature, they could whip up comparabl

      • Re: (Score:3)

        by jockm ( 233372 )

        I think you are referring to Robert Morris' Viaweb [wikipedia.org] (later bought by Yahoo), which was partially implemented in Lisp. But they weren't exposing raw lisp to the users and expecting them to use it. They used it because they were experts, it was something they were very comfortable with, and thus could get things done very quickly. Of course this also dramatically reduced the talent pool they had to draw on for new hires as well.

        Lisp (and derivatives) is an amazing language and great for many problems, but i

      • Is this the essay you remember?

        http://www.paulgraham.com/avg.html [paulgraham.com]

        I don't think most people can write web code faster in lisp than PHP, unless you restrict yourself to a very tiny problem space. PHP has its issues (like a pretty broken language development community, meaning no offense to Rasmus himself) but it does allow incredibly rapid web development. In his essay, Graham says two lisp experts were better off using lisp for web development than using C++ or perl, and gives very good reasons why. But p

  • I'm coining a new term: (Score:4, Insightful)

    by O('_')O_Bush ( 1162487 ) on Wednesday August 31, 2011 @10:36AM (#37265104)
    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).

    • Re: (Score:2)

      by Anrego ( 830717 ) *

      I'm with you!

      This has of course been going on forever, and I'm quite weary of it.

      It also tends to evoke one of my more hated cringe phrases: "If people would only take the time to learn it, everyone would be using it!". Sometimes this is true.. however most of the time good things do become popular, and if something has been around for a while and not taken off, it's either way ahead of its time (rare) or not infact all that great (way more common).

    • Re:I'm coining a new term: (Score:4, Interesting)

      by Z8 ( 1602647 ) on Wednesday August 31, 2011 @11:32AM (#37265778)
      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).

    • 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).

      To be fair, I prefer the academic world, where niche problems are the soup de jour, and no one particularly complains. We work on the weird stuff, because that's what we like and want to work on. Forget you and your "getting work done" mentality... I'm here to play around ;)

  • No Sarcasm: Do People Care? (Score:3)

    by assertation ( 1255714 ) on Wednesday August 31, 2011 @10:47AM (#37265242)

    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?

    • There probably are more than a thousand developers who would like a better extension language, though a LISPy one certainly would not be it

    • Hey, Street Fighter matters! It just does. Now I wouldn't go with Guile necessarily, but he's good. Blanka was my preferred fighter.

    • Re:No Sarcasm: Do People Care? (Score:4, Interesting)

      by DdJ ( 10790 ) on Wednesday August 31, 2011 @01:09PM (#37267080) Homepage Journal

      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.

  • I read into these comments just to see if anybody cares.

    It seems not.

    If the Slashdot crowd doesn't, then why would the wider world?

  • Lisp (Score:2)

    by DrXym ( 126579 )
    Proposing a Lisp dialect as the "official" extension language of GNU is a stillborn idea. It might find favour with the small fanbase of Lisp hackers but nobody else. It would make more sense to define a language neutral automation interface that any process can implement. Scripting languages would soon acquire the bindings to use it.

    • You mean, they should use web services?

    • Proposing a Lisp dialect as the "official" extension language of GNU is a stillborn idea. It might find favour with the small fanbase of Lisp hackers but nobody else.

      That is probably why Guile is the official extension language of GNU. After all, RMS made Lisp machines before he started GNU.

      The GNU manifesto mentions C and Lisp as the two languages in which system programming will be supported. Emacs is also written in Lisp.

      Also, to those who think that Guile didn't become more popular because people don't like the parentheses: there is or at least was support for C-like syntax as well. Personally, I think whether or not extensions take off depends on other factors: how

  • ...and Lisp is weird.

    Yes, Lisp's awesome, and has got all sorts of fascinating and powerful features such as continuations and hygienic macros, but the sad fact is that it's just not accessible. Any programmer with modern training is going to be familiar with Algol languages, specifically C family languages, and is going to take one look at the incomprehensible mass of free-form parentheses that's a Lisp program and simply won't be interested.

    This is one of the reasons Javascript's so successful --- alt

    • Compared to the mainstream of Java/C++, JavaScript's prototype-based OO [mozilla.org] 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.

      • JS's prototype OO model is great because it means you can easily create your own set of object semantics by convention and simulate most other OO languages. Like prototype.js which started out as a ruby.js type of thing. So then when we're writing the JS for a Ruby web app, we can mimic the Ruby semantics. Makes it easier for us.

        JS is a great second language for that reason.

        For a normal extension language for use with trusted apps, I recommend C. We can wrap it with anything, and no matter how bad your API

  • Quoting from the Guile Manual [gnu.org]

    ECMAScript was not the first non-Schemey language implemented by Guile, but it was the first implemented for Guile's bytecode compiler. The goal was to support ECMAScript version 3.1, a relatively small language, but the implementor was completely irresponsible and got distracted by other things before finishing the standard library, and even some bits of the syntax. So, ECMAScript does deserve a mention in the manual, but it doesn't deserve an endorsement until its implementat

    • So there was apparently one and only one person motivated enough to actually start hacking ECMAScript into Lisp. And after some time that person didn't have the time/interest/motivation/whatever to continue that one-man project.

      Somehow even if it's a relatively small language to build a compiler for, I have the feeling that it's a bigger bite than a single hacker can chew. Especially as that hacker is doing it as a hobby project. It could have been helpful if that hacker had received some support and help

  • 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.

  • Modern web-based applications use AJAX and therefore JavaScript in combination with DOM models of HTML and SVG to model user interfaces. This could be a nice design concept as the UI runs on another machine than the core of the application. However, it would be best when the DOM manipulation language would be designed with more safety in mind. I visited a week ago a symposium where someone was explaining all the goodies of JavaScript. And honestly they are cool as in you can do a lot of stuff and need not t

Slashdot Top Deals

Great spirits have always encountered violent opposition from mediocre minds. -- Albert Einstein

Close