Why Tcl? (gist.github.com)

It's weird, I spent 3 years working on one of what must have been the largest TCL codebases in existence, since then I've reached for the language exactly zero times in personal or professional use. I have very little fondness for the language.

Because you work in semiconductor industry.

I've actually found some use for it as a lisp-ish shell scripting language, when the project grows too large for a bash script. In cases where there's a lot of interaction with the OS and a lot of text processing that has to be done on the results, python just gets in the way and TCL is well suited for that.

I found Tcl hard to write, read and debug. (But I'm quite impressed with some of Ousterhout's writing.)

In contrast, Python is easy to read, write and debug.

I quite like the small footprint of Lua as an embedded script language, which is easy to read, write and runs relatively fast.

I'd probably use Lua or a Scheme as an embedded scripting language if I had the need (generally, I try to not let my programs get so big that the require embedded scripting, but instead attempt to create orthogonal CLI commands that do one thing well and that can be scripted from the outside via POSIX sh).

  #!/usr/bin/env tclsh
  
  puts $argv

I kinda wanted to stop reading after this example. It feels dishonest to start with an example for which there is a builtin. Why didn't you show instead how to output arguments joined by a comma or some other separator instead of space. If I were to update the Go or Python examples to use another separator, it'd be just a 1-2 character change, whereas for Tcl I have no idea how that would look.

     puts [join $argv]

     puts [join $argv ,]

     puts [join $argv ", "]

     package require csv
     puts [csv::join $argv]

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, I find TCL is a dead end for a programming language - the negatives accumulate too quickly.

Tcl is a little gem of programming lore, an ugly duckling story where the ducklings are LISPs instead.

One of the most mind-blowing things to me as a (perpetual) Tcl noob is that when you look at

    proc my_function {x} {
        puts $x
    }

You are lead to believe it is an ordinary C-inspired language with an odd syntax. It took me an embarrassingly long amount of time to realize that

    proc my_other_function "x" "puts \$x"

Is equivalent to the former. Other little oddities like `upvar` are beautiful once you understand them. It has some warts but Tcl has never had the luxury of under the scrutiny that languages like Python or Ruby have had. This is one of the reasons I would really like to see a "modern" version of Tcl more suitable for programming in the large---something that happened to Python 3 almost as an accident, imho.

Most of the digital semiconductor design EDA / CAD tools from Cadence and Synopsys use Tcl as the built in scripting language. I have to work with thousands of lines of Tcl code whether I want to or not.

I learned Tcl / Tk back in 1995 because I wanted to write GUI programs and Hello World in Motif was about 2 pages of boiler plate code while in Tcl / Tk it was about 2 lines.

Then I started in the chip design world and Tcl took over so it was good that I already knew it. I was teaching the older engineers Tcl so it helped me gain their respect.

    foreach line [split $file \n] {
            incr count($line)
        }

       foreach {line n} [array get count] { 
            if {$n > 1} {
                puts "$n\t$line"
            }
        }

......

IMHO that's hard to grok. count shows up in the middle of a loop and it's not clear to me what it is. Could be a function, an integer, a map, or an array.

Same problem with this:

>foreach {line n} [array get count]

Not really obvious what any of this does. Guessing it's taking a map, converting it to key/value array, and iterating.

    for dish, price := range menu {
        fmt.Println(dish, price)
    }

    for key, value in menu.items():
        print(key, ' is ', value)

    for (key, value) in hashmap {
        println!("{} {}", key, value);
    }

Every few years I use Tcl/Tk and the most common reasons are:

1- It's easy to make an executable for Windows (as well as running it on Linux);

2- It's easy to write a GUI.

One thing about scripting languages is that it doesn't seem like a hugely meaningful choice anymore.

GPT-4 can easily generate trivial scripts in any language.

Any complex codebase can be maintained in a typical language.

The Python and Tcl programs don't do the same thing. The Python output is in most-common order, which requires a sort. The Tcl one is in arbitrary order.

The idiomatic Python matching what the Tcl code does is:

    #!/usr/bin/env python

    import collections
    import sys

    for p in sys.argv[1:]:
        try:
            with open(p) as f:
                c = collections.Counter(f)
                for k, v in c.items():
                    if v > 1:
                        k = k.rstrip("\n")
                        print(f"{v}\t{k}")
        except Exception as e:
            print(f"dup: {e}")
            continue

Except, even then there are three differences:

1) the Tcl code accumulates the counts across all the files, the Python code resets each time. Though the Tcl code reports the counts after each file???

2) the Tcl code has a file descriptor leak (one of the big issues I have with Tcl is in dealing with resource management. I've used an upvar with a delete trace to emulate local scope, but that makes passing the result upstream tricky).

3) the Tcl code includes the empty string "" after the final newline in the count, which doesn't make sense.

To show the issue, I've replace the Tcl code so it outputs quotes around the line:

                puts "$n\t'$line'"

and set the file descriptor limit to 10 before having it read a file containing only two lines, each containing "A":

  % printf "A\nA\n" > x
  % limit descriptors 10
  % tclsh dup.tclsh x x x x x x x x x x x
  2 'A'
  2 ''
  4 'A'
  3 ''
  6 'A'
  4 ''
  8 'A'
  5 ''
  10 'A'
  dup: couldn't open "x": too many open files
  dup: couldn't open "x": too many open files
  dup: couldn't open "x": too many open files
  dup: couldn't open "x": too many open files
  dup: couldn't open "x": too many open files
  dup: couldn't open "x": too many open files
  % python dup.py x x x x x x x x x x x
  2 A
  2 A
  2 A
  2 A
  2 A
  2 A
  2 A
  2 A
  2 A
  2 A
  2 A

I wonder how many folks learned of tcl/tk cause of eggdrop.

Because you are forced to. That's the only reason.

Otherwise please use something modern and sane like Deno, Python, Go or even Rust.

TCL has many large flaws that those languages don't share:

* No static typing so trivial errors are not caught early and code is difficult to understand and navigate.

* Everything is a string (TCL people try to claim otherwise but semantically it really is true). This leads to typing mistakes too.

* Quoting is a mess. It's simple in that the implementation is simple, but languages shouldn't optimise for that alone. Actually getting quoting right in TCL is ... well it's not as bad as Bash or even YAML but it's still something you have to think about, which isn't true for any of the other languages I listed.

If you need a language to embed in your program then while I'm no Lua fan, it is at least significantly better than TCL.

My biggest question about TCL--pronouncing it: T C L (each letter pronounced on its own) or tickle. I've heard it pronounced both ways by different programmers

TCL is a primary language for sqlite testing: https://www.sqlite.org/testing.html

I never liked TCL because the string quoting rules were almost as bad as Shell's. For small scripting I prefer Lua.

The only two times I've touched something remotely tcl was - working on Metal Gear Solid's port from PS1 to PC - it used TCL-like scripting language for the levels, functions were main-like, e.g. "Chara_Init(int argc, const argv[], / something else here */)", and then it was quickly parsing arguments (like tcl) to initialize initial state and types of characters/items/etc.

The second one was through Maya, if you can call maya's language tcl.

It was fascinating to me back then, but nowadays I'm leaning more and more towards static typing.

This brings back memories. I used TCL/Expect for automating 3rd party software we were told could not be done. TCL/Expect: Hold my beer!

  > Ousterhout's dichotomy claims that there are two general categories of programming languages:
  > 
  > low-level, statically-typed systems languages
  > high-level, dynamic scripting languages

I understand that this may have seemed somewhat more true at the time it was originally stated, but it's not really been true since the '90s, and it's certainly not true now. What an odd thing to lean into in this day and age.

The author should rather be honest and say "I like TCL just because", instead of coming up with contrived examples to state alternatives are bad.

E.G, in the Counter snippet, why make some complicated code when Python is designed to make it simple?

    import sys, collections

    for p in sys.argv[1:]:
        try:
            with open(p) as f:
                for k, v in collections.Counter(f).items():
                    if v > 1:
                        print(v, "\t", k, end="")
        except Exception as e:
            print("dup error: ", e)

I don't buy the argument of simplicity here. Also, if you are going to just do "get", you don't need requests, the stdlib is fine.

And I don't get the speed argument either, given his script uses most_common(), that basically sorts the entire dict, which none of the other codes do. Yes Python is likely slower, but let's not push it.

Also the Go code is more complicated, but you can cross compile it and ship it as is. And it's fast.

I get it, TCL is cute, but making up arguments is not selling it.

  (each ((file *args*))
    (catch
      (dohash (k v [group-reduce (hash) identity (op succ @1)
                                 (file-get-lines file)
                                 0])
        (put-line `@v\t@k`))
      (error (e)
        (put-line e *stderr*))))

  import sys
  print(*sys.argv[1:])

Reminder that TCL was programmed at a time when SPARCstation IPXes with a maximum of 96MB RAM were being used.

Some of the lower-end SPARC machines could only have 16 or 32MB RAM and had perhaps 10 to 12 MIPS of computing power.

Expect, which became a very important extension of TCL, was released in 1990, when the SPARCstation 1+ with about 15 MIPS and max RAM of 128MB was introduced.

Thus any extension language like TCL had to be small and efficient; especially when you consider it was designed to be embedded inside another program.

Sure its good but its a one off script, so who really cares how fast the startup is? Or how elegant it is? I can literally ask LLMs to write a rough working code in seconds and I only need to fix it up a little bit. There's way more resources to find solutions in Python out in the wild that I can leverage.

I would imagine if you just have a tiny bit harder problems, the Tcl code quickly becomes unwieldy and you end up digging through the archives to find some wizard's tome (or maybe there's a large community of Tcl users out there? IDK).

I can easily spin up a GUI in an hour tinkering with PyQt. Can you do the same in Tcl?

DSLs like this tend to have a very nice local maxima. But once you stray away from its original use case you start writing some really confusing code.

The author should investigate their networking setup. I can run their Go fetchall example in no more than 70ms. Their benchmarks are surely dominated by noise.

No Perl comparisons? I must be a dinosaur, but Perl is the best for reading in text, regex matching/search/replace/, and outputting a transmorgified result.

my espresso machine has software written in TCL and within the group of owners/hackers it's quite the bit of drama how much everybody regrets the original developers choice for it and his insistence it is still a good choice. personally, i value language aesthetics highly and TCL is an ugly one.