This is Larry McVoy's company. The main product as of 2001 is BitKeeper, a highly scalable SCM Tk-based application, profiled in http://swexpert.com/CC/SE.C12.SEP.01.pdf .
BitKeeper's featureful. Bryan Oakley has mentioned its potential as the technical base for a solution to the largely-social problem of replacing and bettering SourceForge, CPAN, and so on, and, in this context, justly remarked, "The nice thing about bitkeeper is that the entire repository can easily be cloned by anyone, so while there would be a single master, there could be many duplicate backup servers anywhere in the world."
The BitKeeper site has nice words for tcl/tk [L1 ]
"These tools are written in tcl/tk, calling out to BitKeeper tools for manipulating the revision control files. Many thanks are due to John Ousterhout and the Scriptics team for an excellent GUI toolkit. We've evaluated other toolkits over the years and while they may look nicer, nothing has yet to approach the power of the TK widget set, it is a better design than anything we've seen."
Bitkeeper's controversial. Here [L2 ] is a taste of the back-stage intrigue.
Here is some more nice words about Tcl/Tk from Larry McVoy on the Linux Kernel mailing list:
https://marc.info/?l=linux-kernel&m=99305629011185&w=2
"When was the last time you did the same thing? Nobody gets client side Java to work properly across all the platforms without a lot of tweaking.
And the last time we did it was recently, the entire BK GUI is in tcl/tk, almost 20,000 lines of code (that would be 80,000 for you Java fans), and the GUI has revision history browsers, changeset browsers, source browsers, check in tools, diff tools, rename tools, file mergers, etc. It's pretty complete and it typically comes very close to just working across all platforms. The sort of differences we deal with are little things like the font names not being the same on Unix/NT. Java would *love* to be that good, it's nowhere near.
Here's some more stats. We fired up a Java based file merge tool on a file and then did the same thing with our tk based one. The Java tool took 38MB to do the same merge as the tk one; the tk one took 4MB. And before you start saying "well, the tk one must be simplistic", we hand the Guiffy guy our test cases all the time and it fails them. So it's a pretty reasonable apples to apples, in fact, it's slanted in favor of the Java tool.
We couldn't believe that Java was really that bad so our GUI guy, Aaron Kushner, sat down and rewrote the revision history browser in Java. On a 500 node graph, the Java tool was up to 85MB. The tk tool doing the same thing was 5MB. Note that we routinely run the tool on files with 4000 nodes, we can't even run the Java tool on files that big, it crashes.
You could argue that we need custom widgets to do what we are doing, but that's lame. We don't need any custom widgets for tk, in fact, we are using straight tk, no extensions.
So, yeah, we have done what you think we haven't done, and we've tried the Java way, we aren't making this stuff up. We run into Java fanatics all the time and when we start asking "so what toolkits do you use" we get back "well, actually, err, umm, none of them are any good so we write our own". That's pathetic."