Just Another Guile Hacker

Lee Thomas (leet@or.credence.com)
Fri, 14 Aug 98 14:33:31 PDT

Some more thoughts on Guile versus other languages, but with a less
provocative title than a "Guile Is DEAD" theme:

There has been some discussion of Guile as a replacement for Perl. I
was around for the early days of Perl, and what I most recall about
the comp.lang.perl newsgroup was many, many postings which made the
language accessible. Larry Wall himself often posted raw source
and/or documentation, which would be rewritten via other postings or
via email. Randal Schwartz and Tom Christiansen would either post
examples with copious commentary (i.e., "Hey, look at what I can make
Perl do!") or would try to be first (or best!) to solve someone's "How
do I solve THIS problem in Perl" problem. And it was open to all comers.

Fortunately, this is beginning to happen at about the right time in
Guile's life. I, as a dedicated lurker to this point (although I
built a few early releases before deciding I couldn't devote more time
to it) have started to see posts of actual, useful code, some of which
even have enough commentary that I can follow them. I expect after
the release of 1.3 this will increase rapidly. I think this was what
someone meant by "promoting" Guile.

There are several differences between Perl's development and Guile's:

1. Perl was never intended to be an elegant language with an
academic heritage. Perl could be rewritten, syntax and all, at
Larry Wall's whim - there weren't any books out on it.

2. Perl was directed at the limitations of specific Unix tools
(awk, grep, sed, C shell), rather than supporting Emacs, Tk, C
developers, etc., etc., which is a MUCH bigger job.

3. Perl was basically the first of its kind - a general-purpose
scripting language. There were no expectations for it (other
than failure, by cynics). There was a dearth of alternatives,
so it was easy to say "Let's make Perl do THIS!" without dissent.

4. The alternatives to Perl didn't have name-ownership or O'Reilly
books behind them. Attacking C-shell or awk (Aho, Weinberger
and Kernighan didn't try to defend the attacks, so no
name-ownership) or grep or sed or even C would not generate a
flame war among zealots on each side. Nor would it hurt your
prospects for getting YOUR books published.

5. (This is just an observation, not a criticism.) Perl discussions
were lively and fun due to the personalities involved. It was
almost like a street-theater comedy attracting a crowd. This
tended to make criticism and infighting almost unthinkable.

6. The grossest hack in Perl was lauded for its cleverness rather
than criticized as it probably should have been, again due to
the personalities involved. This let even a novice feel a
welcome part of the group. (JAPHs were a search for completely
outrageous cleverness, which Schwartz could then use to show
off his deep knowledge of the language, to the "audience".)

7. The early Perl community was dominated by system administrators
and shell hackers, rather than mathematicians. This biased the
discussion toward the intensely practical, which led to lots of
examples you could rip off and use immediately - I rarely need
a factorial or a matrix multiplier in my particular work, but
I'm often munging files and directory contents via a batch script.
My first thought in reading examples in the Guile Tutorial is
"So? What do I do with the results of this?" Perl scripts
became part of my work environment early on, so my first tool
to compile on a new job was Perl.

In summary, Guile's opportunity is in a different environment than
either Perl's or Tcl's. (I saw the early development of Tcl, too, and
was always astounded that it thrived - mainly due to addon modules.)
The Guile development community (the Guild?) should seek to emulate
the behaviors that were successful for both of those languages, but
shouldn't try to copy them explicitly. I believe Guile can be an
enormous success, provided everyone pulls together rather than apart,
and I have confidence in Jim Blandy and the rest of the crew.

(Personally, all I want is to be able to write Emacs macros that can
double as shell scripts - and vice versa. An embeddable extension
LANGUAGE would be nice, too. Keep up the good work, all!!)

Lee Thomas                       email: lee_thomas@credence.com  
Software Quality Manager         phone: (503)-350-7551  fax: (503)-350-7400
Credence Systems Corporation, 9000 SW Nimbus Ave., Beaverton, OR, USA 97008