The Tcl Programming Language
magicsplat.com
magicsplat.com
the founding of Netscape occurred at the same time I was deciding where to go in industry when I left Berkeley in 1994. Jim Clarke and Marc Andreessen approached me about the possibility of my joining Netscape as a founder, but I eventually decided against it (they hadn't yet decided to do Web stuff when I talked with them). This is one of the biggest "what if" moments of my career. If I had gone to Netscape, I think there's a good chance that Tcl would have become the browser language instead of JavaScript and the world would be a different place! However, in retrospect I'm not sure that Tcl would actually be a better language for the Web than JavaScript, so maybe the right thing happened.
(That said, Tcl would've been much better than JS, and I suspect that Ousterhout would've figured out some smart things to make it good for the browser.)
Maybe 5 years later, I was meeting with Tim-Berners Lee, and I kinda pitched Scheme to him, without planning to, but he was very interested when he asked what I'd been working on.
But then he went and did a conference keynote, in which he promoted Python as the language for ordinary people doing Web stuff. And I think he referenced one of the things I'd written in support of Scheme... as an anti-requirement for his populist vision for the Web. :)
(I wish I could've been involved in that, because I could've made a case for a populist spin on Scheme at the time.)
But that being said it's an incredibly adaptable language and I have zero doubt it could have been adapted to make DOM manipulation ergonomic.
TCL has an extremely loose runtime model, not to mention everything in the language is basically a string and all that entails.
I’ve been using JavaScript since the early 2000s, just before ES5 dropped.
Like all languages it has its curveballs but it really isn’t all that bad. It simply has oddities due to the quirky nature of the niche it was designed to fill (namely, to be a scripting language that was forgiving to web designers)
The web ate almost everything else for a host of reasons, and JavaScript is still the only language that the web natively supports. You can compile to JS or use WASM with occasional callouts to JS, but you can't get away from it entirely.
Most other languages have a greater sense of choice surrounding them. For backend work you can pick pretty much anything, and mobile is still a small enough chunk of the ecosystem that if you really hate Swift you can just find a job that isn't iOS dev. It's not so easy to get out of web dev without dramatically shrinking your job pool.
If devs want to interact with it less then focus on moving more to the server. You can still serve HTML and CSS and get a long way without ever touching JS.
It’s no different than other domains where one or two particular languages largely dominate. Like I don’t hear developers decrying the existence of C/C++ every chance they get
I think the hate is entirely unjustified. It’s fine to have preferences but so often it goes beyond that.
I guess you haven't encountered the monkey zoo of rust cultists yet
Now I know why PHP devs sometimes get a little defensive
I don't get it either? I've only used it occasionally but it has always struck me as a really impressive example of what can be built on minimal (minimalist?) foundations. Its semantics can understood in 5 minutes.
It reminds me of Scheme in this regard. Writing an interpreter or compiler for it would be easily within reach of an undergraduate student. Contrast with other currently popular (more respected?) languages like Rust, C++, Java, C# or even Python.
I've only recently been expose to Typescript and again, I'm really impressed. I haven't encountered a type system so elegant and orthogonal since first being exposed to ML like languages.
Your definition of "semantics" must be different from mine, or you perhaps haven't seen https://javascriptwtf.com/ (linked in a sibling comment)
Your comment actually made me wonder whether those cited artifacts were implementation bugs or actually in the specification and ... lol, this shit reminds me of people who put comments above functions that just restate the function's name: https://tc39.es/ecma262/2024/#sec-addition-operator-plus
> Writing an interpreter or compiler for it would be easily within reach of an undergraduate student
Surely you don't really believe that? Or is the rest of the sentence "... eventually, over the course of their undergraduate career"
The 15th edition of the standard is 816 pages and now includes specifying the Memory Model. What I suspect you mean is "could write a parser for the 1st edition spec from 1997"
I won’t argue that JS doesn’t have warts - it does and if it wasn’t for backward compatibility I imagine they’d have been removed from the language - but the entries on that website are quite small compared to others - like C and C++ - that I can think of
And yes I do believe that writing an interpreter for Javascript would be no more difficult than doing one for Scheme (which I had to do as a student) - the parser would be more difficult admittedly.
That said, plain JS is not a good fit for larger projects, either. It really needs TypeScript for that. But it does have some very fast engines.
I disagree with that to at least some extent. Everything is a string works well in TCL because the language is built around that abstraction. It works at least as well as other dynamically typed languages in small projects, and is definitely preferable to Javascript's rather weird weak typing.
It also does async and multi-threading really nicely, and encouraged event driven long before it look off elsewhere.
It was definitely possible that Tcl could have ended up the web sripting language.
I cannot possibly imagine the horrors of frontend frameworks that can grab values, or execute, in someone else's context willy nilly
I like Tcl and I think it has some very admirable traits. That being said, I don't even want to picture the hellscape of an ecosystem that would have flourished if it became the language of the web. JS was the better timeline I will admit begrudgingly, and that includes the Scheme timeline as well.
[1] https://github.com/msteveb/jimtcl [2] https://folk.computer/
> have a tcl interpreter as a virtual table
Do you mean this: https://sqlite.org/src/file/src/test_tclvar.c ?
Lol, wut? The literal only working "buy it now" link is to a PDF. Page limits my ass. Or maybe "Paperback: 660 pages" was dangerously close to the Devil himself springing forth from the pages and turning all your codebase into VBScript
Yesterday, over 30 years later I was forced to write my first code. Noticed that a Cisco switch had an incredibly bad ssh implemtation, so to automate some commands I needed expect scripting. Expect is based on Tcl.
[0] That any proximity to commerce is evil?
Stallman's argument at the time was:
"a language for extensions should... be a real programming language, designed for writing and maintaining substantial programs...
The first Emacs used a string-processing language, TECO, which was inadequate. We made it serve, but it kept getting in our way. It made maintenance harder, and it made extensions harder to write...
Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow. Tcl is ok for writing small programs, but when you push it beyond that, it becomes insufficient.
Tcl has a peculiar syntax that appeals to hackers because of its simplicity. But Tcl syntax seems strange to most users."
This hasn't been the case for 25 years, since the 8.0 release. Tcl will store data internally in whatever format it was last used, and only convert if needed. Good coding practice pays attention to this to avoid "shimmering" a value back and forth between different internal representations unnecessesarily.
> It lacks arrays;
It does have associative arrays; and lists when used appropriately can fulfil many roles that would otherwise have been implemented in an array in another language
And tcllib[0], a collection of utilities commonly used with tcl, provides support for a number of different and complex data structions [1], many of which are written in C, not just more tcl scripts.
It's worth noting that Stallman's criticism linked above is more than three decades out of date. As with any programming tool, once you go beyond a superficial understanding of basic syntax, it can serve as a a very expressive and sufficient language.
[0] <https://www.tcl-lang.org/software/tcllib>
[1] <https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/toc.m...> (see: Data structures)
import tkinter
tcl=tkinter.Tcl()
tcl.eval('puts "Hello, world!"')
As a side note, while I have seen many UI elements over the decades, I cannot help but think that the wizard (or whatever you would like to call it) has somehow escaped being listed as a standard UI element. Perhaps it is too large to count for many.
https://www.tcl-lang.com/software/tcltk/9.0.html
but I'm not seeing an easy binary download --- used to be that the availability of a pre-compiled version, nicely packaged which would install easily on one's platform of choice made it wonderfully accessible to new users.
Is that not a focus of the project these days?
- Android 8.6.10 https://androwish.org/download/index.html
- Activestate seems to require account creation: https://www.activestate.com/pricing/
- Windows, nightly build of 9.0.2 from 15 February: https://gitlab.com/teclabat/tcltk/-/packages/34837768
- Windows 8.6.7 https://www.irontcl.com/index.html
This looks like the link I was looking for: Windows 9.0.1: https://www.tcl3d.org/bawt/download.html#tclpure which links to: https://www.tcl3d.org/bawt/download/Tcl-BI/SetupTcl-BI-9.0.1...
It would be nice to have found one for the Mac....
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.
— Bob HarperNevertheless, 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 …
$ 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’
So are Tcl values.
https://en.wikipedia.org/wiki/Category:Free_software_program...
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."
Absolutely huge codebases, there's git blames that go back to the 80s.
(There are alternative implementations of Pd, such as PurrData or PlugData, that use different UI frameworks.)
Infuriatingly, Tcl/Tk (and other things which use Tk) is still light years easier for doing basic GUI programming than anything that exists in 2025.
How the hell can decades have elapsed and Tcl/Tk, Hypercard and VB6 are still vastly better for GUI development than anything we currently have?
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.
[0] https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/co...
[1] https://community.f5.com/kb/technicalarticles/irules-concept...
[2] https://www.acoustic.com/tealeaf
[3] https://help.goacoustic.com/hc/en-us/articles/360043279654-C...
[4] https://www.cmegroup.com/solutions/market-tech-and-data-serv...
[5] http://www.services.fidessa.com/brochures/_training/VF043.pd...
> 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
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.
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.
I guess expect became something almost popular enough to be considered external to TCL in the end, too.
I read almost the full Expect book by Don Libes, the author of Expect, several years ago. He had a unique and very interesting style of writing, in that book.
Yes, so popular that there are also ports of Expect to some other languages, such as Python and others.