In many ways, the communities that surround programming languages are as interesting as many of the languages themselves (no, I'm not being sarcastic, programming languages can be interesting!). See the current over-the-top Rails Rant for an entertaining yet somewhat insightful take.
I've started working on something (will share soon) that involves some cross-language stuff, including digging into some internals. Ruby and Tcl are an interesting contrast, and it comes down to priorities of the core language people in each group.
Matz's philosophy on Ruby is very much that it is a language that programmers should enjoy, and that it should bring delight. That is, reading and writing code should be fun. In Ruby, it is. The syntax is beautiful and elegant, concise and just seems to have that perfect way of expressing almost any problem you throw at it; you may not know what that is at first, but when you stumble on it, it will put a smile on your face. I'm sure Ruby's deep cultural roots in Japan and its appreciation of artistic simplicity and elegance is a huge factor.
Tcl's design aesthetic (yes it has one) is more spare, far less about emotion and more about rigid adherence to rules: Everything Is (appears to be) A String, everything is a command, and the 11/12 syntax/parsing rules. Some (ok, many) might question whether the paradigm these rules set out is fun to program in, or elegant, but the logical consistency is appealing to many, and it's clear that some people are able to leverage that to do great things.
Tcl's reverence of rules springs naturally from the engineering/comp sci culture where it was born. This is even more evident when you look at its implementation. All the rigor that still goes into Tcl's internals — the bytecode interpreter, performance, full Unicode, threading, deployment, cross-platform and all this not only correct, but cleanly coded and well documented. Not surprising given Ousterhout's operating system roots, but it also served to attract people with the same perspective and priorities, and those are the types of people working on it today.
Implementation-wise, Tcl (which is also older of course) is worlds apart from Ruby. Ruby's performance is poor, I18N not there, threading questionable, deployment immature, code documentation of varying quality, and about 25% the amount of test code. It's why, among the dynamic languages, you often see Tcl used successfully in the more "extreme" situations, where correctness and performance and reliability are crucial. The expert Tcl programmer can take things further than the expert Ruby programmer in that regard.
Of course, extreme situations don't affect most development situations, though it's not unusual to get to the point where the pain starts getting very noticeable. But again, priorities. The Tcl guys can't understand why people aren't quite as obsessed with performance and corner cases, and don't understand why people make such a big deal about the syntax... it's just a bunch of rules after all; learn them and all is good.
The Ruby guys... well, it's not that performance etc aren't important, but there's just not as high on the priority list, and success is more "good enough" than "perfect". Which makes perfect sense for a less hardcore engineering culture that also values aesthetic and other concerns. Besides, you spend most of your time reading and writing code (90%?) and not in the really tough parts when the implementation can help you or bite you in the ass (another 10%-90%, depending on the project). Aren't both parts important?
What I want of course is a language with as good an implementation as Tcl has, so I have a development tool that is incredibly robust and scales to different sized problems better, but at the same time is as enjoyable and productive to read and write programs in as Ruby.
Tcl as a language won't significantly change. Ruby's implementation could and is, and its got an eager crowd of followers. The question is whether or not they've attracted the type of people and priorities that will deliver as good an implementation as it needs, and soon enough. I hope so, but I'm not holding my breath.