Tcl might not be viable because it is too hard to hire Tcl-savvy employees

LV First, I just want to say that the title of this page is not accurate. I think it is fairly simple to hire Tcl-savvy employees. It may be difficult to locate one in the pay range or physical locale you want. But if you find one, it probably won't be too tough to hire them on to do Tcl.


Perhaps your organization believes this: "Tcl seems to be an interesting language, but if we use it to solve a problem, then we'll forever be at risk for losing all our Tcl expertise with no effective way to replace it." Your organization would be correct, of course, in its awareness of the strategic nature of its information technology (IT) assets.

Tcl is part of the solution, though, not part of the problem.

[Explain contracting possibilities, acknowledge hiring mis-practices, distinguish Tcl "learnability" from C++, ...]

There are certainly a number of contractors and Tcl programmers available. And in fact, there's always the possibility that one is using Tcl and doesn't even know it - I see remarks by Expect users occasionally that seem to indicate they don't realize the cross over.

RS Tcl skills are less frequently found in the market than, say, Java, but

  • for instance Tcl jobs gives some pointers to available experts
  • developing a working knowledge of Tcl takes a shorter period of time (if you don't expect features you know from other languages to be the same in Tcl)
  • but mastering the Art of Tcl may take a lifetime (after 7 years Tcl'ing, I still discover new things, or learn how to do it simpler)

Re the "mastering" side... seems to hold for all programming languages. Maybe that explains why people stick to what they know, against all further reasoning? -jcw

TV Mastering being interesting and all, it may not be the primary thing necessarily to master a certain language as a purpose, or as motivation. Maybe the only language one can want to master for overall purposes would be machine language, to be sure the machine does what one wants, all other types of 'masteries' would be subjected to at least being inferior or aiming for the type of efficiency lost from using the machine level, assuming that is achievable. Other mastering maybe would refer to ease of use, some eastetics or (legimate) efficiency and neatness criteria, and, importantly so in my opinion, how handy is the language, and how applicable to problems at hand.

Such as that probably C is most powerfull and can be applied to most known computer problems, whereas tcl adds a lot of list and user interface handling for problems which can use that. Redoing binary stuff in tcl may leave you at a loss to begin with, though, that misses the point and is probably because you want portability or not to have to use extensions and such. As well as doing a lot of programmer things like loops: the is given that you are working in tcl which not merely political, but never as efficient as doing the same in a decent compiled languages. Just like memory management is a hassle with them, one may want to combine language and approaches, it doesn't necessarily make sense to expect all from one language, and strife for mastery in such sense.

Coming to the point: getting things done is not so much important it seems in current software peopel employment. Many things could be done long ago, but are redone in java or MS fashion or simply by a certain clan or whatever instead of providing a shopkeeper with a handy bookkeeping and for instance webserving program.

Such considerations would seem important, and in that context, tcl has the potential to be used quite effectively for many problems without too much effort or need for mastery.

I thought I'd make a page about Tcl/tk mastery


[Explain radical claim that Tcl can be so much more productive in apt problems than, say, Java, that a company will find it cheaper to maintain a solution coded in Tcl, even with the cost of learning Tcl from scratch, than applying its in-place Java expertise on the comparable Java-coded solution.]

[You don't really need to explain that "radical claim"; simply make it. Since the claim is true (well, it sounds plausible to me, anyway), it should be much easier to defend than the marketing hype surrounding Java.]


Let's be precise: no one knows what Tcl skills are available in the marketplace. There certainly are people who present themselves as experienced in Tcl, who are, at best, terrible stylists; but I'd guess we've all encountered abundant instances of faked Java- or C-knowledge. What's most certain is that hiring departments are unaware of Tcl. With rare exceptions, they don't have a category for it, they don't track its presence or absence, and most work-seekers know not to waste space and time advertising their Tcl savvy. Few organizations have any positive information about the availability of Tcl skills. They certainly have a right to base decisions on that ignorance. It does not mean, though, that those organizations know that Tcl skills are absent. In fact, I'd guess each of us knows of instances in which an organization believed false things about Tcl, including the mistake that it lacked Tcl experience.


sheila, Question: I've been of the opinion that if someone knows a scripting language (such as perl), then they have already learned the scripting mindset and can easily pick up tcl. I've thought that was the main hurdle -- moving from a non-scripting to a scripting language. Is this not so?

Script-like thinking might confuse a non-scripting thinker because they don't, e.g., think of lists as code or code as lists, but a scripter can pick it up in a snap. They've already made the leap.

If we were looking to hire someone and had trouble finding a person with Tcl experience, I'd be willing to hire up a person who had familiarity with another scripting language. The learning curve is not steep.


Ro: I think you're underestimating the amount of time it takes to become productive in a language. It's not only about the syntax, but also about the tools surrounding the language that help you get work done. You don't just read Tcl.n, you also figure out freewrap, starkits, and all the idiosyncracies that drive us mad, until they become second-nature. Nowadays I don't think about how namespace eval works, but I remember struggling to figure out how to make code libraries... I thank my lucky stars that today is today! Tell me you never struggled with eval ;)


sheila: You have a point! Maybe I should make a new page (or does it already exist?). We have a tcl based automated test tool, and I often have to deal with programmers new to tcl who are assigned to write test scripts during the box test phase. Oh woe is me. :) I've seen some pretty atrocious coding. I want to decrease the learning curve as much as possible without agregious infodumping (which they'd ignore). Does this page exist? a tcl tutorial with surgical accuracy?

LV I doubt that a tutorial that matches what you have in mind exists - so why not start one?

JBR I doubt that the atrocious coding witnessed by anyone has anything to do with tcl.


My problem is a constant fresh influx of users (well, not exactly constant lately). I suppose the answer is DOCUMENTATION. Maybe that's the answer to this page too: good books and resources on all the advanced topics that drive people crazy. I've listed comp.lang.tcl down in my training for this year. (well, that's not how I officially put it, but unofficially, yes.)


AM I would say that the Tcl Tutor by Clif Flynt is an excellent vehicle to write such a tutorial - you can provide different levels of explanation for instance, along with code illustrating your point.


sheila Ok, it's official. Not only am I going to make up a tutorial for people, I'm going to turn it into a presentation. Part of the presentation is going to be on Tcl, the other on our test tool based in Tcl. I may try and see if I can glue Clif's tool into our test tool and write up examples peculiar to our stuff.

I've asked for requests on what people would like to see and a lot of folks said they'd really like some comparisons between doing things the C way versus doing things the Tcl way. RS: See - and refine Tcl in comparison

I'll run the class in about a week and a half and report findings, if I have any useful findings to report.


Arts and crafts of Tcl-Tk programming