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 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.
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.
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.
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.
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.
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...
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? :-)
(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. ;-)
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.
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?
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?
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.