5 ms·

> One of my fondest memories working with Tcl was in the EDA industry. Thanks to its legacy, Tcl/Tk enjoys widespread usage in the entire workflow - from logic

by dded 13y ago

> One of my fondest memories working with Tcl was in the EDA industry. Thanks to its legacy, Tcl/Tk enjoys widespread usage in the entire workflow - from logic design to sign-off Those of us actually using EDA tools are not necessarily so fond of Tcl. Not me anyhow. Tcl is awkward to debug, and its everything-is-string semantics make programming an exercise in quoting. Just when I think I understand the scoping, I screw it up. > Despite its odd syntax Tcl's syntax is one thing that I actually do like about the language. It's odd, yes, but it's simple and clean. > Tcl is one of the rare examples of a functional programming language actively used in the industry (I'm looking at you Lisp). Cadence actually uses a real Lisp in some of their tools; they call it Skill. Skill is, in fact, a joy to code in; and I greatly prefer it to Tcl. They also have a lexically scoped version called Skill+, which I've never got to use. > wishing that something like Python would replace [Tcl] Python, yes! Or Scheme. Or even Perl. I don't know Lua, but have always imagined it to be better than Tcl and it seems to occupy a similar niche. But no one even talks about Tcl getting replaced.

taway2012 13y ago
> everything-is-string semantics make programming an exercise in quoting. Is your code filled with literal strings? Otherwise why your code be "an exercise in quoting"? re Python: Remember that EDA tools aren't libraries, they're actual command line program programs. So those tools will still need a command line language. Python is horribly unsuited as a command line language, so the tool will probably continue to have Tcl to present the text user interface. So you'll then end up with two interpreters in the same tool. Hardly a desirable state of affairs. So yeah, I think the ROI of embedding Python in EDA tools is probably not doing to be worth it. A lot of the C code backing the Tcl APIs directly build Tcl objects or store pointers to Tcl objects in C. It will be giant task to make those APIs work correctly with Python also.
- davidw 13y ago
  I think a lot of the EDA people learned just enough Tcl to kind of sort of do stuff, and perhaps did not learn enough, or put that much effort into writing it well. Also, a lot of those packages are pretty old and thus could not take advantage of a lot of the improvement in the language over the years. That's just what my spider-sense says though - I've never actually looked at those things or their code.

by dded 13y ago

taway2012 13y ago

> everything-is-string semantics make programming an exercise in quoting. Is your code filled with literal strings? Otherwise why your code be "an exercise in quoting"? re Python: Remember that EDA tools aren't libraries, they're actual command line program programs. So those tools will still need a command line language. Python is horribly unsuited as a command line language, so the tool will probably continue to have Tcl to present the text user interface. So you'll then end up with two interpreters in the same tool. Hardly a desirable state of affairs. So yeah, I think the ROI of embedding Python in EDA tools is probably not doing to be worth it. A lot of the C code backing the Tcl APIs directly build Tcl objects or store pointers to Tcl objects in C. It will be giant task to make those APIs work correctly with Python also.

davidw 13y ago
I think a lot of the EDA people learned just enough Tcl to kind of sort of do stuff, and perhaps did not learn enough, or put that much effort into writing it well. Also, a lot of those packages are pretty old and thus could not take advantage of a lot of the improvement in the language over the years. That's just what my spider-sense says though - I've never actually looked at those things or their code.