From: Fernando Mato Mira
Subject: Why is tcl broken?
Date: 
Message-ID: <375F82C7.CF0F0477@iname.com>
Hello,

  I'm trying to collect a list of all the _current_ issues making tcl
a bad language choice. I'd like concrete examples, and not just
vague assertions that cannot be put porward honestly. I think
that as is usual in this newsgroups, there's going to be people that
actually know what they are talking about (and even better, experienced)

when referring to a language that is not their favorite.
  If you have references to articles of the sort, that will be useful,
too.
  Note that I've not listed comp.lang.tcl for increased productivity,
and to avoid starting a flame war. Hopefully some misconceptions
will be filtered down here, and _then_, the summary can be presented
in that newsgroup for their defense.

Thanks in advance,

From: Laurent POINTAL
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <375f92b4.618467559@news.u-psud.fr>
[note Follow-up to: set to comp.lang.python]

On Thu, 10 Jun 1999 11:17:59 +0200, Fernando Mato Mira
<········@iname.com> wrote:

for Python vs Tcl
>:   If you have references to articles of the sort, that will be useful,
>: too.

See http://www.cwi.nl/~sjoerd/PythonVsTcl.html

I remeber having seen an article of a guy explaining why he switched
from Tcl to Python for a large project... but I loose the URL.

A+

Laurent.

---
Laurent POINTAL - CNRS/LURE - Service Informatique Experiences
Tel/fax: 01 64 46 82 80 / 01 64 46 41 48
email  : ·······@lure.u-psud.fr  ou  ········@planete.net 
From: Cameron Laird
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <7jo8ej$gnp$1@Starbase.NeoSoft.COM>
In article <·················@iname.com>,
Fernando Mato Mira  <········@iname.com> wrote:
>Hello,
>
>  I'm trying to collect a list of all the _current_ issues making tcl
>a bad language choice. I'd like concrete examples, and not just
			.
			.
			.
I don't entirely understand your intent.  <URL:http://
starbase.neosoft.com/~claird/comp.lang.tcl/fmm.html>
details confusions that persistently arise in use of
Tcl.  Perhaps that will serve you.

Please give a concrete example of a concrete example.
Commitment to PalmOS for your deliverable is one of
the first issues that comes to my mind; in that case,
Tcl is "a bad language choice", because it's not cur-
rently available for PalmOS.  Is that the sort of
thing you have in mind?
-- 

Cameron Laird           http://starbase.neosoft.com/~claird/home.html
······@NeoSoft.com      +1 281 996 8546 FAX
From: Ian Wild
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <375FA62E.CCEF5079@cfmu.eurocontrol.be>
Fernando Mato Mira wrote:
 
>   I'm trying to collect a list of all the _current_ issues making tcl
> a bad language choice. I'd like concrete examples,

Without knowing what you're choosing it FOR, how
can anyone legitimately say it's a bad choice?
For some problem domains it might well be ideal.
(I mean, it's theoretically possible that, in some
parallel universe, there's a even problem for which
C++ is the ideal choice.)

>   Note that I've not listed comp.lang.tcl for increased productivity,
> and to avoid starting a flame war.

Yeah - right.  And no Tcl users ever read here?
From: Fernando Mato Mira
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <375FB333.5054A4AC@iname.com>
Ian Wild wrote:

> Fernando Mato Mira wrote:
>
> >   I'm trying to collect a list of all the _current_ issues making tcl
> > a bad language choice. I'd like concrete examples,
>
> Without knowing what you're choosing it FOR, how
> can anyone legitimately say it's a bad choice?

Choosing for nothing in particular. It's mainly
a language design question (syntax/semantics).
Although if there're other kinds of problems when
trying to use it in the realm it was designed for, that
would also be interesting.

> >   Note that I've not listed comp.lang.tcl for increased productivity,
> > and to avoid starting a flame war.
>
> Yeah - right.  And no Tcl users ever read here?

Obviously not. The idea was avoid the usual `Why does XYZ suck' flame
bait on comp.lang.XYZ as far as possible, and not irritate and waste XYZ
users' time on issues that some ABC user will point out as false.

There's some tcl lawyer close to me. That's why I did not ask about
the advantages. But nobody knows everything, so in order to make answers
easier to catalogue, I suggest starting another one, "Why is tcl better"
for that.

Thank you for your help,

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

www.csem.ch      www.vrai.com     ligwww.epfl.ch/matomira.html
From: Paul Duffin
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <375FD703.C6D@mailserver.hursley.ibm.com>
Fernando Mato Mira wrote:
> 
> Hello,
> 
>   I'm trying to collect a list of all the _current_ issues making tcl
> a bad language choice. I'd like concrete examples, and not just
> vague assertions that cannot be put porward honestly. I think
> that as is usual in this newsgroups, there's going to be people that
> actually know what they are talking about (and even better, experienced)
> 
> when referring to a language that is not their favorite.
>   If you have references to articles of the sort, that will be useful,
> too.
>   Note that I've not listed comp.lang.tcl for increased productivity,
> and to avoid starting a flame war. Hopefully some misconceptions
> will be filtered down here, and _then_, the summary can be presented
> in that newsgroup for their defense.
> 

I will start by saying that your choice of title and opening statement
was bad and certainly not conducive to a reasoned debate about the
pros and cons of Tcl.

What you are going to end up with from this sort of article is a list of
outdated problems from people who have not touched it for years, plus
a lot of myths and possibly mingled with a few nuggets of useful 
information.

Whether the choice of language is a good or bad idea depends entirely on
the context. i.e. environment and job to be done.

You cannot avoid taking into account the context even if you only look
at the language from a semantic / syntactic view point.

-- 
Paul Duffin
DT/6000 Development	Email: ·······@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880
From: Fernando Mato Mira
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <375FEC11.FD20EDE6@iname.com>
Paul Duffin wrote:

> Whether the choice of language is a good or bad idea depends entirely on
> the context. i.e. environment and job to be done.
>
> You cannot avoid taking into account the context even if you only look
> at the language from a semantic / syntactic view point.

OK. Let's drop the word `choice'. Why do people think tcl is a bad
language then, strictly from a _design_ viewpoint? Let's assume
imperative languages are OK (responses like "it's not declarative"
are obvious and uninteresting and do not help comparing it to other
imperative languages).
From: Paul Duffin
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <3760FAE1.373B@mailserver.hursley.ibm.com>
Fernando Mato Mira wrote:
> 
> Paul Duffin wrote:
> 
> > Whether the choice of language is a good or bad idea depends entirely on
> > the context. i.e. environment and job to be done.
> >
> > You cannot avoid taking into account the context even if you only look
> > at the language from a semantic / syntactic view point.
> 
> OK. Let's drop the word `choice'. Why do people think tcl is a bad
> language then, strictly from a _design_ viewpoint? Let's assume
> imperative languages are OK (responses like "it's not declarative"
> are obvious and uninteresting and do not help comparing it to other
> imperative languages).

Obviously I don't it has a few holes in it and some things could be
improved but I don't consider it a "bad" language.

-- 
Paul Duffin
DT/6000 Development	Email: ·······@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880
From: Lars Marius Garshol
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <wk909syqr4.fsf@ifi.uio.no>
* Fernando Mato Mira
|
| I'm trying to collect a list of all the _current_ issues making tcl
| a bad language choice. 

You can find three interesting articles on this at

<URL: http://itrc.uwaterloo.ca/~papresco/tcl/>

--Lars M.
From: Fernando Mato Mira
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <375FF969.C879B4CD@iname.com>
Lars Marius Garshol wrote:

> * Fernando Mato Mira
> |
> | I'm trying to collect a list of all the _current_ issues making tcl
> | a bad language choice.
>
> You can find three interesting articles on this at
>
> <URL: http://itrc.uwaterloo.ca/~papresco/tcl/>

Thanks. But the Sah article is not accessible,
and his homepage makes no reference to it.

Regarding the Stallman article, it's a quite vague,
and it's not sure one can extrapolate from their TECO experience
to Tcl.

About the Connoly one, the namespace issue seems to
be solved by [incr Tcl]. But what about that "interpreted
multiple times"? Is it just an efficiency issue, or a semantic
nightmare (maybe both)?

What about dynamic scoping?

BTW, I just found:

http://www.vanderburg.org/~glv/Tcl/war/
http://www.vanderburg.org/~glv/Tcl/war2/
From: Cameron Laird
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <7jp0gm$fjd$1@Starbase.NeoSoft.COM>
In article <·················@iname.com>,
Fernando Mato Mira  <········@iname.com> wrote:
			.
			.
			.
>About the Connoly one, the namespace issue seems to
>be solved by [incr Tcl]. But what about that "interpreted
>multiple times"? Is it just an efficiency issue, or a semantic
>nightmare (maybe both)?
			.
			.
			.
It's a different, but no less defensible, choice for
quoting rules than the one LISP made.
-- 

Cameron Laird           http://starbase.neosoft.com/~claird/home.html
······@NeoSoft.com      +1 281 996 8546 FAX
From: Bob Techentin
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <37601668.D9105225@mayo.edu>
These flame wars are more than five years old.  Tcl has had namespaces
and a byte-code compiler for years.

If you want "current" issues, you might just read comp.lang.tcl, or the
"frequently made mistakes" available from the FAQs at
http://www.tclfaq.wservice.com/tcl-faq/  You'll find complaints about
commenting out blocks of code and accidental conversions to octal.

Fernando Mato Mira wrote:
> 
> Lars Marius Garshol wrote:
> 
> > * Fernando Mato Mira
> > |
> > | I'm trying to collect a list of all the _current_ issues making tcl
> > | a bad language choice.
> >
> > You can find three interesting articles on this at
> >
> > <URL: http://itrc.uwaterloo.ca/~papresco/tcl/>
> 
  [snip]
> 
> http://www.vanderburg.org/~glv/Tcl/war/
> http://www.vanderburg.org/~glv/Tcl/war2/

-- 
Bob Techentin                                  ················@mayo.edu
Mayo Foundation                                           (507) 284-2702
Rochester MN, 55905 USA   http://www.mayo.edu/sppdg/sppdg_home_page.html
From: Fernando Mato Mira
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <3760E130.7456447@iname.com>
Bob Techentin wrote:

> These flame wars are more than five years old.  Tcl has had namespaces
> and a byte-code compiler for years.

I know that. But I see some serious things there (the `call by name' issue,
for example) that give me the impression must be still around unless
the semantics have gone through a major change.

I would cut this thread right here before someone comes up
with some myth. There's enough work for debunkers there.

Thanks,
From: Paul Duffin
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <3760FA1F.7BCD@mailserver.hursley.ibm.com>
Fernando Mato Mira wrote:
> 
> Bob Techentin wrote:
> 
> > These flame wars are more than five years old.  Tcl has had namespaces
> > and a byte-code compiler for years.
> 
> I know that. But I see some serious things there (the `call by name' issue,
> for example) that give me the impression must be still around unless
> the semantics have gone through a major change.
> 
> I would cut this thread right here before someone comes up
> with some myth. There's enough work for debunkers there.
> 
> Thanks,

Tcl does not have 'call by name' semantics.
In fact its calling semantics are remarkably like C's.

    C only supports call by value
    Tcl only supports call by value

    In C if you want to pass a "reference" you pass a pointer
    In Tcl if you want to pass a "reference" you pass a variable name

"Call by name" has some very particular characteristics the main one
being that you cannot implement "swap". I can assure you that you can
write a swap function in Tcl.

	proc swap {&a &b} {
	    upvar ${&a} a
	    upvar ${&b} b

	    set t $a
	    set a $b
	    set b $t
	}

-- 
Paul Duffin
DT/6000 Development	Email: ·······@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880
From: Fernando Mato Mira
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <3761021C.8C029142@iname.com>
Paul Duffin wrote:

>     In Tcl if you want to pass a "reference" you pass a variable name

I was refering to this, hence the quotes.
From: Paul Duffin
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <37610395.6799@mailserver.hursley.ibm.com>
Fernando Mato Mira wrote:
> 
> Paul Duffin wrote:
> 
> >     In Tcl if you want to pass a "reference" you pass a variable name
> 
> I was refering to this, hence the quotes.

Then I can assure you that "dynamic scoping" is not a problem.

-- 
Paul Duffin
DT/6000 Development	Email: ·······@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880
From: Hartmann Schaffer
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <mqg83.23803$%65.45559@tor-nn1.netcom.ca>
In article <·············@mailserver.hursley.ibm.com>,
	Paul Duffin <·······@mailserver.hursley.ibm.com> writes:
> ...
> "Call by name" has some very particular characteristics the main one
> being that you cannot implement "swap". I can assure you that you can

This is news to me.  Afair, "call-by-name" was the term for the Algol60
style parameter mechanism, which essentially required each argument
passed by a parameterless function returning a pointer to the passed
value.  Parameter swapping  (and a few pretty usually pointless tricks
like "Jensen's device"(?)) were quite possible.

> ...

Hartmann Schaffer
From: Paul Duffin
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <3760F816.6B53@mailserver.hursley.ibm.com>
Fernando Mato Mira wrote:
> 
> Lars Marius Garshol wrote:
> 
> > * Fernando Mato Mira
> > |
> > | I'm trying to collect a list of all the _current_ issues making tcl
> > | a bad language choice.
> >
> > You can find three interesting articles on this at
> >
> > <URL: http://itrc.uwaterloo.ca/~papresco/tcl/>
> 
> Thanks. But the Sah article is not accessible,
> and his homepage makes no reference to it.
> 
> Regarding the Stallman article, it's a quite vague,
> and it's not sure one can extrapolate from their TECO experience
> to Tcl.
> 
> About the Connoly one, the namespace issue seems to
> be solved by [incr Tcl]. But what about that "interpreted
> multiple times"? Is it just an efficiency issue, or a semantic
> nightmare (maybe both)?
> 
> What about dynamic scoping?
> 

Dynamic scoping I assume describes the mechanism that Tcl uses
to pass references through to procedures, namely that the calling
procedure passes the name of the variable and the called procedure
creates a link from its stack frame back to the calling procedures
stack frame.

If this is the case then it is just not a problem, unless you use
it badly which of course could be said of just about any programming
construct from "goto" to "multiple inheritance".

Obviously some built in support for passing references would be nice
but the BIG advantage that Tcl has over just about every other language
apart from Lisp is its ability to morph itself (which of course can
also be abused) so it is possible to do this in Tcl itself.

> BTW, I just found:
> 
> http://www.vanderburg.org/~glv/Tcl/war/
> http://www.vanderburg.org/~glv/Tcl/war2/

As with most of these articles they are out of date and the authors
tend to have (although not all) an agenda of their own which REQUIRES
that they prove Tcl (or whatever language they are 'analysing') is 
"bad".

Take for instance the Connolly article.
	"Tcl has one great big huge namespace"
		8.0 introduced support for namespaces

	"Tcl code is interpreted multiple times during the execution of
	 a program. There is no intermediate form as in Python and Perl"
		8.0 introduced a byte compiler

The Stallman article written in 1994 is also way out of date and 
adversely affected by his agenda.

Also considering his complaints about Tcl's syntax I was amazed to find
that he chose Lisp because if you replace the '() with {} and replace 
all other () with newlines you end up with a Tcl program (almost).

-- 
Paul Duffin
DT/6000 Development	Email: ·······@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880
From: Michael P. Reilly
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <mtU73.2731$nn.808830@news.shore.net>
In comp.lang.python Fernando Mato Mira <········@iname.com> wrote:
: Hello,

:   I'm trying to collect a list of all the _current_ issues making tcl
: a bad language choice. I'd like concrete examples, and not just
: vague assertions that cannot be put porward honestly. I think
: that as is usual in this newsgroups, there's going to be people that
: actually know what they are talking about (and even better, experienced)

: when referring to a language that is not their favorite.
:   If you have references to articles of the sort, that will be useful,
: too.
:   Note that I've not listed comp.lang.tcl for increased productivity,
: and to avoid starting a flame war. Hopefully some misconceptions
: will be filtered down here, and _then_, the summary can be presented
: in that newsgroup for their defense.

I won't go into too many details, it was on an older version of Tcl.
But some years ago, I played around with making C library wrappers
(before SWIG was around) so the developers could write Tcl test scripts
for their libraries.

The problem was that null bytes ('\000') we frequently used in the
code, and Tcl (at the time) could not handle null bytes.  I abandoned
the proof-of-concept project for that reason.  I did have a little
following of developers who were looking forward to that functionality
tho.

I believe that current releases of Tcl can handle null bytes, but I
have not verified that.

In general, the lack of complex data structures is what I find to be
most troublesome in the Tcl language itself.  Beyond lists and
associative arrays (hashes), you have numbers and strings.  The
language makes it convenient to pack these (split, join, etc.), but not
always to utilize them (array names, etc.).  And evaluation is
sometimes difficult to deal with as part of the language.

But for its problem set, I find Tcl to be flexible, quick and easily
extensible (in C or Tcl).

  -Arcege
From: Cameron Laird
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <7jp5lp$jo1$1@Starbase.NeoSoft.COM>
In article <····················@news.shore.net>,
Michael P. Reilly <······@shore.net> wrote:
			.
			.
			.
>I believe that current releases of Tcl can handle null bytes, but I
>have not verified that.
Yes.  Tcl8.0 and after handle null bytes.
			.
			.
			.
-- 

Cameron Laird           http://starbase.neosoft.com/~claird/home.html
······@NeoSoft.com      +1 281 996 8546 FAX
From: Paul Duffin
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <3760FA78.63AA@mailserver.hursley.ibm.com>
Cameron Laird wrote:
> 
> In article <····················@news.shore.net>,
> Michael P. Reilly <······@shore.net> wrote:
>                         .
>                         .
>                         .
> >I believe that current releases of Tcl can handle null bytes, but I
> >have not verified that.
> Yes.  Tcl8.0 and after handle null bytes.
>                         .
>                         .
>                         .

Although 8.0 did/does have some holes in its null byte support.

-- 
Paul Duffin
DT/6000 Development	Email: ·······@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880
From: Tom Cloney
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <z%Q93.4399$5E4.36952@news2.randori.com>
>   I'm trying to collect a list of all the _current_ issues making tcl
> a bad language choice...

Well, the troll aside, I do have quite a lot of experience with Tcl. Among
other things, I've written a workflow system on the Macintosh for generating
technical book catalogs using a combination of a relational database (4th
Dimension), image processing applications (Photoshop, NIH Image), page
layout and database publishing software (FrameMaker MIF) and other apps. Tcl
was used extensively as glue for doing things like process control and
analyzing Encapsulated Postscript files. The Tcl I used is the one embedded
in Pete Keleher's Alpha text editor, which is a real joy to use. I wish we
had something like it on NT. I've also used standalone versions of Tcl with
and without Tk. I worked with it a lot from about 1992 - 1996, writing many
useful apps. I've kept an eye on the language since then, and while I'm no
longer very Tclish, I reckon my basic take is still valid.

My opinions are, of course, shaped by the way I work. I lean towards
practical applications that one person can write and maintain and still have
a life. Most of the time I find myself practicing the Mad Max
post-apocalyptic school of programming, that is, cobbling together
interesting artifacts that come my way from both commercial and
non-commercial sources. I'm lazy -- I try to write only what I have to, and
then I look for the easiest tools to use to do it. I'm a businessman, so I'm
always balancing cost, productivity, and performance. I'm also aware that an
attractive solution may carry many hidden costs. I'm not going to get into
much academic hair-splitting here. For my purposes I judge language
environments by how easy it is to get things done in them, not by whether
they have a recursively bi-directed optimizing monkee gland compiler. YMMV.

Since the late 60's I've done practical programming in over 60 languages,
from FORTRAN, TECO, and microcode to Java, Python, and *Lisp, with many fun
stops in between (pause for chest-thumping and vine-swinging ;>), which
either makes me experienced or a fossil, depending on your point of view.
That said, here's my take on Tcl.


What I like:

Very readable syntax. A great language for writing more or less
self-documenting "dumb" code that you can come back 6 months or a year later
and still understand and modify. This is hard to overemphasize: clever
things _will_ be forgotten!

It's super when embedded in a text editor. Alpha is a great example.

It's a very nice hackery language. You can just whack away at things until
they do what you want. You don't have to be feeling sharp and clever on days
when you use it.

The language itself is pretty stable, that is, it doesn't usually crash in
bad ways.

It's one of the better languages for text processing. Not as nice as Perl,
but pretty darn good. Good regexp support. Lots of easy and elegant string
munging built in.

Support for lists, while not deep, is elegant and simple as far as it goes.
I don't like it when languages make list operations a big cumbersome deal,
so I appreciate Tcl's elegance here.

Support for hash tables (associative arrays, whatever...) is also elegant.

These three things: clean support for lists, hash tables, and regular
expressions are enough in themselves to make a language attractive. They
just make life much easier for a practical programmer.

GUI support via Tk is nice. It's a bit ideosyncratic, but good for many
things. It's not shrinkwrap-quality stuff, but think of all the great
languages whose inexpensive implementations are crippled by having little,
if any, support for GUI (Perl until recently), produce GUIs that feel slow
and clunky (Java), or make it cumbersome (like the joys of COM/IDL).

Wiser folk than I have said a good language should make doing simple things
simple. Tcl succeeds in this.

Good support for file system ops.

Straightforward interfaces to C etc. are a good thing.

Intangible fun factor. Tcl puts you in a good mood. It's easy. You feel like
you're cheating. You concentrate on the problem domain. You still feel good
when you look at the code six months later.


Now the cold slimy part:

Tcl scales very badly. All the same things in Tcl that make simple things
simple make complex things hard. Tcl is broad and shallow (which is not
always a bad thing). List structure doesn't really scale. There is no OOP
support to speak of, and although various people have hacked quick and dirty
examples, it's not something you would really want to build on. The very
brainlessness of Tcl is part of its appeal, but this is part of the price.
This is a _procedural_ language, which is actually nice on days when you are
too fuzzed out to think like a computer professional. It's not CLOS or
Eiffel, folks. It's not even Java.

The cute hacks that make string munging kind of cool can also be confusing.
You tend to spend a fair amount of time (by Tcl standards) finding subtle
bugs in the way you expressed complex string concatenations and such. It's
not that the language is buggy in this regard. The rules are relatively
simple. But the subtleties are hard to keep in mind. Tcl makes string
processing so easy that you tend to quickly give yourself enough rope to
hang yourself with. Easy debugging takes some of the sting out.

Tcl is slow. Oh, I know that's relative. For many applications it will be
fine. But complex parsing on large amounts of text can really drag. In one
application I needed to parse FrameMaker MIF files. These are SGML-like
ASCII files that often stretch to 600k or more, and which give FrameMaker a
lot of its power as a database publishing platform. Tcl was dog-slow. Perl
was about an order of magnitude faster than Tcl. C++ using the STL was a bit
faster than Perl, but still distressingly slow. I ended up using "cheating
C++", which is C++ with a lot of C standard library calls in it. The C was
about another order of magnitude faster than Perl. Tcl is great for nabbing
some text out of a file and doing some clever things with it (like nipping
the image size data out of an EPS file), but a cruncher it's not.

Perl can be much better for industrial-strength text processing. Perl has
better regexp handling than Tcl, in fact it's usually held up as the
standard by which other regular expression packages are judged. Perl is much
faster than Tcl. Perl 5 has rudimentary OOP support, which is a lot better
than nothing and allows Perl to scale in ways Tcl can't. The comparisons
with Perl are important because Perl does a lot of the same things Tcl does
and more. For a long time the dilemma was that Perl was the better language,
but Tcl had a GUI. Now Perl has a Tk interface (I haven't used Tk from Perl,
so I can't vouch for its elegance). After a while, as I developed more
complex applications in the languages, I found myself abandoning Tcl in
favor of Perl because of the performance and scalability. Perl code lacks
the beautiful brainless stickiness of Tcl, though. Perl is a "clever"
language, with what many would describe as "line noise" syntax. Cleverness
is dreadful when you have to look at it six months later. Tcl is the glory
of "stupid" programming, which I lean towards whenever possible. But it will
drive you crazy the minute you need speed or want to encapsulate something.

Tcl, Perl, and Python all hold out the promise of transcending the speed
problem via extensions written in C or another compiler language. This is
fine as far as it goes, but in the real world it's often difficult to fully
encapsulate speed-critical bits in separate modules (this could be the topic
of a whole thread). It's also somewhat complicated. Tcl makes it as easy as
anybody, but by the time you are organizing your work to the point where
you're designing a full component architecture, you're probably going to
find yourself thinking about using high-level compiler languages that let
you keep it all under one roof.

Tk ports are slow to arrive on some platforms and are buggy for a while. It
took years for heroic volunteers to get a workable Tk on the Mac. I think
Tcl helped show the way, but many of its enthusiasts have drifted away as
more alternatives have become available.

If you want to grind text, why not use Perl? If you want a slow, essentially
free hacking language with all the features of Tcl and very good OOP
support, why not use Python? And if you want a faster "scripting" language
based on the "Boy in the Bubble"* architecture, with built-in GUI, much
wider support, and a religion, there's always the J-word.

* Baby with the baboon heart sold separately.

-Tom
From: Marco Antoniotti
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <lw3dzrn5kt.fsf@copernico.parades.rm.cnr.it>
"Tom Cloney" <····@viadoc.com> writes:

	...
> 
> It's super when embedded in a text editor. Alpha is a great example.
> 

Emacs is a great example :)

Cheers

Marco

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Tom Cloney
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <8VZ93.4602$5E4.56699@news2.randori.com>
> > It's super when embedded in a text editor. Alpha is a great example.
> >
>
> Emacs is a great example :)

Yes, I've often thought of Alpha as a sort of Tcl-based Emacs. Alpha felt a
bit snappier and less burdened with history, though. Emacs Lisp is very
powerful when you get into it. I used to hack it quite a bit on my DOS
laptop, and way before that in ZetaLisp. But when I use Emacs I feel like
I'm definitely going to another planet and leaving the normal OS and apps
behind. A lot of stuff in there was developed long before GUIs were common.
Tcl embedded in a more modern application can give similar extensibility
while preserving a modern look and feel for those times when you don't need
the whole Emacs cultural heritage. Indeed, I think Tcl is ideal for
extending a text processor, since most people never _deeply_ hack that sort
of thing. It's an example of where Tcl's easy-reading "brainless" syntax is
very appropriate. The learning curve is very shallow. A great customizing
language.

I still use Emacs from time to time, though. Its source code formatting
hacks and foreign compiler integration are very good and it has hooks for
languages that haven't even been invented yet. Also, if you reverse your
power cord and turn your monitor upside down Emacs prints out "TECO is
dead".

-Tom
From: Klaus Schilling
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <87r9nbjlib.fsf@home.ivm.de>
"Tom Cloney" <····@viadoc.com> writes:

> > > It's super when embedded in a text editor. Alpha is a great example.
> > >
> >
> > Emacs is a great example :)
> 
> Yes, I've often thought of Alpha as a sort of Tcl-based Emacs.

Does Alpha require pixel-graphics or can it be run on a text-only 
console, which is possible for the GNU Emacs?

Klaus Schilling
From: Tom Cloney
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <_Q8a3.8663$5E4.75114@news2.randori.com>
Klaus Schilling <···············@home.ivm.de> wrote in message
···················@home.ivm.de...
> "Tom Cloney" <····@viadoc.com> writes:

> Does Alpha require pixel-graphics or can it be run on a text-only
> console, which is possible for the GNU Emacs?

Alpha requires a GUI, and actually had some simple GUI functionality built
in before Tk became available on the Mac, such as list pickers, simple
button dialogs, and so on.

My point is that the text-only capabilities of Emacs (which are part of what
make Emacs so transportable) also impose some lowest-common-denominator
baggage on it. I'm certainly not trying to warm up that tired old flame war
about "which editor is best". Emacs and Alpha are both very good in
different, but partially overlapping ways. There are plenty of other good
editors out there, each with its own specialized advantages. What I was
getting at is that Tcl (like Emacs Lisp) is a nice language for embedding in
an editor to provide customization. Perl would also be a cool choice. Like
Emacs Lisp, it might be seen as a bit more powerful than Tcl, but would
probably be a little harder for occasional users to learn and maintain.

-Tom
From: Klaus Schilling
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <87zp1zk9n8.fsf@home.ivm.de>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:

> "Tom Cloney" <····@viadoc.com> writes:
> 
> 	...
> > 
> > It's super when embedded in a text editor. Alpha is a great example.
> > 
> 
> Emacs is a great example :)

Exactly! And it will be a greater example once it will use guile,
the ultimate scripting language.

Klaus Schilling
From: Fernando D. Mato Mira
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <37692021.6CC21569@acm.org>
Clemens Heitzinger wrote:

> > Exactly! And it will be a greater example once it will use guile,
> > the ultimate scripting language.
>
> And it will be an even greater example once it will be based on CL,
> the ultimate programming language.  ;-)

Tell me how to `put the big on the small' and the magic will follow..

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

www.csem.ch      www.vrai.com     ligwww.epfl.ch/matomira.html
From: Fernando D. Mato Mira
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <37692679.689D49F6@acm.org>
"Fernando D. Mato Mira" wrote:

> Tell me how to `put the big on the small' and the magic will follow..

Oh, yes. RMS took care of `that'. Who said he was anti-CL? ;->

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

www.csem.ch      www.vrai.com     ligwww.epfl.ch/matomira.html
From: Marco Antoniotti
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <lwvhcmhhp8.fsf@copernico.parades.rm.cnr.it>
Clemens Heitzinger <········@rainbow.studorg.tuwien.ac.at> writes:

> Klaus Schilling <···············@home.ivm.de> writes:
> 
> > Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> > =
> 
> > > "Tom Cloney" <····@viadoc.com> writes:
> > > > =
> 
> > > > It's super when embedded in a text editor. Alpha is a great example.
> > > =
> 
> > > Emacs is a great example :)
> > =
> 
> > Exactly! And it will be a greater example once it will use guile,
> > the ultimate scripting language.
> 
> And it will be an even greater example once it will be based on CL,
> the ultimate programming language.  ;-)
> 

How true!

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Klaus Schilling
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <873dzq3ciw.fsf@home.ivm.de>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:

> Clemens Heitzinger <········@rainbow.studorg.tuwien.ac.at> writes:
> 
> > Klaus Schilling <···············@home.ivm.de> writes:
> > 
> > > Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> > > =
> > 
> > > > "Tom Cloney" <····@viadoc.com> writes:
> > > > > =
> > 
> > > > > It's super when embedded in a text editor. Alpha is a great example.
> > > > =
> > 
> > > > Emacs is a great example :)
> > > =
> > 
> > > Exactly! And it will be a greater example once it will use guile,
> > > the ultimate scripting language.
> > 
> > And it will be an even greater example once it will be based on CL,
> > the ultimate programming language.  ;-)
> > 

Common Lisp lacks support for termcap and the termios routines.
It can't be used as a base language for the emacs.

Klaus Schilling
From: Marco Antoniotti
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <lwd7yuy1la.fsf@copernico.parades.rm.cnr.it>
Klaus Schilling <···············@home.ivm.de> writes:

> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> 
> > Clemens Heitzinger <········@rainbow.studorg.tuwien.ac.at> writes:
> > 
> > > Klaus Schilling <···············@home.ivm.de> writes:
> > > 
> > > > Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> > > > =
> > > 
> > > > > "Tom Cloney" <····@viadoc.com> writes:
> > > > > > =
> > > 
> > > > > > It's super when embedded in a text editor. Alpha is a great example.
> > > > > =
> > > 
> > > > > Emacs is a great example :)
> > > > =
> > > 
> > > > Exactly! And it will be a greater example once it will use guile,
> > > > the ultimate scripting language.
> > > 
> > > And it will be an even greater example once it will be based on CL,
> > > the ultimate programming language.  ;-)
> > > 
> 
> Common Lisp lacks support for termcap and the termios routines.
> It can't be used as a base language for the emacs.
> 


Ok. Let's see.


(DEFPACKAGE "CL.TERMIO" (:use "COMMON-LISP")
  (:export "...."))

Shall I go on?  :)

Cheers

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: ·······@panix.com
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <ufemjaecj6.fsf@lemur.i-did-not-set--mail-host-address--so-shoot-me>
Klaus Schilling <···············@home.ivm.de> writes:

[...]

> Common Lisp lacks support for termcap and the termios routines.
> It can't be used as a base language for the emacs.

The editor Hemlock runs just fine within a plain old TTY.
From: Christopher R. Barry
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <87d7yuf9v3.fsf@2xtreme.net>
·······@panix.com writes:

> Klaus Schilling <···············@home.ivm.de> writes:
> 
> [...]
> 
> > Common Lisp lacks support for termcap and the termios routines.
> > It can't be used as a base language for the emacs.
> 
> The editor Hemlock runs just fine within a plain old TTY.

Actually Hemlock's TTY support has been broken for quite some time
now. Not that I particularly give a damn about TTY support in
it. Emacs has abandoned its heritage of painstakingly coded redisplay
algorithms that once allowed the editor to be usable over 300 baud
terminals. (Witness MULE.)

Ultimately TTY support will vanish in likewise fashion. Look at all
the stuff supported in X operation of GNU Emacs that is not supported
in TTY operation. It's obvious which mode of operation the developers
prefer. Zmacs, the editor of the Symbolics Lisp Machine, does not
support TTY operation, and it's been around since the early 80s. I
think when the one true successor or next-generation of Emacs based on
CL appears in 200x, TTY support will not be present at all.

I suspect some form of incomplete TTY support will be around for GNU
Emacs as long as Linux and HURD are around, only because of their tie
to the way of Unix and non-mandatory graphics capabilities that every
PC since 1986 has had.

Christopher
From: Tim Bradshaw
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <ey3674l4e9h.fsf@lostwithiel.tfeb.org>
* Christopher R Barry wrote:
> ·······@panix.com writes:
> Zmacs, the editor of the Symbolics Lisp Machine, does not
> support TTY operation, and it's been around since the early 80s. 

I think it does actually.

--tim
From: Christopher R. Barry
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <87zp1xe4l0.fsf@2xtreme.net>
Tim Bradshaw <···@tfeb.org> writes:

> * Christopher R Barry wrote:
> > ·······@panix.com writes:
> > Zmacs, the editor of the Symbolics Lisp Machine, does not
> > support TTY operation, and it's been around since the early 80s. 
> 
> I think it does actually.

How do you use it then? I can't find mention of TTY or terminal
support anywhere in the Genera docs and if I telnet to the XL1201 and
try to do :Select Activity Zmacs I just go into the debugger.

I'm pretty sure it doesn't, but the Zwei predecessor perhaps did. Zwei
is no longer considered an editor nor actually still one itself
though; It is now "a system on which other text editors are
implemented."[1]

Christopher

1. :Show Documentation Zwei Internals
From: Tim Bradshaw
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <ey3yahh2tq0.fsf@lostwithiel.tfeb.org>
* Christopher R Barry wrote:

> How do you use it then? I can't find mention of TTY or terminal
> support anywhere in the Genera docs and if I telnet to the XL1201 and
> try to do :Select Activity Zmacs I just go into the debugger.

I forgot you had a machine to hand (:-).  I was assuming that if you
telnetted then it would work, but I guess it doesn't.

--tim
From: Christopher C Stacy
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <x8l4sk2i420.fsf@world.std.com>
Zmacs only runs on the system console, not over tty/telnet-style connections.

However, the system input editor (which all applications normally use) provides
a subset of emacs commands, and that mostly works on everything.
From: Klaus Schilling
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <87d7yu10f7.fsf@home.ivm.de>
······@2xtreme.net (Christopher R. Barry) writes:

> ·······@panix.com writes:
> 
> > Klaus Schilling <···············@home.ivm.de> writes:
> > 
> > [...]
> > 
> > > Common Lisp lacks support for termcap and the termios routines.
> > > It can't be used as a base language for the emacs.
> > 
> > The editor Hemlock runs just fine within a plain old TTY.
> 
> Ultimately TTY support will vanish in likewise fashion. Look at all
> the stuff supported in X operation of GNU Emacs that is not supported
> in TTY operation.
> It's obvious which mode of operation the developers
> prefer.

Only fools prefer GUI mode which is obsolete junk.

> Zmacs, the editor of the Symbolics Lisp Machine, does not
> support TTY operation, and it's been around since the early 80s. I
> think when the one true successor or next-generation of Emacs based on
> CL appears in 200x, TTY support will not be present at all.

Then I'll have to start my own editor, which supports tty.

Klaus Schilling
From: Tim Bradshaw
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <ey3lndi5r91.fsf@lostwithiel.tfeb.org>
* Klaus Schilling wrote:

> Common Lisp lacks support for termcap and the termios routines.
> It can't be used as a base language for the emacs.

emacs lisp lacks support for for termcap and the termios routines.  It
can't be used as a base language for the emacs.

--tim
From: Klaus Schilling
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <87k8t211q1.fsf@home.ivm.de>
Tim Bradshaw <···@tfeb.org> writes:

> * Klaus Schilling wrote:
> 
> > Common Lisp lacks support for termcap and the termios routines.
> > It can't be used as a base language for the emacs.
> 
> emacs lisp lacks support for for termcap and the termios routines.  It
> can't be used as a base language for the emacs.

Irrelevant. Emacs Lisp is just an extension language, the base language 
for the GNU Emacs is of course C.

Klaus Schilling
From: Tim Bradshaw
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <ey34sk54e7n.fsf@lostwithiel.tfeb.org>
* Klaus Schilling wrote:
> Tim Bradshaw <···@tfeb.org> writes:
>> * Klaus Schilling wrote:
>> 
>> > Common Lisp lacks support for termcap and the termios routines.
>> > It can't be used as a base language for the emacs.
>> 
>> emacs lisp lacks support for for termcap and the termios routines.  It
>> can't be used as a base language for the emacs.

> Irrelevant. Emacs Lisp is just an extension language, the base language 
> for the GNU Emacs is of course C.

C lacks support for termcap and termios routines.  It can't be used as
a base language for the emacs.

Unless you write a library, cretin.

--tim
From: Stig Hemmer
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <ekvhfo5u5yw.fsf@kallesol.pvv.ntnu.no>
Klaus Schilling <···············@home.ivm.de> writes:
> > > Common Lisp lacks support for termcap and the termios routines.
> > > It can't be used as a base language for the emacs.
> > 
> > emacs lisp lacks support for for termcap and the termios routines.  It
> > can't be used as a base language for the emacs.
> 
> Irrelevant. Emacs Lisp is just an extension language, the base language 
> for the GNU Emacs is of course C.

C lacks support for termcap and the termios routines. It can't be used
as a base language for emacs.

Stig Hemmer,
Jack of a Few Trades.
From: Mike McDonald
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <7kdpvt$mjp$1@spitting-spider.aracnet.com>
In article <···············@kallesol.pvv.ntnu.no>,
	Stig Hemmer <····@pvv.ntnu.no> writes:
> Klaus Schilling <···············@home.ivm.de> writes:
>> > > Common Lisp lacks support for termcap and the termios routines.
>> > > It can't be used as a base language for the emacs.
>> > 
>> > emacs lisp lacks support for for termcap and the termios routines.  It
>> > can't be used as a base language for the emacs.
>> 
>> Irrelevant. Emacs Lisp is just an extension language, the base language 
>> for the GNU Emacs is of course C.
> 
> C lacks support for termcap and the termios routines. It can't be used
> as a base language for emacs.

  And since TCL uses the C versions, it can't either.

  Mike McDonald
  ·······@mikemac.com
From: Marco Antoniotti
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <lwpv2tjafd.fsf@copernico.parades.rm.cnr.it>
Klaus Schilling <···············@home.ivm.de> writes:

> Tim Bradshaw <···@tfeb.org> writes:
> 
> > * Klaus Schilling wrote:
> > 
> > > Common Lisp lacks support for termcap and the termios routines.
> > > It can't be used as a base language for the emacs.
> > 
> > emacs lisp lacks support for for termcap and the termios routines.  It
> > can't be used as a base language for the emacs.
> 
> Irrelevant. Emacs Lisp is just an extension language, the base language 
> for the GNU Emacs is of course C.
> 

Irrelevant. C is just an extension language, the base language for any
C application is the underlying assembly. :)

Cheers

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Fernando Mato Mira
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <376B9927.9D5FE2FA@iname.com>
Marco Antoniotti wrote:

> Irrelevant. C is just an extension language, the base language for any
> C application is the underlying assembly. :)

Which makes C an extension for both Lisp and Occam.
From: Fernando Mato Mira
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <376B998D.7FAD55FC@iname.com>
Fernando Mato Mira wrote:

> Marco Antoniotti wrote:
>
> > Irrelevant. C is just an extension language, the base language for any
> > C application is the underlying assembly. :)
>
> Which makes C an extension for both Lisp and Occam.

So Lisp is an extension of Lisp. QED (duh)
From: Russell Nelson
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <m2n1xsmh10.fsf@desk.crynwr.com>
>   I'm trying to collect a list of all the _current_ issues making tcl
> a bad language choice...

Because it necessarily parses strings.  Been there, done that, have
the scars to prove it.

-- 
-russ nelson <······@crynwr.com>  http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | can outdo them. Homeschool!
From: Paul Duffin
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <37776F1C.5656@mailserver.hursley.ibm.com>
Russell Nelson wrote:
> 
> >   I'm trying to collect a list of all the _current_ issues making tcl
> > a bad language choice...
> 
> Because it necessarily parses strings.  Been there, done that, have
> the scars to prove it.
> 

What do you mean by "necessarily parses strings" ?


-- 
Paul Duffin
DT/6000 Development	Email: ·······@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880
From: Greg Ewing
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <37783AEC.931EC3C9@compaq.com>
Paul Duffin wrote:

> Russell Nelson wrote:

> > Because it necessarily parses strings.

> What do you mean by "necessarily parses strings" ?

It's better than unnecessarily parsing
strings, I suppose! :-)

Greg
From: Paul Duffin
Subject: Re: Why is tcl broken?
Date: 
Message-ID: <37776F02.6EEA@mailserver.hursley.ibm.com>
Tom Cloney wrote:
> 
> >   I'm trying to collect a list of all the _current_ issues making tcl
> > a bad language choice...
> 
> Well, the troll aside, I do have quite a lot of experience with Tcl. Among
> other things, I've written a workflow system on the Macintosh for generating
> technical book catalogs using a combination of a relational database (4th
> Dimension), image processing applications (Photoshop, NIH Image), page
> layout and database publishing software (FrameMaker MIF) and other apps. Tcl
> was used extensively as glue for doing things like process control and
> analyzing Encapsulated Postscript files. The Tcl I used is the one embedded
> in Pete Keleher's Alpha text editor, which is a real joy to use. I wish we
> had something like it on NT. I've also used standalone versions of Tcl with
> and without Tk. I worked with it a lot from about 1992 - 1996, writing many
> useful apps. I've kept an eye on the language since then, and while I'm no
> longer very Tclish, I reckon my basic take is still valid.
> 
> My opinions are, of course, shaped by the way I work. I lean towards
> practical applications that one person can write and maintain and still have
> a life. Most of the time I find myself practicing the Mad Max
> post-apocalyptic school of programming, that is, cobbling together
> interesting artifacts that come my way from both commercial and
> non-commercial sources. I'm lazy -- I try to write only what I have to, and
> then I look for the easiest tools to use to do it. I'm a businessman, so I'm
> always balancing cost, productivity, and performance. I'm also aware that an
> attractive solution may carry many hidden costs. I'm not going to get into
> much academic hair-splitting here. For my purposes I judge language
> environments by how easy it is to get things done in them, not by whether
> they have a recursively bi-directed optimizing monkee gland compiler. YMMV.
> 
> Since the late 60's I've done practical programming in over 60 languages,
> from FORTRAN, TECO, and microcode to Java, Python, and *Lisp, with many fun
> stops in between (pause for chest-thumping and vine-swinging ;>), which
> either makes me experienced or a fossil, depending on your point of view.
> That said, here's my take on Tcl.
> 
> What I like:
> 
> Very readable syntax. A great language for writing more or less
> self-documenting "dumb" code that you can come back 6 months or a year later
> and still understand and modify. This is hard to overemphasize: clever
> things _will_ be forgotten!
> 
> It's super when embedded in a text editor. Alpha is a great example.
> 
> It's a very nice hackery language. You can just whack away at things until
> they do what you want. You don't have to be feeling sharp and clever on days
> when you use it.
> 
> The language itself is pretty stable, that is, it doesn't usually crash in
> bad ways.
> 
> It's one of the better languages for text processing. Not as nice as Perl,
> but pretty darn good. Good regexp support. Lots of easy and elegant string
> munging built in.
> 
> Support for lists, while not deep, is elegant and simple as far as it goes.
> I don't like it when languages make list operations a big cumbersome deal,
> so I appreciate Tcl's elegance here.
> 
> Support for hash tables (associative arrays, whatever...) is also elegant.
> 
> These three things: clean support for lists, hash tables, and regular
> expressions are enough in themselves to make a language attractive. They
> just make life much easier for a practical programmer.
> 
> GUI support via Tk is nice. It's a bit ideosyncratic, but good for many
> things. It's not shrinkwrap-quality stuff, but think of all the great
> languages whose inexpensive implementations are crippled by having little,
> if any, support for GUI (Perl until recently), produce GUIs that feel slow
> and clunky (Java), or make it cumbersome (like the joys of COM/IDL).
> 
> Wiser folk than I have said a good language should make doing simple things
> simple. Tcl succeeds in this.
> 
> Good support for file system ops.
> 
> Straightforward interfaces to C etc. are a good thing.
> 
> Intangible fun factor. Tcl puts you in a good mood. It's easy. You feel like
> you're cheating. You concentrate on the problem domain. You still feel good
> when you look at the code six months later.
> 
> Now the cold slimy part:
> 
> Tcl scales very badly. All the same things in Tcl that make simple things
> simple make complex things hard. Tcl is broad and shallow (which is not
> always a bad thing). List structure doesn't really scale. There is no OOP
> support to speak of, and although various people have hacked quick and dirty
> examples, it's not something you would really want to build on. The very
> brainlessness of Tcl is part of its appeal, but this is part of the price.
> This is a _procedural_ language, which is actually nice on days when you are
> too fuzzed out to think like a computer professional. It's not CLOS or
> Eiffel, folks. It's not even Java.
> 

Actually since version 8.0 Tcl has scaled quite nicely thank you, 8.1 has
reduced the scalability of string operations due to a naive implementation
of Unicode / UTF8 support but that will be fixed soon.

> The cute hacks that make string munging kind of cool can also be confusing.
> You tend to spend a fair amount of time (by Tcl standards) finding subtle
> bugs in the way you expressed complex string concatenations and such. It's
> not that the language is buggy in this regard. The rules are relatively
> simple. But the subtleties are hard to keep in mind. Tcl makes string
> processing so easy that you tend to quickly give yourself enough rope to
> hang yourself with. Easy debugging takes some of the sting out.
> 
> Tcl is slow. Oh, I know that's relative. For many applications it will be
> fine. But complex parsing on large amounts of text can really drag. In one
> application I needed to parse FrameMaker MIF files. These are SGML-like
> ASCII files that often stretch to 600k or more, and which give FrameMaker a
> lot of its power as a database publishing platform. Tcl was dog-slow. Perl
> was about an order of magnitude faster than Tcl. C++ using the STL was a bit
> faster than Perl, but still distressingly slow. I ended up using "cheating
> C++", which is C++ with a lot of C standard library calls in it. The C was
> about another order of magnitude faster than Perl. Tcl is great for nabbing
> some text out of a file and doing some clever things with it (like nipping
> the image size data out of an EPS file), but a cruncher it's not.
> 

Tcl can be used to crunch stuff but you just have to be very careful how
you go about doing it. I have written a Tcl program to analyse the whole
Tcl source which is nearly 5MB and it did it very fast indeed.

> Perl can be much better for industrial-strength text processing. Perl has
> better regexp handling than Tcl, in fact it's usually held up as the

Tcl 8.1 now has the same (bar a few weird hacks) regular expression package
that Perl has.

> standard by which other regular expression packages are judged. Perl is much
> faster than Tcl. Perl 5 has rudimentary OOP support, which is a lot better
> than nothing and allows Perl to scale in ways Tcl can't. The comparisons

OOP support doesn't imply scalabity does it ?

> with Perl are important because Perl does a lot of the same things Tcl does
> and more. For a long time the dilemma was that Perl was the better language,
> but Tcl had a GUI. Now Perl has a Tk interface (I haven't used Tk from Perl,
> so I can't vouch for its elegance). After a while, as I developed more
> complex applications in the languages, I found myself abandoning Tcl in
> favor of Perl because of the performance and scalability. Perl code lacks
> the beautiful brainless stickiness of Tcl, though. Perl is a "clever"
> language, with what many would describe as "line noise" syntax. Cleverness
> is dreadful when you have to look at it six months later. Tcl is the glory
> of "stupid" programming, which I lean towards whenever possible. But it will
> drive you crazy the minute you need speed or want to encapsulate something.
> 

It sounds as though you are being a bit unfair with Tcl. You seem to invest
an awful lot of brainpower in Perl (not to deal with the problem but to
deal with the language) but you don't spend any on Tcl because it is so
simple. If you invested as much time learning how to program efficiently
in Tcl as you do in Perl you would soon be able to match performance.

> Tcl, Perl, and Python all hold out the promise of transcending the speed
> problem via extensions written in C or another compiler language. This is
> fine as far as it goes, but in the real world it's often difficult to fully
> encapsulate speed-critical bits in separate modules (this could be the topic
> of a whole thread). It's also somewhat complicated. Tcl makes it as easy as
> anybody, but by the time you are organizing your work to the point where
> you're designing a full component architecture, you're probably going to
> find yourself thinking about using high-level compiler languages that let
> you keep it all under one roof.
> 
> Tk ports are slow to arrive on some platforms and are buggy for a while. It
> took years for heroic volunteers to get a workable Tk on the Mac. I think
> Tcl helped show the way, but many of its enthusiasts have drifted away as
> more alternatives have become available.
> 
> If you want to grind text, why not use Perl? If you want a slow, essentially
> free hacking language with all the features of Tcl and very good OOP
> support, why not use Python? And if you want a faster "scripting" language
> based on the "Boy in the Bubble"* architecture, with built-in GUI, much
> wider support, and a religion, there's always the J-word.
> 


-- 
Paul Duffin
DT/6000 Development	Email: ·······@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880