Unfortunately. It's not too bad for interactive use (it's somewhere between Bash and Python in terms of sanity; maybe closer to Bash). The problem is people end up writing huge scripts and workflows all TCL which is just way beyond its wheelhouse. Often with a bit of Make and Bash thrown in to make it especially awful.
Sadly there is no end in sight because all of the proprietary tools use it and you can't really do anything about that.
They did add a bytecode runner in one version of TCL and I experimented with making a new language that would compile to TCL bytecode, but unfortunately one of our tools (PowerArtist I think) still bundled TCL from 2005 or so and didn't support it.
I also experimented with a WASM to TCL transpiler, and got it to work a little, but the WASM spec is actually quite big and the TCL code you get out is huge so I don't think that is the right way really.
The only good thing about TCL is that it's value based, not reference based. Value based languages are much more intuitive and easy to reason about, but unfortunately most languages are reference based.
In JavaScript, Java, C#, Dart, Python, etc. it will print 3 because a and b are references to values.
In C++, Rust and TCL, (and maybe Go? I don't remember) it will print 1 because a and b are values.
In value based languages you need explicit syntax to make references and dereference.
In reference-based languages you need explicit syntax to copy values. Often this is omitted entirely which is quite annoying. Until very recently the standard solution to copy a variable was to serialise it to JSON and back again!!
Also worth noting that for immutable values (i.e. all values in Haskell, strings in JavaScript, etc.) there's no observable difference between the two.
The two dominate EDA companies are Cadence and Synopsys. All of the digital design tools for synthesis, place and route, and static timing analysis use the Tcl language as the built in scripting language. These tools have literally thousands of built in commands.
You can look up some of the tools like Cadence Innovus that I use every day. A single license has a list price of over $1 million. We get big discounts because we have about 800 licenses.
https://www.cadence.com/en_US/home/tools/digital-design-and-...
Then you write more Tcl code to script things within the tool. A standard thing is building a power grid. You need to write a for loop to build a metal 1 stripe every 5 microns. That's done in Tcl.
You have a list of clocks you need to define with names and frequencies. Use a Tcl array and a for loop.
Our CAD flow is literally tens of thousands of lines of Tcl code to take Verilog and go through all the steps until we get a GDS file with mask data to manufacture.
The confusion here stems from an acronym collision between Exploratory Data Analysis (where R and related packages like ggplot are popular) and Electronic Design Automation.
LOL, I just thought the person I responded to was confused.
There are so many TLA (Three Letter Acronyms) that are the same across industries with completely different meanings. I was on the ECE subreddit which is for Electrical and Computer Engineering. Someone posted a rant about how annoying these children were, how the pay was bad, and the parents were awful. There were some funny comments about how some engineers acted like children and others about the new grads. Finally someone pointed out that ECE was also Early Childhood Education and pointed them to a different subreddit.
The "ecosystem" would just be, e.g. the suite of ASIC place and route tools, or FPGA synthesis tools, provided by each company. They pretty much all have TCL built in, for to help script them all together.
Each individual script is typically very ad-hoc, to address a specific shortcoming in a tool, or to get a particular mix-and-match of tools from various vendors integrated into a design pipeline.
That being said, it is an ancient and venerable tradition, dating back to the creation of tcl itself, and as long as we're making chip from Silicon it will be the duct tape holding it all together.
Not really. Most of the tcl that gets written is very straightforward and business-logic. The framework you're using is pretty much just the host tool. Trying to integrate other libraries is often difficult if the tcl runtime is missing some features (looking at you, xilinx...)
It can but that's working against the design. How you are "supposed to" do it is write reusable standalone objects in C (think the old CORBA way of doing things) and then write a TCL script as the main skeleton of your program that calls them when needed.
And now that I think of it I think the really orthodox way to do it was to write your whole program in TCL, then profile it and if you needed performance improvements use C to implement some of your more expensive blocks. The TCL library for C let you compile a shared library that the TCL interpreter would load and add the functions you wrote in C as new commands to the language.
There really isn't an ecosystem. It's mostly just used for driving the tools and describing the configuration. For example, if you needed to generate power straps for an ASIC, you'd add a line to your place-and-route tcl script to generate them.
Sadly there is no end in sight because all of the proprietary tools use it and you can't really do anything about that.
They did add a bytecode runner in one version of TCL and I experimented with making a new language that would compile to TCL bytecode, but unfortunately one of our tools (PowerArtist I think) still bundled TCL from 2005 or so and didn't support it.
I also experimented with a WASM to TCL transpiler, and got it to work a little, but the WASM spec is actually quite big and the TCL code you get out is huge so I don't think that is the right way really.
The only good thing about TCL is that it's value based, not reference based. Value based languages are much more intuitive and easy to reason about, but unfortunately most languages are reference based.