Advantages of Tcl over Lisp | Hacker News Reader

Advantages of Tcl over Lisp

wiki.tcl.tk

18 pointsgnosis23 comments

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

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.

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.

What is the industry you work in?

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

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.

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

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.

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

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?

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.

That is so painfully wrong.

Would you care to explain?

1) You have no guarantees that code you write will resume from a method invokation point.

2) How do you do safe resource cleanup? If you open a file and pass the method to a handler, how do you guarantee that you can close it after the method call?

3) This feature seems like it would make compiler optimizations difficult to say the least.

But more than anything, it just feels dirty, like goto's.

Yes, exactly. Which is why I haven't used it ever except in that one case where it turned out to make the code clearer (at least to me).

Forth's cute that way too -- it gets a little shout-out in _Thinking Forth_.

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?

Can you serialize the hash-table?

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

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.

Try with a circular list.

(setf * print-circle* t)

In Tcl lists and dicts always store values.

Reply on news.ycombinator.com