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  
 GNU Script isn't fixing something that's broken, so is doomed


Quote:

> :It has the same problem as AREXX and Python, in that it's a procedural
> :and algebraic language,
> For some things, that's just fine.   I'm suppose that you think their
> opposite must be the soi-disant data-driven or object-oriented programming
> styles.

I'm not talking about coding styles at all. I'm talking about a basic
capability common to all Lisp-derived languages that there's no syntactic
distinction between code and data. This makes it *easy* to define a
metalanguage that's declarative, or embedded, or object-oriented, or
what have you. You bring up the example of makefiles... converting a
Makefile to Tcl (I'll use Tcl instead of Lisp or Scheme because I'm
rusty in Lisp) is a simple mechanical *local* translation:

        CFLAGS=-O -g
        OBJS=main.o frob.o
        LIBS=-lreadline

        frob: $(OBJS)
                $(CC) $(CFLAGS) $(OBJS) -o frob $(LIBS)

Becomes:

        source makefile.tcl

        set CFLAGS "-O -g"
        set OBJS "main.o frob.o"
        set LIBS "-lreadline"

        rule frob "${OBJS}" {
                shell "${CC} ${CFLAGS} ${OBJS} -o frob ${LIBS}"
        }

        make

I doubt that a clean Scheme version would be much, if any, more complex.
As you can see, the resulting Tcl makefile is just as readable and
maintainable as the original. Why look, Tcl is now a declarative language!
Nope... but the metalanguage put together from this subset of Tcl *is*.
What was your other example? Oh, an embedded language. OK... here's how
I'd do that:

        source runoff.tcl
        runoff {
        Here you can have your running text,
        isolated from the rest of the world,
        safely quoted,
        with embedded Tcl commands like [exec date]
        handily sucked into the code,
        with no effort expended whatsoever.
        I know this is little harder in lisp itself
        because I used a similar technique
        in an adventure program back in 1979 or 1980,
        in Lisp 1.5
        on the PDP-11.
        }
        flush

In Perl you'd have to define some new encapsulation method for the procedural
fragments associated with each rule of the makefile. Probably using HERE
documents, I guess. You'd have to write some sort of parser for the running
text. You're no longer using the SAME language in each place, and you're
putting a lot more demands on the new language designer that the designer of
a metalanguage doesn't have.

I'm interested in the Perl way of getting something like the same result,
though, so I'm feeding this back to comp.lang.perl.

PS:
  Tom, if you're going to post something to the net and send me mail, let me
  know so I can ignore your mail instead of having to reply to it twice? Like,
  you're undoubtedly a really hoopy hacker but this is getting annoying. I do
  agree somewhat with your thesis, but I think there's just as viable a niche
  for GEL as any other EL so "doomed" is far too strong a word.
--
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U`
1601 Industrial Blvd.     Sugar Land, TX  77478  USA
+1 713 274 5180                       "Hast Du heute schon Deinen Wolf umarmt?"



Tue, 22 Apr 1997 23:18:52 GMT  
 GNU Script isn't fixing something that's broken, so is doomed

:I'm not talking about coding styles at all. I'm talking about a basic
:capability common to all Lisp-derived languages that there's no syntactic
:distinction between code and data.

hm... eval `cat /vmunix` never seems to work. :-)

--tom
--

You have made an excellent hit on the UNIX.--More--



Wed, 23 Apr 1997 00:49:07 GMT  
 GNU Script isn't fixing something that's broken, so is doomed

:
:I doubt that a clean Scheme version would be much, if any, more complex.
:As you can see, the resulting Tcl makefile is just as readable and
:maintainable as the original. Why look, Tcl is now a declarative language!
:Nope... but the metalanguage put together from this subset of Tcl *is*.

tcl is certainly better for making new little languages than perl is.
it's because it doesn't define syntax much, and because it uses braces for
single quoting.  it's just not good for large applications.

--tom
--

    signal(i, SIG_DFL); /* crunch, crunch, crunch */
        --Larry Wall in doarg.c from the perl source code



Wed, 23 Apr 1997 01:31:55 GMT  
 GNU Script isn't fixing something that's broken, so is doomed


Quote:

> :I'm not talking about coding styles at all. I'm talking about a basic
> :capability common to all Lisp-derived languages that there's no syntactic
> :distinction between code and data.
> hm... eval `cat /vmunix` never seems to work. :-)

The shell is a lisp-derived language?
--
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U`
1601 Industrial Blvd.     Sugar Land, TX  77478  USA
+1 713 274 5180                       "Hast Du heute schon Deinen Wolf umarmt?"


Wed, 23 Apr 1997 06:08:34 GMT  
 GNU Script isn't fixing something that's broken, so is doomed

Quote:


>:
>:I doubt that a clean Scheme version would be much, if any, more complex.
>:As you can see, the resulting Tcl makefile is just as readable and
>:maintainable as the original. Why look, Tcl is now a declarative language!
>:Nope... but the metalanguage put together from this subset of Tcl *is*.

>tcl is certainly better for making new little languages than perl is.
>it's because it doesn't define syntax much, and because it uses braces for
>single quoting.  it's just not good for large applications.

It is if you design your code/application correctly.  If you want to write
large monolithic applications where the application runs as one process, no tcl
is not good.  If you write modular applications where the application runs as
multiple processes, tcl is good (at least good enough to control an oil and gas
production facility in the Gulf of Mexico).

I'd defining large as over 100,000 lines of tcl/tk code.

==========================================================================
* Gerald W. Lester                        !   Voice:  (504)-889-2784     *
* Computerized Processes Unlimited        !   FAX:    (504)-889-2799     *

* Metairie, LA  70001                     !   Hours:  09:00-17:00 CDT    *
==========================================================================



Wed, 23 Apr 1997 06:45:14 GMT  
 GNU Script isn't fixing something that's broken, so is doomed


Quote:
> :I doubt that a clean Scheme version would be much, if any, more complex.
> :As you can see, the resulting Tcl makefile is just as readable and
> :maintainable as the original. Why look, Tcl is now a declarative language!
> :Nope... but the metalanguage put together from this subset of Tcl *is*.
> tcl is certainly better for making new little languages than perl is.
> it's because it doesn't define syntax much, and because it uses braces for
> single quoting.

The simple syntax is a common thread among these sorts of languages, whether
lisp-derived or those created out of whole cloth like Forth/postscript/...
and APL.

Calling quoting "single quoting" is itself pretty revealing.

Quote:
> it's just not good for large applications.

I'm not talking about large applications. I'm talking about extension
languages. I wouldn't use "make", "nroff", or HTML for large applications
either.
--
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U`
1601 Industrial Blvd.     Sugar Land, TX  77478  USA
+1 713 274 5180                       "Hast Du heute schon Deinen Wolf umarmt?"


Wed, 23 Apr 1997 08:04:40 GMT  
 GNU Script isn't fixing something that's broken, so is doomed


Quote:
>> [TCL]'s just not good for large applications.

>I'm not talking about large applications. I'm talking about extension
>languages. I wouldn't use "make", "nroff", or HTML for large applications
>either.

Peter,

Are you so blinded by the bright light of declarative semantics
that you fail to see examples of your own argument?  With the
possible exception of make the languages you list above have been
used with great success in the context of moderate to large systems.

It is apparent that troff has been used with some success in at
least one application of moderate size that we are all familiar
with.  Indeed the Unix manuals are a fantastic example of many
enabling principles which allow programming in the large.

In the case of HTML, I for one would not want to claim that the
web is small.  Together HTML and the URL provide another fine
example of a declarative language with strong modular orthogonality.

In their target domains each of these languages, including make,
performs admirably "in the large."  I find your comment that they
are merely "extension languages" that are inappropriate for use in
contexts of large systems irresponsible.

chris
--
PROGRAMMING:   2. A pastime similar to banging one's head against a
wall, but with fewer opportunities for reward.
        -- THE FREE ON-LINE DICTIONARY OF COMPUTING



Fri, 25 Apr 1997 07:47:13 GMT  
 
 [ 35 post ]  Go to page: [1] [2] [3]

 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