🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #7078

Re: GNU Script isn't fixing something that's broken, so is doomed

#7078
From: Daniel LaLiberte
Date: Wed, 02 Nov 1994 20:36
62 lines
3631 bytes
   From: Tom Christiansen <tchrist@usenix.org>

   ... Essentially, it will
   fail due to lack of consideration of these issues:

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

As long as there is a means to translate to the Scheme extension
language, this is possible.

    *  substantial inertia favoring existing practice

I believe this is a recognized hurdle.

    *  sysadmins want easy extensions/config files

These can be viewed as small languages too, translatable to Scheme.
But more often, they will be just read in as data using various
scanf-like utilities.

    *  sysadmins are more used to shellish languages than lispish ones

Understandable.  So the shellish languages can be translated to Scheme.

    *  little languages are best for configlike files

Config files are processed by some larger context, which could be a C
program using the GNU Scheme extension language, or it could be using
the Scheme language directly for the whole program.

So you seem to be missing two major points.  First, the GNU Scheme-like
language (or whatever it is being called) is not necessarily the
language people are required to write their programs or scripts in since
there will be numerous external syntaxes that may be used.  Second, 
this is primarily an extension language for programs that require extension
languages.  But as a fully functional high level language, you could
use it to write whole programs too.

   Declarative languages, perhaps with escapes into code (a la yacc, escaping
   into C or perl), are the best way of handling a lot of problems, and both
   yacc and tcl make it easy create these, and perl certainly is good at
   parsing such files.  There's no reason for all config syntaxes to to be
   the same.  To the contrary:  problems are just too varied for one
   declarative syntax describing them.  And that's ok.

Yes, it is OK.  And Scheme is great for supporting the declarative
semantics under a declarative syntax.

   I genuinely don't see that there's enough substantially wrong with the
   way we make little languages now, either for extension or embeddability,
   that a huge niche will suddenly be filled by gnu script.  GNU only
   succeeds when there's a technical niche to fill, not when there's a
   political need to fill.

The technical need is to leverage off of each others efforts at
extension languages.   The question is do we know enough about different
kinds of little languages to say that Scheme (or any other language) is
powerful enough as the base language for all of them?  I would say 
that Scheme is a good choice for this.

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
Technical Details
Message-ID: <LIBERTE.94Nov2143656@void.ncsa.uiuc.edu>
Path: arc1-ca.pugleaf.net!bga.com!news.sprintlink.net!howland.reston.ans.net!vixen.cso.uiuc.edu!usenet
References: <394kll$kso@csnews.cs.Colorado.EDU>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f891f,9bda08f2f068881f
X-Google-Attributes: gidf891f,public
X-Google-Thread: 1025b4,9bda08f2f068881f
X-Google-Attributes: gid1025b4,public
X-Google-ArrivalTime: 1994-11-03 10:24:34 PST
Path: arc1-ca.pugleaf.net!bga.com!news.sprintlink.net!howland.reston.ans.net!vixen.cso.uiuc.edu!usenet
From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
Newsgroups: comp.lang.misc,gnu.misc.discuss
Subject: Re: GNU Script isn't fixing something that's broken, so is doomed
Followup-To: comp.lang.misc,gnu.misc.discuss
Date: 02 Nov 1994 20:36:56 GMT
Organization: University of Illinois, Urbana-Champaign, NCSA
Lines: 63
Message-ID: <LIBERTE.94Nov2143656@void.ncsa.uiuc.edu>
References: <394kll$kso@csnews.cs.Colorado.EDU>
NNTP-Posting-Host: void.ncsa.uiuc.edu
In-reply-to: Tom Christiansen's message of 1 Nov 1994 05:45:25 GMT