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).
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.)
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
> 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.
"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.
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.
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...
srean · · focus · HN ↗
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).
zitterbewegung · · focus · HN ↗
tlavoie · · focus · HN ↗
vkazanov · · focus · HN ↗
That was my first web kind of framework. The naivette of Zope still amuses me endlessly to this very day.
It tried to be cool, made ALL the wrong choices, and died silently with people just moving on.
pjmlp · · focus · HN ↗
tlavoie · · focus · HN ↗
vkazanov · · focus · HN ↗
I will never recover from debugging ZODB backed by Oracle. Well, somewhat backed.
Who, like, who thought it was cool to have a pickle-based, mostly in-memory, single process, aaalmost transactional database?!
tlavoie · · focus · HN ↗
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.
zahlman · · focus · HN ↗
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.)
grimgrin · · focus · HN ↗
srean · · focus · HN ↗
maybewhenthesun · · focus · HN ↗
'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
kevin_thibedeau · · focus · HN ↗
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.
srean · · focus · HN ↗
One could call Tcl_CreateInterp() multiple times in your code and each call would return an independent interpreter.
bch · · focus · HN ↗
[0] <a href="http://www.beedub.com/book/2nd/interp.doc.html" rel="nofollow">http://www.beedub.com/book/2nd/interp.doc.html
[1] <a href="https://www.guppylake.com/nsb/pubs/ulpaa-94.pdf" rel="nofollow">https://www.guppylake.com/nsb/pubs/ulpaa-94.pdf
pjmlp · · focus · HN ↗
segmondy · · focus · HN ↗
srean · · focus · HN ↗
omilu · · focus · HN ↗
srean · · focus · HN ↗
AceJohnny2 · · focus · HN ↗
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.
srean · · focus · HN ↗
I would hazard a guess that a significant fraction of HNers would have encountered TCL in silicon CAD and took with them a frustrating experience.
pjmlp · · focus · HN ↗
Additionally maybe we should stop complaining about its verbosity, given the amount of English based programming going on nowadays.
tannhaeuser · · focus · HN ↗
bandrami · · focus · HN ↗
avadodin · · focus · HN ↗
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.
dkfellows · · focus · HN ↗
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...