I wonder if you mean Tcl is bad, or that the damage is caused by Tcl being powerful and obviating the need for version upgrades of special-purpose software. Or something else.
I'm not that guy, but here's my interpretation: tcl is used as the embedded scripting language in the vast majority of EDA tools. In some ways it performs this job quite well, with tool companies providing functions which parse their arguments like inputs to a shell script. For example, you can call
report_timing -from ... -to ...
When the commands have 50 optional parameters, this method of calling is convenient.
However, the problem is that it has been pushed to its absolute limit. Massive automated design flows consisting of tens to hundreds of thousands of lines of often highly unstructured tcl are present at most semiconductor companies. All of this code is written by VLSI engineers who have not much software training. These engineers take advantage of the highly dynamic nature of tcl to solve their problems quickly... and the result is often an unmaintainable mess of code. As an example, I've almost never seen anyone use tcls module system, instead its just scripts using the `source` function to load other scripts.
Since the language is not mainstream among software engineers, there is very little material on best practices, and semiconductor companies are extremely locked down meaning there is no open source tooling to speak of. So VLSI engineers continue producing spaghetti code to handle all of the implementation.
Obviously I am speaking in very broad strokes, so there may be companies out there that do it right.
Tcl itself isn't really the problem. EDA tooling is generally a dumpster fire (queue horror stories about checking bitstream files into VCS because there's no guarantee the compiler will ever spit the same one out again, even if nothing changed), and Tcl is used to make patchwork fixes to glaring tooling issues.
This is all fine and good, but when a vendor can no longer change or fix tooling without running the risk of breaking a large customer's Tcl abomination, the flexibility that it provided is now a problem that's dragging everybody down with it. All of this goes without mentioning that electrical engineers that often get saddled with this aren't very good programmers.
People are excited about SymbiFlow for a reason. The hype in spite of how unlikely it is that it will ever match vendor tooling is a testament to the situation.
The simple fact is that the vast majority of the people writing programs aren't very good programmers, even if they've been trained to be. We need more languages like Tcl and Lua that are quick and easy for beginners to pick up and become productive with. Add easy interfaces to AWS services for back-end programming, and a Tk-like interface that dumps out JS code for web app front-end programming, and you'd have a real winner...
