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.
Ayam 3d (3D modeling package)
Source-Navigator (Source code browser and more)
Insight (gdb GUI)
M0571y H@rml355.
I always said TLC didnt write their own music!
Manipulate the moderator system! Mod someone as "overrated" today.
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.
Actually C++'s approach to simplicy is called...
Class Systems.
It's ridiculous to say C++ is a low level language. You can work at whatever high level you want. For god's sake with MS Dev you can even work in "draw an interface click to write code" mode.
No one has convinced me that C++ isn't arbitrarily high or low level, depending on what the developer wants.
-pyrrho
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).
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 $$$.
#!/usr/bin/tclsh
while {1} {
puts -nonewline "crap@syberpc:~$ "
flush stdout;
set instr [gets stdin]
set mcmd [lindex "$instr" "0"]
if {"$mcmd" == "exit"} { break
} elseif {"$mcmd" == "cd"} {
if {[string length [lindex "$instr" "1"]] != 0} {
puts "bash: cd: [lindex "$instr" "1"]: No such file or directory"
}
} elseif {"$mcmd" == ""} {
} else {
puts "bash: $mcmd: command not found"
}
}
#sry... im new to this
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.
"I was visiting to show off some research I was doing at the University of Oregon using Tcl (related to wearable computers)."
"Here, try this, it's a wearable tickle machine. Hey, wait, come back...."
--X [Who can't wait to see one of these on ThinkGeek.]Don't be fooled by the name. Yes, AOL owns this, but it's Open Source and Free Software. It's basically a webserver that heavily relies on Tcl. It's fast and uses a small footprint. And because it uses threaded Tcl, it could use a single thread to make multiple queries to a databse, thereby reducing the number of processes that needs to be spawned by your database server. Think about 8 queries on a single connection to an Oracle server instead of 8 connections (1 connection per query).
The layout managers were an especially nice feature, since they would manage the placement of widgets on the windows automatically. Coming from a Windows/Mac background, I had never seen anything like it.
Unfortunately, the actual experience of using Tcl/Tk was less nice. Even though it had a Windows-esque wrapping, the widgets still seemed to behave like Motif widgets (yech!), and the applications didn't scale well to low resolutions (800x600) - they all seemed to have been written for people with huge X Terminals.
As others have pointed out, the Tcl grammar is quite consistant, but so is LISP. It just felt klunky.
I spent some time browsing the Net looking for a version of Tk that stood alone from Tcl. There was one I found, but it was unmaintained. I dug into the code for a while, trying to see if I could do it myself, but it seemed pretty tightly embedded. Besides, trying to keep up with the changes to Tk seemed hopeless task.
To be fair, Tcl/Tk had a particular niche it was aiming for: being a "glue" language. For that, it seems to do an admiral job. But other languages (Lua, Perl) or toolkits (wxWindows, Qt) seem better poised in the market.
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 programmed both professionally, and while I'd rather use Java when working in a large group, I think Perl is prettier. TCL is elegant, but I hate passing all variables by value, and I think "uplevel" is a terrible idea. I find Perl more fun.
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
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
Robospud was a fixture for testing code in cable tv set-top box. It ran on an old Solaris box. A tv remote control was wired to a serial port, it acted as the "keyboard." The tv's screen was hooked to a video capture board on the Sun. Robospud would push the buttons on the remote, and "watch" the tv, making sure the right control screens came up on the set-top box.
It was written in expectk (tcl/tk/expect). It was a great alternative to testing set-top code by sitting their pushing buttons on a remote control, I met people who were well-paid to perform this mundane task.
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.