🚀 go-pugleaf

In article <394kll$kso@csnews.cs.Colorado.EDU> Tom Christiansen
<tchrist@usenix.org> writes:

   I've been thinking about this new universal scripting language that
   RMS proposes, the one that's supposed to obsolete all other
   scripting languages in existence.  I now believe doomed his plan to
   make a universal scripting language, especially one derived from
   scheme. Essentially, it will fail due to lack of consideration of
   these issues:

    *  a developer's requirement to use whatever they feel like

Maybe I read him incorrectly, but I believe that Stallman was trying
to increase choice. In any case. I don't see why the desire of a
developer to use whatever extension language they like would be an
argument against any particular language. If they like that language
they will use it, if not not.

    *  substantial inertia favoring existing practice

I don't see much existing practice of the use of extension
languages. In the Unix world, the only significantly extensible
applications with large user bases that I see are Emacs and TeX. The
Tcl applications that I see don't seem to be very extensible. Note
that I don't see this (mainly) as the fault of Tcl. I just don't think
that developers have been very good about factoring their applications
into well defined documented API's.

    *  sysadmins want easy extensions/config files

I don't know what you mean by easy.

    *  sysadmins are more used to shellish languages than lispish ones

I think that it's more important to worry about how users will extend
their applications.

    *  little languages are best for configlike files

I'm less concerned about config files than about extensible
applications. However, Scheme is a pretty small language and I hope
that GEL (the GNU extension language) will be also.

   If the language is good for generating and parsing things like .Xdefaults
   or Makefiles or .cliprc files, fine, but if this just forces sysadmins to
   code in scheme or rush or something, they'll just laugh at you.

Once again, I think the point of GEL is real application
extension. Things like .Xdefaults to essentially just set variables
will be just as trivial as they are now. 

This might be a good time to mention that (at least in some
implementations) X doesn't even get the reading of .Xdefaults right; it
includes trailing whitespace in resource definitions.

   But telling someone they must use language GNU Blah for an
   extension language, well, get real: it really just isn't going to
   happen.

Who told anyone that they must use language GNU Blah?

   I genuinely don't see that there's enough substantially wrong with
   the way we make little languages now, either for extension or
   embeddability ...

The major thing that's wrong is that we don't really do it much. In
the cases that we do, like Emacs and TeX, we find the need for genuine
programming languages. To my mind, it's significantly easier to extend
Emacs then to extend TeX. A large part of that is because Elisp is a
better programming language than TeX.

   We'll all just keep using yacc and tcl and perl for these (and maybe even
   ksh and python) and we'll all be happy.  They've decades of combined use
   to hone and perfect.

For shell-like uses, I agree. But that's not the intended use of GEL.


   Can you imagine all dot files and config files and macro files and
   rc files all being in one syntax?

No, and who says they should be. In fact, the more powerful the
extension language the more freedom it gives to the developer to
define appropriate syntaxes for config files because he has more tools
with which to parse and interpret those files.

-Mark
-- 
Mark Friedman
NASA-Ames Research Center
MS 269-2
Moffett Field, CA 94035-1000

vmail: (415) 604-0573
email: bobo@ptolemy.arc.nasa.gov