| Code by Kevin | |||||
|
Subscribe to RSS Feed 2011 2010 2009 2008 2007 2006 Categories Business Software General |
home
Wed, 31 Mar 2010 A hardy perennial among Tcl/Tk developers is hand-wringing over the language and toolkit's standing relative to other languages and toolkits. At one time Tcl/Tk was one of the most widely-used programming combinations around, but in recent years it seems to have lost some popularity and mindshare among programmers and companies. Tcl/Tk developer Mark Roseman has posted an amusing satire about this question. David Welton has also recently posted a more serious consideration of this question. His analysis, which focuses on both the technical and cultural reasons for this erosion in popularity, is astute. Still, even after acknowledging the relative decline of Tcl's mindshare and community size, I still have to believe that it's little more than an inconvenience--not a fatal liability--because the core language and toolkit are still being actively developed. Make no mistake: Tcl/Tk's small community and mindshare are definitely an inconvenience. In Perl or Python, if you're looking for a library or extension package, it's more likely that someone, somewhere has done it already, because their communities are larger. In Tcl/Tk, you often have to do it yourself. In some instances, the functionality I'm looking for is quite difficult to implement (such as SSH support) or is already fully available in another language (such as RSS parsing); in these cases, I may turn to a language that already supports them, such as Python. And even when I do undertake an extension project, such as adding drawers and sheets, I'm often completely on my own because no one else in the community has the expertise or time to offer insight or assistance. Most of my recent posts on the Tcl-Mac mailing list go unanswered because they involve rather complex questions about the integration of Tk and its underlying Cocoa implementation. In fact, it's not an exaggeration to say that the number of active developers of the Tcl-Mac community (contributing to the language's core or with widely-used extensions) can be counted on one hand. But these problems are an inconvenience--not a showstopper. I am usually able, eventually, to work out any problems I encounter in developing Tk extensions. And, more importantly, Tcl and Tk are getting development where it counts most. While the releases and improvements don't come as frequently as some other languages, they do come--and there are real improvements. Of course, many of these improvements are undertaken by the scrappy core team of Tcl/Tk developers. Some of them, however, are the result of corporate sponsorship, which contradicts those who say that Tcl's mindshare is withering. In fact, I am heavily dependent on the Tcl/Tk improvement sponsored by a single company: Apple. Apple has twice sponsored ports of Tk to run on top of its native GUI frameworks: first Carbon in 2001, and then Cocoa in 2009. Even though the core Tk-Mac community is small even by Tcl/Tk standards, Tk itself is so widely used on the Mac (by Python, Ruby, etc.) that Apple wanted it as a first-class cross-platform GUI library. That support by Apple, especially by sponsoring a Cocoa version of Tk, ensures the toolkit's future on the platform and is the major reason I continue to develop my Mac-only apps in Tk instead of another toolkit. I feel very confident in Tcl/Tk's future, and am not troubled by its small community. It would be nice if it had a larger community, but as long as the language continues to evolve and grow, then I will continue to stick with it. |
||||