141 comments
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.
Additionally maybe we should stop complaining about its verbosity, given the amount of English based programming going on nowadays.
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.
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.
One could call Tcl_CreateInterp() multiple times in your code and each call would return an independent interpreter.
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...
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.
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...
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.)
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.
You're not that old, are you? :) Before www, expect was the way to go.
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....
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...
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.
Good to see it's getting some modern support.
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
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).
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
- Lobsters · 5 points · over 7 years ago
- Tcl/Tk 9.1tcl-lang.orgLobsters · 11 points · about 9 hours ago