What's the draw, other than having some existing code written in the language? Gems like the `upvar` command? (http://wiki.tcl.tk/1508)
Is there something special about Tcl that makes it a joy to use?
The TL;DR:
- easy to write interactively because there's no fiddling with the parens, quoting, or commas you find in JS, Ruby, or Python
- uses [ and ] for subexpressions instead of ( and ), which makes typing easier
- "command" oriented, instead of "expression" oriented
- saner than shell while having many of the same advantages
I would like to point out that in several non-US keyboard layouts, [ and ] are harder to type, not easier. For instance, on German keyboards, they are mapped to Right-Alt (AltGr) + 8/9, which is quite annoying to type compared to normal parentheses (which are mapped to Shift+8/9, with Shift being better placed and available on both the left and right side of the keyboard).
AltGr + a -> ä
AltGr + o -> ö
AltGr + u -> ü
I'm Polish and I'm very glad that our most common layout is like that for ąćęłńóśźż (with AltGr + x for ź). Currently I'm in Germany and I wonder if there is similar layout for German umlauts.
I used to get laptops and keyboards with the US layout on them, but stopped since the resale value in Sweden drops sharply because of it. Thankfully, I've touch typed since forever so I rarely look at the keyboard anyway. (Unless, of course, I have to type with the Swedish layout.)
I miss some features of more modern languages though. TclOO (object-oriented extension) is minimally useful but lacks GC, so you have to keep track of all objects to manually destroy them when you are done. I miss easily passing around functions (procs), and saner local namespacing for functions (ie like in python). Exception handling is also a bit of a pain.
A lot of these things are addressed in Jim Tcl, but it hasn't seen much adoption.
Say you want to write an app to rename files in batch, or a wrapper for Ghostscript that automates certain tasks. With Tcl/Tk you can immediately run it on most Linux distros and with Freewrap you get a Windows executable that's a few MB+your source (it's a lot better than having your users install Java).
Compared to Tcl/tk you get (A) catch errors at compile time, and (B) Qt apps usually look better than Tk apps.
With mxe+qmake it's one command to cross-compile from Linux to a Windows binary.
[1] http://www.red-lang.org/p/about.htmlI like Lazarus a lot. I am not a fan of Pascal though, and Red is under 1 MB batteries included. I like how it seems a cross between Lisp, Forth and other languages.
Eventually that got fixed, but we were already busy with other languages.
It was also very easy to embed inside a C application for a user facing scripting capability.
That wasn't my experience. At least in tcl/tk 8.5 things like zooming in/out of a tk canvas or updating a progress bar were a real pain.
For example, tk canvas has this nice, seemingly simple subcommand called "scale" that looks like it does exactly what it's called with a tag and two double-precision floats. Apply it and all the relevant tk items are scaled accordingly. It even has a predefined tag called "all" that applies to all current tk canvas items. Trivial. Awesome.
Except text items don't get scaled. And font sizes are limited to integer pixel/point sizes. So zooming is actually non-trivial. Not awesome.
There are a sufficient number of such idiosyncracies that if you want to make a clear, usable interface you end up battling the toolkit.
Also, on the tcl language level I felt the "everything is a string" feature gets in the way. I'd much rather have implicit expressions and explicit string declarations.
For example: Qt was released around the same time. Do you know if the first version included QGraphicsView? Because it has features we still associate with a modern 2d graphics API-- affine transforms, opacity, grouping of primitives, arbitrarily complex paths, and decent performance even with event handlers and many items being animated on the canvas.
When GP says "one of the first scripting languages with a GUI toolkit", he is talking about the early 1990s. Before even python's first release. In fact, python ended up with Tk as it's stdlb GUI package because that was what was available.
Sure, Tk will never live up to Qt, but in 1991, I bet it was quite impressive to have a relatively simple yet expressive language like Tcl that shipped with a cross platform GUI toolkit, all under a very permissive license.
For most Tcl/Tk usage at the time the same, unchanged, no "ifdef"'s present Tcl/Tk script would run identically on the various environments that it supported.
* the everything is a string, mantra
* meta-programming possibilities
* tcl wiki ( http://wiki.tcl.tk/ )
I think if someone can rewrite tcl or a tcl like language, as the top level language, using a more modern low level language, like Rust or Go ... it will be a very nice combo, I think Tcl can serve as a really nice declarative language
If you look at Sqlite, it really is the perfect example of an offspring of the tcl community, a declarative solution for a complex problem , written in C ... a perfect tcl
I stopped following Tcl a long time ago, so I have no clue where it is at now ... but i hope it is still being used, for the super nice community .. it had/has
Why would someone rewrite Tcl in another language? That is just an immense amount of work and would (re)introduce bugs that have been found and fixed in Tcl over the last 3 decades.
Just the fact that Tcl is old doesn't mean that it is dead. It is actively developed and used, although mostly hidden (its not that kind of hype around as with Python or Ruby). That Tcl is old does in fact imply that the code base is mature and reliable, its well documented and doesn't come with surprises. Which in turn means that your code is almost never broken with a new Tcl version. In fact, scripts and extensions written for 8.4, 15 yrs ago, are mostly still functional in 8.6 without modifications. Yet Tcl does come with pleasant surprises that don't break old programs, as can be seen with the new features in 8.6 (TclOO, coroutines, tailcall, try/trap ...)
we program at two layers, high level, and low level
features needed or preferred in low level programming, may not be required in high level programming and vice versa
there are several ways to work like this, and many people do for example, many developers use lua or python with c/c++
the effort needed to make the two language interact vary
another approach is to use one language with optional features, like optional typing or optional garbage collection, a language i believe is adopting this approach is red
have a programming framework, where two languages optimized for the two different layer use each others entities (names, objects, values, interfaces) seamlessly is in my opinion a super good approach for most programming
tcl + c .. are not exactly that and i believe a more modern combo will be better
I believe in this too. Not only two layers, if necessary there can be more.
For that to work, well designed interfaces are quite necessary.
"tcl + c .. are not exactly that and i believe a more modern combo will be better"
You don't necessarily need to reinvent Tcl in another "more modern" language to achieve that. You can compile Rust crates to dynamic libraries (.dll, .so) and use c types, or ffidl in Tcl (http://elf.org/ffidl/) to call the functions in your DLL-crates. Or write a small Tcl C extension to wrap function calls in the Rust code. That will do, without rewriting Tcl in Rust. For the other way around you can always call the Tcl library via its DLL interface in the same manner (which is the way to embed Tcl interpreters in other programs).
First you use it because it is simple to learn. Then you outgrow it and blame its weaknesses. Then you remember its strengths from a different perspective and pick it up again :)