Biella Coleman: The Peer Review
Thanks to a Mr. Kandinski, I just learned about what looks to be like a really useful (and pretty) guide for graduate students and young professors.
% cat /tmp/junk
matz
% ruby -p -i.bak -e $_.upcase! /tmp/junk
% cat /tmp/junk
MATZ
Very handy. Tcl's command-based syntax just isn't quite as quick for those sorts of operations, so Ruby wins hands down here. I've suggested that the Tcl folks distribute a second program that takes a lot of the Perl-style command line arguments for this sort of work, but the idea doesn't seem to be of much interest.
C API's
On another tack completely, one of the things that originally drew me to Tcl was its very, very nice C API. It's documentation is clear, and thorough, and the API itself lets you get involved in pretty much any aspect of the language that you want. This makes sense, because when Tcl was originally created by Dr. Ousterhout in the late '80ies, the idea was to create a scripting language as a C library that would be loaded into other programs. The language has always been faithful to its heritage, and to this day I find it lots of fun to merge Tcl with C code.
I have to admit that I don't know the Ruby API all that well, but what I have looked up looks pretty nice. To a certain degree, it's comparing apples and oranges, because Ruby requires you to deal with the very object oriented nature of the language, whereas Tcl is a lot more direct. The Programming Ruby book's coverage of the subject also leads me to believe that Tcl really gives you access to more stuff (interpreters, channels, events, and many other parts of the system). Ruby seems to take an approach that might best be described as letting you write Ruby in C - meaning that you create Ruby objects, use their methods, get their values, and so on, but you're still really dealing with Ruby. This has a certain elegance, but sometimes it's necessary to muck about with things at a lower level.
I don't know how it works out in practice, but Ruby has a bit more infrastructure in place for actually building extensions once you've created them. Tcl has "tea", which is a set of m4 macros, but anyone can tell you that the auto tools are not much fun to work with (going to the dentist is more fun) - anything that keeps me away from them is welcome.
Garbage collection
One of the more interesting aspects of the different approaches to C interoperability is the fact that Tcl uses a simple, robust, straightforward reference counting system to keep track of, and throw away resources that are no longer used. Ruby has a mark and sweep garbage collector, which is probably more sophisticated, but also more complicated, and requires a bit more support from the programmer initially. The benefit is that once things are set up, they require less keeping track of, because you hand off memory management to the computer. From the end user's point of view, Ruby wins here, but if you happen to be writing a C extension, I could see it being more difficult to write and debug to this API, although Tcl has its own warts, one of the worst of which is the fact that Tcl values must be convertible back and forth to strings, so that for things like a file handle that can't really survive the round trip, because it's just a pointer, you use a hash table and some sort of string to hold onto the object:
"file1" -> int fd1
"file2" -> int fd2
which makes it impossible to GC these values.
I suspect that both approaches have their merits - Ruby's is more elegant, but Tcl's is simple and rugged.
Licensing
Bouncing back to something completely non-technical, Ruby's licensing is either the GPL, or their own license. If I understand things correctly, you can get around the GPL's "viral nature" by simply renaming things, if you have a need to include Ruby in a proprietary product:
Architecture is the stuff that you can't refactor in an afternoon.(via The Pragmatic Architect)
Next.