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


   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



Wed, 23 Apr 1997 04:00:24 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  
 
 [ 37 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