Tcl the Misunderstood (2006)

[foobarian]

Another excellent aspect of Tcl I found is extensibility of JO's C implementation. At some point I needed to write some native code for speed and making this visible to the Tcl interpreter was a pleasure. Plus the codebase is so clean and well written.

[f1shy]

I've not seen the code, but the author has written a book [1] which has the advice I've ever seen. Much better than "Clean code" and other books in that direction. So it does not surprise me that the code is so well written.

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

[davidw]

Yes! Tcl's C code is a real pleasure to work with and extend.

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...

[082349872349872]

I'm pretty sure Ousterhout intended for people to write a few deep modules in C and only use Tcl to glue everything together/provide extensibility.

(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.)

[johnisgood]

I agree, I have modified Tcl's codebase, too, to suit some of my needs (I wanted to use Tcl as my shell).

[js2]

Previous discussions:

31 points|pmarin|16 years ago|17 comments

https://news.ycombinator.com/item?id=389107

181 points|zeitg3ist|12 years ago|110 comments

https://news.ycombinator.com/item?id=4920831

131 points|throwaway344|11 years ago|45 comments

https://news.ycombinator.com/item?id=7069642

182 points|goranmoomin|2 years ago|79 comments

https://news.ycombinator.com/item?id=31129936

[bsder]

The biggest problem with Tcl is the fact that C won.

This means that "" and {} are expected to work a certain way from C and when you hit Tcl you are HORRIBLY confused.

It's especially confusing as {} is simply quoting and has nothing to do with scope. The fact that Tcl is written such that {} is used with indentation in if-statements muddies the issue even further.

I suspect that a choice of ` (backtick) for Tcl " and " instead of Tcl {} would have made Tcl way less confusing to the vast majority of programmers.

I understand why things weren't done that way--having the ability to know that your quote has different characters for open vs close is very valuable for efficient parsing.

Nevertheless, the Tcl choices were unfortunate given the way history played out.

[mhalle]

The use of {} for strings without substitutions and effectively for scope are actually interrelated, remarkably.

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.

[boomlinde]

Sure, the "biggest problem with TCL" is some minor syntactical annoyance that you'd get over within the first hour of using it.

[lilyball]

In Tcl, "quoting" and "scope" are the same thing.

[ilrwbwrkhv]

This is fascinating. I have emailed Tcl's "father" (John Ousterhout) at length and he is one of the few to have actually tried to test what coding patterns make for better code and is the only book I recommend anyone when they want to get better.

Unfortunately most fall for the more popular Clean Code and it's derivatives.

Edit: The book is "A Philosophy of Software Design"

[lilyball]

I've long wished to have the free time to write a Tcl-derived language, because it really is so elegant in many ways, it just needs a bit of modernization in some areas. It's been years since I really thought much about this but I recall one of the things it's missing is closures (it does have lambdas at least).

Reading through this article, the memoize implementation does have an issue which is if the memoized command wants to call uplevel or upvar it'll get the wrong stack frame. If I were writing this I'd structure it so it's used like

  proc myMemoizingProcedure { ... } {
    memoize {
      ... the rest of the code ...
    }
  }

such that it can just `uplevel` the code. Or better yet I'd make `memoize` replace the `proc` keyword (or perhaps `memoize proc myMemoizingProcedure …`).

EDIT: I suppose memoizing makes no sense in a procedure that wants to use upvar or uplevel though, because memoizing only works for pure functions.

[monetus]

There are these pages on the wiki regarding closures, and a reference to needing to change the internals of tcl_ObjType in order to implement them.

https://wiki.tcl-lang.org/page/Closures

https://wiki.tcl-lang.org/page/Emulating+closures+in+Tcl

TCL 9 has surely fiddled with tcl_ObjType I hope, but it doesn't seem like it from a glance.

[andrelaszlo]

A lot of the power of expect seems to come from the fact that it's (normally) configured/scripted in Tcl

https://linux.die.net/man/1/expect

I really like that it, like the article mentions, just looks like config for basic scripts but also scales to whatever you need it to do.

[pjmlp]

In our application server written in Tcl/C, the configuration files were a Tcl DSL, the server would search for specific extensions and source the files, done.

[AceJohnny2]

indeed, and other ports of Expect (Perl Pexpect, Python PyExpect) feel awkward as the constructs don't map quite as well to those languages.

[sshine]

My favorite obscure line of TCL:

https://github.com/athas/EggsML/blob/master/concieggs/hooks/...

A line that contains a regex pattern for matching regex patterns.

TCL was chosen here because its regex engine isn't too powerful.

[stackghost]

>TCL was chosen here because its regex engine isn't too powerful.

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?

[generalizations]

The biggest weakness IMHO is the inability to comment out elements of an array. Even bash lets you do this and it makes testing and dev so much easier. Really wanted to love it, but that got in the way too many times.

[lilyball]

By arrays you mean something like this?

  array set foo {
    a 1
    b 2
    c 3
  }

If the inability to comment out entries here is a problem, that's also something you can fix, you can write something like

  proc decomment body {
    …
  }

such that you can then write the following and it will remove commented lines:

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

[cmacleod4]

TIP 401 proposed a fix for this but has not progressed so far - https://core.tcl-lang.org/tips/doc/trunk/tip/401.md .

[magicalhippo]

Wish I had this page when messing around with Eggdrop[1] back in the late 90s.

As a self-taught novice programmer that started with QBasic and had moved on to Turbo Pascal, I found Tcl to be very confusing and it left a rather negative impression.

Reading this page now though, it seems a lot more logical and reasonable than it appeared at the time.

[1]: https://docs.eggheads.org/tutorials/firstscript.html

[isr]

Don't blame you. If you treat tcl as a c-like scripting language, it's a mess. If you treat it as a "shell & lisp" combo, then you get to see it's power & flexibility.

[WillAdams]

One thing which I've always not understood about Tcl/TK is why there isn't a standard graphical tool for laying out a GUI program.

For a long while, when I might have used Tcl/TK, I instead used Runtime Revolution/Livecode (a cross-platform HyperCard clone) which had a very nice system for interactively drawing programs.

I'd really like for there to be an agreed-upon standard option for graphical program development which was interactive and cross-platform.

[ofalkaed]

I don't think it is needed. I am a hobby programmer and not even remotely competent but I can whip up GUIs in Tk with little effort and I find it quicker and easier than the graphical UI designers.

[musicale]

> why there isn't a standard graphical tool for laying out a GUI program

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.

[rmu09]

Once upon a time (Tcl??/Tk3.6) there was XF by Sven Delmas. It had some issues and really would have needed something like namespaces. AFAIR it took forever to get a stable version for Tk4.0.

[musicale]

> a cross-platform HyperCard clone

I wish there were more of these, preferably open source (and, since I'm dreaming, native and web versions.) ;-)

[import_awesome]

Another great feature of Tcl for writing servers it that you can reload the code while it is running and keep all the state and connections open. Code up/bootstrap your server while it is running the whole time. Sure this is a security nightmare, but it is fun to code.

[rwmj]

Nice! Did AOLServer (now Naviserver) do that? That was the major Tcl webserver that I remember.

[leoh]

Fun fact: SQLite’s test suite is written in TCL https://github.com/sqlite/sqlite/blob/master/test/strict1.te...

[graemep]

Because SQLite started as a TCL extension: https://sqlite.org/tclsqlite.html

[allknowingfrog]

Does anyone know of a good tutorial for getting starting with Tcl/Tk that still makes sense in 2024? I'm really intrigued by the idea of building and shipping simple, cross-platform GUIs, but I'm completely overwhelmed by all of the installation and configuration options. It seems like tclkit is supposed to be the go-tool tool for self-contained executables, but I honestly can't even figure out which site is the source-of-truth for downloading it, let alone installing it.

[cmacleod4]

I recommend https://wiki.tcl-lang.org/page/LUCK as a very easy way to build self-contained executables which bundle Tcl, a large choice of extensions, and your own code.

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 .

[ofalkaed]

John Ousterhout's Tcl and the Tk Toolkit is great and has been updated to Tcl/Tk 8.5 which is recent enough to not cause headaches. Don't think it goes into self contained executable but covers everything else very well.

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.

[mseepgood]

This language seems like a security nightmare to me regarding code injection attacks through untrusted inputs.

[zombot]

> Concept 9: Eval and Uplevel

That's where it gets really criminal: Dynamic scoping rules. There is no lexical scoping and hence no closures. If you use `uplevel`, your procedure works or doesn't, depending on the caller. There is a reason Tcl is the last language that uses this braindead mechanism.

[77pt77]

Tcl is basically a sloppier Perl with a GUI.

[BoingBoomTschak]

But you can look at it without barfing, at least. And have fun doing wacky metaprogramming instead of wacky code golfing aka obfuscation.

[kqr]

I came into this comment thread thinking "why should I bother with Tcl if I know Perl" but your comment nearly sold me. When I do Perl it's because I can afford to be sloppy, and coming with a GUI sounds like a good deal!

[tlavoie]

Well, and a GUI that people see fit to implement within many other languages as well.

[eternityforest]

TCL fits on microcontrollers. If I'm looking at anything other than Python or bash(for trivial logicless scripting) it's probably because I'm in a constrained environment.

[bch]

> Tcl is basically a sloppier Perl

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