SS 25Jan2005:
It's well known that many Lisp dialects, like Scheme, have features that Tcl does not have. For example first class continuations, automatic tail calls optimization, more speed. This page is instead my personal opinion about what in Tcl is better than in Lisp.
I used Scheme to write Web applications for some time before to switch to Tcl, mostly for the reasons below. Note that I like Lisp a lot, I'm a great fan of it. One reason why I like Tcl is that I find it similar to Lisp in some aspect, similar to what I enjoyed of Lisp, I mean.
This is my list of things I like more in Tcl over Lisp:
Please feel free to comment, expecially if you think some of the points are not fair.
--The #scheme room on irc.freenode.com responds thusly; comments please http://wiki.tcl.tk/13410
<Catfive>There are still people that use Tcl? <xerox>Ok, got it. <forcer>slack_tcl: Argument 1, Macros: Tcl represents everything as strings (formally). That makes optimization horrible, and requires a runtime interpreter. Argument 2, auto-type-conversion: Nice for small stuff, leads to annoying bugs in bigger programs. Argument 3, serialization: Use WRITE to serialize data structures. Argument 4, Strings: A list is a compound data type, a string is not compound, but needs a parser to be so; the basi <forcer>c data type of a language should be a compound type; Scheme has wonderful support for HTML/XML, because HTML/XML is not about strings, but about structure, which Scheme can represent very well. Argument 5, less fragmentation: True (whether that's a pro or con is subjective). Argument 6, event-driven programming: True; Tcl has a better standard library than R5RS; most scheme implementations have a good one as well, and using cont <forcer>inuations, event-driven programming can be abstracted away, which is even better than a basic foundation, which also can be implemented easily in Scheme. ;-) <forcer>``Years ago at an X conference in San Jose, Ousterhout gave a talk on Tcl/Tk. I came away from the talk thinking "Man, what a poorly implemented Lisp interpreter that is!" (Mike McDonald)''
RS HTMLXML is of course about strings, which express structure; and Tcl can work on strings perfectly, as well as on the expressed structures when represented as nested lists...
SS my replies:
In order to model the structure of HTML/XML a Tcl list is indeed more appropriate, but there are many other tasks when you need to work directly with the string: in this contexts variable/command interpolation, no type conversion, makes it a non problem. Scheme is truly generic, this makes it cool and ready to face every kind of problem in theory but there is a price for this: simpler problems are often more complex to solve in Scheme than in other languages with explicit support for such problems.
is very abstract. For example with non-blocking sockets you can write to a socket without to care at all if it is writable or not and Tcl will try in the background to check for write buffer availability to feed the data to the socket when possible. Also the after command makes Tcl one of the few languages that support the notion of time in the default library in a decent way. Btw I agree this are features not about the language itself but about the library that can implemented in many other languages.
About Tcl being a bad implementation of Lisp, I don't think so of course. Surely Lisp was in the mind of John Ousterhout, as he wrote in the usenix paper that was shipped with the first versions of Tcl. Note that many users here think that Lisp in general and Scheme in particulare is something of very interesting to look at. Many Lisp idioms, and bottom-up programming itself are the Tcl way to program too. Just Tcl tries to be more pratical for many of us, supporting at the same time a mix of functional, imperative and object oriented programming, similarly to Common Lisp. Also many real world problems are simpler to solve because of more support inside the language. Of course there are many things that may be better solved using Lisp, expecially when complex linked data structures are needed, or abstractions like continuations.