Watching someone learns basics of programming in Python, I realized that Python is actually not that easy to learn for beginners as I thought:<p>1. Types in Python are implicit. It's really hard to explain that they need to always think about what type something is, especially when they haven't grasped the concept of types yet.<p>2. Indentation as part of the language. I thought it's a great thing for beginners, but it's actually confuses beginners that empty space affects your program, e.g. they think that spaces around assignment or arithmetic operators should affect their program too, which is not the case.<p>3. Ranges for iteration -- they just memorize the syntax blindly :(<p>So I started to wonder whether Pascal is better to learn for beginners -- you have to list all the types at the beginning, and no implicit conversions are done.<p>But now I think what about TCL? Maybe it'd be even easier for total beginners?
Tcl forces you to create new data, because you have to think and work harder to introduce effects on variables in upper scope through the use of uplevel and upvar. This reduces side effects significantly and makes data transformation explicit. Which, in turn, reduces cognitive load and increase productivity.<p>Tcl also does not have distinguished NULL value like Python, C, C++, C# and many other languages. You do not have to account for that.<p>The reduction of side effects and no universal no-value value puts Tcl in my hierarchy of programming languages right below Haskell and above pretty much everything else. Tcl is very easy to use when you know how to structure the program.<p>I still use it for various prototyping when I do not want strict type discipline.
I think it's worth pointing out that in the years since this article was written (2006) quite a few new features have been added to Tcl. A few of the more significant include coroutines, robust object-oriented system, tailcalls, apply (lambdas), namespace ensembles, et.al.<p>Of course some of these features were already present in other languages. However, steady improvements to Tcl have pushed the language well beyond how it was described in the article. Definitely not a "toy" but overall as capable as the other scripting tools out there.
What I like most about TCL is that a TCL REPL feels a lot more like a normal command prompt than Lua or Python or whatever. If I’m going to write a complex program, TCL wouldn’t be my first choice, but if a program I’m using has a command prompt (think autocad or the debug console a lot of games have). Plenty easy for one-off commands, but with a simple and powerful programming language there if you ever need it.<p>Put differently: The command line ergonomics of POSIX shell, with the scripting ergonomics of Lisp
Some discussions over the last several months, including just yesterday:<p>* The Birth of Tcl: <a href="https://news.ycombinator.com/item?id=31111220" rel="nofollow">https://news.ycombinator.com/item?id=31111220</a><p>* TclTutor 3: <a href="https://news.ycombinator.com/item?id=30327945" rel="nofollow">https://news.ycombinator.com/item?id=30327945</a><p>* Tcl/Tk Spline Editor: <a href="https://news.ycombinator.com/item?id=29772621" rel="nofollow">https://news.ycombinator.com/item?id=29772621</a><p>* Tcl library for CSP: <a href="https://news.ycombinator.com/item?id=29421786" rel="nofollow">https://news.ycombinator.com/item?id=29421786</a><p>* Why Tcl syntax is so weird: <a href="https://news.ycombinator.com/item?id=29143346" rel="nofollow">https://news.ycombinator.com/item?id=29143346</a><p>* Tcl: Lisp for the masses: <a href="https://news.ycombinator.com/item?id=28957701" rel="nofollow">https://news.ycombinator.com/item?id=28957701</a>
My favourite thing about Tcl is (was? This was 25 years ago) that adding commands just requires a couple of Tcl things, then an argc/argv, so it was relatively simple to turn an existing C program into a Tcl command:<p><pre><code> int my_command (ClientData clientData, Tcl_Interp *interp, int argc, const char *argv[]) { ... }
</code></pre>
However, that might have been the only thing I liked about Tcl. For some binary data import tasks I ended up writing a Perl program that translated it into Tcl.
The thing that I most appreciate about Tcl is that it feels like Unix shell "done right". It is still a bit weird because everything is a string, but it doesn't have all those footguns around variable expansion, such as word splitting. It also has decent support for subroutines and local variables, no weirdness with subshells and so on.
> Every string is internally encoded in utf-8, all the string operations are Unicode-safe<p>This seems <i>very slightly</i> disingenuous, if my memory is correct. I don't remember all the details, but I ran into an issue with a Tcl application a while back and Unicode support. Digging into it, I recall that the Tcl interpreter actually represents every character as a predefined number of bytes, set by a preprocessor definition. The default was 2, and cut off any Unicode character that needed more than 2 bytes to encode, unless you were willing to recompile the interpreter to use 4 bytes, at the cost of doubling memory consumption for every string.<p>Very nitpicky, but I think it's important to point out it's not "quite" utf-8, because Tcl needs each codepoint to be O(1) indexable in an array, something normal utf-8 can't do.
This is nonsense. I have had the misfortune of having to learn TCL (it's standard in the EDA world unfortunately) and it is most assuredly a toy language. That doesn't mean you can't write big complicated programs with it. You can do that with any language. But stuff like this is an outright lie:<p>> There are no types, and you don't need to perform conversions, however, you aren't likely to introduce bugs because the checks on the format of the strings are very strict.<p>You aren't likely to introduce bugs when literally every type is a string. Even lists. Lists are strings. Lists of strings are strings. Maps are strings.<p>It's pretty insane, and the interpreter does some horrible magic so that if you never access a list as a string it can store it <i>internally</i> as a real list (to avoid insanely bad performance) but to the programmer it's still a string and nothing prevents you from treating it as such.<p>I actually made a semi-funcitonal WASM-to-TCL transpiler to avoid having to write TCL. Worked kind of well! Unfortunately WASM is quite large and I lost interest before completing it.
I've managed to work on two TCL codebases in my career, one in 1992ish, and one in 2011ish. I was very surprised to be working on it the second time! I've said it before, but working on TCL is interesting, kinda fun, and ultimately a lesson in frustration once you get to a certain sized codebase. It really hammered home the need for static typing as your repo gets over 50k lines because it is so "type free". However, it is a cool thought experiment for it's premise, which is more-or-less, "what if everything is a string". It has a lot of benefits, and a lot of nasty side effects. I'm glad I spent time doing it, and I think the use case for which it was made ("Tool Control" roughly speaking) it has good ideas. TK was fun, as well, I miss it in some ways. But ultimately, TCL is a dead end for a programming language - the negatives accumulate too quickly.
The idea that Tcl was a toy came from the 90s and the Tcl Wars Stallman was involved with. But to Stallman, anything other than Lisp is pretty much a toy. Tcl is indeed a deep, deep rabbithole -- again, deeper than our dimension allows and lined with toothed cilia... but I can totally see where a person might look in Tcl's deadlights and want to be there.
It might be powerful, and Lisp like, however in any large application eventually the amount of C code in extensions to make it perform, outgrows the TCL code.<p>And then one stars wondering if it isn't better to migrate to something else.
I remember bumping into Tcl as part of Tcl/Tk, during my xwindows days. Never realised there was still so much work ongoing for the language!<p>Reminds me of Forth too... do people still make firmware with Forth?
This article fails to note that Tcl is very closely related to shell script. A lot of the concepts listed already exist in Shell, and nobody complains that Shell is only a toy language.
Fond memories of tcl inside ModelSim - it was not the Lua I was enjoying then but, like using emacs, made me love automation and coding a little bit more.
TCL was my entry into coding back when I was a teenager, haven't touched it in over 12 years or so but I'll always fondly remember it. The title of this post is very familiar to me, I'm sure I read it back when it was published but its cool to now know it was written by the creator of redis which I now use extensively
Overwhelming number of tcl positive comments here. Must be selection bias. Tcl is ridiculous. I propose that anyone who prefers tcl over other top languages in 2022 simply doesn't have productivity or teamwork as their top goal.<p>Do you want your language to help you solve real problems, or do you just enjoy your weird toy from another era? Everything is a string..? Please.