I would be interested to know if anyone ever built anything non-trivial that didn't turn into a complete mess due to TCL's general type-flimsyness and "everything is a string" philosophy.
TCL stands for "tool command language." In terms of non trivial tools that have been built with it there have been several. AOLServer, MacPorts, tons of CAD and engineering software. There's a whole wikipedia category just for this:
Aside from that there was Tk which was used to create many UIs in an era where scripted UIs were otherwise painful to create and maintain. A prominent example here is 'xconfig' from the linux kernel.
Like any good environment a little bit of practice with it can see you overcome it's apparent shortcomings and see you producing reliable and useful software in far less time that you might have in a more traditional way.
Programming is about trade offs. It's not a checklist of "good ideas."
My big project at work uses pytk only because it was already included with the anaconda distribution. It works fine, it's not pretty but it's just an internal engineering tool.
The GUI of Pure Data (https://en.m.wikipedia.org/wiki/Pure_Data) is written in Tcl/Tk. In the 90s this was a popular and sensible choice, but not so much in 2025 :) I still have hopes that one day we'll manage to replace it with something better.
(There are alternative implementations of Pd, such as PurrData or PlugData, that use different UI frameworks.)
I have been looking at using both of those. I have used TCL before but it was a while back, but Lazarus does have a visual designer which I have played with a bit.
I am not sure which makes producing cross platform binaries easier. I ran into a few issues the last time I tried TclKit I ran into problems so Starkits may not be an easy solution anymore.
Lazarus is excellent. It is very user friendly once you get the hang of it, and you can use Delphi books to learn the language. It also produces static binaries that make it easy to distribute your software.
Yes, both Tcl/Tk and Python/Tk are great in 2025 for doing simple GUI programming and this fact does make me sad. Or perhaps we've found the global minimum? Who knows.
> I would be interested to know if anyone ever built anything non-trivial that didn't turn into a complete mess due to TCL's general type-flimsyness and "everything is a string" philosophy.
Both MacPorts CLI client[0] and ports tree[0] have used it successfully for many years.
Regarding:
"everything is a string" philosophy
That can be said for the vast majority of Unix-like OS user-space programs.
TCL/tk is used for the vast majority of integrated circuit verification tools. This is used by all the large manufacturers, even competitors use each others tools.
Absolutely huge codebases, there's git blames that go back to the 80s.
Someone did a nice job of porting your revision control data. It would be fascinating to know what the previous systems were - probably svn or cvs, maybe both in chronological order, but before that?
I know in the late 90s, early 2000s they were Vignette shop, back when it was a Tcl application. Can only imagine their relief getting to carry over their tcl knowledge while no longer having to suffer with Vignette. I don't think I've ever heard anyone that actually liked Vignette.
I don't recall any groups using Vignette at AOL during that time. It may be that one of the acquisitions used it prior to being acquired, but again, I never heard about it.
CNN.com was definitely using the StoryBuilder part up until the 2005 redesign as it's noted in the source of each and every article, and there were some tell-tale droppings on the home page as well.
A whole company, with our in-house version of AOLServer, using Apache and IIS plugins for the Tcl interpreter, running across AIX, HP-UX, Solaris, Windows 2000/NT, Red-Hat Linux, with our own ActiveRecord like approach (a decade before Rails happened), with connectors for Sybase SQLServer, MS SQLServer, Informix, Oracle, DB2, Access, doing code generation from Oracle based ER diagrams, and an IDE written in VB 6.
Which became a business unit from Altitude Software, eventually due to our MSFT partnership level we got access to .NET builds before it was known to the world, as one of the key Portuguese partners, and started to replicate our stack in .NET, based on the learnings from our Tcl based product.
The founders and core devs, from the original startup, eventually left to create their no code/low code platform, based on the learnings from both technology stacks, what they managed to achieve, and what was not done quite right, out of that OutSystems was born, one of the most successful Portuguese IT companies from the last 20 years.
I think using Tcl for that startup on a tiny Lisbon basement back in the late 1990's, turned out quite alright.
There is no big difference between TCL and other languages like Python in this respect. Yes, TCL stores everything as a string, but it also assigns a type when the data is used. If you need a defined type, you can use structures; there are even classes/objects available as packages.
Yep! It's called shimmering. The way it works is it has a string and internal representation. When the internal representation is modified it invalidates the string version. If the string version is needed later it'll regenerate the string representation. That way it can always be used as a string, but internally it is pretty efficient when it stays as the same type.
You’re misunderstanding. Dynamic languages inherently have a single type that is checked _at runtime_. Store it in a string, store it in a struct. It doesn’t matter.
And in Tcl the runtime type is computed at time of use. An optimized Tcl could cache an integer with a string that represents an int to avoid that cost.
Nevertheless, a runtime type tag is an optimization. That doesn’t make Bob’s statement any less true.
Because Python is “strong typed” vs “weak typed” for Tcl?
$ tclsh8.6
% expr 1 + 2
3
% expr 3 + “hey there”
invalid bareword “hey”
in expression “1 + hey there”;
should be “$hey” or “{hey}” or “hey(…)” or …
vs.
$ python3.11
>>> 1 + 2
3
>>> 1 + “hey there”
Traceback (most recent call last):
File “<stdin>”, line 1, in <module>
TypeError: unsupported operand type(s) for +: ‘int’ and ‘str’
I don’t really see a difference. Both checked types at runtime. Clearly Tcl can check types at runtime, even though it represents everything as a string. Whether all commands do so is another story. But, not all functions in Python check types before trying to do things that don’t make sense, either. So…
100's of Klines of code in continuous development over the last 10 years, still currently maintained and continually adapted for new use cases in Electronic Design Automation (EDA) for logical and physical chip design and verification.
Of course it's possible to create "write-only" code in tcl. But tcl is hardly unique in that respect. Good code design and coding practices help to avoid most issues just as in many other languages.
"Everything is a string" (EIAS) is not what leads to a complete mess; it's failing to go beyond an initial, superficial understanding of the syntax and language capability and general lack of discipline that lead to un-fixable messes.
For FPGA IDEs, a lot of the background is just tcl scripts so you can easily write your own build scripts. You could theoretically put them into your CI pipeline but I don't know if anyone actually does this.
I would be interested to know if anyone ever built anything non-trivial that didn't turn into a complete mess due to TCL's general type-flimsyness and "everything is a string" philosophy.