5 ms·

I'm more surprised Tcl was used in 2009 than I am at any praise or complaint about the quality of Tcl. I used Tcl and Expect (which was a very cool extension o

I'm more surprised Tcl was used in 2009 than I am at any praise or complaint about the quality of Tcl. I used Tcl and Expect (which was a very cool extension of Tcl) in the late 90s in some automation projects as an intern. It did the job and yet I was aware of some of it's issue. But that was so far before 2009. It felt like Tcl was almost done by 2000, I never saw it used again. Perl came and went, Lua had arrived, Python had arrived, etc.. Tcl to me is like Python.. pretty good for small projects by a small team. Not so desirable for a giant enterprise product/platform with a big team.

klodolph 3y ago
Tcl is super interesting from a historical point of view. It seems to hit about halfway between shell and Lisp. With some small differences, it probably would have competed more directly against Perl, Python, or maybe Lua. As it is, it gave us Wish, plus a bunch of GUI wrappers for shell scripts, and we’re thankful for those.
- ben7799 3y ago
  I think some of it back then was there was less internet communication and Tcl could be popular one place and Python was popular in another place and Perl popular in another team. Now we discuss everything so much communities converge on a common choice. Perl & Tcl really share the issue that undisciplined developers could make really obfuscated code that was hard to decipher.
yamtaddle 3y ago
> I used Tcl and Expect (which was a very cool extension of Tcl) I used "expect" about five years ago to help automate deploying an app to a local Roku box from the command line. Much faster dev loop than having to upload a zip to a webpage hosted on the Roku box.
sgt 3y ago
Makes me wonder, are there any current projects still using tcl? I know DDG is still using perl.
- bch 3y ago
  F5 iRules, Cisco iOS (afaik), embedded in network storage devices, Argonne National Laboratory Swift/T supercomputer control, …
- fweimer 3y ago
  gitk and “git gui” are written in Tcl/Tk. Some components of the GNU toolchain use dejagnu in their testsuite, which is based on expect and written in Tcl. The SQLite testsuite uses Tcl, too.
- formerly_proven 3y ago
  Python ships with Tcl/Tk for tkinter.
- cmacleod4 3y ago
  Various projects and companies using Tcl are listed at https://wiki.tcl-lang.org/page/Who+Uses+Tcl https://wiki.tcl-lang.org/page/Who+Uses+Tcl .
  - sgt 3y ago
    If it just had a fresher UI it would be just fine for most users.
    - wrenky 3y ago
      I use Tcl daily for work and personally love it! Its syntax is weird but when it clicks things just make sense in a zen way. Much like getting into the groove in lisp or something, it _feels_ correct in that minute. The main problem is just tooling. There are some insanely cool language features like Expect (still the best implementation) or starpacks/starkits, yet there is no basic package manager. You are stuck installing via yum/apt or building from source if you are lucky to find what you need. Most of the time you can just assume there isn't something you can rely on, and you'll have to patch source tcllib (the batteries included library).
- cozzyd 3y ago
  tcl is heavily used in electronic design tools (e.g. Vivado).
deleted 3y ago
[deleted]
antirez 3y ago
I started with the goal to write a C implementation just after I could verify the idea. Yet this is a list of reasons why, back then at least, Tcl was a great choice to write a prototype: - Tcl reference counting automatic mem management is extermely solid: it does not introduce any pause and is very consistent in long running processes. Another language I love is Ruby: when I used it for similar reasons, a few years later, I was shocked by how impossible it was to run long running processes in Ruby because of the garbage collector limitations. - Now many languages support event-driven programming very well, but Tcl used to have this for many many years in 2009, it was rock solid. So Tcl allowed to write something that was not fragile, but only limited in speed and with a large memory footprint. And that served very well as a proof of concept to validate the idea, and then switch to the C implementation. This code never ran in production, if I remember correctly: I stopped the experiment as soon as I saw it working well and as soon as I understood the fork-based persistence I wanted to implement was impractical in Tcl.
- deleted 3y ago
  [deleted]
gilbetron 3y ago
My first job out of college used TCL in 1992, and I made a decent sized application with it. It was neat, but ultimately weird and kind of unwieldy, and definitely fraught with peril! In 1995, I left the job behind, thinking I'd never see TCL again. Fast-forward to 2011 and I found myself in a new job where I was pointed at their middleware to do some enhancement, only to find myself in a TCL application yet again! Hopefully that was the last I'll have to deal with it professionally, although it is kind of a nifty language.
dfinninger 3y ago
I _started_ writing TCL in 2010. This was for EAD automation, and the software only had a TCL API, so probably just a historical quirk. But the company I was with had a lot of it to automate a lot of flows.
lmm 3y ago
TCL had great async I/O back when virtually nothing else did. In a time that was pre-nodejs (I just checked, started in 2009) and when Python async I/O was still a mess (Twisted worked great, but it wasn't easy to work with), TCL would've been the obvious choice for a high-performance network server. (See e.g. AOLServer). (I mean, the functional world had proper async support at that point - I'd probably have used Scala or OCaml - but a lot of people are scared of those languages)
forgotmypw17 3y ago
When I already know what I want to write, especially for MVP or PoC, I reach for the tool I'm most comfortable with. In my case, it is Perl and HTML/HTTP, and I don't care if it's not "en vogue" in the mainstream, it's the quickest language I can prototype with. Just because it's not popular anymore doesn't mean it can't get the job done. Especially if you're not using a lot of libraries, there are many reasons to use a less popular language, and few not to.

klodolph 3y ago

Tcl is super interesting from a historical point of view. It seems to hit about halfway between shell and Lisp. With some small differences, it probably would have competed more directly against Perl, Python, or maybe Lua. As it is, it gave us Wish, plus a bunch of GUI wrappers for shell scripts, and we’re thankful for those.

ben7799 3y ago
I think some of it back then was there was less internet communication and Tcl could be popular one place and Python was popular in another place and Perl popular in another team. Now we discuss everything so much communities converge on a common choice. Perl & Tcl really share the issue that undisciplined developers could make really obfuscated code that was hard to decipher.

yamtaddle 3y ago

> I used Tcl and Expect (which was a very cool extension of Tcl) I used "expect" about five years ago to help automate deploying an app to a local Roku box from the command line. Much faster dev loop than having to upload a zip to a webpage hosted on the Roku box.

sgt 3y ago

Makes me wonder, are there any current projects still using tcl? I know DDG is still using perl.

bch 3y ago
F5 iRules, Cisco iOS (afaik), embedded in network storage devices, Argonne National Laboratory Swift/T supercomputer control, …
fweimer 3y ago
gitk and “git gui” are written in Tcl/Tk. Some components of the GNU toolchain use dejagnu in their testsuite, which is based on expect and written in Tcl. The SQLite testsuite uses Tcl, too.
formerly_proven 3y ago
Python ships with Tcl/Tk for tkinter.
cmacleod4 3y ago
Various projects and companies using Tcl are listed at https://wiki.tcl-lang.org/page/Who+Uses+Tcl https://wiki.tcl-lang.org/page/Who+Uses+Tcl .
- sgt 3y ago
  If it just had a fresher UI it would be just fine for most users.
  - wrenky 3y ago
    I use Tcl daily for work and personally love it! Its syntax is weird but when it clicks things just make sense in a zen way. Much like getting into the groove in lisp or something, it _feels_ correct in that minute. The main problem is just tooling. There are some insanely cool language features like Expect (still the best implementation) or starpacks/starkits, yet there is no basic package manager. You are stuck installing via yum/apt or building from source if you are lucky to find what you need. Most of the time you can just assume there isn't something you can rely on, and you'll have to patch source tcllib (the batteries included library).
cozzyd 3y ago
tcl is heavily used in electronic design tools (e.g. Vivado).

deleted 3y ago

[deleted]

antirez 3y ago

I started with the goal to write a C implementation just after I could verify the idea. Yet this is a list of reasons why, back then at least, Tcl was a great choice to write a prototype: - Tcl reference counting automatic mem management is extermely solid: it does not introduce any pause and is very consistent in long running processes. Another language I love is Ruby: when I used it for similar reasons, a few years later, I was shocked by how impossible it was to run long running processes in Ruby because of the garbage collector limitations. - Now many languages support event-driven programming very well, but Tcl used to have this for many many years in 2009, it was rock solid. So Tcl allowed to write something that was not fragile, but only limited in speed and with a large memory footprint. And that served very well as a proof of concept to validate the idea, and then switch to the C implementation. This code never ran in production, if I remember correctly: I stopped the experiment as soon as I saw it working well and as soon as I understood the fork-based persistence I wanted to implement was impractical in Tcl.

deleted 3y ago
[deleted]

gilbetron 3y ago

My first job out of college used TCL in 1992, and I made a decent sized application with it. It was neat, but ultimately weird and kind of unwieldy, and definitely fraught with peril! In 1995, I left the job behind, thinking I'd never see TCL again. Fast-forward to 2011 and I found myself in a new job where I was pointed at their middleware to do some enhancement, only to find myself in a TCL application yet again! Hopefully that was the last I'll have to deal with it professionally, although it is kind of a nifty language.

dfinninger 3y ago

I _started_ writing TCL in 2010. This was for EAD automation, and the software only had a TCL API, so probably just a historical quirk. But the company I was with had a lot of it to automate a lot of flows.

lmm 3y ago

TCL had great async I/O back when virtually nothing else did. In a time that was pre-nodejs (I just checked, started in 2009) and when Python async I/O was still a mess (Twisted worked great, but it wasn't easy to work with), TCL would've been the obvious choice for a high-performance network server. (See e.g. AOLServer). (I mean, the functional world had proper async support at that point - I'd probably have used Scala or OCaml - but a lot of people are scared of those languages)

forgotmypw17 3y ago

When I already know what I want to write, especially for MVP or PoC, I reach for the tool I'm most comfortable with. In my case, it is Perl and HTML/HTTP, and I don't care if it's not "en vogue" in the mainstream, it's the quickest language I can prototype with. Just because it's not popular anymore doesn't mean it can't get the job done. Especially if you're not using a lot of libraries, there are many reasons to use a less popular language, and few not to.