5 ms·

Guile - The Failed Universal Scripting Language

77 points by fogus 17y ago

thomas11 17y ago
If you look at guile's history up to 2007 or so, it might indeed look like a failure. But since then, development has been taken up again, and progress is amazing. Andy Wingo did a lot of the work and has been blogging about it at wingolog.org, see especially his talk about the recent developments: http://wingolog.org/archives/2010/04/02/recent-developments-in-guile http://wingolog.org/archives/2010/04/02/recent-developments-.... Guile now has significantly improved performance, a compiler, and it can run JavaScript and Emacs Lisp besides Scheme. The 2.0 release is around the corner. Things look good.
- davidw 17y ago
  He's on HN, BTW: http://news.ycombinator.com/threads?id=wingo http://news.ycombinator.com/threads?id=wingo At this point, though, for me anything that is not BSD licensed is a non-starter. I'm not that much of a license zealot for other things, but for programming languages I think it's pretty important. A lot of the value in a language comes from having lots of users (and thus libraries, support, etc...), so cutting off people who want to include it in a proprietary product seems like a bad idea.
  - _delirium 17y ago
    Guile has a "linking exception", explicitly permitting you to include the interpreter/compiler in a proprietary product. You do still have to release any changes to Guile itself you make, but that seems like a pro rather than con for popularity of a language, since operationally-different commercial forks with no source available are hardly the sorts of things that give a language value. The intended case, where you just embed the interpreter as-is and use it as the scripting language for your app, is perfectly fine to do from proprietary apps.
    - wingo 17y ago
      That used to be the case, up to Guile 1.6. Guile 1.8 is LGPLv2+, and 2.0 (next month?) is LGPLv3+. The only (?) common license that is incompatible with LGPLv3+ is ironically GPLv2 (without +).
      - _delirium 17y ago
        Oops, I missed that change. Are there practical differences between LGPL and GPL-with-linking-exception? I thought the GPL with a linking exception was more or less what the LGPL was...
        wingo 17y ago
        Guile being LGPL allows its code to be _included_ into other LGPL software. Other than that it's the same, just a bit simpler to think about.
    - davidw 17y ago
      I'm just not convinced that the "proprietary fork" thing happens that often in languages to justify a license that scares people who only have a superficial understanding of it. For example, Tcl has had plenty of problems, but companies doing that was not really one of them, despite its popularity, and despite being included in a wide range of proprietary products.
      - _delirium 17y ago
        Yeah, that's a good point--- Lua is another example of an MIT/BSD-style licensed embeddable language that in practice doesn't seem to have produced proprietary forks.
        silentbicycle 17y ago
        I've heard about several in-house forks of Lua, but usually, they happened because companies settled on a specific version (e.g Lua 4.0) and imported it into their project. Lua's small enough that maintaining a private fork of the whole language is reasonable, though. The only public fork of the whole language I've heard of is Metalua, though.
  - wingo 17y ago
    Shh, don't tell ;) Guile is licensed under the LGPL, by the way. In a normal dynamically-linked environment, the only restriction this imposes on you is the requirement to redistribute any modifications to Guile itself. You probably knew that, but I just wanted to be clear.
cageface 17y ago
Scheme is certainly a nicer language than emacs lisp, but is it really worth all the effort of replacing it? So much code is going to have to be fixed or rewritten. Why not spend that time adding new features or building something new entirely?
- thomas11 17y ago
  The Guile VM can run Emacs Lisp. So the only thing that has to be changed is Emacs itself, all the elisp code out there will run unmodified.
  - Niten 17y ago
    Except that, apparently, it turned out not to be so simple in practice: In each and every case we discovered devils in the details and realized "Well, we can't." We could make a TCL-like language that could run many simple TCL programs but that would not be upward compatible - and have that TCL-like language nicely integrated with the larger environment. We could make an Emacs Lisp style of environment that could run some Emacs Lisp code directly but that would not be upwards compatible - and have that alternative Emacs Lisp nicely integrated with the larger environment. But we absolutely could not, for fundamental reasons, directly support Tcl and Emacs Lisp with fidelity and wind up with a sane programming environment. Can anyone point to what kind of fundamental problems he's talking about here?
heowbert 17y ago
Guile also runs on the NanoNote http://zedstar.org/blog/2010/02/25/guile-on-a-ben-nanonote/ http://zedstar.org/blog/2010/02/25/guile-on-a-ben-nanonote/
pellicle 17y ago
Can anyone summarize how Guile is supposed to interpret/interact-with other languages? I thought Guile was just the GNU Scheme interpreter (now bytecode vm, I guess), but it seems lately that it's turning into something like Parrot. Is that the case?
- koenigdavidmj 17y ago
  It was always intended to be a backend for whatever language you want; it just didn't get any real use other than the Scheme frontend until recently.
dasht 17y ago
Huh. Well, that's me (Tom Lord). So, what can I add here for HN? Some of the comments talk about Andy Wingo's good work and leadership in recent years. I agree. Of course, Guile was once my baby, long ago, complete with sleepless nights and other trappings of nervous parenthood. Consequently, I see almost all of the big technical changes made to Guile recently as The Wrong Way. But that's a purely personal, emotional reaction; objectively I see that he's doing good work. Guile failed / stalled for a few years there. It's a bit hard to talk about why. I'll say a few words about it and also point to a link with a an alternative telling of the same tale. Guile got started after some earlier, failed attempts to write a Scheme extension language library for Scheme. There were two earlier attempts that I know of: one called "revoc" (read it backwards) and the other had no name but happened as part of an early GNU spreadsheet project. I went to work for a start-up that, then, had something like 30 employees. It was an unusual start-up for its day for the software part of all of their products was free software. The Linux kernel didn't exist when the company was founded and it barely existed when I first started at that firm. The firm was Cygnus, of course. Back then it was called "Cygnus Support". Cygnus got it into its collective head, for a short period of time, to build a general purpose user interface toolkit for writing GUI apps -- and to make this GUI toolkit Scheme-based and to write GUI apps that were architecturally similar to GNU Emacs, but with fancier graphics and interaction. Building that thing was to be my job. To save time I started with Aubrey Jaffer's Scheme implementation called SCM. I forked SCM and began radically modifying it to make it more useful as a library and to add various desirable features. I wrote a C library for Guile to give it a generic window system interface, providing an X11 implementation of that library. Towards the end, I had much of the heavy lifting of the toolkit done and perhaps another 6-12 months before a real product. In my toolkit I even had a basic Emacs-like program except with features that Emacs lacked at the time like support for multiple-font text and proportionally spaced fonts. It was kind of neat because nearly all of the redisplay code, and all of the code for "text widgets", was written in Scheme - and yet performed reasonably well on even the slow machines of the time. It was a very "hackable", fun, toolkit. Alas, there were political problems. The sales staff at Cygnus, especially, were displeased that the project was taking so long: they had been hoping to have GUIs to show at trade-shows mere months after I started. The famous "Tcl Wars" happened and that led to some political infighting within Cygnus. Cygnus was seeking a next round of VC funding and there was pressure to cut the Guile project from the budget. Most annoyingly, my boss at the end showed me a contract he'd negotiated to help fund Guile work and asked me to approve it. I felt that the contract had some severe problems and would need to be fixed before I could agree to it - he'd negotiated it without any input from me. The next day he signed the contract. About a week later I felt duty bound to quit (because of the contract and because of some bullshit issues about my working remotely). The demise of the Guile project at Cygnus was a profoundly unpleasant experience. Quitting, at that time, was a somewhat crazy step to take. We parted on less than friendly terms. I had been accustomed to job searching in the Silicon Valley, back in those days, this way: you call a few recruiters; you fax or email them your resume; you have phone calls for a few days; you get some interviews; you take your next job. The Valley was, truly, the Garden of Earthly Delights for a hacker in those boom years. This time was different. I spoke to several otherwise decent recruiters who all quickly, and to my surprise, made it clear to me that each and every one had been warned away from me by people close to Cygnus. Some people will tell you that the Silicon Valley elites back then did not secretly blacklist people from employment. Those people are variously mistaken or lying. Get on the wrong side of a couple of those elites and, in my experience - that was it. You're out. The U-Haul place is down the street. On-ramp to highway 80 is over there. Get out of town. See you in the next life. Shortly after that I had to abandon my status as the GNU Guile maintainer (at status conveyed by the FSF, not Cygnus) for financial reasons: I was busy working out some way to keep a roof over my family's head. The project was taken over by one of the "revoc" developers about whose work on it, during that period, I have nothing nice to say. Within those next few years the Linux kernel's foothold got quite strong. The FSF greatly diminished its efforts to build a "complete GNU system" and, rather than making sure lots of interactive applications were extensible in the style of Emacs, the GNU project became more of a follower than a leader. In those same next few years, a faction of people close to Cygnus who had first hostilely forked GCC then forced its maintainership away from the FSF. Overall, the FSF became far less proactive at software development and the original "vision" of a lisp-centric improved version of unix fell by the wayside. One of the last big actions from GNU was to endorse an alternative GUI app framework - GNOME - on the grounds that at least it didn't have the licensing problems that, at the time, KDE had. Any remaining hope of directly developing the lisp-style environment we'd started out to build evaporated right there. Here is a different version of some part of the same story (also as told by me, and why should you believe me? :-) http://basiscraft.com/0800-0100-the-tcl-war.html http://basiscraft.com/0800-0100-the-tcl-war.html (Where did I go after Cygnus? After several agonizing months I landed a job working remotely for an R&D group at UUNET. That was a gig that went very well for a couple of years. You know, until it was suddenly revealed that the firm was bankrupt and that it's CEO was being arrested. I tell ya', I can't catch a break. ;-)

77 points by fogus 17y ago

If you look at guile's history up to 2007 or so, it might indeed look like a failure. But since then, development has been taken up again, and progress is amazing. Andy Wingo did a lot of the work and has been blogging about it at wingolog.org, see especially his talk about the recent developments: http://wingolog.org/archives/2010/04/02/recent-developments-in-guile http://wingolog.org/archives/2010/04/02/recent-developments-.... Guile now has significantly improved performance, a compiler, and it can run JavaScript and Emacs Lisp besides Scheme. The 2.0 release is around the corner. Things look good.

davidw 17y ago
He's on HN, BTW: http://news.ycombinator.com/threads?id=wingo http://news.ycombinator.com/threads?id=wingo At this point, though, for me anything that is not BSD licensed is a non-starter. I'm not that much of a license zealot for other things, but for programming languages I think it's pretty important. A lot of the value in a language comes from having lots of users (and thus libraries, support, etc...), so cutting off people who want to include it in a proprietary product seems like a bad idea.
- _delirium 17y ago
  Guile has a "linking exception", explicitly permitting you to include the interpreter/compiler in a proprietary product. You do still have to release any changes to Guile itself you make, but that seems like a pro rather than con for popularity of a language, since operationally-different commercial forks with no source available are hardly the sorts of things that give a language value. The intended case, where you just embed the interpreter as-is and use it as the scripting language for your app, is perfectly fine to do from proprietary apps.
  - wingo 17y ago
    That used to be the case, up to Guile 1.6. Guile 1.8 is LGPLv2+, and 2.0 (next month?) is LGPLv3+. The only (?) common license that is incompatible with LGPLv3+ is ironically GPLv2 (without +).
    - _delirium 17y ago
      Oops, I missed that change. Are there practical differences between LGPL and GPL-with-linking-exception? I thought the GPL with a linking exception was more or less what the LGPL was...
      - wingo 17y ago
        Guile being LGPL allows its code to be _included_ into other LGPL software. Other than that it's the same, just a bit simpler to think about.
  - davidw 17y ago
    I'm just not convinced that the "proprietary fork" thing happens that often in languages to justify a license that scares people who only have a superficial understanding of it. For example, Tcl has had plenty of problems, but companies doing that was not really one of them, despite its popularity, and despite being included in a wide range of proprietary products.
    - _delirium 17y ago
      Yeah, that's a good point--- Lua is another example of an MIT/BSD-style licensed embeddable language that in practice doesn't seem to have produced proprietary forks.
      - silentbicycle 17y ago
        I've heard about several in-house forks of Lua, but usually, they happened because companies settled on a specific version (e.g Lua 4.0) and imported it into their project. Lua's small enough that maintaining a private fork of the whole language is reasonable, though. The only public fork of the whole language I've heard of is Metalua, though.
- wingo 17y ago
  Shh, don't tell ;) Guile is licensed under the LGPL, by the way. In a normal dynamically-linked environment, the only restriction this imposes on you is the requirement to redistribute any modifications to Guile itself. You probably knew that, but I just wanted to be clear.

cageface 17y ago

Scheme is certainly a nicer language than emacs lisp, but is it really worth all the effort of replacing it? So much code is going to have to be fixed or rewritten. Why not spend that time adding new features or building something new entirely?

thomas11 17y ago
The Guile VM can run Emacs Lisp. So the only thing that has to be changed is Emacs itself, all the elisp code out there will run unmodified.
- Niten 17y ago
  Except that, apparently, it turned out not to be so simple in practice: In each and every case we discovered devils in the details and realized "Well, we can't." We could make a TCL-like language that could run many simple TCL programs but that would not be upward compatible - and have that TCL-like language nicely integrated with the larger environment. We could make an Emacs Lisp style of environment that could run some Emacs Lisp code directly but that would not be upwards compatible - and have that alternative Emacs Lisp nicely integrated with the larger environment. But we absolutely could not, for fundamental reasons, directly support Tcl and Emacs Lisp with fidelity and wind up with a sane programming environment. Can anyone point to what kind of fundamental problems he's talking about here?

heowbert 17y ago

Guile also runs on the NanoNote http://zedstar.org/blog/2010/02/25/guile-on-a-ben-nanonote/ http://zedstar.org/blog/2010/02/25/guile-on-a-ben-nanonote/

pellicle 17y ago

Can anyone summarize how Guile is supposed to interpret/interact-with other languages? I thought Guile was just the GNU Scheme interpreter (now bytecode vm, I guess), but it seems lately that it's turning into something like Parrot. Is that the case?

koenigdavidmj 17y ago
It was always intended to be a backend for whatever language you want; it just didn't get any real use other than the Scheme frontend until recently.

dasht 17y ago

Huh. Well, that's me (Tom Lord). So, what can I add here for HN? Some of the comments talk about Andy Wingo's good work and leadership in recent years. I agree. Of course, Guile was once my baby, long ago, complete with sleepless nights and other trappings of nervous parenthood. Consequently, I see almost all of the big technical changes made to Guile recently as The Wrong Way. But that's a purely personal, emotional reaction; objectively I see that he's doing good work. Guile failed / stalled for a few years there. It's a bit hard to talk about why. I'll say a few words about it and also point to a link with a an alternative telling of the same tale. Guile got started after some earlier, failed attempts to write a Scheme extension language library for Scheme. There were two earlier attempts that I know of: one called "revoc" (read it backwards) and the other had no name but happened as part of an early GNU spreadsheet project. I went to work for a start-up that, then, had something like 30 employees. It was an unusual start-up for its day for the software part of all of their products was free software. The Linux kernel didn't exist when the company was founded and it barely existed when I first started at that firm. The firm was Cygnus, of course. Back then it was called "Cygnus Support". Cygnus got it into its collective head, for a short period of time, to build a general purpose user interface toolkit for writing GUI apps -- and to make this GUI toolkit Scheme-based and to write GUI apps that were architecturally similar to GNU Emacs, but with fancier graphics and interaction. Building that thing was to be my job. To save time I started with Aubrey Jaffer's Scheme implementation called SCM. I forked SCM and began radically modifying it to make it more useful as a library and to add various desirable features. I wrote a C library for Guile to give it a generic window system interface, providing an X11 implementation of that library. Towards the end, I had much of the heavy lifting of the toolkit done and perhaps another 6-12 months before a real product. In my toolkit I even had a basic Emacs-like program except with features that Emacs lacked at the time like support for multiple-font text and proportionally spaced fonts. It was kind of neat because nearly all of the redisplay code, and all of the code for "text widgets", was written in Scheme - and yet performed reasonably well on even the slow machines of the time. It was a very "hackable", fun, toolkit. Alas, there were political problems. The sales staff at Cygnus, especially, were displeased that the project was taking so long: they had been hoping to have GUIs to show at trade-shows mere months after I started. The famous "Tcl Wars" happened and that led to some political infighting within Cygnus. Cygnus was seeking a next round of VC funding and there was pressure to cut the Guile project from the budget. Most annoyingly, my boss at the end showed me a contract he'd negotiated to help fund Guile work and asked me to approve it. I felt that the contract had some severe problems and would need to be fixed before I could agree to it - he'd negotiated it without any input from me. The next day he signed the contract. About a week later I felt duty bound to quit (because of the contract and because of some bullshit issues about my working remotely). The demise of the Guile project at Cygnus was a profoundly unpleasant experience. Quitting, at that time, was a somewhat crazy step to take. We parted on less than friendly terms. I had been accustomed to job searching in the Silicon Valley, back in those days, this way: you call a few recruiters; you fax or email them your resume; you have phone calls for a few days; you get some interviews; you take your next job. The Valley was, truly, the Garden of Earthly Delights for a hacker in those boom years. This time was different. I spoke to several otherwise decent recruiters who all quickly, and to my surprise, made it clear to me that each and every one had been warned away from me by people close to Cygnus. Some people will tell you that the Silicon Valley elites back then did not secretly blacklist people from employment. Those people are variously mistaken or lying. Get on the wrong side of a couple of those elites and, in my experience - that was it. You're out. The U-Haul place is down the street. On-ramp to highway 80 is over there. Get out of town. See you in the next life. Shortly after that I had to abandon my status as the GNU Guile maintainer (at status conveyed by the FSF, not Cygnus) for financial reasons: I was busy working out some way to keep a roof over my family's head. The project was taken over by one of the "revoc" developers about whose work on it, during that period, I have nothing nice to say. Within those next few years the Linux kernel's foothold got quite strong. The FSF greatly diminished its efforts to build a "complete GNU system" and, rather than making sure lots of interactive applications were extensible in the style of Emacs, the GNU project became more of a follower than a leader. In those same next few years, a faction of people close to Cygnus who had first hostilely forked GCC then forced its maintainership away from the FSF. Overall, the FSF became far less proactive at software development and the original "vision" of a lisp-centric improved version of unix fell by the wayside. One of the last big actions from GNU was to endorse an alternative GUI app framework - GNOME - on the grounds that at least it didn't have the licensing problems that, at the time, KDE had. Any remaining hope of directly developing the lisp-style environment we'd started out to build evaporated right there. Here is a different version of some part of the same story (also as told by me, and why should you believe me? :-) http://basiscraft.com/0800-0100-the-tcl-war.html http://basiscraft.com/0800-0100-the-tcl-war.html (Where did I go after Cygnus? After several agonizing months I landed a job working remotely for an R&D group at UUNET. That was a gig that went very well for a couple of years. You know, until it was suddenly revealed that the firm was bankrupt and that it's CEO was being arrested. I tell ya', I can't catch a break. ;-)