Actually, once I read what he REALLY seemed to be shooting for, I think it might actually be a GREAT idea!
Let's say you want to process a list of numbers, a set of data records, or something fairly complex. Internally, you can pass it between functions in a fairly compact, but almost illegible form. If a human user wants to see what's getting passed around, though, it could be handy if the system could automatically transform it to smoothing more human readable: tabulated, indented, pretty-printed, what-have-you.
I could definitely see a use for this, strange as it might seem.
I am primarily working on algorithms and love Tcl for building simple, robust prototypes. It is not perfect (I wish UDP support was a part of a core language or standard library), but I use it surprisingly often. YMMV
TCL was the chosen language of the company we worked for at the time. I tempted the author to join my team, and we collaborated on the book 'Docker in Practice' while implementing Docker within that company 2013-2015, before we both left.
TCL is an unreasonably effective language for certain use cases (the company we worked for were driven by extremely tight deadlines and high performance requirements (appserver written in pure C in late 90s, with call-outs to TCL for business logic).
Author here: doing this in any language is probably going to depend on some implementation details of the language repl, which may require dropping down to a level where you have access to these internals - for example, I can't think of a way you could achieve it in strict mode JS.
Python may well be able to do it with just the stdlib since it has excellent debugging capabilities, but Tcl is relatively weak. You might be able to do something with `tcl::unsupported::getbytecode` and checking the frame level, but this was just a throw-away novelty so I'm not particularly motivated to find out.
I don't think it's that easy. If the context is making javascript output something different in it's REPL for just "foo" vs "console.log(foo)", there's other pieces you would need.
Like overriding a built-in type and getting function.caller into valueOf(). As far as I can tell, JS doesn't let you just tweak valueOf(), you would have to re-implement all of, for example, the String class.
Reimplementing whole classes wouldn't have been a problem, just replace the original ones with a proxy to a copy.
Luckily console.log calls are actually excluded from the callers stack, so the only way is to change console itself. Just as evil if you also intercept console methods logging and return the original ones, but less of a mess at least.
I believe the point is that the bytecode 'knows' the context the value will be delivered to, which is the interesting thing that separates this from most other languages. From the README:
This is somewhat interesting. You can't use frames to differentiate between puts [schro] and schro, as they're both in the same frame. In fact, in the general case for a programming language, this is impossible - it would depend on using an oracle to predict what's going to happen to the value you return.
Happily, in Tcl we can cheat! There are three vital points - 1. Tcl compiles lines passed into the repl to bytecode, 2. Tcl bytecode is a stack machine and 3. Tcl has a pointer to the current execution location in the bytecode (note that point 1 only became true in Tcl 8.6 (I believe) so this code won't work before then).
- The cross platform UI, Tk. Even if you didn't like Tcl, it was, for a while, one of very few open source ways to get a UI that worked on a variety of platforms. Many things, mostly the web, killed this need. Also, there are Tk bindings for other languages now.
- Dead simple, lightweight, way to embed a user facing scripting engine into your application. Especially when the end user might be "technical", but not a developer by trade. This is still a need, but it looks like people are turning to Lua, Javascript, etc. Tcl is still embedded in a lot of hardware devices though...cisco routers, F5 load balancers, etc.
Edit: Related trivia. TCL's inventor, John Ousterhout, was also one of the co-creators of the raft consensus algorithm.
The thing is: I know what I think of TCL now, and I know what I thought of it at the time. They're pretty different.
I think ultimately we've come the conclusion that whole design space isn't that productive. Pervasive string expansion in an era of untrusted input probably killed it for the web before it even began.
It's a truly awful language. For some reason it's used by a lot of CAD/EDA tools (hardware development), so if you're working in that ecosystem it's often all you've got.
If you use it like, say, perl, then yes - some of the code looks horrible.
If you take a step back, really try to grok it, and then use it like a lisp (but for strings, rather than linked-lists), then its actually quite elegant (with sometimes messy indentation).
If you take another step back, glance sideways, look at every other unix shell, then look again at tcl's "undefined cmd" behaviour, the exec cmd, its inherent lispiness (see above) ...
... then you smack yourself on the head when you realise this is yet another defeat grasped from the jaws of victory.
Tcl should have replaced bash et al.
Especially so for jimtcl (a lightweight reimplementation of tcl, started by the redis author).
Right, Tcl is the lingua franca of EDA tooling. People just expect that you can talk to it via Tcl. It's often the only way to automate design flows, so you better get used to it.
Tcl is actually pretty decent as a language, very elegant in its utmost simplicity. I don't get the bashing here.
I didn't realize that this would come across as senseless bashing.
My main complaints against TCL basically center around the everything-is-a-string mentality and the corresponding lack of type safety anywhere.
A more minor objection is that I strongly dislike the syntax for numerous reasons, such as
- Comments aren't like any other language and have numerous gotchas, e.g., you can't use mismatched {}s in a comment within a proc,
- Whitespace is relevant in surprising ways, such as requiring Egyptian brackets for procs/ifs, and I constantly forget line continuations
- Using foo for lvalues but $foo for rvalues, while sensible, is a constant source of typos...
but, of course, you do get used to it. Mostly. But the comment thing really irks me.
I will certainly agree that you can do worse. TCL is surely a fine alternative to awful shell languages (bash, C shell, etc.)
But in the realm of dynamically typed scripting languages, I'd absolutely nominate Python or Ruby as a much more reasonable and sensible for your everyday programmer, and Lisp's S-expressions seem far more elegant if you insist on a unifying principle like everything-is-a-...
One thing that may be non-obvious to people unfamiliar with Tcl is that it's syntactically a shell-like language, i.e. functions are invoked with a space-separated list of arguments and no parens. So `schro` on a line by itself executes the function and `[schro]` is equivalent to `$(schro)` in shell.
Only when you're using the REPL. They call it "interactive mode". [ls], for example, will generate an error if you put that in a tcl script run non-interactively.
Another common cause can be the difference between interactive and command modes for Tcl. When you start up a Tcl interpreter, get a prompt, and type in commands to Tcl, this is called interactive mode. In this mode, Tcl does a few extra things for you. For instance, if you type ls, and you have no proc called ls defined, Tcl will try to exec a command called ls. This sometimes misleads a new Tcl user into thinking that Tcl has ls defined." [1]
