Slashdot Mirror
Tcl Core Team Interview
Gentu writes "OSNews features a nice and long-ish interview with the Tcl core development team for just about everything. " Covers a lot of ground like what they actually use Tcl for, how they came to maintaining Tcl and so forth.
All the info you need
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
The last time I spent any time working with Tcl -- about five years ago -- I got frustrated by some of the same problems that it sounds like they're still facing (e.g. no standard methods for defining modules or objects). Based on the interviewees' responses to the "What are you working on now?" question(s), it doesn't sound like these issues are high priority, either (e.g. it sounds like most of Jeff's time at ActiveState is devoted to working on Tcl development tools).
I wonder if anyone setting out on a new software project even considers Tcl as a scripting language anymore, over (say) Ruby or Python. Has Tcl become the new COBOL, in the sense that its only relevance is for maintenance of legacy code?
They say that those who do not understand LISP are doomed to reimplement it, poorly.
Tcl stands as starkly illustrative of this principle.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Also, if you look at areas where Tcl/Tk applications compete with applications written in other toolkits (Zircon, Tkabber, etc.), the Tcl/Tk applications may be uglier, but they tend to be far more feature-complete.
Of course, Tcl/Tk has its limits, and something like iTcl/iTk is rather ugly. But overall, it looks to me Tcl/Tk must be doing something right, and it might be well worth for the developers of other GUI tools to try to figure out what that might be so that we might get the best of both worlds.
Ousterhout and Welch are still members of the Tcl Core Team, even if they aren't in the interview. Ousterhout doesn't do *any* coding anymore, on any project; a severe hand injury makes it impossible for him to type. And I have nothing but respect for Ousterhout's wisdom in letting himself be bought out two years ago, when a software company was still worth something. I'd hardly call it "bailing", more like "taking a profit." The point that Ousterhout and Welch used to reply to questions is a good one. The Tcl community is still like that. comp.lang.tcl is one of very few newsgroups where newbies don't get flamed to a crisp.
BTW, he still does use it, he has just decided that there is more to life than language development (he prefers building products). He has always been a good capitalist at heart, and language designers don't see big $$$.
No, no it's not. There is a reason no one else uses pass by name. It sucks.
How exactly does P-B-N make recursion and package scoping any easier than it is in a decently designed language?
Tcl is an okay language - I have been using it for more than 10 years in some big applications. But I've been using Python for about a year now and I feel that it's much better for real programming. The data structures are much richer - not everything is a string, it's faster, more readable, and makes good programming more natural.
John was a great software guy but he wasn't a language designer and (no offense) it kind of shows up in Tcl. The way comments work, and the fact that error messages don't tell you a line number from a source file, are both side effects of Tcl's hacky implemention.
The one huge advantage that Tcl has is Tk and even though other languages have Tk bindings they all seem awkward and second-class. But is that a strong enough advantage? I guess it depends on the application.
How does pass-by-name make recursion any easier?
The only decent advantage I've seen for pass-by-name is the oft-cited Jensen's device (lets you calculate summations rather elegantly by taking advantage of the way pass-by-name works). On the whole, it leads to a lot of unintuitive behavior, which means a lot of bugs.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I've racked my brain trying to figure out why Tcl is hated by so many in the "pop" geek community. The only answer that I've been able to come up with is the fact that those making the complaints are those who: a) do not actually know Tcl and haven't taken the time to understand it and b) are zealots of some other scripting language. A third possible reason that comes to mind is perhaps that some people just can't stand the idea of something that doesn't even closely resemble C-style syntax.
I started using Tcl/Tk at the suggestion of a fellow LUG member after explaining that I needed something a bit more complicated than xmessage to drive a script that I was working on. I dug in, found it strange, then found it cool, then found it fun, and finally knew enough to start doing some real work. I now use Tck/Tk on a daily basis on a wide variety of projects and have no intention of giving it up. A 5-year-old can understand the syntax, the commands are very well documented, and the community is stellar... none of the condescending holier-than-thou's that always seem to surround the hip scripting language of the month.
The Tcl'ers Wiki has quite a few pages examining why some people like Tcl and they're even keeping tabs on who says Tcl sucks and why.
TCL is a command language for TK. For that purpose it is excellent, but for general scripting it is awkward at best. If you have a GUI intensive application to write, use TCL/TK, otherwise use another language, such as Python.
By the way, check out GVI, the Graphical Voter Interface, which I wrote in TCL/TK.
I watch Brit Hume on Fox News
I'm working on a Java front end to talk to a Tcl back end. The back end runs on a 100Mhz 486 w/ 32MB of ram.
To do the Java (develop it -- with Netbeans) I needed to find a 1GHZ+ Pentium box with 256 MB of ram (could use more). And you know what with all that the TCL application starts (from source, remember) much faster than the (compiled) java app. Apples to oranges in some ways, sure, but still...
Plus TCL has built-in associative arrays and lists (how in gods name did they leave this out of Java), better event handling, and you get the source!
-- ac at work
OK - let's take these points in order.
Firstly you comment on lack of good libraries (perhaps missing Expect and Tk as obvious counter-arguments). There are plenty of libraries for Tcl of very good quality, as a quick trawl of the Tcl'ers Wiki, the Tcl FAQ or the Tcl developer exchange would show you.
Next, you move on to not supporting various programming paradigms. I'm completely lost by this statement. Tcl supports procedural, functional, OO etc styles quite easily. One of Tcl's key advantages is that it is easily adaptable to new paradigms. The fact that Tcl only contains the basic constructs for procedural programming in the core command set maybe where you are getting this from. A bit more in-depth look would show you that Tcl easily allows you to build on these to create whatever language/programming environment fits your problem. It's a very powerful technique.
Life outside the ivory tower seems to use Tcl quite a bit, if you look at places like IBM, AOL and NASA. Tcl is used in misson-critical applications which have run 24/7 for years.
As for syntax, Tcl has used the minimum set to do the job well. If you don't like using whitespace to delimit function parameters, you can define your own function construct which takes parameters separated by commas, or whatever. That's the beauty of Tcl - if you don't like it, you can change it *from within Tcl!* See wiki pages on Radical Language Modification and others for more details.
On top of all this, Tcl has great i18n and asynchronous I/O which most other languages still don't come anywhere near (especially on Windows). Threading is getting very robust. Virtual filesystem support, which enables technology like starkits, is also very cool. Tcl still has a lot to recommend it.