[1] https://milkov.tech/assets/psd.pdf

I got to write some of the updates in this 2nd edition regarding the C interface:

https://www.oreilly.com/library/view/tcl-and-the/97803216017...

(we did exactly this for networking code about 30 years ago: C for the data plane and Tcl for the control plane. That architecture remained in service for decades.)

Scopes are special syntactic forms that delegate variable substitution to the associated procedures. For example, a "for" statement evaluates the body of the function after substituting the loop variable. In a string based language, that's basically the same as expressing the scope in a string form where the string content is passed verbatim as an argument without variable substitution or function invocation.

Having used Tcl extensively back in the day, I am not sure that this syntactic cleverness really was a major impediment to adoption. It was just something to learn. Same was true with [] meaning lisp-like function calling rather than array definition.

Baseline Tcl's biggest challenge, in my opinion, was providing mechanisms to write modular code for larger programs and data encapsulation. Core Tcl put off decisions about the appropriate mechanisms to do so by only providing "namespaces" as a building block for higher level third-party syntax. That led to fragmentation at a time when other languages were gaining popularity.

Uh, not sure I see the significance but wouldn't that make Tcl less apt for this than something else? Why would you purposely choose a less powerful regex engine?

  array set foo {
    a 1
    b 2
    c 3
  }

  proc decomment body {
    …
  }

  array set foo [decomment {
    a 1
    # b 2
    c 3
  }]

It is a bit surprising since it seems like you could use Tcl/Tk to write it.

The Tk canvas makes writing simple drawing programs fairly easy, and a GUI editor seems like it wouldn't be terribly difficult.

There is a tutorial on the Tcl wiki which should be reasonably up-to-date - https://wiki.tcl-lang.org/page/Tcl+Tutorial+Lesson+0 .

Edit: Just remembered that Tcl/Tk: A Developer's Guide by Flynt has a chapter on self contained executables and the various tools for making them. Have not looked into this book much so can't comment on it.

If you were going to handle "untrusted input", that's how you would do it in tcl.

Note: this is separate from tcl's multithreading capability, where it can also run individual interpreters per thread , with thread safe channels between them. (btw, you can mix & match both approaches - multithreading & nested interpreters)

That’s a hot take for one language with basically a sheet to describe it[0], and another whose “rules” are best described by “whatever this implementation does.”

[0] https://wiki.tcl-lang.org/page/Dodekalogue

The last implementation in https://wiki.tcl-lang.org/page/Closures is pretty nice.

    type Point struct {
        X int
        Y lnt
    }

I think a lot of this ground was treaded with modern JS compilers (that had to infer a lot of this kind of information from very little context), or efforts like Python type annotations. Dynamic languages are still cool, and even cooler when the compiler can still somehow actively help you.