3 ms·
Although I never used Tcl myself, I've worked in/with teams that need to interface with these EDA tools, and most of the folks there are not SW programmers, but
by BeetleB 3y ago
Although I never used Tcl myself, I've worked in/with teams that need to interface with these EDA tools, and most of the folks there are not SW programmers, but electronics folks who need to write Tcl to get their job done.
Their code sucked like crazy. Usually in such teams you are not evaluated by the quality of code.
Ever since then, any time I'm job hunting and I see a listing for a SW programmer that mentions Tcl, it's always been for EDA tools and I run in the other direction.
- i_am_a_peasant 3y agoat my last job we used tcl for manufacturing tests automation. it was way better than the dsl they previously had. tcl was chosen because it was easy to port an interpreter to their c++ test automation framework
- zwieback 3y agoMaybe because EDA users think in terms of hardware description languages like Verilog. When I realized that they have to start with things as basic as clock edges and registering signals it dawned on me that that mindset also lends itself to TCL code unpalatable to SW engineers.
- doix 3y ago> Their code sucked like crazy. Usually in such teams you are not evaluated by the quality of code. I worked in the semiconductor industry, specifically writing internal tools. I had to look at _many_ tools/scripts written in Tcl/SKILL/perl/awk/sed with some code being 30 years old and still being used. Honestly, it wasn't the worse thing. There was usually very little abstraction, the code pretty much always told a story of what the writer was trying to achieve. Naming things was usually pretty bad and you'd get into some pretty gnarly regex/string matching, but at least it usually wasn't some over-complicated highly flexible but also restricting in-house framework.