From: Alexey Goldin
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date: 
Message-ID: <m1u3l8f32q.fsf@spot.uchicago.edu>
····@danpc.cris.com (Dan Haskell) writes:

> 
> Anyone who wanted a simple scripting language that could be easily embedded
> into their applications. Last time I checked Tcl was the only language you
> could do this with. There was something called libscheme that came close,
> but did not really allow for full integration with the application.

Have you tried SIOD? CLISP?

From: ·······@cas.org
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date: 
Message-ID: <5j12ue$9ib@srv13s4.cas.org>
According to Alexey Goldin   <···········@o-d-d-j-o-b.u-c-h-i-c-a-g-o.e-d-u>:
:> Anyone who wanted a simple scripting language that could be easily embedded
:> into their applications. Last time I checked Tcl was the only language you

:Have you tried SIOD? CLISP?


I know that I've not tried either of these.  In fact, I've never
seen an app that embedded either of these.  however, I've seen
several hundred that embedded Tcl - including the latest version of
nvi.  Since I prefer to use apps that share the same embedded language
when possible, use of tcl works for me at this time.

-- 
Larry W. Virden                 INET: ·······@cas.org
<URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
Unless explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.
From: Paul Wilson
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date: 
Message-ID: <5j1ib1$kp3@roar.cs.utexas.edu>
In article <··········@srv13s4.cas.org>,  <·······@cas.org> wrote:
>
>According to Alexey Goldin   <···········@o-d-d-j-o-b.u-c-h-i-c-a-g-o.e-d-u>:
>
>:Have you tried SIOD? CLISP?
>
>I know that I've not tried either of these.  In fact, I've never
>seen an app that embedded either of these.  however, I've seen
>several hundred that embedded Tcl - including the latest version of
>nvi.  Since I prefer to use apps that share the same embedded language
>when possible, use of tcl works for me at this time.

Larry,

   This seems like the only reasonable argument that people have raised
and one I have some grudging respect for.

   I haven't seen much in the way of defenses of Tcl per se as a language,
but people like Tk and Expect, and like the fact that Tcl is embeddable
and has a simple (albeit crude) foreign function call interface.  None
of these are things that can't be done with much better languages---even
small ones.  (And they'll generally run 30-1000 times faster than
Tcl, so you can write most of your app in a friendly interactive
language, if you want to, without much performance loss relative to C.)

   Ousterhout has declined to defend his argument that a scripting
language should not be a reasonable language for general-purpose programming.
Everyone else seems to think it would be nice, including many Tcl users
who write whole apps, or most of their apps, in Tcl.

   Ousterhout's argument that Tcl's terseness is due to deep facts
about the language design (string representation of code, dynamic 
typing) seems to have been rebutted with no counter-rebuttals.

   Several other questions have arisen that Ousterhout has ignored.

   In all of this, it seems that the Ousterhout has opted out of
serious discussion, and interestingly, few Tcl fans have defended
Tcl in these areas.  The main defense seems to be that "I use it
already, and other people use it already, so we're going to stick
with it and recommended it to others, whether or not it's fundamentally
lame."  (Sorry to put it in such an extreme way, but that's pretty much
how I see it.)

   My impression is that Sun made a similar marketing-based decision, 
killing several very interesting and worthwhile language project, just
keeping Java (which isn't horrible) and Tcl.  They had more market share
or mind share than, say, Self.  (The orphaning of Self was really sad.)

   (BTW, I don't generally buy the "right tool for the job" argument
about the proliferation of languages.  There may be no single language
that's perfect for everything, but I think we need to focus on a 
few that have fairly broad applicability.  Some languages are simply 
more powerful than others, and often simpler, easier to use, and
faster than weaker languages.  You can have a fairly small and powerful
toolkit, instead of a proliferation of weak and uselessly different tools.)

   One semi-reasonable argument is that Tcl is a handy language for
writing 1- to 20-line scripts.  But most people seem to think you
need extra discipline and/or kludged-up abstraction facilities such 
as [incr tcl] to get very far beyond that.  And the advantage seems
to go away if you're not familiar with the UNIX shell programming
paradigm.  (Most programmers are not, because they don't use UNIX,
and many UNIX programmers have never learned to script competently
because UNIX shell languages are unnecessarily arbitrary and inscrutable.)

   In the Tcl group I've seen postings that say things like "I tend to
lose it around 1000 to 2000 lines" and "heck, I lose around 500 lines".
This seems really relevant because Tcl may have advantages for UNIX
shell hackers writing 5-or-10 line one-offs.  It seems that most
programming effort goes in to programs one to three decimal orders
of magniture larger.

   There was a posting in this thread to the effect that "I wrote my
whole app in Tcl and it was great---all I had to do was go out
and get a much faster processor."  I think many people would consider
that a failure for Tcl, because in just about any other language it would
probably have run at least 10x faster, and been just fine on the original
machine.

   So the bottom line is that Ousterhout seems to have bailed, and 
other Tcl fans don't seem to be defending Tcl against several serious 
technical criticisms.  Is that because they don't have good answers
(except for market-share arguments), or just that they lost interest
in the flamewar?

   In case it's not clear, I'm not saying that everybody should just
drop Tcl right now in favor of (say) Smalltalk or Scheme or Gofer
or Python or Perl.  I do wonder whether Tcl is too weak to have
good prosects in has a chance in the longer run.  Many of its advantages
for UNIX, X, and C are greatly reduced on Windows or the Mac and Java.

   I think Tcl will be mainly a niche language, with much less appeal
outside its own turf---and serious competition in home games, too---and 
I think it's reasonable to consider switching to a language with better 
long-term prospects which isn't as popular right now, because we don't
want to get trapped in a dead end.

-- 
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (······@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and  Scheme interpreters and compilers available via ftp from 
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)      
From: Hume Smith
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date: 
Message-ID: <5j2qsf$hj0@news.istar.ca>
In article <··········@roar.cs.utexas.edu>, ······@cs.utexas.edu says...

>   So the bottom line is that Ousterhout seems to have bailed, and 
>other Tcl fans don't seem to be defending Tcl against several serious 
>technical criticisms.  Is that because they don't have good answers
>(except for market-share arguments), or just that they lost interest
>in the flamewar?

bingo.

I gave up fighting "my language is better than your language" junta years ago. 
they *are* religious wars and *cannot* be resolved.  why can't we just let 
people use what language they like and stop the fucking quabbling!?!  i'm sick 
to bloody death of this bollocks.  i've used around twenty languages; tcl is 
nice for some things (it was the first X program i had; it's been very nice 
in DB-HTML-WWW interfacing), awful for others (i wouldn't try writing yacc or 
other symbol-heavy stuff in it; but then i wouldn't write them in C either).  
right now i like it because it's a vast improvement over opther UNIX scripting 
languages (lists that work (nest, can have arbitrary strings), globbing 
that works (doesn't blast any little string that comes along with a * in 
it), arrays that work, procedures that work, commands that nest (do 'this 'do 
that''? right)...), i can run my email program on both my Unix and Windows 
machines, i can glue things into it on UNIX (Windows doesn't have anything 
worth glueing in), i can read it (i've passed the point of being able to keep 
straight all the little squiggly characters so beloved in the Temples of C++ 
and Perl)...

i don't do everything in it, but i'm alwful gald it exists.  now shut UP and 
leave me BE.
From: Graham C. Hughes
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date: 
Message-ID: <87hggyp3m5.fsf@A-abe.resnet.ucsb.edu>
-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Alexey" == Alexey Goldin <······@oddjob.uchicago.edu> writes:

Alexey> Have you tried SIOD? CLISP?

Quite frankly, since I discovered SWIG
(ftp://ftp.cs.utah.edu/pub/beazley/SWIG) any of Perl, Python, Tcl, and
Guile became easily extensible scripting languages.  Thus, I get just
about anything I want, and can judge languages on other merits, such
as libraries or asthetic implications.

As a side note, are there any proposals in the works to create a
comp.lang.advocacy newsgroup where this sort of thing would be allowed
full reign?  I can't fiddle the followups as would be my normal wish
on a thread this crossposted because I can't in good faith send them
anywhere.  comp.lang.misc is for things other than advocacy
``discussions''.
- -- 
Graham Hughes    http://A-abe.resnet.ucsb.edu/~graham/     MIME & PGP mail OK.
const int PGP_fingerprint = "E9 B7 5F A0 F8 88 9E 1E  7C 62 D9 88 E1 03 29 5B";
   #include <stddisclaim.h>


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM13CaiqNPSINiVE5AQF1MAP8CkOLQA3jCoVbO7H7QuRs42praU182Enb
QVi4jfP6JPdjakpe4W2nqH/qyViGO8p9ERbwwqc88hCuG/3QEUpg4UzrFf4XTNiF
hTtuCLSC7vVX54uCHFf6nysC+mqGPShW4rxIUAqjOjBYtipiPOZcpbOZVPhxvmRX
bOUh0qXV9Jk=
=caTl
-----END PGP SIGNATURE-----