[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: transports directory



[ On Sun, July 16, 1995 at 22:36:57 (-0400), Mark Moraes wrote: ]
> Subject: Re: transports directory 
>
> This is an argument in favor of something?! :-)

Sort of -- the GNU following is large (how large? I don't know :-), and
if one assumes it's going to gain some success, then

> --
>  > Language designers love to argue about why this language or that language
>  > *must* be better or worse a priori, but none of these arguments really
>  > matter a lot.  Ultimately all language issues get settled when users vote
>  > with their feet.  If Tcl makes people more productive then they will use
>  > it;  when some other language comes along that is better (or if it is
>  > here already), then people will switch to that language.  This is The
>  > Law, and it is good.  The Law says to me that Scheme (or any other Lisp
>  > dialect) is probably not the "right" language:  too many people have
>  > voted with their feet over the last 30 years.  I encourage all Tcl
>  > dis-believers to produce the "right" language(s), make them publically
>  > available, and let them be judged according to The Law.
>  > 	John Ousterhout.

Yeah, well 98.3% of all statistics are made up, and that goes for
measuring things by popular vote too.  People don't necessarily approve
of things that are good for them, but rather often stick with things
that drag them down and reduce their effectiveness.  Such is politics.
The same argument can be said of lots of computer languages, such as
C++, Ada, Cobol, etc.

IMHO, if Ousterhout had chosen an existing embeddable language to use
for Tk, that language, no matter what it was, would have enjoyed a great
deal of popularity.  If it had been perl, we'd all be buying more RAM,
and faster CPU's, but generally would be happy.  If it had been scheme,
there'd be some stupid grumbling about parenthesis, but everyone would
have dug out their old CS-201 text's and begun programming away.

Back to the language of choice for zmailer:

IMO, zmailer should use a language that's well suited for the problem
being solved, not for popularity's sake.  I think that's the failing
zmailer now suffers -- popularity won over requirements.  Now we have a
language that easily leads to some rather nasty errors.

That's why I suggested (originally to a different list), that zmailer be
re-implemented using the AT&T rc(1) shell language by Tom Duff.  Rc
attempts to correct many of the failings of Bourne shell syntax, and
though it's not perfect, it goes a long way towards that goal.

Ideally zmailer would use a small, standard, well structured language
like scheme.

However, we can indeed follow Ousterhout's advice and implement an
number of competing languages.  Instead of waiting for popular choice to
pick the winner though, I'd suggest a more scientific evaluation....

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>