[adunsmoor]

I'm a long time Tcl/Tk user - it's still the defacto standard in the electronic design automation industry.

My own tl;dr for this comment: David makes good points and his experience mirrors some of my own. I think the biggest mistake was not going with a "batteries included" strategy for Tcl releases.

1) Tk got left behind by Qt, GNOME, etc.

I whole-heartedly agree with this. We spent a very long time making our Tk apps fit in on user's Linux based desk tops - tweaking color schemes, widget dimensions, and even adding new widgets that Qt and and GNOME had that Tk didn't (trees, tables, buttons that could show images and labels, for example). Tk has since made this a lot easier but at the time it was frustratingly time consuming.

The author's other point that there were too many ugly Tk apps. Maybe. You definitely could spot a Tk app a mile away. But there are plenty of ugly X apps where X is any GUI framework so I don't buy in to that theory as much.

2) The debate between making Tcl batteries included or not.

In think this is the #1 issue. I love Tcl for quickly stitching together a few apps or processing files. Tcl makes working with the system really easy and it's "everything can be a string" roots can be tremendously useful. But... if you want to do something that's not in the core language - you had to build it yourself. There were quite a few useful external packages but they were often incompatible or tied to specific versions of Tcl etc, etc. Comparing that to the first time I built something in python and needed to process a gzipped file. Just import zlib. Wow!

Every big Tcl project I'm aware of had to devote a lot of energy adding support for some fairly basic - in comparison to other scripting languages - features. Tcl's philosophy was very much like the C language. Keep the core small - let the users work out the rest.

3. Missing default support for object orient programming.

Sure. Maybe. That kind of goes with point 2 above. It wasn't ever so much of an issue for me or any of the projects I worked on.

4. Missing support for some modern conveniences (no PNG, no readline based shell)

Sure. It goes with the batteries included or not theme. It was (and still is in some cases) a sign that tcl was falling behind.

5.Everything must be representable as a string

I spent a lot of time dealing with this. It's incredibly convenient when writing Tcl scripts. It's incredibly difficult when writing C extensions. The Tcl_Obj structure is actually really clever but managing the life cycle of objects is frustratingly complicated.

This is advanced enough of a feature that I don't think it impacts that many people. That said, fixing this flaw might have allowed for more interesting extensions.

6. (I'll add one of my own.) Multi-threaded tcl is not built in. You have to make the choice at compile time. Compiling in support for threads slows down tcl enough to be noticeable for the kinds of people that are interested enough to do multi-threaded programming with Tcl. :-)

[henry_flower]

'it's still the defacto standard in the electronic design automation industry.'

Can you elaborate on that? I know nothing about that industry but I still have some nostalgia for Tcl despite of using Ruby now.

In the past I was a solid Tcl user (couple years ago even did a small custom Linux distro where bash was replaced with Tcl & installater was written in Tcl/Tk. It was fun!)

My thoughts on its ~ 0 popularity are:

* No Rails equivalent.

* No gems equivalent. In modern world it is a disaster. (One could notice how quickly nodejs got its npm.)

* 8.6 and OO system are in aplha/beta stage for 6 (?) years. Many of us just gave up waiting.

I still remember '2007 would be a great year for Tcl.' What a joke.

[adunsmoor]

Tcl is used quite heavily as a command line shell EDA tools. Google "pt_shell tcl" or "ncsim tcl" for examples.

Cadence and Mentor Graphic's digital simulation GUIs were built with Tk. Probably a lot more. The big win for Tk in GUIs in the late 90's was it's cross platform support. For all of its limitations - Tk was a huge improvement over Motif!

Tcl is also used as a data file format for describing desing rules. Synopsys' SDC (standard design constraints) and Cadence's CPF (common power format) are both just design specific variations of Tcl. Writing a parser for these formats just requires writing command implementations. Tcl takes care of the rest.

[henry_flower]

Thank you for the answer.

Never realized that Tcl empire was so broad.

[phalina]

Former EDA GUI programmer here, I feel your pain! The lack of multithreaded execution can be a bitch. Worse is the lack of ways to "group" data together, I don't need full out OOP concepts like classes, methods and inheritance, just simple C structs would improve the flow of large programs a lot.

I also found a few bugs in the file selection dialog code. Someone on my team got an error during bug testing. I traced it to the file selection code built into TK and patched it there. Then I got curious, the same bugs were reproducible in ModelSim.

[helmut_hed]

One more EDA programmer reply, here... Tcl is super easy to embed as a shell for users, either in the terminal window the application is launched from or in a GUI text window. No doubt Tcl's embedability and historical connections to EDA come from Ousterhout's authorship of the Magic layout editor.

Lately I've been trying to embed Ruby the same way, and while I've succeeded, the process has been painful. The "event loop" is a particular challenge. So as far as I can tell Tcl is still leading in this regard. Can anyone chime in about Lua? I've heard some positive anecdotes.

[copper]

Wow, there are a lot more EDA programmers on HN than I'd expected, some of whom I even recognise by name.

On topic, it's probably easier to embed Lua than Tcl, though you may miss some of the libraries. The language is cleaner (in some sense). For an EDA application, the only real problem is what your customer is supposed to do with 20+ years of scripts that they've written that are specific to their flow :)

[kickingvegas]

My distaste for Tcl/Tk helped me leave the EDA business.

Some backstory: Thanks to Randy Pausch, in the early 90's I was fortunate enough to be exposed to Python and the Tkinter interface to the Tk widget set. With that experience I ended up building large and complex EDA apps for the SoC IP market in the late 90s. Python was the enabler because its language and library features supported programming in the large as opposed to Tcl with its arcane syntax (especially for those with a C background) and minimal library support.

I still pity the AEs who write Tcl scripts for EDA tools.

[veyron]

Glad to see I'm not the only one still using Tcl :)

"even adding new widgets that Qt and and GNOME had that Tk didn't (trees, tables, buttons that could show images and labels, for example). Tk has since made this a lot easier but at the time it was frustratingly time consuming."

Can you open these up? More generally, is there a real CPAN for Tcl/Tk (and is there interest)?

[adunsmoor]

I wish I could have. I'm not working at the same place anymore.

The CPAN equivalent for Tcl has been tried a few times. See Teacup for the latest. None of these ever reached critical mass to gain wide spread adoption though.

[aswanson]

I add 7) Weak scoping rules, resulting in inevitable variable collisions exacerbated by a primitive type system (see 5)

[luser001]

Can you expand on "weak scoping rules"?

If anything, I thought Tcl's scoping rules were too strict. E.g., global and namespace variables are not automatically available in functions, unless you import it explicitly.