Live data from Hacker News

Why You Should Not Use Tcl (1994)

groups.google.com

11–20 of 55 posts

Re: Why You Should Not Use Tcl (1994)

#11

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…

If you go through the linked discussion on google groups you'll find Guido van Rossum advocating for using python :P

Re: Why You Should Not Use Tcl (1994)

#12

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…

I disagree, Python is exactly the glue language that Ousterhout was describing.

Re: Why You Should Not Use Tcl (1994)

#13

My 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 Tcl scripting language grew out of my work on design tools for integrated circuits at the University of California at Berkeley in the early 1980's. "

History of TCL, https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php

Re: Why You Should Not Use Tcl (1994)

#15

Earlier 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.

I can't understand why anyone would decide to write anything complex in Python.

Re: Why You Should Not Use Tcl (1994)

#16

Earlier quoted context omitted.

Stallman is always right, if you're willing to wait long enough.

if Stallman is the answer, it must be a pretty intolerant question.

the joke is the Stallman fanbois downvoting the comment about Stallman being intolerant of opposing opinion.

Re: Why You Should Not Use Tcl (1994)

#17

My 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…

I have hated industrial automation software from a particular manufacturer, but Structured Text, while a crappy language, was the least of my issues. The tools were really bad and the provided codebase amateurish.

Maybe it's a similar situatuon with these expensive proprietary EDA tools often being quirky?

Re: Why You Should Not Use Tcl (1994)

#18

My 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…

I understand how you feel, but if EDA had settled on Python, many of the same things we see would still be prevalent. They would be slightly reduced due to Python being a slightly less dynamic language than TCL but I am not sure it would matter.

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.

Post reply on HN