Newsgroups: comp.lang.scheme,comp.lang.misc
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!travelers.mail.cornell.edu!news.tc.cornell.edu!caen!hearst.acc.Virginia.EDU!murdoch!elvis.med.Virginia.EDU!sdm7g
From: sdm7g@elvis.med.Virginia.EDU (Steven D. Majewski)
Subject: Re: Extension/Scripting language comparisons
X-Nntp-Posting-Host: elvis.med.virginia.edu
Message-ID: <DBK8HE.KD4@murdoch.acc.Virginia.EDU>
Followup-To: comp.lang.misc
Keywords: Scheme, Tcl, Perl
Sender: usenet@murdoch.acc.Virginia.EDU
Organization: University of Virginia
References: <3thlus$isi@hpbab.wv>
Date: Tue, 11 Jul 1995 16:29:38 GMT
Lines: 64
Xref: glinda.oz.cs.cmu.edu comp.lang.scheme:13095 comp.lang.misc:22261

In article <3thlus$isi@hpbab.wv>,
Joe Mueller <joemu@aardvark.mentorg.com> wrote:
>
>Some time ago there was a raging debate over the virtues of Tcl vs. Scheme
>as an extension/scripting language. Unfortunately I did not capture the
>major pros/cons at that time. Could someone send me a synopsys of the major points?
>

There are pointers to archives and material from that debat on my
Programming Languages Critiques Web Page at :
  <http://minsky.med.virginia.edu/sdm7g/LangCrit/>

( specifically, in:
<http://minsky.med.virginia.edu/sdm7g/LangCrit/Tcl/> 
 There are a selection of posts by Richard Stallman, John Ousterhout,
 Adam Sah and others, and pointers to Adam Sah's critiques and papers
 and to a more full archive of the discussion. ) 

Re: the comments in this thread that tcl's string substitution is easier
to understand than scheme's continuation and closures: 
   - string substitution may be a simple *concept*, but in practice, it
  is subtle and confusing when you can have several levels of 
  substitution - especially when some substitutions are explicit
  and other are implicit. 
  - excluding continuations, scheme's evaluation model is remarkably
  simple and unambiguous ( simpler that tcl IMHO ). ( Continuations
  are also simple in concept, but can get pretty baroque in practice. 
  In average use, I think you are more likely to manage to avoid the 
  baroque extremes of scheme continuations that you will be able to
  avoid strange side effects of string substitution. ) 



A string based language may be a good idea for a command language:
it avoids a lot of quoting and unquoting by making the defaults 
for commands simpler. That's clearly why tcl followed the unix shells
in that respect. However, this initial simplicity, which works fine
for commands and short scripts, tends to make things even more complex
in less simple programs. So I think it's important to consider what
sort of programs or scripts will be written in this language. 


  Tcl is good for what it was designed for, but we are seeing it 
being used for all sorts of things for which it wasn't designed 
and for which it is ill suited. Oh well: "When all you have is 
a hammer, everything starts to look like a nail!" 


Tcl is not really much less complex that scheme, and certainly not
any easier to understand. However, there *really* are some applications
where a string substitution language makes sense. Nathaniel Borenstein,
for example, chose SafeTcl to build his Enabled Mail system, after
having done an earlier attempt at the same sort of thing with 
AtomicMail - which was, I believe, a lisp based system. So I would
suggest you think quite a bit about the requirements and then actually
try prototyping in a couple of the more likely candidate languages. 



BTW: Another language to consider is Python - especially if a "user
friendly" syntax and an easy to learn language are requirements. 
See <http://www.python.org/>

[ Followup changed to comp.lang.misc and crossposted there. ] 
