From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.lisp.guile.devel Subject: Re: What is Guile? Date: Tue, 2 Sep 2003 09:47:53 -0700 (PDT) Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <200309021647.JAA27864@morrowfield.regexps.com> References: <3EF2F7DF008213D5@pop3.es.tisadm.net> (added by postmaster@netmail.tiscalinet.es) NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1062620689 3856 80.91.224.253 (3 Sep 2003 20:24:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 3 Sep 2003 20:24:49 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Sep 03 22:24:47 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19ueBL-0006Qp-00 for ; Wed, 03 Sep 2003 22:24:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 19ueBC-0007Xe-W1 for guile-devel@m.gmane.org; Wed, 03 Sep 2003 16:24:39 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 19uIbF-0007qM-2h for guile-devel@gnu.org; Tue, 02 Sep 2003 17:22:05 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 19uG3O-00046O-6z for guile-devel@gnu.org; Tue, 02 Sep 2003 14:38:59 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.22) id 19uEKU-0002c7-R8 for guile-devel@gnu.org; Tue, 02 Sep 2003 12:48:31 -0400 Original-Received: from [65.234.195.45] (helo=morrowfield.regexps.com) by mx20.gnu.org with esmtp (Exim 4.22) id 19uEII-0007Vd-GZ for guile-devel@gnu.org; Tue, 02 Sep 2003 12:46:15 -0400 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id JAA27864; Tue, 2 Sep 2003 09:47:53 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Original-To: ricardmm@tiscali.es In-reply-to: <3EF2F7DF008213D5@pop3.es.tisadm.net> (added by postmaster@netmail.tiscalinet.es) (message from Ricard Mira on Mon, 1 Sep 2003 16:54:28 +0200) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2737 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2737 > From: Ricard Mira > What is Guile? > Guile is the GNU *multi-lingual extensibility interpreter*. The > goal of the Guile project is to give users a choice of extension > language. As a point of history, being multi-lingual was _a_ goal, but certainly not _the_ goal. RMS still highlights the multi-lingual goal in some of his talks, but I think he is misplacing emphasis. Having a standard, powerful, extension language was more of a priority. Emacsen (and much else, besides) had proven that lisps are a good choice of extension languages, and we were interested in building on that observation. At the time that the Guile project started (back when it was called GEL), Sun was pushing Tcl as a proposed "universal scripting language" and the distinction, if there is one, between extension languages and scripting languages was not very clear. This was shortly before Oak was released as Java. The social dynamic around this kind of thing was somewhat different back then -- there was no /., no freshmeat, and barely a linux, for example. Sun was not in so much of a slump, at the time. When Sun started making press releases about Tcl as the universal scripting language, it seemed plausible that that would have a nearly irresistible impact. Even Usenix got in on the act and started hosting conferences devoted to Tcl. In short, Tcl seemed to have a lot of "mindshare", especially with people who had only a casual interest in extensible applications and extension languages. In my own rather unpleasant experience, I had a project to build an extensible application canceled out from under me because I had decided to use GEL (Guile) rather than Tcl. The experience of some of us, which assured us that Tcl was not a good choice for an extension language, was difficult to argue for. The Tcl implementation was unusually clean and simple code. The language was easy to learn. Tk was an nearly unprecendented set of functionality to offer in a tiny interpreted language for unix-like environments. To a casual observer, those virtues of Tcl were the most important thing. Several of us agreed, though, that Tcl had some serious problems. While it was a clean language if compared to, say, sh -- it was nevertheless a string-based language with the weaknesses that that implied. It didn't support garbage collected types and, generally, had limited data structures. It didn't support closure but did support some vaguely similar constructs that had their own problems. And so on.... When we started talking about using Guile instead of Tcl, people often replied with various things they liked about Tcl. For many small programs, a string-based langauge is convenient. Many people preferred Tcl's syntax to a lisp syntax. Back then, people could still be taken seriously if they said "garbage collection is bad." So we pointed out that Scheme was more powerful, more flexible. We pointed out that Tcl-like languages could be implemented (well) as libraries for Guile, but that the reverse was not true. One of the graduate students who worked on Tcl even supported our arguments by implementing Rush -- a nearly-Tcl language -- in Guile. He went on to suggest a set of changes that should be made to Tcl as a result of what he had learned (with the aim of making Tcl faster and more compilable, mostly by making it semantically cleaner). (His work did have influence on the language design of Tcl and on implementation changes that made Tcl faster For my part, shortly after Java was released, I demonstrated a C-like syntax for Guile. I think that, quite bitrotted now, that code is still floating around. So in the Propoganda, these ideas got very oversimplified. I can't speak for RMS but for my part, I wanted to try to consciousness raise people to realize that the language wars were pointless. You want to use a different syntax? That's a trivial matter. You want string-based data types? That's just a library. The important thing was to make the core of the extension language a powerful and fully general run-time system and interpreter, ideally based on a language with good prospects for efficient compilation. Nowadays, Tcl is mostly quiet (relatively speaking). Python and Java have a lot of "mindshare" (as do some other languages). As with Common Lisp, a large part of the economic effectiveness of those languages comes from the wide range of available libraries for them. The dominant importance of the libraries is, in retrospect, a quite obvious development. It also puts a serious crimp in the value of an extension language being "multi-lingual". Sure, a multi-lingual framework can, in some sense, use the set-union of all of those libraries. On the other hand, the "styles" of various languages are sufficiently different that such library sharing is of distinctly limited utility. A good Python library is not necessarily a good Scheme library or a good Java library or a good Tcl library. You can glue the libraries together in a pinch -- but to make a programming environment that is comprehensive yet compact and clean, you're probably better off sticking to just one programming language. Nowadays, I don't think people care too much if you happen to be able to program Guile in Python. (Evidence for this can be seen in the Real Soon Now translator for Python->Guile.) Perhaps if Python-in-Guile offered significantly better performance or profoundly new capabilities for Python programmers it would be a bigger deal --- but merely being able to type in some Python syntax and sorta-kinda use Python libraries is not a very compelling story. So, in short, I would not recommend starting off the Guile manual in the way you have quoted above. And, if _I_ were maintaining Guile, looking around at the scene, I think I'd be thinking about how to make a really great extended Scheme, fast, clean, and small. Finally, let me say this about Tcl: in some cases, garbage collection _is_ bad. In some cases, a language that can be implemented well in <20K LOC is a serious virtue. Tcl is not necessarily a great language design -- but it's implementation continues to have many virtues in some circumstances. I now think that rather than just thinking about a "multi-lingual extensibility interpreter", there would be some value in thinking about how to design Tcl or Python-like languages that admit tiny, simple implementation -- but that also "pun" as a subset of a lisp dialect. You can use the smaller language when you want -- but then you also have the option of scaling to the larger language, sharing _some_ libraries between the languages, and exchanging data between the languages. -t _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel