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)
[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 comparisonI'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
