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-....
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.
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.
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.
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...
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.
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.
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.
The sad thing is that it is a bad business decision to not submit changes back to an open source project. If your company makes a change, the best outcome for the original project to adopt the code and assume the cost of maintaining the code. The worst (most costly) is your your company maintaining a fork. Never mind the loss of recruiting opportunities.
Agree completely: which is why I wouldn't worry about 'proprietary forks'. For almost any reasonably popular language, the community version's progress will quickly outstrip almost any company's version. If the company's smart, they'll try and stay as close as possible to the original, submitting patches and so on.
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.
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?
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?
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?
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 eve...
As I recall, the contract was vague and bullshitty and I didn't see any upside for the potential customer and suspected it had been offered as a "favor" in relation to some larger deal. I don't roll that way. That it was also then signed in spite of my specifically not agreeing to it was also the penultimate confirmation that I really no longer had any place at that firm.
I didn't look for a job before quitting because I'd never before had any problem finding a job. It was like I say: you call a few people, chat a bit, you get job offers. It didn't take courage to quit that time, just anger.
Yes. I meant "penultimate". I did not mean "ultimate". Nor did I mean "antepenultimate". I happen to love that triad of words (three years of Latin and two of Attic Greek in high school) and am sometimes accused over over-using them. I do use them with accuracy, though. The contract was the second to last reason added to the heap. The straw that broke the camel's back was a different matter.
but i have to say, this is no way to win friends and influence people. i read your account at basiscraft.com, and you seem to have a real chip on your shoulder. this makes me think that the other people in this drama might also have a story worth hearing.
26 comments
[ 3.1 ms ] story [ 63.6 ms ] threadGuile 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.
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.
The only (?) common license that is incompatible with LGPLv3+ is ironically GPLv2 (without +).
The only public fork of the whole language I've heard of is Metalua, though.
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.
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?
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 eve...
Dogbert would say: I like stories in which visions meet reality.
P.S. What was it about the new contract that made you quit, and why didn't you look for a job before quitting?
I didn't look for a job before quitting because I'd never before had any problem finding a job. It was like I say: you call a few people, chat a bit, you get job offers. It didn't take courage to quit that time, just anger.
but i have to say, this is no way to win friends and influence people. i read your account at basiscraft.com, and you seem to have a real chip on your shoulder. this makes me think that the other people in this drama might also have a story worth hearing.