GNU Script isn't fixing something that's broken, so is doomed 
Author Message
 GNU Script isn't fixing something that's broken, so is doomed

[Note the followup-to line, and adjust if necessary.]

After attending the VHLL Symposium at Santa Fe where zillions of languages
were showed off and talked about, 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.  He would like this language to be used by any application
wanting embeddability or extensibility will employ.  Essentially, it will
fail due to lack of consideration of these issues:

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

 *  substantial inertia favoring existing practice

 *  sysadmins want easy extensions/config files

 *  sysadmins are more used to shellish languages than lispish ones

 *  little languages are best for configlike files

The only points RMS makes which I recall to have substantial weight are
that you need a fully-featured and reasonably fast language for real-world
applications and that tcl isn't very good at this.  Well, maybe the latter
is indeed true, but given that people are using tcl for this and are doing
so with reasonable efficacy proves it works sufficiently well for this
purpose.  tk and expect prove that.  Please remember that as a glue
language, tcl doesn't need to handle large 50,000-line programs well.
Making it do so could in fact impair its being good glue language.

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.

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.

I'll tell you a place the FSF can perhaps help.  Consider the benefit from
the perl<->ksh portability dialog, or better, the refined and streamlined
C API for tk that I presume will come out of the tkperl<->tkpython
dialog.  This is the kind of thing we need.  It's good to have a common C
API.  If GNU can standarize things like that, then great.  But telling
someone they must use language GNU Blah for an extension language, well,
get real: it really just isn't going to happen.

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.

--tom
--

if (shm == (char *)-1)  /* I hate System V IPC, I really do */
    --Larry Wall, from doio.c in the v5.0 perl distribution



Sat, 19 Apr 1997 13:45:25 GMT  
 GNU Script isn't fixing something that's broken, so is doomed
Tom Christiansen:
. Until gnu script appears, it's vaporware of a purely political
. nature, and just so much hype and hormones.  

???

Not to the people who are working on it, or planning to work on it.

Enough said.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

                         NB.  public e, n, y
                         x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q



Sun, 20 Apr 1997 00:55:59 GMT  
 GNU Script isn't fixing something that's broken, so is doomed

:Tom Christiansen:
:. [Note the followup-to line, and adjust if necessary.]
:. ...  He would like this language to be used by any application
:. wanting embeddability or extensibility will employ.
:
:"any" is too strong a word.
:
:From what I read, RMS wants to make something available which is
:faster and more powerful than TCL.  He wants to use this "something
:better" in a number of significant projects.
:
:. Essentially, it will fail due to lack of consideration of these
:. issues:
:.  *  a developer's requirement to use whatever they feel like
:
:RMS is a developer, so are some other people that have expressed
:interest in this project.

Well, fine.  Giving us another potential interface is just fine.
Restricting our choices won't.  As I said, a reasonable thing for the FSF
to do might be to look toward unifying the C API to tk with an eye towards
efficiency and portability.  It's currently used in subtly different ways
by tcl, perl, python, scheme, and even prolog.  Guido and Malcolm were in
heavy conference last week, so they'll probably do it anyway without the
FSF's blessing.  There's also the "danger" that what they'll do won't be
copylefted, as both perl and python are available under alternative
licencing restrictions to facilitate embedded use in commerical products,
something at which they've been quite successful.

At the risk of repeating myself, I'll state that in this community, only
technical criteria matter.  Politics do not drive the technical, but vice
versa.  To see it as otherwise is to fight a losing battle.  Until gnu
script appears, it's vaporware of a purely political nature, and just so
much hype and hormones.  Once it does, it has the potential of being a
technical wonder and filling some gaping niche (which most of us can't
see), at which point it will be judged on its technical merits.  

--tom
--

- Real programmers like vending machine popcorn.  Coders pop it in the
  microwave oven.  Real programmers use the heat from the CPU.  They can tell
  which jobs are running from the rate of popping.



Sun, 20 Apr 1997 00:08:38 GMT  
 GNU Script isn't fixing something that's broken, so is doomed
Tom Christiansen:
. [Note the followup-to line, and adjust if necessary.]
. ...  He would like this language to be used by any application
. wanting embeddability or extensibility will employ.

"any" is too strong a word.

From what I read, RMS wants to make something available which is
faster and more powerful than TCL.  He wants to use this "something
better" in a number of significant projects.

. Essentially, it will fail due to lack of consideration of these
. issues:
.  *  a developer's requirement to use whatever they feel like

RMS is a developer, so are some other people that have expressed
interest in this project.

.  *  substantial inertia favoring existing practice

A good reason for doing "something better than tcl" now -- before the
inertia gets worse.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

                         NB.  public e, n, y
                         x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q



Sat, 19 Apr 1997 23:36:52 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. GNU Script isn't fixing something that's broken, so is doomed

2. GNU Script isn't fixing something that's broken, so is doomed

3. Fixed point math in asm -HELP ME I 'am dying here

4. Why CGI script isn't worked ?

5. Why isn't Haskell mainstream?---A newbie's view

6. COBOL isn't dead, but I'm learning C++

7. Tcl script exec'd from VMS tcl script doesn't display puts o/p

8. Something strange with 'object'

9. 'who am i' from unix

10. Broken '+' key

11. break out of 'case'

 

 
Powered by phpBB® Forum Software