From: bitwize@wizards-of-source.org
Cc: Tanel Tammet <tammet@staff.ttu.ee>, <guile-devel@gnu.org>
Subject: Re: Roadmap and goals?
Date: Mon, 22 Apr 2002 00:26:05 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.44.0204212027480.16335-100000@phantom.h07.org> (raw)
In-Reply-To: <87sn5sxevl.fsf@ortler.iwr.uni-heidelberg.de>
On 19 Apr 2002, Nicolas Neuss wrote:
> 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).
What about .NET? :) (Actually, this too is proof of your point; in order
to shoehorn certain languages, such as Perl and even Visual Basic, into
.NET's architecture some pretty significant changes had to be made to
these languages' syntaxes and paradigms.)
This hacker couldn't care less about the ideology and motivation behind
Guile. Perl and Tcl annoy me, but Guile is fun and it's useful, and I can
quickly hack up workable programs with it that would have taken quite a
long time with another language. (I once wrote a fairly complete, albeit
non-validating, XML parser in Guile over an evening or two.) It is for
these reasons that I joined guile-devel not too long ago (after lurking on
guile-user for X years): I want to help keep Guile strong.
> 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.
I disagree with this position. There are many things that Guile has going
for it.
> 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]
As I mentioned before, the fact that "it's GNU" means a great deal to
Guile. There are a lot of disparate variations of Scheme out there, that's
true. (Some, such as SIOD, call themselves Scheme but don't adhere to any
published Scheme standard.) Part of Scheme's problem is its Pascal stigma:
it's an "educational" language, so no one will use it for any *real*
work, so why not slap your own umpteenth extension on it. Even
though Guile is Scheme, it possesses some really robust APIs, particularly
in the string handling, file, and networking side of things, that make it
useful for real-world tasks. It is also central to several GNU projects,
including TeXmacs and GNOME. Because it is a living, functional part of
the GNU project, Guile is well suited to shake off the Pascal stigma and
*become* a sort of de facto standard, one whose APIs and paradigms other
Schemes hopefully will emulate.
The SRFI process, which helps crystallize the Scheme community around some
good ideas and provide implementations that work across Schemes, is a
step in the right direction. Maybe more Guile hackers should contribute
SRFIs that encapsulate Guile's strong points.
> [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.]
LISP has a lot of things going for it too, but I don't want to start an
advocacy flamewar. LISPers see enough advantages in LISP that Perl,
Smalltalk, Java, et al. have yet to match in any significant way. "Those
who do not understand LISP are doomed to reimplement it, poorly." :) We
could debate the technical points all we like, but LISP has an ineffable
nature about it that most other languages lack... or maybe no programmer
has yet effed it in a suitable manner. In contrast I find Perl's nature to
be quite effable; I find myself frequently muttering, "This effing
syntax..." :)
My point is that LISP (and by extension, Scheme (and by extension,
Guile)) is more than the sum of its parts and will remain a strong
language for a variety of applications.
> 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).
AFAIK Guile is a derivative, and extension, of SCM. SCM's goals appear to
be different from Guile's.
> 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.
There are Emacs-like editors written in Scheme too: see MIT Scheme's
Edwin. :)
> 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.
Sorry to see you go. That's the way these things go, I guess.
--
Jeffrey T. Read
"LOBSTER STICKS TO MAGNET!"
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-04-21 22:26 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
2002-04-21 15:14 ` Rob Browning
2002-04-21 22:26 ` bitwize [this message]
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=Pine.LNX.4.44.0204212027480.16335-100000@phantom.h07.org \
--to=bitwize@wizards-of-source.org \
--cc=guile-devel@gnu.org \
--cc=tammet@staff.ttu.ee \
/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).