Comment by iberator

Which is exactly the quoted text.

> Living proof that languages doesn't need forced types.

The opposite surely? TCL is practically dead, and only lingers on in the EDA industry (which has zero taste). Virtually every successful language today has at least a few different basic types for numbers, arrays, strings, maps and so on.

I'm aware. It's awful because of the implications for the programmer, not the runtime.

The convenience of not having to marshal data over a network is certainly a use case. But I'll admit that two of the worst programs I ever saw were written in Perl and TCL. Somehow just a big jumble of inscrutable regexes.

When "everything is a string" then you have no choice but to literally treat everything as a string. Painful. Very cool project though.

It's a combination of cumbersome syntax and the vendor's poor API design and execution environment.

For a syntax example, compare python to Tcl. In python, there's a compact array lookup operator, and dictionaries allow string keys:

  mydata["channel"][2]

Tcl, however, requires a function call to access an array index, resulting in nested function calls with magic numbers for the simplest expressions:

  lindex [lindex $mydata 35] 2  # Tcl 

Then there isn't any static type checking so you have to run code to see if it would work; the shape of a return may surprise you. Connecting to hardware may be your only opportunity to exercise certain code paths.

So for any non trivial task, Tcl becomes effectively write-only.

Some tools allow you to export Tcl scripts that automate tasks like project creation to help you avoid tracking intermediate objects in source control, but because the Tcl cwd path can change throughout a script, they export every source path as a hard coded absolute path, including whatever developer's home directory it might be residing in. This is not suitable for source control (because it would preclude building on any other machine) so then you have to post process these scripts before tracking them. But since it's Tcl there aren't good scriptable tools for programmatic Tcl AST manipulation, so you have to modify these files with some sort of a state machine, looking for various sentinels to trigger the various string replace behaviors you need. It's not all Tcl's fault, but if a vendor is only using Tcl for automation and you need automation, you have a battle ahead of you.

Outside the language, you'll often find that your runtime tool locks the UI thread to run your scripts, so long running operations are impossible to pause or cancel. And I've never seen a vendor expose adequate objects to allow full control, so often, the critical actions you hoped to automate are only possible through the GUI.

In the 90s, an integrated Tcl interpreter was a good sign that your vendor cared about developers. Today it's more a sign of neglect.

My experience with Tcl is 30 years of using EDA tools, all of them equipped with this language from hell. Luckily, I've been to restrict the scripting part to the minimum. I'm sure that if you know the language well, you can see the foundational model that's behind it, but for occasional users, there's nothing predictable about it.

I couldn't tell you exactly all the thing that are wrong with it. Let's just say that a language where this is ok:

puts "Hello"

But this is not:

puts "Hello" # A comment

shouldn't exist.