That was the point! I pasted it as an example of what you can do with upvar, by bypassing lexical scoping. Take a look at other entries on that page: almost all high-level languages either pack the two variables into a list of some kind (passed by reference) or have a specialized language construct for this (inout etc.)
> neither has Tcl
This is very easy to disprove, take a look. This code:
proc g {} {
echo $a
}
proc f {} {
set a 10
g
}
f
can't read "a": no such variable
while executing
"echo $a"
(procedure "g" line 2)
invoked from within
"g"
(procedure "f" line 3)
invoked from within
"f"
(file "main.tcl" line 35)
(defun g ()
(message "%s" a))
(defun f ()
(let ((a 10))
(g)))
(f)
> just a really bad one.
It (upvar and uplevel) lets you easily define new control structures (think "unless", "until", "await", things like these). I don't think you can convince me that adding a powerful feature to the language is a bad decision... but that's indeed a matter of preference and there are people who use Go, so I'm not going to argue about this :)
At least there's no need for any kind of toString() method...
This is a design decision which makes the language smaller and easily composable. It also helps greatly with metaprogramming, because the code itself is also just a string - this makes Tcl homoiconic, which is a nice property to have. Last but not least, you can easily type-tag the values you use in more than one way if you want; you also have a built-in object system for cases where you need more structure in order for things not to get hairy.
> Dynamic scoping rules and `uplevel` & Co
Tcl is lexically scoped by default, it just provides ways to break out from lexical context. It's a good thing, allowing you to write for example this: http://rosettacode.org/wiki/Generic_swap#Tcl without any hassle. Like all design decisions it has its downsides, but it's a powerful tool if used correctly.
Tcl is not a bad language, it's just ill-suited for you or for your use case.