This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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