All of which I used many years to go to write "Snit", a quite nice object system for coding up Tcl objects and Tk widgets. Snit's a TCL library that takes a nice, easily readable description of your desired object type (the instance variables, the methods, and so forth), translates it immediately into standard TCL, and then evaluates that to define your type. Basically, it's a macro system for defining object types. (I say "object types" rather than "classes" because there is no inheritance.)
I loved your 'expand' utility - and wrote a truly heinous Tcl to PHP framework/translation layer using it, because I preferred Tcl to PHP at the time - still do, but the early hatred for PHP has muted - that powered an application at the college I attended for an embarrassingly long time.
I've always thought of Tcl as a type of Lisp. Clearly, the relationship isn't direct, but it allows a lot of the same things that Lisps do. Plus, the way one nests commands is similar.
And it shares a lot of the same metaprogramming that Lisps have - more so than the vast majority of other languages.
As someone who did enough of both (in fact, Tcl was my gateway to Lisp), I'd say yes and no.
Classical Lisp (Scheme/CL) has much more elegant core concepts/semantics, but often much more clunky stdlibs and small/outdated batteries. This shows in unexpected places like the way homoiconicity has a big caveat: comments break the "code as tree" contract, forcing you to revert back to the useless "code as string" middle ages.
So, despite the fact that I'd probably recommend Janet to people who want Tcl without Tk, these days, I still like it. Do note that compared to its competitors (Ruby, Python, Perl), its POSIX support is _really_ bad. There's no way in core to do signal handling or open a UNIX socket (and dead TclX that doesn't use namespaces isn't a replacement). Even SBCL has sb-posix.
I think of it as an alternate take on Lisp's metaprogramming. A form of cosmic-horror take that will drive you insane, yes, but Lisp-like metaprogramming nevertheless. Stare too long into Tcl's deadlights and you will want to be there.
I have a soft corner for TCL, because of its idiosyncracies and weird dynamic stringy playfulness. I would be wary of using it professionally but to play around for the fun of it ... it's just too much fun. Upvar and uplevels are crazy.
Python is that kind of cool one behaves when visiting parents of your would be spouse for the first time. Tcl on the other hand is like playing one's secret exclusive and somewhat dangerous games with kid school bestie.
Tcl/Tk pioneered the notion of a scripting language as a library. It got threading right. You can run multiple independent Tcl interpreters in the address space of your process and they can exchange messages. Entirety of interpreter state is encapsulated inside the interpreter object, no globals. To a user an it is just a pointer to an object.
No need for GIL, no need for serialization/deserialization (pickle/unpickle) ... just within process memory copy (or no copies in case data is immutable).
This is funny because so much Silicon CAD automation is written in TCL. I mean the most advanced technology in the world depends on TCL in its pipeline (also Excel VBasic!) (let's not talk about COBOL, that's in banking)
TCL is the original extension language, and in the very hidebound electronics CAD world, has a very long tail.
There's an alternate timeline where Ousterhout's dream was realized and TCL filled the role that the Javascript swamp filled. I think that's a better timeline from a tech perspective.
> Entirety of interpreter state is encapsulated inside the interpreter object
This was their attempt to position Tcl as an alternative to JS. The sub-interpreters were introduced as controllable sandboxes for running untrusted code with reduced privilege. Instead we got a web scripting language that allows untrusted code to interact with your USB devices. Python sub-interpreters are a joke compared to what Tcl has.
Are you sure ? Tcl is almost a decade older than javascript although subinterpreters came later. Even before subinterpreters you could have multiple Tcl interpreter instances in your code.
One could call Tcl_CreateInterp() multiple times in your code and each call would return an independent interpreter.
My uncle, who worked for oil companies all his life, always had the opinion that the Indians use english better than the English. :-)
'prepone' is an example of why I sometimes agree. Most indian guys I know also up the baudrate of english so much that they get twice the information flow compared to british english. With the disadvantage that both sides of the conversation need to speak indian english or you'll get protocol errors :-D
Unfortunately, it isn't getting much use anymore because of changes in architecture, but it was easy enough and the control I used for logs was much better than the c# forms stuff it replaced that would pin the CPU 100% and OOM after a few thousand lines.
If I read it today, it makes as much sense as Mayan pictographs, though.
There are a very few truly global entities there, most notably the current working directory and the environment variables. They're global because the underlying concept leaks through into C code you link in and subprocesses you launch, and changing that would be really quite nasty. The Tcl interfaces to those things are internally protected against multithreaded access, of course, but you can still get yourself into a mess that way.
The bit I really like about Tcl is how easy it makes asynchronous I/O across all its supported platforms. This doesn't sound significant to Linux users, but on Windows that's a very very big deal...
Sort of interesting how Python has got rid of the GIL. Serialization of data securities is still something relevant though and I’m not sure if you should use pickle still?
Pickle is likely still handy, as long as you created the data that you're deserializing. Zope's object database was a big pickle file, as I recall. But yeah, not a good idea if you're cracking open user-supplied files in any way.
Hahaha. Well, I didn't run into that issue, so it mostly "just worked" in the sense of where we had used it. I did mess around a bit with the Plone CMS that runs on top of Zope, and found it horribly slow and resource-hungry for the time. Someone must like it, it's still getting releases in 2026.
I was more traumatized by the Java-based product from Open Market (acquired from Future Tense back in the day), and all the horribleness that that entailed. Starting from XML as a template language, then seemed to get only worse. Nothing like having multiple content areas all rendered as 500 Server Error pages within one page, when it all goes sideways.
Pickle is insecure by design, but definitely convenient if you can trust the input.
If you need something safe then you really need to identify your requirements and your threat model first anyway; I wouldn't blindly reach for a one-size-fits-all solution in any programming language.
(Although I would do a quick check to see JSON or TOML is sufficient and practical.)
"wary of using it professionally". what does this even mean? you can use anything professionally if done so in a professional manner. it's just a tool, use it correctly and within limits.
I don’t understand the question. Are you implying someone cannot know how to do something in a particular codebase unless they’ve already done it on that same codebase?
To be a good performance optimize yes,you need to have done it a few times to be good at it and have acquired not just the skill but the discipline and taste.
More than having done it a few times though, what is more important is to have thrived in a space that is welcoming of intellectual curiosity and play in matters of performance. That's how one becomes good at it.
If you ever feel inclined to learn Hindi there is more to grapple with. The verb gender is sometimes set by the gender of the object, sometimes by the gender of the object. Which way this will go loosely depends on tense.
Of course this is very complex and not intuitive if you're a language learner. My point was that while there are parts of grammar that native speakers struggle with, and kids drill them for good grades in school, this is not one of that parts. And my broader point was that "needlessly pointless part of the language" is subjective and something language users should judge.
Oh it seems you took it personally, whereas I mentioned "every native speaker". My intention was not to rule you, just to underscore the point that native speakers have it easier and may not be able to experience or understand the difficulties of a non-native speaker.
I didn't read it as something being taken personally, just as a clarification. A misquote is a misquote no matter whose it was
> My intention was [...] just to underscore the point that native speakers have it easier and may not be able to experience or understand the difficulties of a non-native speaker.
Fwiw, that was not at all clear to me from a sarcastic few words
No sarcasm intended, I was being literal. Me and my wife have different mother tongues. What's natural to her isn't to me and vice versa and we keep telling each other that it's easy.
Huh, I'm in the same situation but not sure I've ever considered an aspect of my language easy just because I speak it, and my partner's country is known for saying "deutsche sprache, schwere sprache" (german language, difficult language) so the entire country seems to realise it. I'll poke fun at "we only have like half the genders you do" but it's always clearly in jest; from learning a language as an adult myself the difficulty is very clear. Interesting to hear the different perspective
I haven't sampled all mathematicians on the planet and I don't think there's a study on this but I would argue a lot of people will agree with mathematics with being elitist, and from my experience mathematicians aren't very keen of interacting with math "enthusiasts" or the wider community in general, they interact with a very select number of other specialist through a small set of conferences.
Mathematics is by far the most accessible "science" in academia. Anyone can, in theory, produce novel results with nothing more than a pencil and paper. And while the existing literature may not always be readily "accessible" (in the easy-to-understand sense) it is pretty widely available (often online and certainly via any decent academic library).
But "frontier" mathematics is still a highly advanced, highly specialized field. It can take years of study to be prepared to understand the established theory and results for a given subtopic.
These two observations, taken together, lead to the predictable outcome of a lot of math "enthusiasts" with an incomplete understanding of the field loudly asserting that they have discovered a radical new result. Often they lack the foundation to even understand what they are doing wrong.
The reluctance of mathematicians to engage with amateurs that come off as cranks is a symptom of how accessible the field is.
reply