Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,comp.lang.misc,comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!news.duke.edu!concert!hearst.acc.Virginia.EDU!murdoch!elvis.med.Virginia.EDU!sdm7g
From: sdm7g@elvis.med.Virginia.EDU (Steven D. Majewski)
Subject: Re: Why you should not use Tcl
Message-ID: <Cwr9Jr.H35@murdoch.acc.Virginia.EDU>
Sender: usenet@murdoch.acc.Virginia.EDU
Organization: University of Virginia
References: <9409232314.AA29957@mole.gnu.ai.mit.edu> <3635a6$ang@apollo.west.oic.com> <366krq$c91@shore.shore.net>
Date: Mon, 26 Sep 1994 21:11:51 GMT
Lines: 59
Xref: glinda.oz.cs.cmu.edu gnu.misc.discuss:18307 comp.lang.tcl:19326 comp.lang.scheme:9925 comp.lang.misc:17859 comp.lang.dylan:2777

In article <366krq$c91@shore.shore.net>, Robert Withrow <witr@rwwa.com> wrote:
>
>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
either. 

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! ] 


-- Steve Majewski       (804-982-0831)      <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center        Charlottesville,VA 22908 --
		 [ "Cheese is more macho?" ] 

