5 ms·

Advantages of Tcl over Lisp

18 points by gnosis 16y ago

anonymous246 16y ago
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 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 16y ago
  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 16y ago
    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 16y ago
      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 16y ago
        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.
- m0th87 16y ago
  That is so painfully wrong.
  - anonymous246 16y ago
    Would you care to explain?
    - m0th87 16y ago
      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.
      - anonymous246 16y ago
        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).
- abecedarius 16y ago
  Forth's cute that way too -- it gets a little shout-out in _Thinking Forth_.
copper 16y ago
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 16y ago
  What is the industry you work in?
srean 16y ago
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 http://wiki.tcl.tk/13840
Vivtek 16y ago
Tcl is brainlessly easy to extend in C, too. An enjoyable language all around.
derleth 16y ago
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 16y ago
  Can you serialize the hash-table?
  - derleth 16y ago
    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 16y ago
      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.
- pmarin 16y ago
  Try with a circular list.
  - 16y ago
malkia 16y ago
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.
Zak 16y ago
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.

18 points by gnosis 16y ago

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 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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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.
m0th87 16y ago
That is so painfully wrong.
- anonymous246 16y ago
  Would you care to explain?
  - m0th87 16y ago
    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.
    - anonymous246 16y ago
      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).
abecedarius 16y ago
Forth's cute that way too -- it gets a little shout-out in _Thinking Forth_.

copper 16y ago

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 16y ago
What is the industry you work in?

srean 16y ago

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 http://wiki.tcl.tk/13840

Vivtek 16y ago

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

derleth 16y ago

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 16y ago
Can you serialize the hash-table?
- derleth 16y ago
  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 16y ago
    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.
pmarin 16y ago
Try with a circular list.
- 16y ago

malkia 16y ago

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.

Zak 16y ago

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.