
Advantages of Tcl over Lisp - gnosis
http://wiki.tcl.tk/13410
======
srean
Tcl does not get a lot of love. I think some of it is due to the fact that it
is not lisp, it does not have closures, and perhaps the association with the
famous Tcl wars. I have always found it a lively little language to code quick
and dirty things. Dirty Tcl, isn't particularly dirty (well, it's not
particularly quick either, but better than what I expected it to be) and
pretty easy to embed. Upvar is sort of nonstandard, but one can get by with
it.

It is one of the very few interpreted languages that had a nice threading
support since ages. But for me the best part has been the community and
wiki.tcl.tk. I dont think it is very common in other communities that you get
responses in real time. To me Tcl was (I know I will be violently killed for
this) a cleaner non-cowboy Perl (as well as Lua of the 90s).

If it interests HN readers, Jim, an implementation of Tcl, has closures.
<http://wiki.tcl.tk/13840>

------
Zak
_many thinks[sic] like HTML, XML, Networking Protocols, are about strings more
than they are about lists._

HTML and XML structured as trees made from nested lists. Manipulating them as
strings is difficult and error-prone. Dealing with them as lists is much
cleaner in most cases, even when your language isn't Lisp.

------
copper
In the industry I work in, Tcl is used extensively as the application
language, and it works out well enough in practise (funnily enough, one of the
larger players in this space use a dialect of Scheme.)

I guess the greatest advantage Tcl has is of being embedded deep into peoples
workflows (changing which tends to be a huge investment both in terms of
money, and what is more valuable, time) so it's very difficult to be dislodged
from there. Also, once an EE manages to grok "everything is a string", there's
absolutely nothing to stop him from writing horrible code :)

As for advantages, meh. The only one that really stands out for me is this
one:

> There aren't a big number of implementations of Tcl, and there is a bigger
> default library.

~~~
xiongchiamiov
What is the industry you work in?

------
Vivtek
Tcl is brainlessly easy to extend in C, too. An enjoyable language all around.

------
malkia
Lots of Maya (Autodesk property now) users are in fact TCL users. Maya's MEL
script is very close to TCL.

I've seen it also used in Konami's Metal Gear Solid for scripting the levels,
and in one game studio for the sound tool and processing.

Also Tk is used a lot, and through many languages.

------
anonymous246
My favorite cool feature of Tcl: A return statement that can return by
arbitrary number of levels instead of 1.
<http://www.tcl.tk/man/tcl8.5/TclCmd/return.htm#M15>

I found this very useful, for example when writing a webapp that expected a
session ID in a cookie. When not found, it was supposed to redirect to an
error page.

In Tcl:

    
    
      proc handler {} {
        load_session
        # do stuff
      }
    

load_session will use two-level return to redirect to the error page.

In python etc:

    
    
      def handler:
        if load_session() == error:
          return
        # do stuff
    

Minor, yes, but we're talking language nerdery. :)

~~~
silentbicycle
Continuations handle this more cleanly. Heck, you can return to an arbitrary
point 1 or more functions back on the stack _in C_ , via setjmp/longjmp, when
you really need to.

~~~
anonymous246
Can you explain how continuations apply here. I don't really have a good idea
about that.

Wrt setjmp/longjmp, I think the key differences are the lack of a 'setjmp' and
that you don't have to pass in the setjmp buffer down the calls. If you ignore
those aspects and focus only the barest essence, yes they're the same (just
like nitrogen and a cake are the same because they're both made of protons,
neutrons, and electrons).

~~~
silentbicycle
Think of a first class continuation as a heap-allocated setjmp buffer - rather
than unwinding the stack, it changes the stack to a saved stack (which, since
it isn't unwound, can be returned to multiple times).

Continuations and longjmp can't return an arbitrary number of levels up the
call stack without placing some sort of marker there first, but IMHO that's a
good thing. Continuations are a "structured" version of that Tcl return
construct. While I haven't done much with Tcl, is it typically used to
implement other language constructs with more specific semantics, or is it
typically used directly?

~~~
anonymous246
I've never seen it used (except by myself once). :) Because the control flow
becomes hard to understand, and the called function becomes extremely context
sensitive. But I think it has its uses within libraries' private functions or
in code which can afford to be blub-incompatible.

------
derleth
Educate me, because I think I've found an outright error in the linked page:

> 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.

This is, from what I can see, wrong: In Lisp, you have the write function,
which can 'serialize' arbitrarily complex data structures in a form acceptable
to the read function. That's pretty much it, unless you're trying to do
something odd like applying write to a compiled function or some other
implementation-specific bizarre internal data structure that doesn't have a
write-able representation.

Therefore, the linked page seems to be missing or mis-stating a core feature
of Lisp. Am I wrong about this? Does the Tcl world have something
significantly different in this regard?

~~~
malkia
Can you serialize the hash-table?

~~~
derleth
Yes, you can:

    
    
         > (write (make-hash-table :initial-contents '((a . b) (c . d))))
        #S(HASH-TABLE :TEST FASTHASH-EQL (C . D) (A . B))
    

If you wrote the output to a file and used read to input that file, you'd get
precisely the same hash table back into your program.

(That's Common Lisp. Scheme might be different.)

~~~
pmarin
Does hash tables stores only values or they can store other data structures?
What happen when they store references to other data structures?

In Tcl, list and dict _always_ are values so their string representation is
already a serialization.

