---
created_at: '2017-10-29T06:46:44.000Z'
title: Advantages of Tcl over Lisp (2005)
url: https://wiki.tcl.tk/13410
author: tonyjstark
points: 75
story_text: 
comment_text: 
num_comments: 41
story_id: 
story_title: 
story_url: 
parent_id: 
created_at_i: 1509259604
_tags:
- story
- author_tonyjstark
- story_15578238
objectID: '15578238'
year: 2005

---
25Jan2005:

It's well known that many 

It's well known that many [Lisp](/1657) dialects, like [Scheme](/2254) ,
have features that Tcl does not have. For example first class
[continuation](/13232) s, automatic [tail call optimization](/1348) ,
more speed. This page is instead my personal opinion about what in Tcl
is better than in [Lisp](/1657)

I used 

I used [Scheme](/2254) to write Web applications for some time before to
switch to Tcl, mostly for the reasons below. Note that I like
[Lisp](/1657) a lot, I'm a great fan of it. One reason why I like Tcl is
that I find it similar to [Lisp](/1657) in some aspect, similar to what
I enjoyed of [Lisp](/1657) , I mean.

This is my list of things I like more in Tcl over 

This is my list of things I like more in Tcl over [Lisp](/1657)

  - Tcl is a programmable programming language like [Lisp](/1657), in
    both you can write new control structures, and more generally it's
    possible to specialize both the languages. But while in
    [Lisp](/1657) is usually needed to write macros, in Tcl you have to
    write normal procedures.
  - [Lisp](/1657) has types, more or less like [Python](/1395) and
    [Ruby](/1386). 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](/1657), where you need to perform serialization.
  - [Lisp](/1657) 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](/777),
    [XML](/1740), Networking Protocols, are about strings more than they
    are about lists. To deal with strings in [Lisp](/1657) is not as
    natural as with Tcl. On the other side, Tcl lists features allow to
    exploit many programming paradigms used in [Lisp](/1657). 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 so simple it's funny.

Please feel free to comment, especially if you think some of the points
are not fair.

Please feel free to comment, especially if you think some of the points
are not fair.

\--The \#scheme room on irc.freenode.com responds thusly; comments
please 

``` 
 <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)''
```

\--The \#scheme room on irc.freenode.com responds thusly; comments
please
[http://wiki.tcl.tk/13410![](/ext.png)](https://wiki.tcl.tk/13410)

[RS](/1683) [HTML](/777)/[XML](/1740) 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 [list](/440) s...
And lists are not just strings, at heart they are dynamic vectors of
references to objects, which again can be lists, or integers, or
doubles... but every object can be represented as a string, too.

What I like most about Tcl, compared to 

What I like most about Tcl, compared to [Lisp](/1657) , is the
simplification by unifying concepts:

  - **commands** work as functions, special forms, macros (well, sort
    of)
  - **lists** cover the uses of [Lisp](/1657) lists, vectors, arrays,
    structs...

my replies:

  - 1\) Optimization is not horrible but via dual-ported objects with a
    well defined semantic. Interpretation is not needed, actually Tcl8.x
    is byte-compiled. Also I feel shocked that [Scheme](/2254) people
    are talking about implementation details instead to talk about
    abstraction power ;) In Tcl metaprogramming is more abstract, you
    always requires Tcl procedures for every kind of work, being it a
    new control structure, or a procedure to sum two numbers. in
    [Lisp](/1657) there is less abstraction because to do some work you
    need to perform a source level transformation, for others you need a
    function.
  - 2\) In Tcl is less likely that auto conversion turns to bugs,
    because the auto conversion works checking that the format of the
    string is compatible with the destination type. This means that if I
    try to sum "12" with "foobar" there will be a runtime error because
    "foobar" is not a valid representation for an integer.
  - 3\) WRITE: nice abstraction, but you are requiring a layer that do
    the conversion like any other language where objects are
    semantically typed.
  - 4\) Note that in Tcl strings and lists are both central data types,
    for instance every Tcl list is also a valid Tcl command, but a list
    is in turn a string. 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](/2254) 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](/2254) than in other languages with explicit support for
    such problems.
  - 5\) This is very questionable, fragmentation may also mean faster
    evolution, but too fragmentation may just mean that there are far
    more [Scheme](/2254) implementation and wasted efforts than needed.
    Btw I'm not fully against fragmentation if it has a good reason, in
    fact I'm writing the [Jim](/13693) interpreter, an implementation of
    Tcl with some changes.
  - 6\) [Continuations](/3453): good point. Still event driven is many
    times a fast and comfortable way to model problems, the Tcl
    implementation of event driven programming 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](/808) 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 

About Tcl being a bad implementation of [Lisp](/1657) , I don't think so
of course. Surely [Lisp](/1657) was in the mind of [John
Ousterhout](/36) , as he wrote in the usenix paper that was shipped with
the first versions of Tcl. Note that many users here think that
[Lisp](/1657) in general and [Scheme](/2254) in particular is something
of very interesting to look at. Many [Lisp](/1657) idioms, and bottom-up
programming itself are the Tcl way to program too. Just Tcl tries to be
more practical 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](/1657) , especially when complex
linked data structures are needed, or abstractions like
[continuations](/3453)

  - 7\) ... also note that many features of [Lisp](/1657) that are not
    in [Tcl](/445) may appear later or in a different implementation of
    [Tcl](/445). For example the [Jim](/13693) interpreter has closures
    (see [Jim Closures](/13840)), garbage collecting [lambda](/8704),
    more functional programming support and other interesting features.

"The thing about both Lisp and Smalltalk that keeps making me feel
alienated is that their power seems much weaker beyond their kingdom.
The outside world does not have an object browser, nor is it made of
s-expressions.

"The thing about both Lisp and Smalltalk that keeps making me feel
alienated is that their power seems much weaker beyond their kingdom.
The outside world does not have an object browser, nor is it made of
s-expressions.

"Tcl occupies a very nice place in this regard: its homoiconicity and
symmetry (and late binding) come from text. The outside world, to a very
close approximation, is also made of text. Subprocesses, sockets, FFI,
files and user interaction just feel more native - in the image-oriented
languages, I always find myself fighting the ambassador who imperfectly
represents these things in forms the kingdom understands." \[

"Tcl occupies a very nice place in this regard: its homoiconicity and
symmetry (and late binding) come from text. The outside world, to a very
close approximation, is also made of text. Subprocesses, sockets, FFI,
files and user interaction just feel more native - in the image-oriented
languages, I always find myself fighting the ambassador who imperfectly
represents these things in forms the kingdom understands." \[
[1](https://news.ycombinator.com/item?id=14335325)
