Linked by David Welton on Mon 10th Mar 2003 21:42 UTC
Original OSNews Interviews The Tcl programming language has been immensely successful in its almost 15 years of existence. Tcl, stands for 'Tool Command Language' and is pronounced 'tickle' by those in the know. It's probably most famous for the Tk graphical toolkit, which has for years set the standard for rapid, scriptable, cross-platform GUI development, but the language is used throughout a staggering variety of applications, from the open source web server that runs AOL's web site, to code for network testing, to code to run oil rigs.
Order by: Score:
Some thoughts on TCL
by Anton Klotz on Mon 10th Mar 2003 22:42 UTC

At the moment Im writing my diploma thesis with TCL. At first I found TCL to be very obscure, it has quite different philosophy to other languages I used to use (JAVA, C, Perl). But now I really adore it. TCL is very robust and it is very fast to develop a program with it. It often happens to me that during I think how to solve a problem I start to type and voila the problem is solved, so Im surprized how easy it was.

But there are a few points which really should be regarding if you program TCL:

1. Documentate everything! Three days after writing you need some time to understand what you did. After one month it is very hard. For an outstanding person it is quite impossible. Every other language is easier to read and understand what the programmer meant to do with his code.

2. Think about efficient programming. Instead of writing constucts like these: lreplace $list [lsearch $list $element] [lsearch $list $element]], first define the result of lsearch and then do lreplace. Don't forget that every operation is a complex algorithm, which takes time to proceed.

3. Do refer by refernce, not by value. It takes time and space. IMHO TCL lacks an efficient garbage collector which frees lists, which are not longer needed. Please dont blame me if this has changed in the latest versions, my company where I write my diploma thesis is pretty conservativ with upgrading.

Does anybody has futher tips how to improve speed of the programm? I have to handle a lot of data, so Im happy about every speedup-tip I can get. Thanks.

Greetings from Anton and long live and prosper TCL.

Thanks
by Eike Hein on Mon 10th Mar 2003 23:58 UTC

Great & interesting interview. Good stuff in the last few days. First the KDE/Gnome one, now this. Kudos to the OSNews team.

Ok you have this large complex program probably written in C or C++. You need a simple straightforward interface that is portable between Unix, PC and Macs. You need it fast but it has to be flexible and good.

Tcl just rocks for this and creating tools (hence the name). I have worked on a project where it was used as the complete end to end development language for a large aolserver based web app. God it does not scale for me as well on the server backend due to speed issues and thread queueing between different parts of the application. The thread support is my opinion weak but I have NOT used tcl/tk 8.4.x so that might well be no longer an issue. However, let me say that I am quickly developing the opinion that scripting languages are usually not the best choice as a matter of course for large complex backend apps.

Maybe this is because I do software configuration management and keeping track of Perl Mods and tcl extensions many of which are obscure and hard to keep track of on a large project.

good story
by Taras on Tue 11th Mar 2003 01:53 UTC

Its too bad that tcl is soo evil. Every time I tried to program in tcl it feels like i have to turn my brain inside out. I might be good at C-style languages, but lispy stuff just hurts my puny little mind..tcl is probably the worst one. It looks like a normal lang..but as soon as you try to get something done..it hurts!

A few thoughts
by RJW on Tue 11th Mar 2003 02:47 UTC

I was going to post virtually the same think that Eike posted, so ditto to that.

I've had a soft spot for Tcl since I started playing around with AOLserver(http://aolserver.com) and ACS(http://openacs.org) a couple years ago. I don't agree that it's hard to read the code, I think it's pretty simple and reminiscent of shell scripts. I like being able to expand variables within strings, which makes text processing easy. I may have to go find something to do with Tcl now...

Using Tcl
by Clif Flynt on Tue 11th Mar 2003 02:50 UTC

The first time I played with Tcl, it felt a bit strange. But, after a dozen languages, all languages are a little strange.

By the end of the afternoon, I was producing more functionality per hour in Tcl than I'd ever managed in perl, awk/sed/sh, C, C++ or the other languages I'd used for years.

As a consultant, I bid jobs in hours, where other outfits bid them in months.

I use Tcl/C now the way I used C/Assembler a decade ago. Tcl for the structure and C for the parts that need speed.

I liked the language enough, I wrote a free CAI tutorial package for it (and later a book). Folks using TclTutor (http://www.msen.com/~clif/TclTutor.html) are generally writing production code in a couple hours.

Re: Using Tcl
by RevAaron on Tue 11th Mar 2003 05:32 UTC

Folks using TclTutor (http://www.msen.com/~c lif/TclTutor.html) are generally writing production code in a couple hours.

I don't know if you have a different definition of "production code," but I would not trust a complete newbie's code after running through a single tutorial. Hell, even in the language in which I have the most experience and am most comfortable, I would not put a substantial amount of code I've over a couple of hours into production. No way do you have enough time to test it. And this is Smalltalk, where I tend to write almost bug-less code. Unless, of course, you're using "a couple of hours" very liberally, meaning 24-48 hours. But that's a bit of a stretch.

Fixed link: http://www.msen.com/~clif/TclTutor.html

Re: Using Tcl
by Clif Flynt on Tue 11th Mar 2003 06:19 UTC

To clarify, after a couple of hours, folks are writing production grade code. Not finishing production grade application in just a couple hours. The actual applications may take much longer to complete, but the programmers are able to start on them quickly.

It takes me (and most programmers I know) at least a day of reading manuals and writing test programs in a new language before I'm willing to start writing 'real' code.

I agree that the time spent testing an application may exceed the time to write it.

Regression testing robotic vision code was what got me into Tcl in the first place. I needed a test platform that was not only robust, but easily rebuilt and reconfigured as the application was extended and modified.

Tcl/Expect fit the bill, and my benchtop test application eventually grew into the hardware production test system. This ran for 7 years, 24/7, until they discontinued the product.

It was a great language, however...
by xiong huan on Tue 11th Mar 2003 06:30 UTC

Tcl was a great language. The idea of a language that is embeddable and extensible is cool. However, its time has passed, python has surpassed it in all these aspects and is much better in many other aspects.

IMHO, among many other key features(ie, strongly typed or not, object oriented, garbage collection, etc.), readability and good api design are two important factors which affects if a language can be accepted widely or not. That is the reason why java and python has been widely used for large projects but perl and tcl not. For example, Tcl doesn't have good support for complex data structure. Although that can be improved, however, I don't think that will change people's traditional view of the language.

It may be argued Tcl is actually designed as a glue language for high level usage, as explained in http://home.pacbell.net/ouster/scripting.html . That is a good article and I learned a lot from it. However, being a glue lanuage doesn't necessarily mean being low in capability and putting everything in its backend module. In addition, after 5 years from the time the ariticle was written, there aren't many signs that script language is a better choice over system language for large software system integration. For example, GNOME and KDE are all based on component model, and their components are glued together mainly with C/C++ language. That reason is system language itself is also envolving and programmers have build enough skills and experience and know how to use it with great power and avoid pitfalls at the same time.

Having said that, I would like to show my respect for all these developers for their great work on Tcl and Tk(Tk is really impressive!). Anyhow, having one more choice when selecting language is always a good thing. ;)

I find Tcl useful as another tool in my scripting toolbag.
While I prefer in many cases to code in ksh or awk, I find Tcl most useful to me when used in conjunction with one of the dozens of useful extensions, such as Expect (for interacting with text based services and programs), Tk (for writing quick GUI tools), Oratcl (for interacting with Oracle), and so forth.

I also find http://wiki.tcl.tk/ and the associated chat room to be two of the more valuable programming resources to which I have access. The third valuable Tcl resource is news:comp.lang.tcl - the usenet newsgroup where, in more than 95 percent of the cases, civility and respect rules in
interactions with posters.

Re: Some thoughts on TCL
by Donal K. Fellows on Tue 11th Mar 2003 11:30 UTC

Anton: if you have any questions about speeding up Tcl, don't hesitate to email me if you don't want to ask somewhere like comp.lang.tcl. There's also a page about getting more performance out of Tcl on the Wiki (see URL in Larry's message.)

On the specific point of documentation, you should trust me in that in any language you need to take time to document what you do. It doesn't make much odds what language you use, as that program is going to be deeply mysterious in 6 months anyway. Often sooner than that...

Luv it!
by John on Tue 11th Mar 2003 13:51 UTC

3 words: I luv TCL!

I don't use TK, but use plain tcl for writing script to automize "things" (i'm a adminstrator) and I can archive it pretty quickly. And it's easy for me to understand as I said my main job is administrator so don't have much time to learn other things, but TCL was pretty easy to understand

Clean and perfect
by Kris Lawson on Tue 11th Mar 2003 15:53 UTC

Just have to mirror what Jeff said as I was just thinking the same the other day: if I had to design a language today from scratch, without any knowledge of Tcl, it would probably turn into Tcl in the end. Tcl just fits my style of thinking perfectly: it is syntactically uniform, yet doesn't force you into any particular paradigm or mold. Tcl cannot get old with time, as one can always write new language ideas as extensions to the language. So, in short, ultimate power and yet pure simplicity. Not many other languages can match that.

Strange that nobody mentioned RMS
by vlad on Tue 11th Mar 2003 16:44 UTC

I'm really surprised to see Clif Flint here - and I want to thank you for your book. That was really good book.
Welch's bokk turned me on to Tcl/Tk, but your book was more helpful in later work - especially in writing extensions.

Stallman did a horrible thing to Tcl/Tk - he didn't like the license (not GNU) and he didn't liked the language itself - he preferred Lisp (duh!). He combined both opinions together (was it on slashdot ?) and given his visibility many people on Internet were turned off from Tcl.
Their loss, IMO.

tcl and tk....
by hmmmmm.... on Tue 11th Mar 2003 18:08 UTC

fun stuff!





tcl/tk : Bloody good tool !
by Fortran Consulting on Tue 11th Mar 2003 20:58 UTC

Fortran + tcl/tk is an excellent combination for portability.

tk looks good on windows and bad on x11
by smoerk on Tue 11th Mar 2003 22:24 UTC

i wish tk would visually better integrate with gnome or kde. i think tk widgets on unix looks horrible and it's quite okay on windows (again: no standards for look and feel on most unix).

Re: Strange that nobody mentioned RMS
by RevAaron on Tue 11th Mar 2003 23:26 UTC

The RMS thing you're talking about can be read here:
http://www.base.com/gordoni/web/tcl-rms.html

This happened over Usenet, not Slashdot. This happened back in 1994, way before Slashdot. Most Slashdot readers have read nary a Usenet article that wasn't in alt.binaries.*. While RMS's opinion certainly influenced the decisions and the minds of the faithful, I don't see it as being a showstopper in the adoption of Tcl for new projects or by new programmers today.

RMS makes some good points, and some or many of these things are no longer true. However, some important points are still quite true and will never change, due to the design of Tcl, while some people may interpret some of these aspects as advantages of Tcl. RMS's idea in putting Tcl down was to push Guile up- Guile is GNU's official scripting language and GNU's official Scheme interpreter. It is quite powerful. I'm sure, over the years, RMS has wanted to see a wider adoption of Lisp in general and especially Guile by hackers in general, for tasks including prototyping and scripting. Unfortuantely, programmers are still not smarter than they were 10 years ago, and Guile, while a nice language, is still not very popular. I'd even say Tcl probably has more users.