You want to be a developer, so you're learning a language that is little-used. How do you plan on being employed?
In case your market share isn't small enough, you're then limiting yourself even more by focussing on an OO extension that fragments that miniscule market even further.
And you're arguing that TCL is great with a group of people, many of whom are developers who've used TCL in the past and deliberately don't use it any more. And you don't see any cause to wonder if they might have a reason for that?
Yes, I'm sure that there are people who still think that TCL is great. They're wrong. I know that it is no longer popular. And I'm positive that you lack the experience base needed to really judge its quality.
Here's some background information for you.
The object model that you're so impressed by? That's straight from Smalltalk. Except that it works better there than in TCL because OO isn't an extension - everything in the language can be leveraged that way. People have only been playing with this since the 60's, which is probably before you were born.
And some TCL history for you. TCL originally was a scripting language based on the idea that the only real datatype that you needed was the string. Properly delimited strings can be interpreted as anything that you want. Arrays, hashes, etc. And, better yet, if you did everything this way then it is really easy to interface with C programs - you just pass a string. Which was the point, the language is Tool Command Language - the tools that made it useful are supposed to be extensions written in C.
The idea was fairly reasonable circa 1990, and the rapid emergence of some useful tools like Expect and Tk proved its value. Adoption was quick.
However the language ran into a few stumbling blocks.
First of all it didn't do the whole scripting language thing very well. At about the same time that TCL was becoming popular, so was Perl. And Perl was a lot better than TCL - you could write real programs in it. For instance while you were supposed to extend TCL in C, you were supposed to extend Perl in Perl. (You could extend Perl in C but doing it in Perl was a lot easier...) Perl avoided a lot of parsing overhead. It came up with a lot of big improvements in what regular expressions should do. And as a result, Perl wound up resetting expectations about what a scripting language should be.
Secondly many of the tools, while useful, were bad ways to develop software. For instance Expect makes it easy to automate an existing console program. However if you do that, the result is very fragile - unanticipated errors cannot readily be trapped. This is not a good way to develop complex software. It is a good way to build a quick and dirty bandaid but it will fall apart later.
Thirdly it turns out that while it was easier to build tools and integrate them with TCL, building bindings to other scripting languages isn't that hard in the end. As a result the big tools that made TCL popular, namely Tk and Expect, wound up with bindings for every other major scripting language. And with popularity the other scripting languages (particularly Perl) wound up with bindings to every useful library under the sun - including many which TCL did not get (or at least not as promptly).
The result is that by 1999 it was fairly obvious that TCL was on its way out as a major scripting language. TCL 8 was a major rewrite that, as I recall, made TCL internally move away from the "everything is a string" philosophy, which greatly improved its performance. However they didn't give up the stupid idea of trying to be POSIX compliant on regular expressions. (Hint: POSIX and Perl's extensions do not play together in any reasonable way.) And they didn't manage to turn around TCL's long-term trajectory.
So lots of people here have used TCL. We used it because at one time it was the only way to access some genuinely useful tools. But it wasn't very good, and as soon as those tools were available in a different environment, we moved away from TCL.
Cheers,
Ben