I'm sorry, but you're really wrong. TCL is a beautiful language; consistent, easy to extend both semantically and syntactically, it offers a stable and mature ecosystem and is quite performant for an interpreter.

> it's the most god-awful language I've ever seen

I wonder, how many and which exactly languages have you seen, used and learned? Are you sure you're versed in PLT enough to be able to really understand all the TCL features and their impact on the language?

I'd say TCL is fairly similar to Lisps and REBOL, which makes it both simple and hard to master. It also makes it very different from BASIC...

[EDIT: typo]

My exact pain points with Tcl are: (1) No types at all, everything is a string. If strings are all you have to deal with that may be enough but it gets hairy fast for everything else. (2) Dynamic scoping rules and `uplevel` & Co. Do I really have to say anything about that?

> No types at all, everything is a string

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.

That rosetta code has NO static scoping (neither has Tcl, you got that wrong). It uses dynamic scoping with `upvar`. It's a design decision all right, just a really bad one.

> That rosetta code has NO static scoping

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

results in an error in Tcl:

    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)

while in a dynamically scoped language, like Emacs Lisp, it would work:

    (defun g ()
      (message "%s" a))

    (defun f ()
      (let ((a 10))
        (g)))

    (f)

How can you argue with that, I wonder? :)

> 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 :)