An excellent read! Judging from the comments, it seems some old-timers agree with the assessment in this article.
Do also read an anecdote of the challenges in the response at http://robertvbinder.com/what-i-learned-building-a-software-product-with-tcl/ .
I was a longtime professional TCL programmer. As an old timer, I’d say there were a couple of big things that really hurt the language.
TCL has awesome dynamic typing but its early implementation was notoriously slow. It was dramatically improved over time, and the language got a JIT bytecode compiler in version 8 in ‘97, but by then the language had been in use for seven years, and opinions had been formed. While today’s TCL is fast, its reputation for slowness was set in stone.
TCL was easy to embed in other projects, but it used to be very difficult to bring other projects into TCL. If you wanted to use the powerful commands added by Expect, you had to run Expect to execute your TCL. If you wanted to make a GUI with Tk, you needed to run your TCL under the WISH executable. If you wanted to script up tests using vendor A’s test hardware, you ran your TCL under vendor A’s custom TCL interpreter. Want to put all three into one program? Nope. The ease of embedding TCL into executables was great, but it slowed down the addition of external library/package support into the language.
As mentioned in the article, TCL has this great ability to extend its own language syntax at run time. I used it many times to provide ease of use constructs and sand boxing in the test harnesses that I developed. Another great example of the language modifying ability was the [incr tcl] extensions. Announced in ‘93, they added true object oriented structure to the language, just by loading the incrTcl package. I can’t imaging working on a large TCL project without [incr tcl]. However, because you could load the extensions when you wanted to use them, they never needed to become an official part of the language. In fact, there were several different, incompatible OO systems developed for TCL. Instead of bringing more programmers into the fold, that flexibility really just served to fragment the language into different dialects and camps.
I think the biggest one was Sun Microsystems deciding that it was going “all in” on Java for everything. The people at Sun that had been developing, researching, using, and promoting the language suddenly found themselves on the wrong side of the fence, and faced significant pressure to leave TCL alone and get in line with the Java vision. Without a strong group of leaders to direct and promote the language, its decline in popularity was inevitable.
Sounds like its history has some similarities with LISP vs imperative 3GL’s. Appreciate the insights. The other one in this category is Rebol with its descendant Red. I always think of LISP, Rebol, and Tcl together for simple, flexible and productive languages. I mean, one could throw real meta-languages like META II in there, too. I just didn’t know about it back then.
I’ve been programming real software for 30+ years. I’ve done some Tcl/Tk, some expect. It was the best of times, it was the worst of times.
(A lot of great software has been tested by humble expect and a bit of Tcl.)
I’m currently floating, 99.9995%, in the Lua space. For me it is everything I need in order to maintain a stable platform interest - once I have grok’ed a platform, I prove it to myself by putting it all together into a Lua VM, and give myself my own Framework.
This is a lot of work, and there are arguments pro/whatever for/against just being a platform-specific developer, but if you are building the sorts of apps which benefit from having an internal scripting engine, you know that platform competence is a given, anyway. You have to move beyond the platforms, to glom some Lua framework on top of it all which makes all the pain go away and supports a valid application development environment, above and beyond the limits imposed by the platform.
That said, there is of course, this:
$ luarocks search tcl
0.9-3 (rockspec) - https://rocks.moonscript.org
0.9-3 (src) - https://rocks.moonscript.org
I cringe when I read some things I’ve written in the past, but I’m pretty happy with how this has held up. I certainly learned a lot thinking about Tcl that I’ve been able to appy elsewhere.