296 points•dmux•1 day ago•141 comments•

141 comments

srean1 day ago
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).

AceJohnny2about 18 hours ago
> I would be wary of using it professionally

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.

bandramiabout 15 hours ago
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.
pjmlpabout 17 hours ago
Not to sidetrack that much, COBOL is now in ISO 2023, even has OOP features, there are ways to do microservices in it, and nice modern IDEs as well.

Additionally maybe we should stop complaining about its verbosity, given the amount of English based programming going on nowadays.

sreanabout 17 hours ago
I know.

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.

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

sreanabout 21 hours ago
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.

dkfellowsabout 13 hours ago
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...

grimgrin1 day ago
if anyone was curious! "soft spot" has an Indian English "soft corner", so says website dot com
sreanabout 18 hours ago
Very interesting. I was not aware at all that this was an Indianism. One that I like quite a bit is the word prepone.
avadodinabout 15 hours ago
I wrote an internal tool UI in TCL/TK.

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.

ripe1 day ago
Tcl is certainly a bit weird and takes getting used to, but I have found it worth learning its idiosyncrasies, particularly because my applications use sqlite, which fits very naturally with Tcl.

From D. Richard Hipp [1]:

"SQLite is a TCL extension that has escaped into the wild.

"The design of SQLite was inspired by the design of TCL, both in the way it handles datatypes and in the formatting of its source code. The index use case for SQLite was in a Tcl/Tk application for an industrial company. From its inception, SQLite has always depended heavily on TCL. These days, SQLite no longer uses TCL internally and can be run separately from any TCL interpreter, and yet the SQLite development process still depends heavily on TCL."

[1] https://www.tcl-lang.org/community/tcl2017/assets/talk93/Pap...

neilv1 day ago
The biggest early selling point of Tcl was Tk, as a relatively easy way to make good-enough GUI programs with open source on Unixen and the X Window System. Even much easier than the easier-to-use X toolkits like XView with C, and the alternatives only got more difficult from there. There were no Web frontends.

Tcl itself was quite clever as what I'd actually call a string-based scripting language (contrast with Bourne/C-shell/etc. that preceded it on Unix).

Originally, Tcl was among the handful of off-the-shelf extension languages. You write your big application in C or C++, and then you embed an interpreter for a higher-level extension language, for users or the original developer to add on functionality. The options at the time were usually a small Lisp/Scheme, Tcl, Python, or something entirely bespoke and probably quirky and half-butted.

During early dotcoms, there was considerable interest in Tcl for backend work, and it also wouldn't have been the worst choice to put into the browser. Like Python, Tcl would've been more accessible and democratizing-the-Web than JavaScript, and there were already solid off-the-shelf designs and implementations. (Scheme would've appeared slightly more intimidating than Python or Tcl, and was more powerful, which I think was why Tim Berners-Lee preferred Python over Scheme as the people's programming language for various Web purpose. The semantics of the JavaScript we got was more a hurried toy Scheme, plus the simplest object model, and a more intimidating syntax that came from systems programming.)

bloafabout 24 hours ago
So I also love Tcl, but I think it would have not been great as a web language. I think the small amount of type information we can pass via json is just about right, and tcl would have made it impossible.

You cannot encode arbitrary tcl data to a typed object "correctly" because every tcl dictionary is a valid list, and every list is a valid string (numbers are also strings, and so is code). So in a world of "tcl code on the web", both the sending and parsing ends of a 'tcl data stream' would need to know which type they're "supposed" to treat the data as.

monista1 day ago
> The biggest early selling point of Tcl was Tk

You're not that old, are you? :) Before www, expect was the way to go.

<https://en.wikipedia.org/wiki/Expect>

RHSeegerabout 19 hours ago
Expect was amazing - game changing. The things you could do with it couldn't be replicated elsewhere (well, clearly "could", but not reasonably so)
mikestorrent1 day ago
Y'all remember TkDesk at all? https://tkdesk.sourceforge.net/

I loved it back in the day, tons of fun to configure with code, somehow friendly enough for me to play with in high school with no background knowledge and only some man pages to help me. Coupled with a lightweight WM like CTWM https://www.ctwm.org/index.html it lead to a really performant desktop on the single-core ~400mhz machines we had in our computer lab....

flopsamjetsam1 day ago
My pet project in those days was writing a C++ X-Windows gui toolkit, and I took a lot of inspiration from Tk. Both design, and "how do I do this" from the source code were invaluable.

Didn't Cisco use Tcl in one of their IOSes? Found it: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/co...

manbartabout 21 hours ago
Yes the legacy Cisco IOS had a Tcl interpreter built in, you can drop in to the repl with the tclsh command. The command is still there on newer Linux based IOS versions
zahlmanabout 17 hours ago
Yep, the age of Python and the C-steeped culture of its original developers probably has a lot to do with the choice of Tcl/Tk as a basis for the standard library GUI framework. But even then, there's significant wrapping; and Python's type system is, if anything, even further away from the free-wheeling "stringly typed" Tcl than JavaScript is.

I do sometimes yearn for the alternate universe where web browsers ended up doing Python natively (and PyPy style optimizations became the default, and the dynamism was reined in to an extent where it could offer JavaScript-tier performance).

Aside from the emphasis on "continuation passing style" though I don't get how you're relating JavaScript to Scheme.

trebligdivad1 day ago
Tcl/Tk has got to be the easiest GUI system out there; you can get simple stuff going with no effort - nothing I've seen comes close to that simplicity.

Good to see it's getting some modern support.

dkfellowsabout 13 hours ago
The current main project for Tk, targeting the 9.2 release next year, is porting to work on Wayland. (But not dropping support for X11, Windows or macOS.) Apparently, the widget demo is now working (i.e., you could probably build some applications on it) but advanced features like accessibility support are still in progress.
trebligdivadabout 11 hours ago
Hey Donal, long time! Great to see you still involved.
BoingBoomTschakabout 7 hours ago
Didn't expect Wayland support that soon!
agumonkey1 day ago
It hits a sweet spot for a lot of basic UI needs.
iamcreasy1 day ago
Is it still true if I want to custom widget with animations?
convolvatron1 day ago
I've done animations at the Tcl layer before with composition of Tk objects. for little visualizations its just fine, certainly not AAA
Dwedit1 day ago
What about oldschool Visual Basic?
WillAdamsabout 22 hours ago
It was nice/workable for its time, and one wishes that there was some modern alternative, but "RAD" seems to have dropped off the radar.

Some things I've tried/looked into (beyond TCL/TK):

- Gambas --- Linux only, not sure if there's a nice visual UI builder

- LiveCode --- still salty about the license rug pull, wish the openxtalk folks could get some traction

- MoonBasic --- looks promising, but currently trying....

- flet.dev --- the AI-integration in this makes it quite compelling, though I wish that there was an integrated UI drawing tool, https://github.com/raffieeey/Flet-Visual-Builder is self-described as buggy and hasn't seen an update in 7 months

- Lazarus --- still bummed I never got anywhere with Delphi --- if flet.dev doesn't work out, may try it

pjmlpabout 17 hours ago
Besides the sibling comment, VB.NET is still around, even if not with the attention it once had.

VB + C# with Windows Forms is not much different from old school VB.

And for the pixel positioning complaints, it is about time people learn about FlowLayoutPanel and TableLayoutPanel, they exist since .NET 2.0 (2005).

bitwizeabout 11 hours ago
Too much rat wrestling. You could bang out a few lines of Tcl in your editor and have a working GUI. Even stub out the commands that widgets run, tweak and reload until it behaves right, then add those back for a working program. Absolutely nice for providing a visual interface for your Unix scripts or programs, or for building whole applications in if you're daring.
qalmakka1 day ago
Tcl is way too smart of a language for its own good. I love how everything is a string or can be hacked on a string, so you can basically do levels of metaprogramming that reach unheard of levels
srean1 day ago
Not to mention uplevels and upvar.
wduquette1 day ago
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.)
RHSeegerabout 19 hours ago
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.

Read the full thread on Hacker News →

Related stories