See also Ousterhout's reply: https://groups.google.com/g/comp.lang.tcl/c/7JXGt-Uxqag/m/vQ...
Ousterhout's main argument seems to be: > This is the proposition that you should use two languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions. Thankfully, today, we have great programming languages, like Python, tha…
Why You Should Not Use Tcl (1994)
11–20 of 55 posts
Re: Why You Should Not Use Tcl (1994)
#12See also Ousterhout's reply: https://groups.google.com/g/comp.lang.tcl/c/7JXGt-Uxqag/m/vQ...
Ousterhout's main argument seems to be: > This is the proposition that you should use two languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions. Thankfully, today, we have great programming languages, like Python, tha…
Re: Why You Should Not Use Tcl (1994)
#13My only issue with Tcl is that aweful, aweful language that one way or the other managed to become the language of choice for EDA tools. I hate it with a passion. Other than that, it’s fine…
History of TCL, https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php
Re: Why You Should Not Use Tcl (1994)
#14Re: Why You Should Not Use Tcl (1994)
#15Earlier quoted context omitted.
Ousterhout's main argument seems to be: > This is the proposition that you should use two languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions. Thankfully, today, we have great programming languages, like Python, tha…
I can't say I enjoy large software systems written in Python.
Re: Why You Should Not Use Tcl (1994)
#16Re: Why You Should Not Use Tcl (1994)
#17My only issue with Tcl is that aweful, aweful language that one way or the other managed to become the language of choice for EDA tools. I hate it with a passion. Other than that, it’s fine…
Maybe it's a similar situatuon with these expensive proprietary EDA tools often being quirky?
Re: Why You Should Not Use Tcl (1994)
#18My only issue with Tcl is that aweful, aweful language that one way or the other managed to become the language of choice for EDA tools. I hate it with a passion. Other than that, it’s fine…
The problem with EDA automation software is that it has been historically written by people with low skill in software development. Their domain of expertise is hardware. These shops also have not had for the most part a cohesive culture that spanned projects. For an org that focuses on digital design, the other 80% of that task is verification, but this has been prone to outsourcing and has had more churn on project to project.
I could be wrong, as I am outsider in this industry but this is what I see from my interaction with the EDA space. It puts up with horrible bugs, tools are hard to compose, the installers are crufty and target ancient OS versions. The secrecy within in the industry itself has made it a very late participant in open source.
So much conspires against any language that EDA would adopt.
Re: Why You Should Not Use Tcl (1994)
#19Of course, these days, Python also has Expect-like capabilities, so.
Re: Why You Should Not Use Tcl (1994)
#20Tcl needs to change to a Lisp Like syntax and add a package manager to survive. My thoughts.