7 ms·

What is Tcl?

38 points by blacksqr 12y ago

biomimic 12y ago
This: http://genopharmix.com/TuataraSum/index-142.html http://genopharmix.com/TuataraSum/index-142.html 100% Tcl.
danjayh 12y ago
If you've dealt with vxWorks and Wind River's toolchain, you've been using TCL for over a decade.
vortico 12y ago
Despite the numerous books and talk about Tcl, I've never seen any actual Tcl for two reasons. 1) It seems to be used in GUIs for biological and medical sciences only, which is distant from my field. 2) There are absolutely no code samples on the surface of tcl.tk or on this article, and after clicking "Random Page" a statistically significant number of times I found that only 1/6 pages have any Tcl code at all. Even the tutorial for the language itself has a strangely low code-to-text ratio. It makes me wonder that the developers are wanting to hide the code due to shame, or the CEO bosses behind the project only feel that advertising features of the implementation, applications, and the language's popularity are important, while in fact these are relatively useless to speculating and beginner Tcl programmers.
- stormbrew 12y ago
  Almost all of my exposure to TCL was IRC clients (xircon) and bots (eggdrop) in the 90s. Also my first job used it in some capacity that I forget, but it was through the tcl at that job that I had my first exposure to an event driven framework with chaining (twisted python style). It's a pretty odd language, but has some interesting and powerful ideas in it.
  - rodgerd 12y ago
    Mine was the ArsDigita stack and Vignette StoryServer. There was a lot of the latter in the wild for a long time.
- peteretep 12y ago
  > It seems to be used in GUIs for biological and medical > sciences only, which is distant from my field. Technically that's Tk, isn't it? I've written quite a lot of Perl that uses Tk before, and there was even an ORA book about it.
  - vortico 12y ago
    Well, yes. Technically. Although I personally haven't seen Tcl in use without Tk.
- michaelsbradley 12y ago
  Expect[1] (a Tcl-based tool) is still quite useful despite its age, and Don Libes' book[2] is a devops classic (if there is such a thing). The examples directory[3] from expect's source code repository should help you get the flavor of good Tcl programming. `brew install expect` `apt-get install expect` Readily available on many other platforms as well, including Windows. [1] http://www.nist.gov/el/msid/expect.cfm http://www.nist.gov/el/msid/expect.cfm [2] http://shop.oreilly.com/product/9781565920903.do http://shop.oreilly.com/product/9781565920903.do [3] http://expect.cvs.sourceforge.net/viewvc/expect/expect/example/ http://expect.cvs.sourceforge.net/viewvc/expect/expect/examp...
  - sanxiyn 12y ago
    GCC testsuite is still written in DejaGnu, which is written in Expect. http://www.gnu.org/software/dejagnu/ http://www.gnu.org/software/dejagnu/ It works for what it does.
- cleverjake 12y ago
  way back when, a large amount of AOL stuff was written in tcl. AOLServer was one, and they actually opened sourced it - https://github.com/aolserver/aolserver https://github.com/aolserver/aolserver
  - evilotto 12y ago
    And lest you think that AOLserver is dead based on the lack of new activity on that github repo (which is just a mirror, BTW), Naviserver - https://bitbucket.org/naviserver/naviserver https://bitbucket.org/naviserver/naviserver - which was forked from AOLserver some time ago, just released a new version yesterday.
- biomimic 12y ago
  TiVo started out as a Tcl house too. Their boxes have a Tcl tcp socket server that I built installed on each one.
- serverhorror 12y ago
  I too had that impression. I can vouch for (1) being correct since I am managing an HPC Cluster for a company right now. The way to to is modules.sf.net (or the newer and nicer Lmod which is Lua). The usual need is for a multitude of versions being avaible and easily usable. This starts at the compiler level and goes up to stuff like I have 5 versions of Tool X. This needs Python 2.7.3 (yes exactly that version). Now make it easy for me to use it. It has been my only touching point with TCL so far -- I. Don't. Like. It.
- schlenk 12y ago
  Well, you might not notice Tcl if you see it sometimes. For example have a look at the build scripts in MacPorts, those are valid Tcl programs (if you load the needed procs first). https://guide.macports.org/chunked/development.examples.html https://guide.macports.org/chunked/development.examples.html As Tcl is very often used for DSL style usecases, you might mistaken Tcl code for more or less pseudo code, config files or something like that.
abfan1127 12y ago
TCL is the defacto language in EDA ASIC Design Tools (synthesis, place-and-route, static timing analysis). In my opinion, its a terrible language, especially since the tool vendors all add their own flavors. The flow control is painful to use, it lacks OOP data structures. If given the opportunity, I'd avoid it at all costs.
- aceperry 12y ago
  LOL, I've always wondered why TCL didn't become more popular since it has a lot of advantages, on paper. The one thing that really turned me off of it was the way it looked, really butt ugly.
  - abfan1127 12y ago
    oh, its hideous. Especially when hardware design engineers write it. No tests, no real comments, just code that didn't work commented out. For all of the flack PHP receives, TCL is a hammer with the steel claw removed and replaced with a picture of a butterfly.
    - smiletoday 12y ago
      Yeah, I'm a hardware engineer, and I've come across code like that! But it's not Tcl's fault that hardware engineers can't write code, or even comments to go with the code.
      - abfan1127 12y ago
        I agree, but it still leaves a bad taste in my mouth...
  - smiletoday 12y ago
    I guess beauty is in the eye in the beholder. I like the syntax, but you're right that a lot are put off by what the syntax looks. If you get past that however, it's a very, very nice bit of kit.
- 12y ago
gshrikant 12y ago
IIRC, Xilinx's EDA toolchain (ISE; I haven't used Vivado) used Tcl for scripting. So does OpenOCD [1] (a ISP and hardware debugging tool). [1] http://openocd.sourceforge.net/ http://openocd.sourceforge.net/
- hornd 12y ago
  As does Alteras. It's almost the defacto scripting language supported by HW vendors. It can be a fun change of pace, too.
- kevin_thibedeau 12y ago
  Vivado is even more heavily dependent on Tcl as they've merged all the separate tools into one application guided solely by Tcl commands. It feels much more like Synopsys Design Compiler which also migrated from its homebrew scripting language to Tcl a few years ago.
exogen 12y ago
I had an unexpected need to write some Tcl recently when I had to wrap a command line tool in a helper script in order to add some features and automation. Turns out the Unix tool `expect' was designed exactly for this purpose and was already available on my Mac, and thus seemed like a practical solution. Expect programs are written in Tcl: http://en.wikipedia.org/wiki/Expect http://en.wikipedia.org/wiki/Expect
tateeskew 12y ago
iRules within the F5 BigIP products are written in Tcl. I spent a lot of time over the last 15-20 years writing/managing iRules and I always quite enjoyed it. Don't have much recent exposure over the last few years, though.
trimbo 12y ago
Fun fact, in TCL, everything is a string: http://wiki.tcl.tk/3018 http://wiki.tcl.tk/3018 Nuke -- the image compositing system used in visual effects -- has included TCL from its origin as far as I know. That would be 1993. Nuke now offers Python, but TCL's still in there.
- evilotto 12y ago
  Well, kinda. The novice says "everything is a string." The adept says "tcl values are implemented as dual-ported objects, meaning that the internal representation of every value is automatically and transparently converted to the type that is needed at that time." The wizard says "everything is a string." Everything can be a string. From the outside, everything looks like a string. And it's considered bad style to violate this principle. But if you're talking implementation, everything isn't exactly a string.
BioVector 12y ago
I find it the most useful of any language I've used over the years.
- towelrod 12y ago
  Can you expand on this? What other languages have you learned, and how are they less useful than Tcl?
  - estava 12y ago
    I don't know Tcl much. But when I learned about Tk in Ruby I kind of expanded my knowledge of Tcl since Tk was the GUI toolkit of Tcl that was borrowed by many other scripting languages. Tcl/Tk had features like distribution of a deployment binary. It could create an .exe file for Windows deployment for example. Tk included a Domain Specific Language for layout/GUI controls which was useful, without requiring an additional form designer as in other languages. Others have mentioned Expect above, it was a good reminder, imagine creating a GUI application to control a command-line tool, Expect allowed for that very easily, as it could keep open the output/input of the tool it was adding a GUI to. Since it included so much by default, the community could easily contribute with some other tools that you could reuse in your solution. Before "RubyGems" even existed, people were already reusing libraries in Tcl/Tk. :-) The problem of other languages is that they come with more abstractions than people needed. We can fight against "state" in modern programming languages, but it doesn't change the fact that the more complex we make it, the harder it is for people to just get something up and running quickly. That's why systems like Tcl/Tk cannot be retired.
towelrod 12y ago
I frequently write tcl, and I work in a company that has been using it in production for 20+ years. I've written thousands of lines of Tcl, but I only go back to Tcl when I have to work on legacy stuff these days. I wouldn't even remotely consider writing something new in Tcl. I really wish someone would take charge of wiki.tcl.tk and cut out all the nonsense. For example, I am currently in need of producing some JSON from one of our Tcl apps. So I search for JSON and I get this: http://wiki.tcl.tk/13419 http://wiki.tcl.tk/13419 It starts out pretty promising -- listing a bunch of competing JSON implementations for tcl -- which is unusual for a wiki.tcl.tk page. But then it quickly devolves into the usual stream of consciousness that infects every tcl wiki page. What am I supposed to actually do? At first we have a big list of different implementations; that makes sense, every language is kinda like that. But before the first page is even finished, we get weird "string is double gotcha" stuff from gchung, including "you should use the following" 100 character regex! How about: you should use this module for doing this usual thing that every language in the world can do? Then, we get JMN's thoughts about how a JSON generator is better than a JSON parser. Apparently TCV solved this himself in 2009 (but, no code referenced). Very quickly we get into "here's my version!". I'm not complaining about all these guys contributing different solutions. But can't the community gather around one of them? It's like searching wikipedia but always landing on the "talk" page. Hey tclers, try this on for size. Google for "perl json" and see if you get a real response that explains how to do it, or a bunch of random guys talking about how they solved it themselves. Then try "ruby json", "java json", "python json". That is why tcl is dead.
- _delirium 12y ago
  > It's like searching wikipedia but always landing on the "talk" page. I think the TCL wiki is old enough that it dates to the era when that was what a wiki was supposed to be. The original c2.com wiki has a lot of that flavor too. The Wikipedia idea of having main pages that serve as working drafts of "articles" and moving the discussion to separate "talk" pages caught on a few years later. Of course that doesn't preclude switching now...
- rcfox 12y ago
  If it helps, I've recently used huddle[0] to create arbitrarily-nested dictionaries and output JSON of them. It can be quite slow to do a jsondump for large dictionaries though: it sometimes takes a few minutes to output a multi-megabyte file. And, to add to your point, it wasn't even listed on the JSON page you mentioned until the "Misc" conversation section. [0] http://wiki.tcl.tk/21116 http://wiki.tcl.tk/21116
sentenced 12y ago
"That thing you had to know if you wanted to write Eggdrop scripts."
zak_mc_kracken 12y ago
If you think Brainfuck is a sadistic language, you probably haven't heard of Tcl's upvar: https://www.tcl.tk/man/tcl8.4/TclCmd/upvar.htm https://www.tcl.tk/man/tcl8.4/TclCmd/upvar.htm
- cafard 12y ago
  Upvar, properly used, is an excellent tool. Years ago I went looking for an equivalent of PHP. One of the first links thrown up by Google was a PHP discussion thread on which the fellow wishing for upvar was told that he was a bigot (or worse) for even thinking of such a thing.
- RHSeeger 12y ago
  The upvar and uplevel commands allow for some really powerful capabilities, like writing new control structure. They're amazing.
pslam 12y ago
TCL is an incredibly useful language to quickly construct small code snippets in, and is especially good as a REPL language - as a command line interface. On the other hand, it's the bane of my life. It's particularly bad (and verbose) at anything involving expressions. Unfortunately, that's mostly where I find it being used, because it's very popular in hardware. You'll find it being used for emulators, simulator, FPGAs, JTAG interfaces, and so on. There, it's shuffling a lot of data around, and in particular performing bitfield operations. It's notoriously verbose at doing all of that. Hardware register definitions and the like are also usually expressed in a C-like fashion - that is to say they're usually using square brackets e.g "some_reg[2]" notation. This is annoying for TCL, because square brackets are its "string eval replace" construction, so you end up escaping stuff. Its error traceback, usually "puts $errorInfo", is also awkward and often doesn't give you the right locality of where the error was, especially if it's syntax-related. One of the most infuriating aspects is that the comment character "#" doesn't obey the rules you see in other languages - it's not like a pre-processed character. Scope rules still apply within comments, e.g you can open a proc definition and it'll complain about a dangling brace because it still parses the comment line contents. The everything-is-a-string design is awesome but also makes it inherently slow, to the extent that even on a modern system it can end up being the bottleneck in execution. It also results in really weird parameter passing rules between functions. I'm not a fan of having to occasionally add magic intermediate string evaluation steps, or the wildcard expansions necessary for passing lists. It's error-prone and sometimes feels like just hammering the interpreter until it Does What I Mean. Everything-is-a-string is also damn dangerous, and can result in arbitrary code execution if you're not careful. Anyone who's ever run an IRC script or bot has probably experienced this, and knows what I mean. That's not to say Tcl is crappy. It's just a language which was designed in another age, and it's really showing it. It's awesome as a command line REPL, but I highly recommend something else (Python or Lua) if you're doing anything even moderate scale behind the interface.
- na85 12y ago
  >comment character Yes the comment syntax can be infuriating if you're not ready for it. This might not be true any longer, but a number of years ago when I was still using Tcl, # this was a valid comment #this was not a valid comment due to the parser reading "# this" as a comment token followed by its string arguments (I guess it's semantically a noop that takes a string arg) and "#this" which threw an invalid token error. Coming from C/C++ it drove me nuts.
alexholehouse 12y ago
In the biomedical community the standard way to interact with VMD[0] - one of the major molecular viewers and really a workhorse of modern biology - is through Tcl. I always think this is rather unfortunate, because it means that for many people, their first introduction to scripting ever comes in the form of trying to decipher the Tcl docs and just figure out the simplest things. [0] - http://www.ks.uiuc.edu/Research/vmd/ http://www.ks.uiuc.edu/Research/vmd/
Zuider 12y ago
Tcl was not originally intended to be used for writing large programs on its own, but to act as an interface to compiled programs. The actual heavy lifting was meant to be done in C, while interactions with the user could be quickly prototyped in Tcl. Tk simply added a way to do this graphically. The name 'Tool Control Language' points at its intended niche.
- pjmlp 12y ago
  Yes, its FFI API is quite clean because of that goal.
pjmlp 12y ago
A great dynamic scripting language that helped the first startup I worked for, to have a very capable web application middleware for its products. Similar to AOLServer, and with features comparable to Ruby On Rails, but around 2000. It also taught me that if one wants performance in scalable application servers, in the end a JIT or AOT compilation support is a must have.
RHSeeger 12y ago
Personally, Tcl is by far my favorite language to program in. While I admit it's not the right tool for every job, but I feel a great sense of job when it IS the right tool because writing code in it always makes me happy. When I'm writing pseudo-code for someone, I almost always wind up writing something that looks like Tcl (which a bit of OO/functional mixed in). I think there's a number of reasons why I enjoy it so much: - I find it's minimal syntax very easy to work with (for normal cases, admittedly it has it's warts) - I've been using it so long (since about '95) that I tend to "think in Tcl" - The ability to add new control structures to the language makes simplifying other code (ie, adding try/catch/finally to the language yourself) amazing. It's somewhat lisp-like (though not as powerful) My use of Tcl over the years has spanned many different environments - Interacting/automating network hardware tasks (SNMP, Expect, device scripting) - AOLServer - Vignette - Personal tasks (lots of them) - (minor) modifications to the core - Plugins/Scripting for various other programs
schlenk 12y ago
I don't write much Tcl the last few years (mostly Python now, as it pays the bills), but looking from the Python perspective towards Tcl, i see a lot of good things i left behind: * No GIL. Real threads with no silly global locks * A very cool VFS layer, a bit like the stuff you can see in windows powershell with the Registry/Certstore/etc drives * A beautiful implementation really worth a read (no silly 'XXX: don't know what to do, lets print to stderr' inside a library like you find in pythons source) * An extremly consistent language far more than python which does all kinds of junk 'to make parsing easier' even if it makes the language harder * Sandboxing interpreters (doesn't work with python, no chance) * Stacked channels and a cool streams abstraction (Pythons io module is still some way behind its options) * A built in event loop (Python just got one with 3.4...) * A standard lib that mostly takes event driven as given (unlike pythons blocking stuff) * very powerful metaprogramming support (e.g. have some logging code with 'ZERO' overhead when disable at runtime) * good C-API and excellent support for embedding * Stable ABI since more than 10 years (e.g. you can load a binary extension compiled against 8.1 into a current 8.6 interpreter and it just works, one of the reasons many Tcl projects didn't release new versions, no need. Unlike the python nonsense with -2.5,2.6,2.7 versions for every package, okay Python got a partial stable ABI now too, years later) * mostly sane platform abstractions (the world isn't posix everywhere) * packaging with starpacks (python's pyinstaller comes close, but lacks the VFS stuff, years later), a bit like cross-platform OS X app bundles * Non mutable values by default, no pointers, so it is kind of functional * A nice package system that doesn't mix up filesystem layout and namespaces and supports version So if you look at it, it is kind of a weird crossover between ideas you now find in: Go, Node.js, Lisp, Powershell. Just a bit outdated and in need of some love.

What is Tcl?

38 points by blacksqr 12y ago

biomimic 12y ago

This: http://genopharmix.com/TuataraSum/index-142.html http://genopharmix.com/TuataraSum/index-142.html 100% Tcl.

danjayh 12y ago

If you've dealt with vxWorks and Wind River's toolchain, you've been using TCL for over a decade.

vortico 12y ago

Despite the numerous books and talk about Tcl, I've never seen any actual Tcl for two reasons. 1) It seems to be used in GUIs for biological and medical sciences only, which is distant from my field. 2) There are absolutely no code samples on the surface of tcl.tk or on this article, and after clicking "Random Page" a statistically significant number of times I found that only 1/6 pages have any Tcl code at all. Even the tutorial for the language itself has a strangely low code-to-text ratio. It makes me wonder that the developers are wanting to hide the code due to shame, or the CEO bosses behind the project only feel that advertising features of the implementation, applications, and the language's popularity are important, while in fact these are relatively useless to speculating and beginner Tcl programmers.

stormbrew 12y ago
Almost all of my exposure to TCL was IRC clients (xircon) and bots (eggdrop) in the 90s. Also my first job used it in some capacity that I forget, but it was through the tcl at that job that I had my first exposure to an event driven framework with chaining (twisted python style). It's a pretty odd language, but has some interesting and powerful ideas in it.
- rodgerd 12y ago
  Mine was the ArsDigita stack and Vignette StoryServer. There was a lot of the latter in the wild for a long time.
peteretep 12y ago
> It seems to be used in GUIs for biological and medical > sciences only, which is distant from my field. Technically that's Tk, isn't it? I've written quite a lot of Perl that uses Tk before, and there was even an ORA book about it.
- vortico 12y ago
  Well, yes. Technically. Although I personally haven't seen Tcl in use without Tk.
michaelsbradley 12y ago
Expect[1] (a Tcl-based tool) is still quite useful despite its age, and Don Libes' book[2] is a devops classic (if there is such a thing). The examples directory[3] from expect's source code repository should help you get the flavor of good Tcl programming. `brew install expect` `apt-get install expect` Readily available on many other platforms as well, including Windows. [1] http://www.nist.gov/el/msid/expect.cfm http://www.nist.gov/el/msid/expect.cfm [2] http://shop.oreilly.com/product/9781565920903.do http://shop.oreilly.com/product/9781565920903.do [3] http://expect.cvs.sourceforge.net/viewvc/expect/expect/example/ http://expect.cvs.sourceforge.net/viewvc/expect/expect/examp...
- sanxiyn 12y ago
  GCC testsuite is still written in DejaGnu, which is written in Expect. http://www.gnu.org/software/dejagnu/ http://www.gnu.org/software/dejagnu/ It works for what it does.
cleverjake 12y ago
way back when, a large amount of AOL stuff was written in tcl. AOLServer was one, and they actually opened sourced it - https://github.com/aolserver/aolserver https://github.com/aolserver/aolserver
- evilotto 12y ago
  And lest you think that AOLserver is dead based on the lack of new activity on that github repo (which is just a mirror, BTW), Naviserver - https://bitbucket.org/naviserver/naviserver https://bitbucket.org/naviserver/naviserver - which was forked from AOLserver some time ago, just released a new version yesterday.
biomimic 12y ago
TiVo started out as a Tcl house too. Their boxes have a Tcl tcp socket server that I built installed on each one.
serverhorror 12y ago
I too had that impression. I can vouch for (1) being correct since I am managing an HPC Cluster for a company right now. The way to to is modules.sf.net (or the newer and nicer Lmod which is Lua). The usual need is for a multitude of versions being avaible and easily usable. This starts at the compiler level and goes up to stuff like I have 5 versions of Tool X. This needs Python 2.7.3 (yes exactly that version). Now make it easy for me to use it. It has been my only touching point with TCL so far -- I. Don't. Like. It.
schlenk 12y ago
Well, you might not notice Tcl if you see it sometimes. For example have a look at the build scripts in MacPorts, those are valid Tcl programs (if you load the needed procs first). https://guide.macports.org/chunked/development.examples.html https://guide.macports.org/chunked/development.examples.html As Tcl is very often used for DSL style usecases, you might mistaken Tcl code for more or less pseudo code, config files or something like that.

abfan1127 12y ago

TCL is the defacto language in EDA ASIC Design Tools (synthesis, place-and-route, static timing analysis). In my opinion, its a terrible language, especially since the tool vendors all add their own flavors. The flow control is painful to use, it lacks OOP data structures. If given the opportunity, I'd avoid it at all costs.

aceperry 12y ago
LOL, I've always wondered why TCL didn't become more popular since it has a lot of advantages, on paper. The one thing that really turned me off of it was the way it looked, really butt ugly.
- abfan1127 12y ago
  oh, its hideous. Especially when hardware design engineers write it. No tests, no real comments, just code that didn't work commented out. For all of the flack PHP receives, TCL is a hammer with the steel claw removed and replaced with a picture of a butterfly.
  - smiletoday 12y ago
    Yeah, I'm a hardware engineer, and I've come across code like that! But it's not Tcl's fault that hardware engineers can't write code, or even comments to go with the code.
    - abfan1127 12y ago
      I agree, but it still leaves a bad taste in my mouth...
- smiletoday 12y ago
  I guess beauty is in the eye in the beholder. I like the syntax, but you're right that a lot are put off by what the syntax looks. If you get past that however, it's a very, very nice bit of kit.
12y ago

gshrikant 12y ago

IIRC, Xilinx's EDA toolchain (ISE; I haven't used Vivado) used Tcl for scripting. So does OpenOCD [1] (a ISP and hardware debugging tool). [1] http://openocd.sourceforge.net/ http://openocd.sourceforge.net/

hornd 12y ago
As does Alteras. It's almost the defacto scripting language supported by HW vendors. It can be a fun change of pace, too.
kevin_thibedeau 12y ago
Vivado is even more heavily dependent on Tcl as they've merged all the separate tools into one application guided solely by Tcl commands. It feels much more like Synopsys Design Compiler which also migrated from its homebrew scripting language to Tcl a few years ago.

exogen 12y ago

I had an unexpected need to write some Tcl recently when I had to wrap a command line tool in a helper script in order to add some features and automation. Turns out the Unix tool `expect' was designed exactly for this purpose and was already available on my Mac, and thus seemed like a practical solution. Expect programs are written in Tcl: http://en.wikipedia.org/wiki/Expect http://en.wikipedia.org/wiki/Expect

tateeskew 12y ago

iRules within the F5 BigIP products are written in Tcl. I spent a lot of time over the last 15-20 years writing/managing iRules and I always quite enjoyed it. Don't have much recent exposure over the last few years, though.

trimbo 12y ago

Fun fact, in TCL, everything is a string: http://wiki.tcl.tk/3018 http://wiki.tcl.tk/3018 Nuke -- the image compositing system used in visual effects -- has included TCL from its origin as far as I know. That would be 1993. Nuke now offers Python, but TCL's still in there.

evilotto 12y ago
Well, kinda. The novice says "everything is a string." The adept says "tcl values are implemented as dual-ported objects, meaning that the internal representation of every value is automatically and transparently converted to the type that is needed at that time." The wizard says "everything is a string." Everything can be a string. From the outside, everything looks like a string. And it's considered bad style to violate this principle. But if you're talking implementation, everything isn't exactly a string.

BioVector 12y ago

I find it the most useful of any language I've used over the years.

towelrod 12y ago
Can you expand on this? What other languages have you learned, and how are they less useful than Tcl?
- estava 12y ago
  I don't know Tcl much. But when I learned about Tk in Ruby I kind of expanded my knowledge of Tcl since Tk was the GUI toolkit of Tcl that was borrowed by many other scripting languages. Tcl/Tk had features like distribution of a deployment binary. It could create an .exe file for Windows deployment for example. Tk included a Domain Specific Language for layout/GUI controls which was useful, without requiring an additional form designer as in other languages. Others have mentioned Expect above, it was a good reminder, imagine creating a GUI application to control a command-line tool, Expect allowed for that very easily, as it could keep open the output/input of the tool it was adding a GUI to. Since it included so much by default, the community could easily contribute with some other tools that you could reuse in your solution. Before "RubyGems" even existed, people were already reusing libraries in Tcl/Tk. :-) The problem of other languages is that they come with more abstractions than people needed. We can fight against "state" in modern programming languages, but it doesn't change the fact that the more complex we make it, the harder it is for people to just get something up and running quickly. That's why systems like Tcl/Tk cannot be retired.

towelrod 12y ago

I frequently write tcl, and I work in a company that has been using it in production for 20+ years. I've written thousands of lines of Tcl, but I only go back to Tcl when I have to work on legacy stuff these days. I wouldn't even remotely consider writing something new in Tcl. I really wish someone would take charge of wiki.tcl.tk and cut out all the nonsense. For example, I am currently in need of producing some JSON from one of our Tcl apps. So I search for JSON and I get this: http://wiki.tcl.tk/13419 http://wiki.tcl.tk/13419 It starts out pretty promising -- listing a bunch of competing JSON implementations for tcl -- which is unusual for a wiki.tcl.tk page. But then it quickly devolves into the usual stream of consciousness that infects every tcl wiki page. What am I supposed to actually do? At first we have a big list of different implementations; that makes sense, every language is kinda like that. But before the first page is even finished, we get weird "string is double gotcha" stuff from gchung, including "you should use the following" 100 character regex! How about: you should use this module for doing this usual thing that every language in the world can do? Then, we get JMN's thoughts about how a JSON generator is better than a JSON parser. Apparently TCV solved this himself in 2009 (but, no code referenced). Very quickly we get into "here's my version!". I'm not complaining about all these guys contributing different solutions. But can't the community gather around one of them? It's like searching wikipedia but always landing on the "talk" page. Hey tclers, try this on for size. Google for "perl json" and see if you get a real response that explains how to do it, or a bunch of random guys talking about how they solved it themselves. Then try "ruby json", "java json", "python json". That is why tcl is dead.

_delirium 12y ago
> It's like searching wikipedia but always landing on the "talk" page. I think the TCL wiki is old enough that it dates to the era when that was what a wiki was supposed to be. The original c2.com wiki has a lot of that flavor too. The Wikipedia idea of having main pages that serve as working drafts of "articles" and moving the discussion to separate "talk" pages caught on a few years later. Of course that doesn't preclude switching now...
rcfox 12y ago
If it helps, I've recently used huddle[0] to create arbitrarily-nested dictionaries and output JSON of them. It can be quite slow to do a jsondump for large dictionaries though: it sometimes takes a few minutes to output a multi-megabyte file. And, to add to your point, it wasn't even listed on the JSON page you mentioned until the "Misc" conversation section. [0] http://wiki.tcl.tk/21116 http://wiki.tcl.tk/21116

sentenced 12y ago

"That thing you had to know if you wanted to write Eggdrop scripts."

zak_mc_kracken 12y ago

If you think Brainfuck is a sadistic language, you probably haven't heard of Tcl's upvar: https://www.tcl.tk/man/tcl8.4/TclCmd/upvar.htm https://www.tcl.tk/man/tcl8.4/TclCmd/upvar.htm

cafard 12y ago
Upvar, properly used, is an excellent tool. Years ago I went looking for an equivalent of PHP. One of the first links thrown up by Google was a PHP discussion thread on which the fellow wishing for upvar was told that he was a bigot (or worse) for even thinking of such a thing.
RHSeeger 12y ago
The upvar and uplevel commands allow for some really powerful capabilities, like writing new control structure. They're amazing.

pslam 12y ago

TCL is an incredibly useful language to quickly construct small code snippets in, and is especially good as a REPL language - as a command line interface. On the other hand, it's the bane of my life. It's particularly bad (and verbose) at anything involving expressions. Unfortunately, that's mostly where I find it being used, because it's very popular in hardware. You'll find it being used for emulators, simulator, FPGAs, JTAG interfaces, and so on. There, it's shuffling a lot of data around, and in particular performing bitfield operations. It's notoriously verbose at doing all of that. Hardware register definitions and the like are also usually expressed in a C-like fashion - that is to say they're usually using square brackets e.g "some_reg[2]" notation. This is annoying for TCL, because square brackets are its "string eval replace" construction, so you end up escaping stuff. Its error traceback, usually "puts $errorInfo", is also awkward and often doesn't give you the right locality of where the error was, especially if it's syntax-related. One of the most infuriating aspects is that the comment character "#" doesn't obey the rules you see in other languages - it's not like a pre-processed character. Scope rules still apply within comments, e.g you can open a proc definition and it'll complain about a dangling brace because it still parses the comment line contents. The everything-is-a-string design is awesome but also makes it inherently slow, to the extent that even on a modern system it can end up being the bottleneck in execution. It also results in really weird parameter passing rules between functions. I'm not a fan of having to occasionally add magic intermediate string evaluation steps, or the wildcard expansions necessary for passing lists. It's error-prone and sometimes feels like just hammering the interpreter until it Does What I Mean. Everything-is-a-string is also damn dangerous, and can result in arbitrary code execution if you're not careful. Anyone who's ever run an IRC script or bot has probably experienced this, and knows what I mean. That's not to say Tcl is crappy. It's just a language which was designed in another age, and it's really showing it. It's awesome as a command line REPL, but I highly recommend something else (Python or Lua) if you're doing anything even moderate scale behind the interface.

na85 12y ago
>comment character Yes the comment syntax can be infuriating if you're not ready for it. This might not be true any longer, but a number of years ago when I was still using Tcl, # this was a valid comment #this was not a valid comment due to the parser reading "# this" as a comment token followed by its string arguments (I guess it's semantically a noop that takes a string arg) and "#this" which threw an invalid token error. Coming from C/C++ it drove me nuts.

alexholehouse 12y ago

In the biomedical community the standard way to interact with VMD[0] - one of the major molecular viewers and really a workhorse of modern biology - is through Tcl. I always think this is rather unfortunate, because it means that for many people, their first introduction to scripting ever comes in the form of trying to decipher the Tcl docs and just figure out the simplest things. [0] - http://www.ks.uiuc.edu/Research/vmd/ http://www.ks.uiuc.edu/Research/vmd/

Zuider 12y ago

Tcl was not originally intended to be used for writing large programs on its own, but to act as an interface to compiled programs. The actual heavy lifting was meant to be done in C, while interactions with the user could be quickly prototyped in Tcl. Tk simply added a way to do this graphically. The name 'Tool Control Language' points at its intended niche.

pjmlp 12y ago
Yes, its FFI API is quite clean because of that goal.

pjmlp 12y ago

A great dynamic scripting language that helped the first startup I worked for, to have a very capable web application middleware for its products. Similar to AOLServer, and with features comparable to Ruby On Rails, but around 2000. It also taught me that if one wants performance in scalable application servers, in the end a JIT or AOT compilation support is a must have.

RHSeeger 12y ago

Personally, Tcl is by far my favorite language to program in. While I admit it's not the right tool for every job, but I feel a great sense of job when it IS the right tool because writing code in it always makes me happy. When I'm writing pseudo-code for someone, I almost always wind up writing something that looks like Tcl (which a bit of OO/functional mixed in). I think there's a number of reasons why I enjoy it so much: - I find it's minimal syntax very easy to work with (for normal cases, admittedly it has it's warts) - I've been using it so long (since about '95) that I tend to "think in Tcl" - The ability to add new control structures to the language makes simplifying other code (ie, adding try/catch/finally to the language yourself) amazing. It's somewhat lisp-like (though not as powerful) My use of Tcl over the years has spanned many different environments - Interacting/automating network hardware tasks (SNMP, Expect, device scripting) - AOLServer - Vignette - Personal tasks (lots of them) - (minor) modifications to the core - Plugins/Scripting for various other programs

schlenk 12y ago

I don't write much Tcl the last few years (mostly Python now, as it pays the bills), but looking from the Python perspective towards Tcl, i see a lot of good things i left behind: * No GIL. Real threads with no silly global locks * A very cool VFS layer, a bit like the stuff you can see in windows powershell with the Registry/Certstore/etc drives * A beautiful implementation really worth a read (no silly 'XXX: don't know what to do, lets print to stderr' inside a library like you find in pythons source) * An extremly consistent language far more than python which does all kinds of junk 'to make parsing easier' even if it makes the language harder * Sandboxing interpreters (doesn't work with python, no chance) * Stacked channels and a cool streams abstraction (Pythons io module is still some way behind its options) * A built in event loop (Python just got one with 3.4...) * A standard lib that mostly takes event driven as given (unlike pythons blocking stuff) * very powerful metaprogramming support (e.g. have some logging code with 'ZERO' overhead when disable at runtime) * good C-API and excellent support for embedding * Stable ABI since more than 10 years (e.g. you can load a binary extension compiled against 8.1 into a current 8.6 interpreter and it just works, one of the reasons many Tcl projects didn't release new versions, no need. Unlike the python nonsense with -2.5,2.6,2.7 versions for every package, okay Python got a partial stable ABI now too, years later) * mostly sane platform abstractions (the world isn't posix everywhere) * packaging with starpacks (python's pyinstaller comes close, but lacks the VFS stuff, years later), a bit like cross-platform OS X app bundles * Non mutable values by default, no pointers, so it is kind of functional * A nice package system that doesn't mix up filesystem layout and namespaces and supports version So if you look at it, it is kind of a weird crossover between ideas you now find in: Go, Node.js, Lisp, Powershell. Just a bit outdated and in need of some love.