It's the scripting language of the EDA industry. If you're designing computer chips, you're using TCL. Cadence and Synopsys standardized on TCL 30+ years ago.
It's strength is that you get to operate EDA tools as if they were shell script commands, like run_my_task -option_a -option_B
If you aren't designing computer chips, you have no reason to use it. It's a horrible language.
The sooner the EDA industry can get rid of TCL, the better.
A long time ago as a college student I used Tcl in an EDA internship. It was awful for reasons completely unrelated to Tcl. There was a library of tool-specific primitives. The primitives were badly documented, badly tested, and nobody actually understood how any of it worked except cargo-culting and copy-pasting each others' scripts. Code only worked on the happy path and there was almost no thought given to edge cases. There was no culture of code review so nobody scrutinized your code to find out whether you were using Tcl in the right way or not. I'll grant, though very lightly, that Tcl has more accessible metaprogramming facilities than Python which makes it easier to misuse than Python. Similar to how Ruby in the hands of a undereducated/bad Ruby programmer is also quite gross.
But I had the same issues using Perl in the EDA industry. The conclusion I came to was that code standards were just abysmal in EDA because code was largely seen as a cost-center activity rather than a profit-center activity as the real output was the ETL or the device and not the code that went into it.
I re-learned Tcl when I was older and when my time in EDA was a faint memory and I found the language a joy. It was remarkably easy to get started in and really easy to build an application out of. This experience further made me reflect on how bad the code culture in EDA was.
So I'm curious what specifically you'd see the EDA industry move to and how you think it would fix the problems EDA currently has with Tcl. Python, is the successor I imagine? That said my actual time in EDA was very short so I welcome the opinion of an actual insider.
It's basically like shell scripts, and really only useful for running shell-like commands. You don't want to do anything complicated with it, such as any direct data processing. I mean, you can, but your code is not going to be readable. As a Cadence Applications Engineer, I had to decode so many customer TCL scripts, some tens of thousands of lines, to figure out what they were trying to do. It's not fun.
As a language, Python is the correct answer.
And now, Python just has so much more widespread support. You can get any library you want in Python, with its millions of packages available. Want to do some AI processing on your schematics while printing out a graph? There are all sorts of libraries for that. You can't get that in TCL.
> If you aren't designing computer chips, you have no reason to use it. It's a horrible language.
What an unfair statement to make; by no means is it an horrible language. Just because it doesn't fit your tastes doesn't make it "horrible".
That's like me saying having to start a line of Python with three spaces is annoying design which makes it an horrible language. Take your statement elsewhere.
It's strength is that you get to operate EDA tools as if they were shell script commands, like run_my_task -option_a -option_B
If you aren't designing computer chips, you have no reason to use it. It's a horrible language.
The sooner the EDA industry can get rid of TCL, the better.