Ding ding. (Round 1 – for those who missed it)

Kidding aside, remember that I like and respect both of them.

Libraries

In the first article, I mentioned that Ruby has a lot of momentum, which is a pleasant change from Tcl’s relative ‘uncoolness’ amongst the Web 2.0/O’Reilly/”next big thing” crowd. That said, there are still places where that momentum hasn’t taken it. I set about writing some code that I’d wanted to play with that involves sending some email. Something that’s very easy in Tcl:

http://tcllib.sourceforge.net/doc/smtp.html (towards the end of thepage).

Python seems to have a pretty complete email system too, for that matter: http://docs.python.org/lib/module-email.html.

So it appears that, based on a sample of one attempted task (how’s that for statistics?), that Ruby is still lacking a few things in its standard distribution. Note that this functionality is available elsewhere (TMail, to cite one), but email is ubiquitous enough that it ought to be in the standard library.

Command line swiss-army knife

While Ruby’s OO system gives it a head start when you need to create a larger system with distinct parts, it can still be used as a quick’n’dirty scripting language for quick one-off jobs. From the man page:

% 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:

1. You may distribute the software in object code or executable
   form, provided that you do at least ONE of the following:

   a) distribute the executables and library files of the software,
   together with instructions (in the manual page or equivalent)
   on where to get the original distribution.

   b) accompany the distribution with the machine-readable source of
   the software.

   c) give non-standard executables non-standard names, with
   instructions on where to get the original software distribution.

   d) make other distribution arrangements with the author.

So it seems that you’re ok if you just call it something else. However, the license goes on to talk about several other files in the core distribution:

1. You may modify and include the part of the software into any other
   software (possibly commercial). But some files in the distribution
   are not written by the author, so that they are not under this terms.
   They are gc.c(partly), utils.c(partly), regex.[ch], fnmatch.[ch],
   glob.c, st.[ch] and some files under the ./missing directory. See
   each file for the copying condition.

Looking through the LEGAL file in the distribution shows that there are files distributed under other terms. Of course, they’re all free software, but some are LGPL, some BSD, and a few others for good measure.

Tcl’s licensing, on the contrary, requires very little understanding. The language was developed at the University of California, Berkeley, and the license remains BSD. This goes for many of the libraries and extensions as well. If you need to embed a language in your proprietary system, Tcl and its libraries present no problems whatsoever. Of course, I prefer to work with open source code and communities, but that’s not possible 100% of the time, so it’s always nice to know things are free and clear, should that need arise.

Internationalization

This is something the Ruby folks know they need to fix, and are working on, so it’s not worth dwelling on it much, but it is a proud point for the Tcl community. Tcl has had very nice i18n setup for many years, at this point – since the 8.0 release. It’s built into the language, so that everything works with it. You have commands to set encodings of IO channels, and even munge strings. Tcl wins here – no contest.

As I continue exploring Ruby, I think I’ll find more stuff to compare with Tcl, so we won’t ring the final bell just yet.