🚀 go-pugleaf

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

   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.  Well,
   until they're FORCED to use it, at which point they'll kick and scream for
   something easier.

If you're saying that sysadmins =like= scads of twisty little syntaxes
and semantics, all different, I find that hard to believe.  If you're
saying that once they've learned such beasts, they're reluctant to
change, I'd say that any new technology has to aim first at the "early
adopters"--people who aren't already firmly wedded to the status quo.


   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.

If you cannot imagine a single syntax flexible enough to express
procedural code, declarative relationships, and about anything else, I
suggest you look into the languages of the Lisp family, for example.


   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.

   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.  GNU script will not have that.  Without TREMENDOUS
   incentives, nothing will change.  Can you imagine all dot files and config
   files and macro files and rc files all being in one syntax?  This will
   never happen.  And if you try to enforce it, it'll blow up in your face.
   Straitjacketing won't win you friends.

   In summary, I truly fear you're wasting a great deal of time attempting to
   create something no one wants or needs badly enough to put up with.  In 
   other words: it's not broken, so don't try to fix it.

Indeed, those who believe that the present Tower of Babel is
acceptable will have little incentive to migrate, unless/until they
see others out-competing them via new technology.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.