Live data from Hacker News

Tcl the Misunderstood (2006)

antirez.com

51–60 of 72 posts

Re: Tcl the Misunderstood (2006)

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

Re: Tcl the Misunderstood (2006)

#52

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.

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

Re: Tcl the Misunderstood (2006)

#53

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

One genuine problem was the you could send snippets of code to any Tcl/Tk program running on the same X server and it would execute them. Obviously X isn't the most secure of systems and you should trust your X clients, but this made it very easy if you could persuade someone to run a "command line" program. I wonder if that was fixed?

Re: Tcl the Misunderstood (2006)

#54
post #20

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.

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

While I agree, it was what eventually made us move into .NET, and the founders of the startup I started in 1999, eventually went on to create OutSystems.

Too much code being rewriten from Tcl into C for performance and scalabity reasons, and it still doesn't have a proper JIT.

Now as a way to script C code, it is even easier than CPython.

Re: Tcl the Misunderstood (2006)

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

Re: Tcl the Misunderstood (2006)

#56

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 sour…

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 .

Re: Tcl the Misunderstood (2006)

#57
post #53

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

One genuine problem was the you could send snippets of code to any Tcl/Tk program running on the same X server and it would execute them. Obviously X isn't the most secure of systems and you should trust your X clients, but this made it very easy if you could persuade someone to run a "command line" program. I wonder if that was fixed?

This is something to be aware of. It can be guarded against, see https://www.tcl-lang.org/man/tcl/TkCmd/send.htm#M9 .

Re: Tcl the Misunderstood (2006)

#58
post #53

Earlier quoted context omitted.

One genuine problem was the you could send snippets of code to any Tcl/Tk program running on the same X server and it would execute them. Obviously X isn't the most secure of systems and you should trust your X clients, but this made it very easy if you could persuade someone to run a "command line" program. I wonder if that was fixed?

This is something to be aware of. It can be guarded against, see https://www.tcl-lang.org/man/tcl/TkCmd/send.htm#M9 .

To be fair, it is a pretty cool feature.

Re: Tcl the Misunderstood (2006)

#59

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.

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.

Re: Tcl the Misunderstood (2006)

#60

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…

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

[dead]
Post reply on HN