Re: Finding a niche for Tcl


Merrilee Larson wrote:

I agree! If the libraries *are* freely available, then the issue of "bundling"
them with the interpreter is only one of convenience. It wouldn't hurt if
there was a central repository for these libraries though - like CPAN, e.g.

There's been, in the past, several attempts at this. A new effort was
announced at the recent Tcl workshop - I suspect we'll begin to hear
more about this as Tcl 8.5 moves into beta.

We as a community need to publicize that fact in various ways, and
manuever ourselves into the limelight somehow - kick-*** projects;
side-saddling with Ubuntu et al; and, like you say above, have a well-organized
administration. We need to get back into the game!! What do you think?

I agree. And it doesn't take a lot of technical expertise for this to
happen. What will it take? Involvement by community members. When you
write a Tcl program that you are making available for others, mention
Tcl in the announcement. Copy comp.lang.tcl when you post an
announcement about your program in other newsgroups. Create a page on
http://wiki.tcl.tk/ and a link to the page from an appropriate page.
Write an article about your program for one of the various online web
magazines - and drop a reference to Tcl in the article. And so forth.

Within the tcl community itself, plan on working with the repository
team to contact the authors of your favorite extensions, volunteering
to help them (if necessary) to set up the formatting of the extension
into a format suitable for the repository and putting things in place
so that updates automatically get reflected to the repository. Send a
letter to the "editor" of your favorite technical magazine, mentioning
the repository, etc.

Then, those of you so anxious to get hoards of new Tcl users -
volunteer to answer questions here , on the wiki, and elsewhere. I
mean, if you want lots of people, then you need to step up to the plate
to hold their hands as they begin to use Tcl. Because the few resources
we have now are spread thin across working on the Tcl code, etc.

And, finally, help out with that job. If you know C, help with
debugging. If you know Tcl, help with debugging that portion, or
writing new test cases, or writing demos for code which doesn't have
demos yet. If you want some place to get your feet wet, help work on
the tutorial, submit bug reports about typos or missing info in the man
pages. If you have web experience, volunteer to help with
http://www.tcl.tk/ . The more of these things that you do - the less
that the C and Tcl programmers have to do relating to the less
technical aspects ... which means more features and bug fixes. You
could even help with the bug database - look at open bug reports,
attempt to reproduce the problems with the current version of Tcl, and
add a comment showing people what you've found.

.