5 ms·

To anyone who upvoted this, can you relate why one may consider using TCL today? What are it's strengths and weaknesses compared to other 'common' scripting lan

To anyone who upvoted this, can you relate why one may consider using TCL today? What are it's strengths and weaknesses compared to other 'common' scripting languages ie python, lua, ruby, ... ? And why is translation and static compilation desireable?

a8da6b0c91d 11y ago
TCL is probably the only major scripting language that has rock solid thread and concurrency (events, too) support. As a matter of opinion, the embedding api is cleaner than most alternatives.
- kbenson 11y ago
  Unfortunately, I'm not sure how "major" it's can be considered these days. Perl struggles with maintaining that title (if it hasn't already lost it for the majority of people), and my impression has always been that Perl is quite a bit more popular than TCL. That impression could be quite off though, as programming language usage measurements are always rife with controversy.
Zenst 11y ago
Legacy reasons and existing code base works. This might offered a migration path for those who wish. Though the TCL/TK combo for some has always been appealing and simple enough to work and come across it in area's for comm's to nice display interface and medical data processings. Cloverleaf being worth a mention and that is written in TCL and used that near on 20 years ago for processing medical important things from banks of modems - it worked. Sure could use something else but that is true of everything. Still TCL been around a while, back in a time in which perl was popular.
blacksqr 11y ago
Compilation is desirable for increased performance. See submission link for statistics. As for why use Tcl, see: http://wiki.tcl.tk/what%20is%20tcl http://wiki.tcl.tk/what%20is%20tcl
GFK_of_xmaspast 11y ago
I haven't used tcl for 20 years and probably will never use it again, but upvoted on grounds of 'hey, that looks cool'.
antirez 11y ago
Hello, Redis test suite is written in Tcl because for this kind of stuff Tcl is very good. A few reasons: 1. It is very easy to write DSLs in Tcl, you can turn it into a radically different on-purpose language. If you think Ruby is good at DSLs, try Tcl. 2. It has good I/O functions and is event-driven by default. The Redis test for example uses a server-client model using the event driven support of Tcl. 3. It has excellent ways to interact with other Unix commands, see for example the [exec] command: http://www.tcl.tk/man/tcl8.5/TclCmd/exec.htm http://www.tcl.tk/man/tcl8.5/TclCmd/exec.htm 4. It has automatic memory management but does not use a garbage collector, reference counting is used instead. This means that the memory footprint is small and there are no GC pauses. Moreover the interpreter is extremely stable. There are more reasons for using Tcl in certain projects, the above are the reasons I'm using it for Redis testing.
- srean 11y ago
  Ha! I would have expected to see Jim there. Do some of these strengths not apply ? I have heard rumors about Tcl 9.0 and Jim merging, any opinion on that. Would love to hear how Jim came about in the first place.
- yellowapple 11y ago
  The use of reference counting is suddenly really compelling for me to try out Tcl a bit. I've been looking for a good reference-counted language (other than Perl, which is where much of my programming background originated), and Tcl's looking more and more like a good fit.
  - beagle3 11y ago
    CPython is a good reference counted language. So are J/K/A+/Kona. (PyPy and Jython are NOT reference counted - so saying "Python is reference counted" is wrong)
aylons 11y ago
In my case, EDA and FPGA stuff. Tools like Mentor Graphic Modelsim and Xilinx Vivado (this one is quite recent by EDA standards) use TCL as both a console interface and scripting language, to the point that configuration files are also written in TCL. Knowing TCL enables me not only tool automation, but a huge deal of personalization and setup, by allowing me to access data and internal functions of the systems. Modelsim, for example, has its whole GUI made in TCL/TK and I can easily create new GUI elements in TCL to help me debugging. Also, TCL is a very interesting language by itself. Ok, not modern or cool, but much more interesting than most people think of it. This blog post [1] tries to make this point, and was already discussed in HN [2]. [1] http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html [2] https://news.ycombinator.com/item?id=7069642 https://news.ycombinator.com/item?id=7069642
0xdeadbeefbabe 11y ago
I'm familiar with parts of TCL, but I still can't arrive at a good answer for those questions. It has a unique (wild and strange) feature called upvar that I haven't seen in python or lua. You "use" it to reference a previous frame in your call stack.
- davidw 11y ago
  You can use upvar and uplevel to write control structures (if, while, that kind of thing) in Tcl itself. For instance, Tcl itself does not have a do ... while loop, but you can write one that will look like it's part of the language. Also: it's Tcl, by the way, not TCL.
  - beagle3 11y ago
    Lua has something called an "upvalue" but it's a completely different thing. Lobster[0] also lets you write do/while loops and new conditionals, but does that in a different way that does not require upvar/uplevel, and is IMHO cleaner. (It is less capable in general, but captures 99% of the use cases that I've seen for upvar/uplevel in Tcl) It is indeed Tcl, but it IS an acronym for "Tool Command Language", or at least started out that way. [0] http://strlen.com/lobster http://strlen.com/lobster
    - sigzero 11y ago
      The acronym is true but the community uses Tcl now and has for quite a while.
      - amyjess 11y ago
        Stuff like this intrigues me, from a linguistic perspective. I'm really curious what lead to the community settling on this. You'll occasionally see all-lowercase in some projects thanks to the fact that *nix commands are usually all-lowercase, but title-casing an acronym is weird. If I had to hazard a guess, I'd say it's because "Tcl" is typically pronounced as a word ("tickle"), so it got de-acronymized like "radar" or "scuba". Then again, nobody writes SCSI as Scsi. I'd love to study this some more...
hardwaresofton 11y ago
TCL is still a mainstay of IC (Integrated Circuit) development design and test. It was originally developed for that purpose, and it's deeply entrenched. I personally think it should die a very quick (honorable) death.
- rainer_muell 11y ago
  > I personally think it should die a very quick (honorable) death. Mind elaborating?
  - hardwaresofton 11y ago
    While TCL does a good job gluing together IC tools, there are many languages that are much more expressive, powerful, and even just as simple (with good DSL support), with larger communities and more modules to choose from that aren't being used because TCL is. TCL has always seemed to me to be the incumbent that prevented uses of more modern languages. I can't think of one thing TCL does better than any of the languages that come after it that warrants keeping it around, outside of super easy C bindings and some light metaprogramming capability. A lack of good resources on TCL also leads to people learning it all sorts of ways, and writing all sorts of (often buggy) code with it. Maybe that's just symptomatic of the companies at which I've used TCL, but I think it's pretty clear that there are way more good resources on something like lisp or python than there are on TCL (I mention lisp because if you squint and replace some [ ]s with ( )s, TCL looks almost like lisp) A lot of my reasons aren't quite concrete, but in short, I think using an almost-dead language like TCL leads to stagnation of a code base. People aren't pushing boundaries, doing new things in TCL. There's definitely nothing wrong with having a no-surprises go-to language that just gets stuff done, but I just don't personally find TCL stimulating. Maybe I'm just too much of a new-shiny-language hipster
- sigzero 11y ago
  > I personally think it should die a very quick (honorable) death. No, I would disagree. I like Tcl. I like using Tcl. The community is very good as well. The Tcl maintainers are really good at what they do for Tcl and the community. There is no reason IMO for it to die at all.
forinti 11y ago
It's very simple to create an executable for Windows with Freewrap so that your users don't need anything pre-installed.
lbruder 11y ago
Interesting article about the "Tcl experience" here: http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html I love how simple the language is. Quick and easy to learn, small footprint, embeddable. For quite a while I used to prototype simple web services in Tcl, then convert to C for speed. The Tcl versions were so much easier to write, adapt, and debug, and had more features, because in C at some point I thought, meh, don't really need this...
pimlottc 11y ago
You can't be a serious IRC bot hacker without knowing TCL ;)
tpoindex 11y ago
Author here, happy to answer any questions. For this question: I've used Tcl for 20+ years for various things, database, web, monitoring, prototyping - basically anything you'd use any other scripting language, it just happens to fit me well (I also use Python for some things). Tcl is not without its warts, but positives far out weigh any negatives. Translation to C or Java is done primarily for performance, other use cases would be for IP protections.
mzs 11y ago
TCL interpreter is really easy to embed into your own project and then you get impressive scripting for that small effort. You can also extend it pretty easily. A lot of people say it's hackish, but it's really not that bad if you sort of follow this mindset like you are ping ponging between what's in charge - your code or the interpreter in turns.
- djur 11y ago
  Is there any good documentation out there on embedding Tcl? The current page about it on the Tcl site (which itself is a maze of twisty passages) is mostly dedicated to trying to convince you not to embed it, and then there's some broken links to other sites.
  - mzs 11y ago
    There was some papers and a book (sorry can't remember anymore which one, there used to be more out there about TCL) I used but mostly looked at the expect source as an example.
    - adunsmoor 11y ago
      Tcl and the Tk Toolkit by J. Osterhout is an old reference but very useful for getting started with the C API to Tcl including embedding an interpreter. The last 1/3rd of the book is on writing Tcl applications in C. Also look at the the source files for the Tcl (tclsh) or Tk (wish) shells. They are fairly concise.
      - davidw 11y ago
        There is also an updated version out (with my name on the cover, to boot:-) http://amzn.to/1LQrLTK http://amzn.to/1LQrLTK Although even that is not super recent. Tcl's C API is very pleasant to work with, and its C code is a good read - except for the regex stuff, which are the first few files you'd see in an alphabetical listing.
      - mzs 11y ago
ArkyBeagle 11y ago
Python is excellent, although I'd still give Tcl a small edge over Python for quick use. I find event driven, sockets and serial ports a bit more tedious with Python. The suite of first class objects in Tcl is very appropriate. But I have more experience with Tcl, so there's another bias. There's a way to do state machine patterns with Tcl that I've not seen in any other language - arrays of code-strings indexed by state - you "eval $fsm($state)". I'm sure there are other languages that do this, so observer bias. That, with event-driven socket/serial port/file I/O is where it shines the most. The strengths are really the Tcl core team, who have all been at it for a long time, have excellent backgrounds and don't ship a lot of problems. IMO, Tcl's "obscurity" ( relative to Perl ) was a saving grace - Tcl moved at a more deliberate pace. I also tend to trust my own Tcl code more than things developed in other ways - I've used it to find countless bugs in other peoples' stacks and libraries. I have not used static compilation, so I'll withhold comment. There is freewrap at least for making a standalone Tcl application. It basically embeds a Tcl interpreter with the "executable". Also - I think the way to learn Tcl is to use the Brent Welch book.

a8da6b0c91d 11y ago

TCL is probably the only major scripting language that has rock solid thread and concurrency (events, too) support. As a matter of opinion, the embedding api is cleaner than most alternatives.

kbenson 11y ago
Unfortunately, I'm not sure how "major" it's can be considered these days. Perl struggles with maintaining that title (if it hasn't already lost it for the majority of people), and my impression has always been that Perl is quite a bit more popular than TCL. That impression could be quite off though, as programming language usage measurements are always rife with controversy.

Zenst 11y ago

Legacy reasons and existing code base works. This might offered a migration path for those who wish. Though the TCL/TK combo for some has always been appealing and simple enough to work and come across it in area's for comm's to nice display interface and medical data processings. Cloverleaf being worth a mention and that is written in TCL and used that near on 20 years ago for processing medical important things from banks of modems - it worked. Sure could use something else but that is true of everything. Still TCL been around a while, back in a time in which perl was popular.

blacksqr 11y ago

Compilation is desirable for increased performance. See submission link for statistics. As for why use Tcl, see: http://wiki.tcl.tk/what%20is%20tcl http://wiki.tcl.tk/what%20is%20tcl

GFK_of_xmaspast 11y ago

I haven't used tcl for 20 years and probably will never use it again, but upvoted on grounds of 'hey, that looks cool'.

antirez 11y ago

Hello, Redis test suite is written in Tcl because for this kind of stuff Tcl is very good. A few reasons: 1. It is very easy to write DSLs in Tcl, you can turn it into a radically different on-purpose language. If you think Ruby is good at DSLs, try Tcl. 2. It has good I/O functions and is event-driven by default. The Redis test for example uses a server-client model using the event driven support of Tcl. 3. It has excellent ways to interact with other Unix commands, see for example the [exec] command: http://www.tcl.tk/man/tcl8.5/TclCmd/exec.htm http://www.tcl.tk/man/tcl8.5/TclCmd/exec.htm 4. It has automatic memory management but does not use a garbage collector, reference counting is used instead. This means that the memory footprint is small and there are no GC pauses. Moreover the interpreter is extremely stable. There are more reasons for using Tcl in certain projects, the above are the reasons I'm using it for Redis testing.

srean 11y ago
Ha! I would have expected to see Jim there. Do some of these strengths not apply ? I have heard rumors about Tcl 9.0 and Jim merging, any opinion on that. Would love to hear how Jim came about in the first place.
yellowapple 11y ago
The use of reference counting is suddenly really compelling for me to try out Tcl a bit. I've been looking for a good reference-counted language (other than Perl, which is where much of my programming background originated), and Tcl's looking more and more like a good fit.
- beagle3 11y ago
  CPython is a good reference counted language. So are J/K/A+/Kona. (PyPy and Jython are NOT reference counted - so saying "Python is reference counted" is wrong)

aylons 11y ago

In my case, EDA and FPGA stuff. Tools like Mentor Graphic Modelsim and Xilinx Vivado (this one is quite recent by EDA standards) use TCL as both a console interface and scripting language, to the point that configuration files are also written in TCL. Knowing TCL enables me not only tool automation, but a huge deal of personalization and setup, by allowing me to access data and internal functions of the systems. Modelsim, for example, has its whole GUI made in TCL/TK and I can easily create new GUI elements in TCL to help me debugging. Also, TCL is a very interesting language by itself. Ok, not modern or cool, but much more interesting than most people think of it. This blog post [1] tries to make this point, and was already discussed in HN [2]. [1] http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html [2] https://news.ycombinator.com/item?id=7069642 https://news.ycombinator.com/item?id=7069642

0xdeadbeefbabe 11y ago

I'm familiar with parts of TCL, but I still can't arrive at a good answer for those questions. It has a unique (wild and strange) feature called upvar that I haven't seen in python or lua. You "use" it to reference a previous frame in your call stack.

davidw 11y ago
You can use upvar and uplevel to write control structures (if, while, that kind of thing) in Tcl itself. For instance, Tcl itself does not have a do ... while loop, but you can write one that will look like it's part of the language. Also: it's Tcl, by the way, not TCL.
- beagle3 11y ago
  Lua has something called an "upvalue" but it's a completely different thing. Lobster[0] also lets you write do/while loops and new conditionals, but does that in a different way that does not require upvar/uplevel, and is IMHO cleaner. (It is less capable in general, but captures 99% of the use cases that I've seen for upvar/uplevel in Tcl) It is indeed Tcl, but it IS an acronym for "Tool Command Language", or at least started out that way. [0] http://strlen.com/lobster http://strlen.com/lobster
  - sigzero 11y ago
    The acronym is true but the community uses Tcl now and has for quite a while.
    - amyjess 11y ago
      Stuff like this intrigues me, from a linguistic perspective. I'm really curious what lead to the community settling on this. You'll occasionally see all-lowercase in some projects thanks to the fact that *nix commands are usually all-lowercase, but title-casing an acronym is weird. If I had to hazard a guess, I'd say it's because "Tcl" is typically pronounced as a word ("tickle"), so it got de-acronymized like "radar" or "scuba". Then again, nobody writes SCSI as Scsi. I'd love to study this some more...

hardwaresofton 11y ago

TCL is still a mainstay of IC (Integrated Circuit) development design and test. It was originally developed for that purpose, and it's deeply entrenched. I personally think it should die a very quick (honorable) death.

rainer_muell 11y ago
> I personally think it should die a very quick (honorable) death. Mind elaborating?
- hardwaresofton 11y ago
  While TCL does a good job gluing together IC tools, there are many languages that are much more expressive, powerful, and even just as simple (with good DSL support), with larger communities and more modules to choose from that aren't being used because TCL is. TCL has always seemed to me to be the incumbent that prevented uses of more modern languages. I can't think of one thing TCL does better than any of the languages that come after it that warrants keeping it around, outside of super easy C bindings and some light metaprogramming capability. A lack of good resources on TCL also leads to people learning it all sorts of ways, and writing all sorts of (often buggy) code with it. Maybe that's just symptomatic of the companies at which I've used TCL, but I think it's pretty clear that there are way more good resources on something like lisp or python than there are on TCL (I mention lisp because if you squint and replace some [ ]s with ( )s, TCL looks almost like lisp) A lot of my reasons aren't quite concrete, but in short, I think using an almost-dead language like TCL leads to stagnation of a code base. People aren't pushing boundaries, doing new things in TCL. There's definitely nothing wrong with having a no-surprises go-to language that just gets stuff done, but I just don't personally find TCL stimulating. Maybe I'm just too much of a new-shiny-language hipster
sigzero 11y ago
> I personally think it should die a very quick (honorable) death. No, I would disagree. I like Tcl. I like using Tcl. The community is very good as well. The Tcl maintainers are really good at what they do for Tcl and the community. There is no reason IMO for it to die at all.

forinti 11y ago

It's very simple to create an executable for Windows with Freewrap so that your users don't need anything pre-installed.

lbruder 11y ago

Interesting article about the "Tcl experience" here: http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html I love how simple the language is. Quick and easy to learn, small footprint, embeddable. For quite a while I used to prototype simple web services in Tcl, then convert to C for speed. The Tcl versions were so much easier to write, adapt, and debug, and had more features, because in C at some point I thought, meh, don't really need this...

pimlottc 11y ago

You can't be a serious IRC bot hacker without knowing TCL ;)

tpoindex 11y ago

Author here, happy to answer any questions. For this question: I've used Tcl for 20+ years for various things, database, web, monitoring, prototyping - basically anything you'd use any other scripting language, it just happens to fit me well (I also use Python for some things). Tcl is not without its warts, but positives far out weigh any negatives. Translation to C or Java is done primarily for performance, other use cases would be for IP protections.

mzs 11y ago

TCL interpreter is really easy to embed into your own project and then you get impressive scripting for that small effort. You can also extend it pretty easily. A lot of people say it's hackish, but it's really not that bad if you sort of follow this mindset like you are ping ponging between what's in charge - your code or the interpreter in turns.

djur 11y ago
Is there any good documentation out there on embedding Tcl? The current page about it on the Tcl site (which itself is a maze of twisty passages) is mostly dedicated to trying to convince you not to embed it, and then there's some broken links to other sites.
- mzs 11y ago
  There was some papers and a book (sorry can't remember anymore which one, there used to be more out there about TCL) I used but mostly looked at the expect source as an example.
  - adunsmoor 11y ago
    Tcl and the Tk Toolkit by J. Osterhout is an old reference but very useful for getting started with the C API to Tcl including embedding an interpreter. The last 1/3rd of the book is on writing Tcl applications in C. Also look at the the source files for the Tcl (tclsh) or Tk (wish) shells. They are fairly concise.
    - davidw 11y ago
      There is also an updated version out (with my name on the cover, to boot:-) http://amzn.to/1LQrLTK http://amzn.to/1LQrLTK Although even that is not super recent. Tcl's C API is very pleasant to work with, and its C code is a good read - except for the regex stuff, which are the first few files you'd see in an alphabetical listing.
    - mzs 11y ago

ArkyBeagle 11y ago

Python is excellent, although I'd still give Tcl a small edge over Python for quick use. I find event driven, sockets and serial ports a bit more tedious with Python. The suite of first class objects in Tcl is very appropriate. But I have more experience with Tcl, so there's another bias. There's a way to do state machine patterns with Tcl that I've not seen in any other language - arrays of code-strings indexed by state - you "eval $fsm($state)". I'm sure there are other languages that do this, so observer bias. That, with event-driven socket/serial port/file I/O is where it shines the most. The strengths are really the Tcl core team, who have all been at it for a long time, have excellent backgrounds and don't ship a lot of problems. IMO, Tcl's "obscurity" ( relative to Perl ) was a saving grace - Tcl moved at a more deliberate pace. I also tend to trust my own Tcl code more than things developed in other ways - I've used it to find countless bugs in other peoples' stacks and libraries. I have not used static compilation, so I'll withhold comment. There is freewrap at least for making a standalone Tcl application. It basically embeds a Tcl interpreter with the "executable". Also - I think the way to learn Tcl is to use the Brent Welch book.