5 ms·

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 po

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. :-)

aswanson 15y ago
I add 7) Weak scoping rules, resulting in inevitable variable collisions exacerbated by a primitive type system (see 5)
- luser001 15y ago
  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.
phalina 15y ago
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.
henry_flower 15y ago
'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 15y ago
  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.

aswanson 15y ago

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

luser001 15y ago
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.

phalina 15y ago

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.

henry_flower 15y ago

'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 15y ago
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.