Most interesting use I saw for it was in agent-oriented programming. The idea was to move the code over to where the data was, it do necessary work, and it brings results back. The idea was especially interesting to those of us on 28Kbps modems. Tcl was one of contenders for being easy to read/write/process, having a Safe subset, cross-platform w/ GUI, and small programs in general. Telescript and Obliq were more practical. Tcl was quite versatile for a little, command language. Later powered then heaviest site, AOL, though the now open-sourced AOLserver and Tcl web framework.
It was also the scripting language used in Massive, the agent simulator for rendering crowds and battle scenes in the lord of the rings movies (and many others now).
Tcl is the language first used by the Expect testing framework back in ‘90. It was also used as the control programming language by nearly every networking hardware tool vendor since then. As such, Tcl became the default programming language of network and embedded systems QA and test automation engineers.
Tcl’s ability to extend the language syntax from within itself, and its ability to safely wrap procedure calls to recover from errors gave it a real edge in writing scaleable test harness frameworks. I’ve managed automation projects with 20+ engineers working on code bases with several 100K lines of code, all of it in Tcl. It is a powerful programming language that has been used behind the scenes in the corporate world for decades, and definitely not a ‘toy scripting language’!
Odds are very good that your Internet data is (right now!) going over some network hardware that was tested by a very large library of tests written in Tcl.
I think it’s super interesting how strings replace pointers as the main method of indirection in Tcl. I’m curious how this works from a security perspective - is it easy to accidentally put user data in a string that ends up being evaluated in Tcl?
I’d say its not any easier to do it accidentally than it is to do it in most other languages. A really neat aspect of Tcl, however, is that you can pretty much patch any language function in-situ. So if you are going to play things fast and loose and try to eval some user supplied data, you can patch up eval to do some extra sanity filtering for you and to run in a namespace with limited scope.
Its a really great language for writing programming sandboxes in. Say, for example, a test harness that needs to run individual test procs, but the harness itself needs protection from the test code it is running.
Most interesting use I saw for it was in agent-oriented programming. The idea was to move the code over to where the data was, it do necessary work, and it brings results back. The idea was especially interesting to those of us on 28Kbps modems. Tcl was one of contenders for being easy to read/write/process, having a Safe subset, cross-platform w/ GUI, and small programs in general. Telescript and Obliq were more practical. Tcl was quite versatile for a little, command language. Later powered then heaviest site, AOL, though the now open-sourced AOLserver and Tcl web framework.
It was also the scripting language used in Massive, the agent simulator for rendering crowds and battle scenes in the lord of the rings movies (and many others now).
A very stringly typed language, for sure.
Tcl is the language first used by the Expect testing framework back in ‘90. It was also used as the control programming language by nearly every networking hardware tool vendor since then. As such, Tcl became the default programming language of network and embedded systems QA and test automation engineers.
Tcl’s ability to extend the language syntax from within itself, and its ability to safely wrap procedure calls to recover from errors gave it a real edge in writing scaleable test harness frameworks. I’ve managed automation projects with 20+ engineers working on code bases with several 100K lines of code, all of it in Tcl. It is a powerful programming language that has been used behind the scenes in the corporate world for decades, and definitely not a ‘toy scripting language’!
Odds are very good that your Internet data is (right now!) going over some network hardware that was tested by a very large library of tests written in Tcl.
I think it’s super interesting how strings replace pointers as the main method of indirection in Tcl. I’m curious how this works from a security perspective - is it easy to accidentally put user data in a string that ends up being evaluated in Tcl?
I’d say its not any easier to do it accidentally than it is to do it in most other languages. A really neat aspect of Tcl, however, is that you can pretty much patch any language function in-situ. So if you are going to play things fast and loose and try to eval some user supplied data, you can patch up eval to do some extra sanity filtering for you and to run in a namespace with limited scope.
Its a really great language for writing programming sandboxes in. Say, for example, a test harness that needs to run individual test procs, but the harness itself needs protection from the test code it is running.