[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 opiniom 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: * Tcl is a programmable programming language like Lisp, in both you can write new control structures, and more generally it's possible to specialize both the languages. But while in Lisp is usually needed to write macros, in Tcl you have to write normal procedures. * Lisp has types, more or less like Python and Ruby. For example in order to use a number as argument of a string manipulation function, there is to convert from one type to the other. * In Tcl serialization just happens for many types because almost everything has a string representation. You can write a Tcl list in a file just with: puts $fd $list. This is not possible in Lisp, where you need to perform serialization. * Lisp central data type is the list, while Tcl central data type is the string. Tcl also makes a lot of use of lists that are just special strings. In today's world, to have strings as base type is usually more useful, because many thinks like HTML, XML, Networking Protocols, are about strings more than they are about lists. To deal with strings in Lisp is not as natural as with Tcl. On the other side, Tcl lists features allow to exploit many programming paradigms used in Lisp. For example to convert a string into a list of characters, and manipulate it as a list when is more convenient. * The Tcl world is less fragmented. There aren't a big number of implementations of Tcl, and there is a bigger default library. * Tcl has built-in event-driven programming, integrated with the I/O library. To write complex networking programs with just what is provided in the core language is a joke. Please feel free to comment, expecially if you think some of the points are not fair.