Re: Perl vs Scheme vs ML vs ... for autoconf

[Guido Draheim]

a) automake was not ported from perl to guile for years,
   and I don't know of experiments to actually do it now,
   or have it done in this decade (it wasn't in the last).
   Moving it from perl to guile does not earn much for 
   features or maintainability - it would just be another
   point to spread guile which I suspect to be one of
   the intents for RMS to propose it ;-)
b) perl is nice for its builtin regex, string-ops and
   system-support supported with syntactic sugar. It has
   an easy learning curve which gave it a good audience,
   Using perl for autoconf.* feels natural - you want to
   search, extract and write things, and the best thing 
   to use is a Practical Extraction and Report Language.
   The syntactic sugar however does sometimes confuse
   people which is the downside of TMTOWTDI.
c) a + b plus perl being ubiquitous - what else, hmmm..
d) if you ask for a language that had been forgotten,
   I'd point to php which is an original for string and
   database too, and with the advent xml era, it show
   an enormous growth, just like python in its first years.
   However, I feel it is still "evolving" in the sense
   it could shiftshape where perl is pretty done now.
e) autoconf.* maintainerscripts look short, I have to admit 
   that I don't get the idea of changing things. And if so,
   use the scripter that people are fluent with. You have
   automake.pl aclocal.pl autoupdate.pl, and automake.pl is
   bigger that the sum (!!) of the other auto*-tools. That's
   an argument to let converge maintaince on both sets of
   the autoconf/automake theater.

just my 2cent,
-- guido                         Edel sei der Mensch, hilfreich und gut
31:GCS/E/S/P C++$++++ ULHS L++w- N++@  d(+-) s+a- h.r(*@)>+++ y++ 5++X-