3 ms·

There's something about Tcl that I like. It managed to take a few simple rules and parlay that into a language that seems like it's much more complicated than i

There's something about Tcl that I like. It managed to take a few simple rules and parlay that into a language that seems like it's much more complicated than it actually is. When someone asks me about Tcl I always tell them to just "man Tcl" (if you have a Mac, it's already installed). Look at that man page—that's the entire syntax of the language. Everything else in the language is commands. It's almost lisp-ish in its simplicity, but it feels like a "normal" scripting language. Even the base language was always made to be embeddable and extensible. I always loved that when you created a new Tcl command, the C function to implemented it looked like: typedef int Tcl_CmdProc(ClientData clientData, Tcl_Interp *interp, int argc, const char *argv[]); IE, just standard "main()" style code with a couple extra args. (The newer Tcls have a new API that doesn't use strings for everything but that's a little more complicated). This interpreter seems even easier, and that's saying something.

bch 11y ago
> typedef int Tcl_CmdProc(ClientData clientData, Tcl_Interp * interp, int argc, const char * argv[]); > IE, just standard "main()" style code with a couple extra args. (The newer Tcls have a new API that doesn't use strings for everything but that's a little more complicated). Tcl "Objects" (versus the pure string implementation) do honour the power, simplicity and "spirit" of Tcl just as well as your string example... int myCommand (ClientData clientData, Tcl_Interp * interp, int objc, Tcl_Obj * const objv[]) The "objects" (I quote this for a reason) are not object-oriented constructs, but a compound structure (we're talking the internal C implementation here...) to manage what a Tcl component is. The computing model is (and always has been) "Everything is a string (eias)", which is to say, there are no ints, floats, chars, etc in Tcl -- just strings. Non-string values are coerced correctly at runtime. With an object though, the "native" value for an entity is stored internally so that it doesn't have to be computed at every access. So, storage that is "9" will have (int)9 tucked away in the Obj if one is doing integer work with it. If you switch to float, it will have 9.0... you'll have fast access to the computed native value as long as you don't interleave accesses that want a different native type -- such as trying to retrieve an int, then a float, then an int, then a float... in this case, the objects "shimmer", in Tcl parlance. Like a lot of things Tcl (which has a long history), much of peoples recollections come from a long time ago... in this case, the new object (versus pure string) representation came into effect in 1999[0] with Tcl 8.0. In my opinion, the objects are just as easy to use as strings, and bring some nice performance improvements to the table. Otherwise, Tcl is still as fun to use today as it's always been, while it's also getting interesting tweaks and additions as time goes on. [0] http://www.tcl.tk/software/tcltk/8.0.html#What%27s%20New%20in%20Tcl%208.0 http://www.tcl.tk/software/tcltk/8.0.html#What%27s%20New%20i... Edit: formatting
kevin_thibedeau 11y ago
Jim is a nice lightweight reimplementation. I will say I was a bit disturbed at how the built-in commands are haphazardly scattered in the code when I had a peruse through it once. They are just randomly mixed in with other internal functions with no care for rational organization

bch 11y ago

> typedef int Tcl_CmdProc(ClientData clientData, Tcl_Interp * interp, int argc, const char * argv[]); > IE, just standard "main()" style code with a couple extra args. (The newer Tcls have a new API that doesn't use strings for everything but that's a little more complicated). Tcl "Objects" (versus the pure string implementation) do honour the power, simplicity and "spirit" of Tcl just as well as your string example... int myCommand (ClientData clientData, Tcl_Interp * interp, int objc, Tcl_Obj * const objv[]) The "objects" (I quote this for a reason) are not object-oriented constructs, but a compound structure (we're talking the internal C implementation here...) to manage what a Tcl component is. The computing model is (and always has been) "Everything is a string (eias)", which is to say, there are no ints, floats, chars, etc in Tcl -- just strings. Non-string values are coerced correctly at runtime. With an object though, the "native" value for an entity is stored internally so that it doesn't have to be computed at every access. So, storage that is "9" will have (int)9 tucked away in the Obj if one is doing integer work with it. If you switch to float, it will have 9.0... you'll have fast access to the computed native value as long as you don't interleave accesses that want a different native type -- such as trying to retrieve an int, then a float, then an int, then a float... in this case, the objects "shimmer", in Tcl parlance. Like a lot of things Tcl (which has a long history), much of peoples recollections come from a long time ago... in this case, the new object (versus pure string) representation came into effect in 1999[0] with Tcl 8.0. In my opinion, the objects are just as easy to use as strings, and bring some nice performance improvements to the table. Otherwise, Tcl is still as fun to use today as it's always been, while it's also getting interesting tweaks and additions as time goes on. [0] http://www.tcl.tk/software/tcltk/8.0.html#What%27s%20New%20in%20Tcl%208.0 http://www.tcl.tk/software/tcltk/8.0.html#What%27s%20New%20i... Edit: formatting

kevin_thibedeau 11y ago

Jim is a nice lightweight reimplementation. I will say I was a bit disturbed at how the built-in commands are haphazardly scattered in the code when I had a peruse through it once. They are just randomly mixed in with other internal functions with no care for rational organization