Why you should not use Tcl 
Author Message
 Why you should not use Tcl


>Aside:  I suggest that criticisms about the durability of Tcl in larger
>projects be taken seriously, even by Tcl boosters (of which I am one).
>I remember when Pascal was proclaimed the one-true-language-for-everything.
>I also remember when C was criticized as being deficient for large projects.
>I think most people will agree that Tcl *does* have problems WRT larger
>projects.  But is that flaw terminal?

As a veteran python booster in the "language wars", I'll try to set a
precedent for candor and rational discussion in this thread ( if it's
not already too late! :-) by admitting that Python ain't perfect

It shares with tcl the problem/benefit of having a single widely
available implementation, which, in practice, IS the language
definition, rather than an independent description. ( Basic tcl -
the tcl described on John Osterhout's original paper has the
advantage of being much simpler, but is there actually much
written using only the base language ? )

Scheme, on the other hand, has lots of implementations - free and
commercial, and there has been a lot of research and progress on
better implementation. However - scheme has been around quite a
while ( +++ They've had time to discover and try to tackle some of the
problems that tcl folk are just starting to bump into. ) and ( --- )
it drags a lot of baggage with it that someone starting from scratch
would probably drop.

Dylan is an example of trying to do an object oriented scheme-like
language with the freedom to start over from scratch.
However - knowing RMS attitude concerning Apple - Dylan may not be
a favorite candidate for FSF support. Also, (IMHO) I'm not sure that
Dylan has "got it right". Dylan may be trying to do too much and be
all things to all programmers.

[ See Richard Gabriels paper on " ... how to win big ... " for an
 alternative view of "the next lisp" ]

Perl and Tcl on the other hand, started out to do one or two things
really well - were successful at that, and as a result are being asked
to expand their domain into areas they were not designed/intended for.
[ The same statement can be made in principle for scheme and Python,
 but, I think, less strongly, as I think both started out with a more
 general purpose "target". ]

The question, as someone else in this thread stated it, is - is it
worth the surgery to fix the problems, or is it better to take the
lessons learned and start over ?

[ I don't personally have an answer for this question! ]

-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center        C{*filter*}tesville,VA 22908 --
                 [ "Cheese is more macho?" ]

Sat, 15 Mar 1997 05:11:51 GMT  
 Why you should not use Tcl
|> John Ousterhout, in his post in this thread

|> | 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.

I think it is not necessarily the case that when some better language
comes along people will switch to it.  Just as with operating systems
there is huge momentum/inertia, and whatever gets established first
has the tendency to prevail regardless of competition that is actually better.

Wed, 26 Mar 1997 11:16:11 GMT  
 Why you should not use Tcl

> |> | 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.

Actually, I don't think many language designers argue about
something being better or not - usually it's the users that
do that.  At least not a-priori.
Darin Johnson

    This is the first time I've ever eaten a patient -- Northern Exposure

Sat, 29 Mar 1997 11:49:01 GMT  
 [ 4 post ] 

 Relevant Pages 

1. why TCL and why not TCL with JAVA

2. how to access prolog from tcl?(not using tcl/tk interface from prolog)

3. Why not using functional Types?

4. Why not using LOCALs in LOOPs ?

5. Why not using [] instead of () for array?

6. why Ada not used much in commercial server side development

7. Why does using threads not speed up things?

8. Why DDE not wrapped using prowrap?

9. Why is Lisp not more widely used?

10. Why was typed lambda calculus not used?

11. extensibility (was: Why you should not use Tcl)

12. Why you should not use Tcl


Powered by phpBB® Forum Software