3 ms·

I think you should get an afternoon and learn Tcl, because it is clear from your post that you don't know it enough. A few remarks: 1) Ruby DSL, really? After

by antirez 15y ago

I think you should get an afternoon and learn Tcl, because it is clear from your post that you don't know it enough. A few remarks: 1) Ruby DSL, really? After you understand Tcl you'll discover how Ruby is not really a language suited for DSLs compared to TCL, even if Ruby is quite suited for this use case indeed. Tcl is not just much more DSL-ish as a syntax and structure, but also has some kind of "run time lisp macros" (uplevel) that let you do everything in your DSL. 2) Tcl built-in event loop provided a way to write very fast evented I/O apps easily. Something node.js is providing now was, in a different form, available since 10 years, and nobody noticed. However it is still very interesting, now with support for coroutines Tcl is very suited to take the state between firing of events. 3) Tcl as alternative of shell script is great, for a number of reasons: from the [glob] command to an [exec] command that is able to mimic a lot of what a shell can do. See the Redis unit test for an example of scripting stuff with Tcl. 4) Tcl vs Lua: Lua IMHO wins in the implementation, Tcl has not an ANSI target, and is a much larger implementation. But actually it is possible to write a large subset of Tcl in a very small space. I tried it in the past with http://jim.tcl.tk http://jim.tcl.tk, and indeed now this implementation is in use in the embedded world. Tcl lost at this point, but programmers willing to understand it will do a great thing, it is like to be exposed to a different new world. It's like learning Scheme or FORTH: mind changing.

SimHacker 15y ago
It's not that nobody noticed that TCL had async i/o, but that it didn't have closures, which make doing async i/o (or even user interface programming) much more difficult in TCL.
- johnm 15y ago
  In terms of this point, the lack of closures forced one to NOT write that messy garbage of code that people complain that the newbs are doing in node. I.e. it forces one to separate out the behavior from the construction and so systems (rather than off-the-cuff demos) are cleaner and easier to read and maintain.
  - SimHacker 15y ago
    Are you joking? It requires you to use a bunch of global variables and other auxiliary keys and data structures to keep track of the state that you would have been able to capture in closures. I ported SimCity to Unix with TCL/Tk around 1993 or so, and this is the typical code for handling an async IRC chat connection -- look at all the globals and spaghetti code: http://code.google.com/p/micropolis/source/browse/trunk/micropolis-activity/res/micropolis.tcl#1283 http://code.google.com/p/micropolis/source/browse/trunk/micr... Without closures, it's even harder to write reusable "components" that you can make more than one instance of. Look over that TCL code and try to figure out how it handles making more than one instance of each kind of window. It supports multi-player mode by making multiple X11 server connections, so it can have more than one instance of each kind of window, one for each X11 server connection, and some windows can have multiple instances on each server (like the edit and map windows). I had to write a lot of boilerplate infrastructure for creating/destroying windows and handling events, to store all the state for each window in global variables and structures, keyed by the window id, linked together symbolically, so windows on different screens don't clash, and even fix some bugs in Tk itself relating to having multiple windows on different servers: http://code.google.com/p/micropolis/source/browse/trunk/micropolis-activity/res/micropolis.tcl#702 http://code.google.com/p/micropolis/source/browse/trunk/micr... To create each window it would reload a file like this each time that set up all the globals and window links and bindings like "LinkWindow $head.map $win" and "bind $win <Visibility> {[WindowLink %W.view] Visible [string compare %s FullyObscured]}". Ugly shit man! Give me closures any day: http://code.google.com/p/micropolis/source/browse/trunk/micropolis-activity/res/wmap.tcl http://code.google.com/p/micropolis/source/browse/trunk/micr... Multi-head X11 support was not well tested in 1993, it got confused if the X11 servers had different visuals, and the TCL menu handling code had to be rewritten to keep the state in per-window structures instead of globals that made the assumption that only one menu could be popped up across all screens at once. Notice the "set screen [winfo screen $w]" and "set tk_priv(posted@$screen) $w" stuff: http://code.google.com/p/micropolis/source/browse/trunk/micropolis-activity/res/menu.tcl http://code.google.com/p/micropolis/source/browse/trunk/micr...
mechanical_fish 15y ago
Actually, I was technically a professional Tcl programmer in 1999, and I remember "uplevel" very well, because I got to watch as the MIT Scheme wizards put it through all its paces. Oh, the things those folks could do with Tcl. I really can't overstate how much fun it was to read their new libraries as they came out. I admit I've forgotten most of my Tcl, though. Because I haven't had a compelling need to use it in ten years, so I haven't. See above. Tcl is indeed "a different new world, like learning Scheme" (though Scheme has SICP, and Tcl has... what?) but this essay is not about "why Tcl makes a great academic paper" or "why Tcl is a great way to spend a Saturday night" but rather "why Tcl is not popular as a mainstream programming language". Being "mind-blowing" is not only not a path to mainstream popularity, but it's also a field with a lot of stiff competition: Scheme, Forth, Factor, Erlang, Io, Common Lisp, Haskell... several of these are on my personal todo list ahead of revisiting Tcl.
- jayferd 15y ago
  TCL has the TCLers wiki (http://wiki.tcl.tk/ http://wiki.tcl.tk/), which isn't the same as SICP, but is a great place to see awesome things TCL can (and can't) do.
jayferd 15y ago
> 3) Tcl as alternative of shell script is great, for a number of reasons: from the [glob] command to an [exec] command that is able to mimic a lot of what a shell can do. See the Redis unit test for an example of scripting stuff with Tcl. The thing TCL doesn't have are pipes. Not even Unix pipes, just some way of chaining little blocks together, so that complexity extends rightward, as you type.
- adunsmoor 15y ago
  What do you mean? exec cat /etc/passwd | grep root works just fine. You can also use Tcl's open command with a pipe to do back and forth communication with a subprocess. http://www.tcl.tk/man/tcl/tutorial/Tcl26.html http://www.tcl.tk/man/tcl/tutorial/Tcl26.html
  - jayferd 15y ago
    Yes, tcl's `exec` command implements a special syntax for using UNIX pipes, but what I'm referring to is not UNIX pipes, but a language feature - an interactive language needs to implement some kind of pipe/chain/cascade syntax, so you can use the results of a command without having to go back and surround it with parentheses or brackets.

by antirez 15y ago

SimHacker 15y ago

It's not that nobody noticed that TCL had async i/o, but that it didn't have closures, which make doing async i/o (or even user interface programming) much more difficult in TCL.

johnm 15y ago
In terms of this point, the lack of closures forced one to NOT write that messy garbage of code that people complain that the newbs are doing in node. I.e. it forces one to separate out the behavior from the construction and so systems (rather than off-the-cuff demos) are cleaner and easier to read and maintain.
- SimHacker 15y ago
  Are you joking? It requires you to use a bunch of global variables and other auxiliary keys and data structures to keep track of the state that you would have been able to capture in closures. I ported SimCity to Unix with TCL/Tk around 1993 or so, and this is the typical code for handling an async IRC chat connection -- look at all the globals and spaghetti code: http://code.google.com/p/micropolis/source/browse/trunk/micropolis-activity/res/micropolis.tcl#1283 http://code.google.com/p/micropolis/source/browse/trunk/micr... Without closures, it's even harder to write reusable "components" that you can make more than one instance of. Look over that TCL code and try to figure out how it handles making more than one instance of each kind of window. It supports multi-player mode by making multiple X11 server connections, so it can have more than one instance of each kind of window, one for each X11 server connection, and some windows can have multiple instances on each server (like the edit and map windows). I had to write a lot of boilerplate infrastructure for creating/destroying windows and handling events, to store all the state for each window in global variables and structures, keyed by the window id, linked together symbolically, so windows on different screens don't clash, and even fix some bugs in Tk itself relating to having multiple windows on different servers: http://code.google.com/p/micropolis/source/browse/trunk/micropolis-activity/res/micropolis.tcl#702 http://code.google.com/p/micropolis/source/browse/trunk/micr... To create each window it would reload a file like this each time that set up all the globals and window links and bindings like "LinkWindow $head.map $win" and "bind $win <Visibility> {[WindowLink %W.view] Visible [string compare %s FullyObscured]}". Ugly shit man! Give me closures any day: http://code.google.com/p/micropolis/source/browse/trunk/micropolis-activity/res/wmap.tcl http://code.google.com/p/micropolis/source/browse/trunk/micr... Multi-head X11 support was not well tested in 1993, it got confused if the X11 servers had different visuals, and the TCL menu handling code had to be rewritten to keep the state in per-window structures instead of globals that made the assumption that only one menu could be popped up across all screens at once. Notice the "set screen [winfo screen $w]" and "set tk_priv(posted@$screen) $w" stuff: http://code.google.com/p/micropolis/source/browse/trunk/micropolis-activity/res/menu.tcl http://code.google.com/p/micropolis/source/browse/trunk/micr...

mechanical_fish 15y ago

Actually, I was technically a professional Tcl programmer in 1999, and I remember "uplevel" very well, because I got to watch as the MIT Scheme wizards put it through all its paces. Oh, the things those folks could do with Tcl. I really can't overstate how much fun it was to read their new libraries as they came out. I admit I've forgotten most of my Tcl, though. Because I haven't had a compelling need to use it in ten years, so I haven't. See above. Tcl is indeed "a different new world, like learning Scheme" (though Scheme has SICP, and Tcl has... what?) but this essay is not about "why Tcl makes a great academic paper" or "why Tcl is a great way to spend a Saturday night" but rather "why Tcl is not popular as a mainstream programming language". Being "mind-blowing" is not only not a path to mainstream popularity, but it's also a field with a lot of stiff competition: Scheme, Forth, Factor, Erlang, Io, Common Lisp, Haskell... several of these are on my personal todo list ahead of revisiting Tcl.

jayferd 15y ago
TCL has the TCLers wiki (http://wiki.tcl.tk/ http://wiki.tcl.tk/), which isn't the same as SICP, but is a great place to see awesome things TCL can (and can't) do.

jayferd 15y ago

> 3) Tcl as alternative of shell script is great, for a number of reasons: from the [glob] command to an [exec] command that is able to mimic a lot of what a shell can do. See the Redis unit test for an example of scripting stuff with Tcl. The thing TCL doesn't have are pipes. Not even Unix pipes, just some way of chaining little blocks together, so that complexity extends rightward, as you type.

adunsmoor 15y ago
What do you mean? exec cat /etc/passwd | grep root works just fine. You can also use Tcl's open command with a pipe to do back and forth communication with a subprocess. http://www.tcl.tk/man/tcl/tutorial/Tcl26.html http://www.tcl.tk/man/tcl/tutorial/Tcl26.html
- jayferd 15y ago
  Yes, tcl's `exec` command implements a special syntax for using UNIX pipes, but what I'm referring to is not UNIX pipes, but a language feature - an interactive language needs to implement some kind of pipe/chain/cascade syntax, so you can use the results of a command without having to go back and surround it with parentheses or brackets.