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.
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
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...)
Actually, Tcl's C source code is some of the most beautiful I have ever seen. It is a pleasure to read and study. This is one of the reasons why it is so popular for embedding/extending.
You can check out an HTMLized version here:
http://tcl.apache.org/sources/tcl/
http://www.welton.it/davidw/
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.
For my part, I use Tcl/Tk for the GUI in my projects, but I don't build the whole thing with Tcl. What's handy about it is you can write your program in whatever language you want to, then start up an inferior wish process and send your GUI commands (generated at runtime) to that.
This gives a lot of easy flexibility, and also lets you use compiled languages as well as ones that don't have an up-to-date set of Tk bindings of their own (in my case, Common Lisp).
So for people who are just sending wish commands generated by another program like myself, it doesn't matter if Tcl itself lags in areas like OO, since you're only issuing commands one line at a time and the details are managed by the calling program.
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).
#!/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
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.
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.
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.