Much like Clojure took a bunch of neat stuff from recent programnming languages (first class hash maps! immutable data structures!), I'd love to see a Tcl variant that takes some inspiration from recent trends.
The "string based" part lies at the very heart of Tcl and plays a big role in what makes Tcl Tcl. However, modern Tcl has moved away from "everything is a string" to "everything is also a string". The difference is that in the normal execution path native types are manipulated for speed, but the string representation is always available should one need more dynamism.
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. No need for GIL, no need for serialization/deserialization (pickle/unpickle) ... just within process memory copy (or no copies in case data is immutable). Its virtual file system was another great innovation.
Lua has taken the crown for small embeddable/extendable language but I still have a soft corner for the playful vibe of Tcl. I would hesitate to use it in a project where I have to interact with folks with whom I have not programmed before (things like 'upvar' and 'uplevel' ups the amount of trust you need). But when its play time, breaking out Tcl is one of those guilty pleasures. Getting rarer these days, playtime that is.
Tcl had a reputation for being slow. But those were different times when the standards for 'fast' was much more demanding. Now I doubt it would be any slower than Ruby, it would likely be faster.
https://utcc.utoronto.ca/~cks/space/blog/programming/WhereTC...
https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...
... and discussion of the page immediately above:
https://news.ycombinator.com/item?id=3579088
Tcl does have a strange syntax. It tries to be "Lisp but with strings" and strings aren't even as easy to work with as what Lisp gives you, which are singly-linked lists of tokens and other singly-linked lists. And doing Lisp with other representations isn't that new: XSL is "Lisp but with XML", for example.
Today, Python has grabbed a lot of attention from Tcl - for "programming" it might be the more elegant language, but for "scripting" Tcl is hard to beat. But it is ironic that Python still ships Tkinter as the default GUI solution. If any language, Python should have standardized on GTK support, it had good support for GTK, but never standardized it.
The Tcl syntax is a bit rough, but is built on extremely simple rules. This has two benefits. First of all, it is - that was what it was designed for - a great language to control tools, that is, script complex programs. Thanks to the syntax, every function immediately becomes a command a user can type, no complex syntax for the input required. In that sense, like shell scripting, Tcl sacrifices a bit of syntax suger for the developer for a nice interactive input syntax. It is vastly nicer to program in compared to the shell languages :) The second benefit ist the ability to extend the language by the users - it doesn't even need a macro system for that like Lisp. Tcl is one of the few homoiconic languages.
Finally, while Tcl isn't as activelely maintained and especially extended as other "modern" languages are, this cuts in two directions. The implementation is extremely robust and many features are very efficient. Of course the basic execution speed of Tcl code is one of the slower scripting languages, but the libraries it uses are excellent. It had high performing event handling many years before Node.js made that populer.
I've been diving back into Scheme and one thing I found out was that in Scheme, procedures don't normally have an "external representation." I.e., once a procedure has been defined, I don't think there's a way to get that definition back out.
Tcl is really interesting in this aspect since procedure definitions (names, argument lists and bodies) can be viewed using the "info" command.
With that in mind, I'd say it's actually more homoiconic than Scheme.
Thanks!
It seems strange until you internalise the 12 rules, then it flows very naturally. There are none of the weird quirks you get in Ruby or Perl.
Tcl also added coroutines and a native object system in the past decade.
Tcl has variable trace hooks which can be called whenever an attempt is made to change a variable's value, the hook can block the change, making any so-traced variable effectively immutable. (see: https://rosettacode.org/wiki/Enforced_immutability#Tcl )
Tcl was designed in a different time when memory was scarce.
The point of being so "stringy" is that you could parse it in place in the same amount of RAM as the original "string program" took up.
I really would love something with similar constraints as the old Tcl for microcontrollers. BASIC used to run in 4K RAM with 4K ROM--I really wish we had a modern equivalent that I could connect to with a UART.
Quite often my constraint on a microcontroller is waking up and waiting for a sensor, transmitter, etc. -- I have forever to run interpreted code. A small language would be really nice.
Its focus on asynchronous programming, rather than relying on threads, really helps, as does the small memory footprint (105mb of RAM used for my app).
Java-based apps on the same tablet that I supply with the espresso machine run at a crawl, whereas my Tcl app feels normal.
If those tablets were running something like Aicas Java runtime, it would be much different.
What I want is something that I can hook up to the UART serial port, and start typing interactive commands into it to debug why my system is hung/stuck/etc. It needs to live in about 4K of RAM (and I can trade quite a bit of flash to do that).
16K of RAM is too much. Something like a Nordic nRF52811 only has 24K of RAM, and a lot of that gets used for the Bluetooth stack.
On bigger devices (PC/SBC/...) with an OS, Tcl/Tk is a wonderfully effective programming tool!