Why Tcl?

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.

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.

The gist of those examples in TypeScript:

EXAMPLE 1: Echo command-line input

    console.log(process.argv);

EXAMPLE 2: Count duplicates in a file

    import { readFile } from "fs/promises";
    readFile("0.txt", "utf-8").then((text) => {
      const frequency: { [line: string]: number } = {};
      text
        .split("\n")
        .forEach((line) => (frequency[line] = frequency[line] + 1 || 1));
      Object.entries(frequency)
        .filter(([key, value]) => value > 1)
        .forEach(([key, value]) => console.log(value, key));
    });

EXAMPLE 3: GET request

    fetch(process.argv[2]).then(console.log).catch(console.error);

EXAMPLE 4: GET parallel requests

    process.argv.slice(2).map((url) => {
      const start = Date.now();
      fetch(url).then((res) =>
        console.log(
          `${(Date.now() - start) / 1000}s`,
          res.headers.get("Content-Length"),
          url
        )
      );
    });

Using the author's criteria, relative to Tcl, these implementations (to me) are:

1. Significantly shorter, just as expressive, and familiar to millions of (JS/TS) devs

2. Fast, owing to Node.js/V8's insane optimization level

3. Strongly typed

But you know what? I don't care much about terseness or speed when writing scripts. Honestly, the real reason I use TS for scripts is simple: comfort. I'm comfortable and productive with it. Everything else is just post-hoc rationalization. I'd wager it's the same story for many of these "Why <language/tech>?" posts.

It's perfectly fine to use something simply because you like it -- you're in good company. :)

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.

  #!/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.

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.

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).

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.

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

How about some PowerShell instead?

# Echo command-line input

    $args -join " "

(Yes, it's a single line.)

# Count duplicates in a file

    $lines = @{}
    foreach ($path in $args) {
        cat $path | % { $lines[$_] += 1 }
    }
    $lines.GetEnumerator() | % { if ($_.Value -gt 1) { "$($_.Value)`t$($_.Name)" } }

# GET request

    param($url)
    irm $url

# Parallel GET requests

    $before = get-date
    $args | % -parallel {
        $res = iwr $_
        $after = get-date
        $time = ($after - $using:before).TotalSeconds
        "${time}s`t$($res.RawContentLength)`t$_"
    } -ThrottleLimit 12345
    $after = get-date
    $time = ($after - $before).TotalSeconds
    "${time}s elapsed"

I'm showcasing a few different ways of doing things: using $args, using the param directive; using foreach, or % which is an alias of ForEach-Object; irm for Invoke-RestMethod, iwr for Invoke-WebRequest...

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.

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.

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.

    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.

Because you work in semiconductor industry.

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.

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.

  > 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.

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

As others have said, Tcl has some unique advantages.

My preferred one, which I have not found in other languages (besides LISP, obviously): treat data as code.

This way your configuration files are Tcl code using some proc's that you have defined, but they can also include arbitrary code. In order to read them, you simply fire up a slave (safe) interpreter and get the results.

If anyone knows how to do this easily in Python, I'm all ears!

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!

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 have a tcl/tk distribution (now IronTcl 8.6.7) with tcllib on each computer I use since a lot of time. It's very handy : md5 and other hash tools ? tcllib. Quick and simple representation of data as graph and calculations ? tcllib. Simple data structuration ? Tcl dicts. String search/substitutions/regex ? pure tcl. batch operations on files/folders ? pure tcl. Easy and fast database with sqlite ? Tcl sqlite lib. Custom menu and app launcher in your desktop ? Pure Tcl. Hex and binary file reading and formating ? Pure tcl. And so on. As a public administration worker, Tcl Tk helped me working very faster for a lot of tasks.

The article is so laughable.

1. Of course "Hello world" takes more lines in Go than Python or Tcl. But that does not mean anything. The "overhead" here will become meaningful for larger scripts/projects, and Go or Python are far more capable of much more complex things than Tcl. This is simply a dumb example.

2. Other than certain circumstances, I never heard any one care about scripting performance on the ms level. Often not even at 1-2s (which rarely happens anyway). Putting a table out there and say "this is faster by <1ms" is meaningless to anyone other than the author.

I just remembered the Decent Espresso machine has its UI written in tcl/tk https://decentespresso.com/

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

For me for Tcl to be relevant again its needs

1. a Package Manager (they sort of already have one called TEA, but its not active as far as I know)

2. an IDE or a good modes for the popular editors (VS Code, Emacs, Vim, Sublime Text)

For a UI language the absense of a good IDE or editor modes is very strange, you would expect that a Tcl/Tk IDE written in Tcl/Tk (one that also serve as UI framework or scaffolding for other apps) would be its killer app, but there isnt one

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.

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 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.

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.

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.