adunsmoor

I'm a long time user of Tcl. For me, the biggest strength of Tcl is it's C API. It's quite straightforward to implement extensions. That, and the people that were involved in the language early on are incredibly smart and creative.

I had the good fortune of working with Michael McLennan and George Howlett for a while (both mentioned in the referenced history).

Michael's "Effective Tcl/Tk Programming" is a fantastically written programming reference. He was a prolific creator of interesting applications and toolkits. I recall him creating a GUI for our boring corporate bug database where he added a points system to make fixing bugs "more fun".

George managed to avoid incrementing the version number on his BLT toolkit by appending letters of the alphabet to releases. I never did learn why. I just checked and I see he made it all the way to 2.4z!

Jobs like you

Tcl and the Tk Toolkit by J. Osterhout is an old reference but very useful for getting started with the C API to Tcl including embedding an interpreter. The last 1/3rd of the book is on writing Tcl applications in C.

Also look at the the source files for the Tcl (tclsh) or Tk (wish) shells. They are fairly concise.

Your error looks like there might be an extra space after the line continuation (backslash) in the example.

The trace command is split in to 2 lines for readability but the web page's formatting introduced a hidden space if you try to copy/paste the example in to a tcl script.

It doesn't work well with Google's account switching yet.

I happen to have 2 google accounts (personal and work) and was logged in to both. With mail and docs I can switch back and forth between them.

In Google Play, there wasn't a way to switch from the "default" account to purchase music unless I signed out of 1 and signed in with the other.

I'm sure that'll come along later, though. I realize my usage is an edge case.

Here's my feedback after playing with the demo tree that's on your front page. The demo looks very nice. It's attractive and makes me want to interact with the page. That's great.

The one time I built a family tree graphically was when my kids had a school project to do. We wanted to print a nicely organized diagram but couldn't do it with the tools we found online. We ended up printing out the information from a text file and organizing it ourselves on a sheet of paper. I don't know if I'd have paid for something or not at the time. It definitely would have been a one time use, though.

Overall I expected the interaction to be more like a modern maps interface (think Google maps) - zoomable with scroll wheel, click and drag to pan, etc.

The click to navigate seemed outdated. If I want to move up and to the right. Click the button on the right, now click the button on the top, now to the right a few more times...

Same feedback for the time line. It's a neat idea but I expected to be able to navigate by dragging it around.

Also, the zoom +- would be easier to use if they stayed in a fixed location. Having them centered based on the size of the zoom scale meant they kept jumping around. Really hard to click, click, click to zoom in.

If navigation were a little easier and more fluid I could see using something like this to create hierarchical diagrams. Right now it was too frustrating to examine larger trees.

I hope the feedback helps.

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.

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.

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

It's been a while but I believe when using the "Send mail as" feature in gmail it puts your preferred address in the from: field but keeps your gmail address in the sender: field.

That's probably fine in most cases but I was getting inconsistent results when people replied to my emails. Some were addressed to my domain and others to my gmail address.

I was also concerned that this might give me a slightly higher perceived risk in some SPAM filters.

Like I said earlier, none of this was a huge deal. It was just one of those inconsistencies that led me to routing all my mail to Google Apps.