My favorite Tcl story is a little side note about how Tcl could have been the language of the web[1]
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.
Too humble Dr. Ousterhout! It would have been a far better language.
I was leading a Tcl project around then, and, though there were some very neat things about the unusual Tcl evaluation model, I wasn't a fan of using it for nontrival work. For example, it wasn't a natural fit for working with graph structures like I had to, and like you might want for browser DOM.
(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.)
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)
I think Tcl as it was back then especially would have been a terrible DOM manipulation choice. I love the language but the hacks frameworks like openacs used to use to imitate basic stuff like a list of database records are among the ugliest upvar/up level hacks I've seen.
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.
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.
Does Tcl have lexical scoping yet? If not, I'd have to disagree that it would have been a better language. JS is not one of the better languages I know, but it does have lambdas and lexical scoping. And as bad as JS's type system may be, at least it's not stringly-typed.
Funny that Tcl was mentioned today. I've recently been hacking on jimtcl[1] (a small footprint implementation of Tcl) to make objects multi-threaded safe, as that's the core language that folk.computer[2] uses (the main authors are making the interpreter and reactive DB parallelizable rn, so I've been tinkering with how to reduce copying).
Surprised no mentions of sqlite yet :) I've always associated Tcl with sqlite because of how much it is used in their test suite and how you can have a tcl interpreter as a virtual table. Very interesting and seemingly often overlooked little language.
I have used both TCL and Sqlite a fair bit but not both together. I have thought that TCL + in memory Sqlite would make a powerful combination for some tasks but have never actually tried it.
I can't comment on virtual-table shenanigans, but I'll enthusiastically confirm that thought. Not only is an in-memory database powerful and useful for all the obvious reasons, but (I would argue) the Tcl interface to SQLite is perhaps the best relational database API in any language. (Even if it cheats a bit by being an embedded database, as with <https://sqlite.org/tclsqlite.html#function>.) It's easily as synergistic a combination as Tcl and Tk themseves, possibly more.
> Some content has been removed in the second edition of the book because of limits on the number of pages
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
I have known about Tcl since the 1990s. I remember Stallman advising not use it. Maybe he did not like the license?
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.
"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."
> It fakes having numbers, which works, but has to be slow.
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.
If I recall correctly, I think he was just more of a lisp fan and promoted something like Guile or E-Lisp. It may have been license as well. I'm not very sure about it though.
I think he was worried about Sun Microsystems involvement[0] w Tcl when John Ousterhout went there[1], too. But mostly seems like a collection of unsolicited strawmen[2]. Also probably love-of-lisp.
I own the first edition of this book and it's really good. I've written a few tcl scripts with it, but nothing major. Python just has the better ecosystem now for my needs. I might use tcl if I needed something really small though.
I'm aware, but that kind of defeats the point (at least to me). If I want to build out some cute DSL for a project, it would just be with the small tcl interpreter.
Nice memories of having our own AOLServer like clone, Vignette, routinely writing extensions in C, and also why since 2003 I tend to avoid languages without JIT/AOT unless it is for banal OS and application scripting task.
I may have to learn its other half, Tk, as a side project of mine is starting to feel less like something I can pull off as a "wizard" on the command line. I had wrestled with wxPython many moons ago and, while I got through it, I felt like I had perhaps taken a wrong turn.
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.
Readit News
1 - https://pldb.io/blog/JohnOusterhout.html
(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.)
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)
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.
It was definitely possible that Tcl could have ended up the web sripting language.
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.
I cannot possibly imagine the horrors of frontend frameworks that can grab values, or execute, in someone else's context willy nilly
[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.
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)
[0] That any proximity to commerce is evil?
[1] https://en.wikipedia.org/wiki/John_Ousterhout
[2] https://vanderburg.org/old_pages/Tcl/war/
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.