From: Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de>
Cc: guile-devel@gnu.org
Subject: Re: Roadmap and goals?
Date: 19 Apr 2002 10:38:06 +0200 [thread overview]
Message-ID: <87sn5sxevl.fsf@ortler.iwr.uni-heidelberg.de> (raw)
In-Reply-To: Tanel Tammet's message of "Wed, 17 Apr 2002 15:21:47 +0300"
Dear Guilers.
Motivated by the recent message from Tanel Tammet on the guile-devel
mailing list (and the answers, which are IMO unsatisfactory), I want
to present also my point of view on Guile.
First, let me tell a little bit of my own history. I was a C
programmer who searched an extension language for an application.
First, I thought about using Elisp (having immediately an integration
with the editor). Thus I wrote to Stallman and asked him about this,
and, of course, he suggested Guile. I came to Guile in 1998.
Maintainer was Jim Blandy at that time. Somewhat later he gave up,
was followed by Maciej Stachowiak, who was joined by other developers
(Mikael Djurfeldt, Michael Livshin, and Marius Vollmer, if I remember
correctly). Who is maintainer now? I don't know precisely, because I
read the Guile mailing list only superficially since the year 2000.
Now, what are Guile's goals? IMO, Guile arose from several ideas of
RMS: the first that Lisp-like languages are best, the second that
combining several languages (i.e. using extension languages as he did
with Emacs) is the way to go, the third that Elisp should be replaced
by Scheme, and the fourth that such software has to be under the GPL
and maintained by the FSF. During the so-called TCL flamewar, a fifth
idea was brought up, namely that the FSF extension language should
emulate others.
Unfortunately, all those goals are very questionable. First, non-lisp
languages get more and more of Lisp's capabilities[1] and the
advantage is not large any more, especially for the spartanic Scheme
branch. Second, my guess is that most applications are written within
one language, because maintaining the interface between two languages
is a problem. Third, replacing Elisp with Common Lisp would probably
be both easier and better (but is still difficult, see below).
Fourth, more liberal licenses than the GPL (e.g. some BSD license) or
GPLed software not maintained by the FSF is also a nice thing[2].
Fifth, emulating languages in an integrating way is easy to say, but
difficult to work out (this is proved by Guile not emulating one
single other language in a reasonable way).
Where does Guile stand now? In my eyes, Guile is fighting on a lost
position. I will elaborate a little bit on this in the following.
First, there are several strong and healthy Schemes competing. I
don't know about SCM and Bigloo which the previous poster suggested,
but I know a little about PLT Scheme. This Scheme has an IDE making
it work under Windows, Mac and Unix very nicely. And a lot of work is
put into it from several people at several universities (Matthias
Felleisen, Shriram Krishnamurti, ...). [One can look at this as
unfair competition because Guile has no such direct university
support. But that doesn't count, at least for me as a user.] Its
license is even more liberal than the GPL, and therefore could be
accepted IMO.
Second, I have serious doubts that Scheme as a language succeeds (in
spite of PLT Scheme). It is quite astonishing that at this time a
language is propagated as the ultimate weapon, which has neither OO
support nor modules/namespaces in a standardized way. It seems that
the Scheme dogma of accepting only perfect solutions approaches now a
boundary where only several 90% solutions are available, and thus
cannot be extended further. Even inside the Lisp language family,
Scheme looses against (ANSI) Common Lisp which supplies both a very
strong OO system and packages in a standardized way. There are also
good and free CL implementations, namely CLISP (GPL, only
byte-compilation, very portable) and CMUCL (public domain, compilation
to native code, less portable). [3]
[Third, of course, it is questionable if Lisp itself will survive,
because the Lisp family as a whole is attacked by other languages like
Java, C++, ML, Smalltalk/Squeak, ... But there were Kassandras for
Lisp all the time during its long life.]
What should Guile do? In my opinion, there should be a drastic change
in direction. First, of course, you should finish the current ?1.6?
release as fast as possible. But then you should evaluate several
other Scheme implementations, as well as CLISP and CMUCL. If it
should turn out that Guile has enough merits (apart from the merit
that it's the Scheme you know), fine, forget my words. If not, you
should talk seriously to RMS. Because then it is time to rethink this
project and take appropriate actions. These actions may go from
joining with SCM on the one side[4] to shifting the whole project
towards Common Lisp as extension language on the other side (leaving
the domain "Scheme as an educational language" to PLT Scheme).
Concerning Elisp replacement, it would make sense to drop Scheme in
favor of CLISP, too. This would make the project much easier, because
CL and Elisp are comparatively near (especially when you do (require
'cl) in Emacs:-). Further, there are Emacs-like editors written in
CL, see Hemlock for CMUCL from which one could maybe take some code.
Also, there may be CL people willing to help, even Erik Naggum (see
footnote) once planned something like that. One should keep in mind,
that it is still a hairy project[5]. But it could succeed, if
Stallman pushed it.
That's all I have to say. What concerns myself, I have switched to
Common Lisp about two years ago. I guess, I'll drop out of the Guile
mailing list soon. I want to thank the people that were and are on
this list. I learned a lot of things, but I prefer another playground
now.
Goodbye,
Nicolas.
[1] see the web page of Paul Graham at
<http://www.paulgraham.com/articles.html>
[2] It seems that while the GNU system being under the GPL is
certainly achievable, it does not really work that the FSF is the
copyright hodler of all essential parts. This goal should be
abandoned.
[3] I do not mention GCL here, because it is not ANSI compliant, and
appears not to be actively developed any more. It seems to be one
of those projects where you have to tell people NOT to use the FSF
version (similar to the Hurd kernel, and maybe Guile).
[4] IMHO, it is a terrible nonsense that people work on so many Scheme
implementations in parallel, only to feed the egos of their
respective leaders.
[5] See the articles on this topic at the Xemacs web site
http://www.xemacs.org/Architecting-XEmacs/index.html .
P.S.2: If some of you did not yet look at CL, you could start with
reading comp.lang.lisp. [You will meet several other (former) Guilers
there:-).] But when joining that newsgroup, please remember the
following things:
1. It is about (Common) Lisp, not about Scheme. Scheme has an own
newsgroup (comp.lang.scheme).
2. Many burning questions (why is () equal to #f?, why are there two
namespaces?, replacing Elisp, ... and so on) have already been
discussed, most of them several times. You can find such info in
the FAQ
<http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/top.html> or
via Google group search <http://groups.google.com/groups?selm=>.
3. There is a guy called Erik Naggum who is very rude. Nevertheless,
he is one of the sharpest guy I know, and you do everyone a favor
if you keep that in mind. Don't get into a struggle with him,
those exchanges are extremely annoying.
4. As with every newsgroup or mailing list, you should read it for
some time without posting.
In parallel, you should read an introductory book (I'd recommend
Graham's "ANSI Common Lisp"). And install the Common Lisp Hyperspec
(because of this tremendous thing, documentation is not a problem with
CL).
P.S.2: I thought about sending this also to guile-user@gnu.org. I
refrained from doing so, because Tamel did not do that, and because I
do not want to be too destructive. But IMHO, also users should know
about these problems in Guile's design. So, it remains for you
maintainers to inform them...
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-04-19 8:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-17 12:21 Roadmap and goals? Tanel Tammet
2002-04-17 20:59 ` Neil Jerram
2002-04-18 8:37 ` Panagiotis Vossos
2002-04-19 9:14 ` Panagiotis Vossos
2002-04-20 6:58 ` Thien-Thi Nguyen
2002-04-20 10:18 ` Panagiotis Vossos
2002-04-18 14:58 ` bitwize
2002-04-18 19:26 ` Rob Browning
2002-04-20 7:23 ` Thien-Thi Nguyen
2002-04-18 0:57 ` Christopher Cramer
2002-04-19 17:36 ` Marius Vollmer
2002-04-19 8:38 ` Nicolas Neuss [this message]
2002-04-21 15:14 ` Rob Browning
2002-04-21 22:26 ` bitwize
2002-04-22 18:36 ` Kirill Lisovsky
2002-04-23 7:53 ` rm
2002-04-23 15:11 ` Rob Browning
2002-04-20 7:47 ` Thien-Thi Nguyen
2002-05-14 8:26 ` Thien-Thi Nguyen
-- strict thread matches above, loose matches on Subject: below --
2002-04-20 12:55 Kirill Lisovsky
2002-04-20 20:01 ` Rob Browning
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sn5sxevl.fsf@ortler.iwr.uni-heidelberg.de \
--to=nicolas.neuss@iwr.uni-heidelberg.de \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).