Why You Should Not Use Tcl (1994)

I had to use TCL at a company where Prof. Ousterhout was on the board. I had used it a bit at university but I was coming from a Python job so, naturally, I hated its syntax BUT:

1. The project was in ancient C++ for many reasons and even the most modern C++ is at least 5x more difficult to write code in than TCL. So why write code that runs once in the life of the program in C++? There's often plenty of code that doesn't benefit from being compiled - that looks for a configuration file, reads and validates lines and calls functions to build initial datastructures...setup code, string handling. You save a millisecond or two by doing it in C++ but only once in a program that runs for hours - why waste all that dev/debug effort?

If you choose judiciously then you can end up doing a lot of your performance insensitive, setup-type code in TCL and a great deal of the time you'll be able to debug and fix bugs in an interpreted language without recompiling anything.

2. Python, though great, has a global interpreter lock. TCL fits in with threaded programs excellently. This can be a make-or-break feature.

3. TCL's syntax which I dislike, seems to map excellently into C - calling C from TCL just seems a lot easier than in python.

Recent and related:

A brief interview with Tcl creator John Ousterhout (2023) - https://news.ycombinator.com/item?id=41017367 - July 2024 (56 comments)

Previous discussions of current submission:

Why you should not use Tcl (1994) - https://news.ycombinator.com/item?id=14944103 - Aug 2017 (52 comments)

Why you should not use Tcl (1994, "The Tcl War") - https://news.ycombinator.com/item?id=7071479 - Jan 2014 (1 comment)

The funny thing for me about this popping up from time to time is, that I like both Tcl and Scheme a lot. Each for their purpose. While certainly not beautiful and never ment to be an implementation language for large-scale applications, Tcl does a wonderful job for its designated tasks. The syntax might seem bizarre, but there is actually a great and simple system behind it, I strongly recommend to read the chapter about the syntax in the book by Ousterhout. Like Lisp Tcl is actually a homoiconic language. And like lisp you can create your own syntax, as required. On top, basic control like function calling, looks more like natural language, little syntax required.

Of course, as programming language, Scheme is much better, and it is the language I use for day to day work. In that respect Stallman is right. However he missed a few important points and that is why Tcl is still so popular, probably more so than Scheme, if you just count users. Tcl didn't just bring a language to the table, it also has an excellent implementation which always was freely available and could be embedded into any software project. It has a nice range of very powerfull tools, Tk obviously the most fameous one. Still today it is one of the most popular GUI toolkits. And that is where Stallman with the GNU project failed. Had they at that time or in the following years provided a comparable Scheme implementation, it would have been extremely popular for application writers. Assuming of course, that it had been licensed under LGPL so that any application could use it. But it took most of the 30 years after this post for Guile becoming an option there.

Tcl is/was worth it for Expect alone, which is humorously best described as "AutoHotKey but for your command line". That sentence feels way more anachronistic than it is.

Of course, these days, Python also has Expect-like capabilities, so.

My only issue with Tcl is that aweful, aweful language that one way or the other managed to become the language of choice for EDA tools. I hate it with a passion.

Other than that, it’s fine…

This is a standard Usenet comment from Stallman, so I don't take it that seriously.

Tcl achieved many things, including the Tkinter GUI with a native look in Windows. Other projects like Python rely on it in the shrinking set of included batteries.

I would prefer if Lisp had won, especially in scientific code, but the C-API is not good enough. Unfortunately, currently Python is popular, so one thing is clear: People want a low level C-API in C with a published low-level interface. All other attempts have mostly failed in terms of popularity, so languages that want to take on Python better take note.

See also Ousterhout's reply:

https://groups.google.com/g/comp.lang.tcl/c/7JXGt-Uxqag/m/vQ...

> auth required pam_faillock.so preauth silent deny=3 unlock_time=never fail_interval=900

I have seen other security theater types suggest this. What a completely stupid idea. If an attacker or even a well meaning script triggers this on the account you have sudo with you are now locked out forever.

Using fail2ban with a temp ban is enough to stop brute force attempts.

I have to agree with RMS that 1994 Tcl was pretty terrible. I remember cursing the lack of structs while using it for a larger program. All of this has been largely fixed in more recent versions.

On the other hand, 1994 Tcl/Tk was the best way to create simple user interfaces, and is (IMHO) much better than current tooling.

Tcl needs to change to a Lisp Like syntax and add a package manager to survive.

My thoughts.

anyone else notice that the 2nd reply to this was from Hal Finney? Wild.