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.
We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
I hope maintaining TCL is easier than maintaing projects written in TCL...
With the rest of computing going off in the direction of pass-by-reference, it's kind of refreshing to see some languages sticking to their antiquated guns and pushing pass-by-name.
It's kind of a forgotten art, but P-B-N makes some things like recursion and package scoping very very easy.
I have been pwned because my
I couldn't believe all the questions before you can download this stuff!
Look here:
Geez, some people. Oh yeah, get the crack yourself.
From the article:
.
Table of contents
1. TCL/TK Interview, Part 1
2. TCL/TK Interview, Part 2
3. TCL/TK Interview, Part 3
4. TCL/TK Interview, Part 4
5. TCL/TK Interview, Part 5
6. TCL/TK Interview, Part 6
Good thing they have it all on one page with the Printer-friendly version
Most people who hate Tcl just base their opinions on hearsay. I only respect the views of those who actually have maintained code.
It is easy, ecstatically so, to write organized, well-performing Tcl applications at any capacity. This is also true of Perl or even C++ (if you have a high pain threshold). That is to say, C++'s approach to simplicity and readability - if I dare assert that it has one at all - is being a low-level language, which keeps you in touch with the entire process on a byte-by-byte level, so it's never a challenge to understand what's going on under the hood. Perl's Way is to act like a natural language, so reading it taps into our inherent linguistic talents. And Tcl's is to just have an extraordinarily simple syntax - and in my opinion, it works.
The hysterical anti-Tcl sentiment is unfounded. My reply to one of these Tcl trolls on Everything2 goes into more detail: http://everything2.com/index.pl?node_id=1325568
(I'd be in under my normal account, but I can't retrieve my old password)
and the use of Tcl in the Mars Explorer project (the one that didn't crash!).
I was particularly interested in that use of Tcl, so I searched the web for more info, and all I could find was this document. Any more info would be appreciated!
Very popular slashdot journal for adul
For the most part, they were all Emacs losers. It's interesting that Mark Harrison, the only one to have "real world" experience (as opposed to academia and the Open Source world), uses vi.
I have been pwned because my
<Shameless Plug>Check out TPOP!</Shameless Plug> It's a POP mail client written entirely in TCL (by me) for the Tivo. (Tivo is heavily dependant on TCL for its functionality...)
They were TCLed pink.
OS Software is like love: The best way to make it grow is to give it away.
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?
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.
At the 1998 Usenix convention in New Orleans Ousterhout asked how many people used TCL w/o TK. Few raised their hands. Then he asked how many used both. Most raised their hands! Finally he asked about just TK users. Far more raised their hands than the just TCL crowd. He was surprised. He seemed to feel that TK was an addon. For a number of developers that I know and myself TK was the glitz and feature that drew me in. Otherwise I would have stuck with Perl.
With Ousterhout looking for greener pastures does this weaken the product? I would think so. If he doesn't believe in it then why should I? How long as he been gone. I couldn't tell exactly from the interview. If I missed it sorry.
I don't know about anyone else but I get in a "TCL" frame of mind. If I go off and do some C++ or Perl coding I cannot seem to read TCL code for a bit. I have to "warm up" or something. I'm aware of flaws in other languages - Perl syntax for example - but you can get some nasty TCL bugs that will simply doom you. It IS tricky at times.
I feel that TCL's strength was it was an early tool that worked across platforms, and was great for X GUIs. Today that is much more common among tools.
-Ron
PS: Ousterhout AND Welch used to reply to my questions years ago. They were terribly generous with their time answering emails. It kept me working with the tool.
One place that TCL really shines is with async sockets. TCL makes it really easy to prototype a server. It's builtin support of the server socket [socket -server cmd ...] enables a very easy creation of an non-forking iterative server, that does surprisingly well. And is also remarkably portable between windows, Linux, and Solaris.
I've also used Python for this, but I feel that Python's asyncore is still too buggy for prime time, and also the asynchore library is slightly more complex to utilize.
Another great aspect of TCL is how easy it is to extend. I can compare directly to JNI and Python extensions. TCL by far has the easiest and cleanest extension API for C or C++.
And finally embedding an TCL interpreter into another ap, is equally easy... Hence the near ubiquitour support of TK in other scripting languages, including Python and Perl.
Opinions from experience.
I'm at this point where I'm finding i'm doing everything in C, Fortran or shell.
I'm reckoning that I aught to learn a language that sits in the middle.
Is TCL a good option here? Or would I be better with Python or Perl. (Ruby's out - don't know anyone to ask stupid questions about Ruby to).
Tcl runs the operator interface of Shell Oil's Auger, a drilling rig in the Gulf of Mexico. See pictures of the rig here, and read about the system integrators here.
Don't like oil rigs? Well, it's highly unlikely that you can mod this post down without the Tcl that's built into practically every Cisco router on the planet. Read Cisco's tesimonial.
Once you've done that, go log off and watch TV. Oh yeah, did you know that the NBC network control system is a Tcl application? It is; it's been in the digital broadcast system from prototype all the way to full 24x7 operation. ComputerWorld ran an article about the project.
Science geeks will be interested that a Tcl interface is used to program the Hubble Space Telescope
Database heavies will be intrigued by the intimate role that Tcl has in Oracle Enterprise Manager.
I could go on all evening, this is just the tip of the proverbial iceberg.
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.
This is because they use AOLserver which is a massively scaleable and powerful web application server. Some of its features are:
The reason Tcl is the embedded language is that AOLserver was developed in the early nineties, when Tcl was the hot new language. If the system were to be developed today, I'm sure that the developers would have chosen Python, Perl or some other more buzzword compliant language that has a strong following.
That being said, Tcl in AOLserver still rocks for developing DB backed websites. In fact, the Open Architecture Community System (OpenACS) is a complete web toolkit for building just these kinds of sites. The Sloan School of Management at MIT recently funded the development of an open source course management system called dotLRN that is build using the OpenACS as its foundation.
So Tcl isn't just a GUI tool or a glue language. It's also a great language for web scripting!
talli
A number of the comments above revolve around Tcl's percieved lack of a standard object system. There is one, it's called [incr Tcl]. There are also a large number of other object systems many that fit naturally into the system for which they have been designed. I see no reason to insist on incorporating any object system into the core language. Much better to keep the basics small and compact and allow extension. The now standard Tcl distribution from ActiveState supplies all the bells and whistles you might need. But if you want a minimal system, you need go no further than the tcl sourceforge project and obtain just the language core. I would favour making the language more modular. Not less. Get the TCP sockets out into a loadable module. Chop out the regexp engine. This way if your intention is to drive a washing machine without internet access, you can use only the pieces you need. I've yet to meet another language that is as easy to extend with compiled modules as Tcl. Minimalism - it's the way forward.