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.
Unlike Perl or Python, which are still maintained by their
original authors (Larry Wall and Guido van Rossum), Tcl
ownership has changed hands – Dr. John Ousterhout, who wrote Tcl
while a professor at UC Berkeley, has moved on to other
endeavors (although he does keep an eye on his creation), and
others have stepped forward to not only maintain Tcl, but work
on improving and extending it.
Several of the "core team", including the lead maintainer, Jeff
"The Tcl Guy" Hobbs, Andreas Kupries, Donal Fellows and Mark
Harrison, were kind enough to take some time to respond to some
questions about a variety of topics via email. We start by
asking Jeff about how the torch was passed…
Jeff, can you tell us a little about how ‘ownership’ of Tcl,
passed from Dr. Ousterhout to yourself?
Jeff: John hired me to do it. ๐ It
actually took three tries (third time’s the charm). The first
time I met him was while he was at Sun Labs. I had been working
with Tcl for a while already, both at the Tcl user level as well
as the Tcl/C level, including extension authoring. I was visiting
to show off some research I was doing at the University of Oregon
using Tcl (related to wearable computers). I met all of the Sun
Labs Tcl team at that time. It was actually following that visit,
after talking with John and Jacob Levy, that I was inspired (with
some encouragement from them) to write the first Tcl plugin to
Netscape. It was a windowless version, but it worked. Anyway, I
digress … I had an offer to join the Sun Tcl team after
graduation but turned it down as I wasn’t so sure about moving to
the Silicon Valley and working for a large company. I received
another offer as he was forming Scriptics, but that coincided with
the time that I had received an offer from Siemens in Munich. The
idea of a startup was more appealing, but the choice between
Munich and Mountain View was … well, we know how that turned
out. ๐
The third and successful offer came while I was at Siemens in
1999. It took John some convincing to get me out of Munich, but
basically the management of core development at Scriptics (which
it was still called at that time) was all the sweetening that
was necessary. Previous offers had been more oriented towards
being a part of the core team, but as Scriptics was becoming
more successful, John had essentially stopped coding to work on
the business side, and other previous core team members were
focused on other development. At that time the management of
the core was nearly non-existent, which was becoming apparent to
the community as well. I have a very nice graph from the
February 2000 Tcl conference that shows the marked decline in
open bugs and features requests following my starting with
Scriptics in August 1999.
I wasn’t the only one qualified to take over from John, although
I did have years of experience with Tcl/Tk by then. I have
always had the luck of having had a job that intimately involved
Tcl development since university (where I started using it).
Other core team members like Brent Welch and Scott Stanton were
interested in other things. One important facet that I did
bring to it, which perhaps only an outsider could bring, was
enthusiasm, and a project like this requires lots of that, plus
energy and the right stuff to keep going.
What is your role in the Tcl core team?
Jeff: I am the release manager,
maintainer of too many parts to remember, general motivator and
rabble-rouser.
Andreas: I have one?
Donal: I’m the TIP editor and a core
maintainer too.
Can you tell us a little bit more about what
the TIP, or "Tcl Improvement Proposal" is?
Donal: Well, the TIP process came
about when we started to think about how we could encourage
people in the community to contribute to Tcl and Tk. While we
could have kept going in the way that Sun and Scriptics had
operated in the past, we really wanted to encourage more people
to contribute; it was felt that the barrier to entry was too
high before. But we weren’t willing to drop our engineering
standards; good tests and documentation are a vital part of
contributing to the core, since we recognized that that was one
of the big strengths of what John Ousterhout etc. had achieved
already. However, it was when someone spotted what the Python
people were up to that we decided we wanted something similar
ourselves. Not that there was a lot of agreement on how to do
it though; early versions were heavily dependent on using
tclhttpd as a hosting environment. The current format is
something I invented (over a weekend) based on the input format
used by the Tcl’ers Wiki [*]
(which it was obvious at that point was going to be hugely
popular, even though we – well, I at least – didn’t expect it to
grow quite as much as it has done) though it fixes some of the
things that I thought were wrong with the Wiki format (the TIP
format is far less ambiguous) and it has mail-like headers to
handle the additional features due to TIPs being more than
collaboratively edited documents, but rather something of a
standards process.
They’ve done well, haven’t they! :^)
How did you get started using Tcl?
Mark: I was present at John
Ousterhout’s 1991 Usenix presentation talking about wish. It
totally blew me away, and I knew it was a system I wanted to
use.
Jeff: I’ve been using Tcl for about a
decade, since 6.7, picking it up in university. At the time I
used perl more for general scripting, but Tcl really grabbed me
with Tk, and over time I grew to appreciate Tcl more.
Andreas: That is quite long in the
past. … Tcl 7.3, Tk 3.6. A co-worker at my employer used it
for… I don’t know anymore (despite the fact that said
co-worker liked lisp/scheme more). It interested me enough that
I bought John Ousterhout’s book when I saw it. From there on it
was a long slide into … hm, I can’t say insanity, because it
is not. Whatever.
Donal: First encountered it when I
saw Ian Jackson using it to write a very neat network client.
(He was actually using wishx, I know now.) Then I did nothing
about it for a year, because I was sorting out things like
graduating and getting a new job. However, I eventually found a
copy of John Ousterhout’s Tcl book, read that cover-to-cover,
downloaded 7.4b1/4.0b1 and haven’t looked back since.
The original core team was elected in the
Summer of 2000 by Tcl users. All of the interviewees were
elected then to be part of that team, but we ask them how they
got to that point:
Mark: There’s a funny story about
that. When the voting opened up, I was imagining the thousands
of Tcl programmers at IBM, Sun, Motorola, etc, casting their
votes. So I sent an email to my coworkers at AsiaInfo telling
them to vote for me as soon as possible if they wanted me to
represent them on the core team. Unfortunately, I had seriously
overestimated the amount of voting which would go on in the TCT
election. Because of that, and because China’s daytime is
everyone else’s nighttime, on that day our votes represented a
bit over one third of all the votes cast.
There was quite a to-do over the whole incident, especially as I
tried to demonstrate that all the various Wangs, Zhous, and
Zengs were real Tcl programmers and not the imaginative
byproducts of a Tcl voting script. ๐
Donal: I’ve no idea really. I
volunteered (for reasons I don’t remember), but didn’t really
expect to get in. Perhaps people voted for me because I liked
(and still like) to help people out by trying to see what their
real problems are, but I wish I knew for certain.
Jeff: I’ve been a contributor to the
core for a long time, but getting hired to manage it at
Scriptics likely secured my spot (they are of course
correlated).
What do you use it for?
Mark: Tcl was a critical part of our
infrastructure at AsiaInfo. We used it as an embedded logic
language for expressing rules regarding the Internet subscriber
database.
The first Tcl program I wrote that ever shipped to a customer
was a database entry/query system for Alcatel. The real GUI
(done with OpenLook) was scheduled to take about six weeks. We
sent this little program to our beta customer and it worked well
enough that the original GUI was not needed. It was later used
in a GUI design course as the example of an ugly GUI that
shouldn’t ever be shipped to a customer.
Jeff: At ActiveState we continue to
develop new developers’ tools for Tcl users, built in Tcl/Tk.
The ActiveState GUI Builder [*],
which targets multiple Tk-enabled languages, is also written in
Tcl/Tk.
Donal: Right now, not very much. I’m
currently stuck in Java-land… :^/
What do you like most about Tcl?
Andreas: The power in simplicity.
Donal: It’s clean, both as a language and as an implementation.
Mark:
1. It is easily embeddable in other programs.
2. It is very robust.
3. Along with lisp, Tcl has the feature that a Tcl program can
be represented in a native Tcl data structure. It is very easy
to write fundamental language constructs such as "for" and
"while" using standard Tcl language features.
Jeff: The fact that it is so easy to use, yet so powerful.
What do you feel are the most important things
to improve in Tcl?
Jeff: I feel that more things around
Tcl need improvement, but in Tcl itself I would consider
improving core data structures.
Mark: There are no standard methods
for defining modules or objects. This has caused a lot of
slight incompatible wheel reinvention as every package author
implements his or her own module system.
Andreas: Uh. I consider the
language and the basic command set very mature and thus not very
much in need of changing. Yes, we can improve on things like
namespaces, ensembles [*],
the package command, regularize the list commands, etc., however
to me these are all minor things.
To me most of the work to be done is in the parts surrounding
the language. For example to get a package repository going. Not
a panacea either, but definitely something I believe we should
have.
Donal: There’s TIPs on this sort of
thing. ;^)
Objects, ensembles and expansion are probably high up the list.
At least as something for improving the Tcl language. The
library of commands can always do with more tweaking and nifty
features for people to use when necessary. As for Tk, MORE
WIDGETS!
What are you working on personally?
Jeff: As one of the few people
fortunate enough to work on Tcl full time, this changes a lot.
Currently it is reviving the Tcl/Tk web browser plugin [*], updating the
ActiveState GUI Builder, and adding more tools to the Tcl Dev
Kit. Did you really mean, like in my "off" time? Well, I don’t
see much of that, and when I do, it’s on related things like
TEA2, TclX, tktable, and other extensions not yet public.
Donal: In Tcl, several TIP
implementations. In real work, Resource Brokering on the Global
Grid.
Andreas: I interpret this as what I
am working on my free/spare time, and not doing for ActiveState.
Too many things are in front of my eyes.
Near term:
Convert the core functionality currently embodied in mpexpand [*]
(see tcllib/doctools) into a true package, so that doctools can
be used not only in and by tcllib, but in other applications as
well. For example as part of an embedded help system.
Write two TIPs, one about extended channel driver
initialization, the other about a Tcl Messaging Service. The
former to have a general solution to the bug encountered when
transferring sockets between threads. The latter to get a
generic framework which does for message/packet based
communication what the Channel system of Tcl does for
stream-based communication.
Finalize Img 1.3.
Farther future: Create TEA 2 build systems for TLS [*], and hopefully Expect
[*] too. Collect a script
library for Trf [*]. Refactor that
extension like Img, i.e several smaller packages. Get TrfCrypt
into SourceForge too, under the wings of Trf (tcltrf at SF).
See http://wiki.tcl.tk/TclVM. Play with the code to see how far we can get with
decompiling.
Play more with the Scripted Compiler stuff I have started on the Wiki.
What kinds of work have you done in the past (and maybe still maintain)?
Andreas: Memchan [*], Trf, a number
things for Tcllib [*]. For
ActiveState I am revamping the tools in the TclPro suite (now
Tcl Dev Kit).
Mark: Pretty much all of my current
coding energy is devoted to my day job.
Donal: API design. Programming.
Writing papers, presentations, posters, etc.
Are you paid to work on it (does your work
include working on Tcl)?
Donal: I’m not paid to work on Tcl.
Wish I was.
Jeff: 100% Tcl minus time spent
managing Tcl-related things at ActiveState.
Andreas: Yes. S.a. I am employed by
ActiveState to work on Tcl Tools.
Mark: I help to maintain our internal
version of tcl.
How much overlap is
there between what your employer has you do for Tcl, and what
you think Tcl needs?
Mark: Since most of my Tcl work has
been in support of work related tasks, nearly all of it. As I
mentioned above, a standard method for defining modules and
objects would be very nice.
Andreas: A package repository is
something which is sort of planned, but not actually being
worked on.
Donal: None at the moment. Maybe
I’ll be able to change this in the future.
Jeff: Since we sell services and
support for Tcl, I can end up working on things for companies
that isn’t fixing bugs or the like. Also tools development is
not core development, but we do get to focus on the tools we
think the community needs most.
What motivates you to work on the Tcl
core?
Donal: It’s fun. A great way to get
rid of stress.
Mark: At AsiaInfo, the management team
gave me a lot of support for using Tcl as a key component of
their software, even when there was not a lot of "buzz" around
the language. I wanted to make sure that Tcl would continue to
evolve in such a manner that it would still be useful to them.
Jeff: Love of the language. Oh, and
the pay helps too. ๐
What other
languages do you use and enjoy? What would you use if you
didn’t have Tcl?
Andreas: I use shell. I can’t say
that this is enjoyment. For low-level work I use C. With no Tcl
… I guess Python, and maybe I would try my hand at Haskell.
Mark: C++. Python is also pretty nice
once you get used to the indentation thing.
Donal: I also use C and Java quite a
bit, but neither’s particularly fun. They let me do what I need
to do (or want to do). But without Tcl, I suppose I’d still be
using Perl. Or maybe Python or Ruby or … I don’t know.
Jeff: I’d write Tcl. Honestly, I have
a strong background in languages, and Tcl turned me on early for
its unique mix of power and simplicity. I still write the
occasional bit of perl or python, but only when necessary.
With what languages do you most often combine
Tcl?
Jeff: C.
Andreas: See above. C and shell.
Mark: Mostly with C++. At NEC, I made
a pretty large system by combining Tcl/Tk GUI frontends with
Perl file processing backends. That was in 1991, so it was easy
to determine the breakdown — perl didn’t support GUIs, and Tcl
didn’t support files.
Donal: C. Only way to seriously
tinker with the core. ;^)
To what do you attribute the success of Tcl?
What are reasons why it hasn’t been even more successful than it
is?
Jeff: The ease of use factor is one of
the strongest success factors. Things that have held it back
from being more successful could be the lack of strong
multi-package distributions for so long. This includes the
resistance to object orientation, which was available in a good
package that could have been in a better distribution, but those
better distributions weren’t available.
Donal: Success: Clean engineering.
Good test suite (and test bed system.) And definitely Tk and
Expect. Problems: I’m not sure.
Mark: It’s been successful because
it’s easily embeddable in other programs, and because Tk GUIs
were so much easier to build than Motif GUIs.
I think Tcl lost mindshare when object oriented programming
became the norm. Most other scripting languages have native OO
support so Tcl fell off the radar for many people.
What is your philosophy behind the design of
a high level language? Does Tcl match what’s in your head?
What would you change?
Jeff: Tcl is fairly close. I would
perhaps include OO at the core level, but I don’t think the OO
available for Tcl is insufficient – it just isn’t in the core.
Donal: Common things should be easy,
and difficult things should be possible.
As for what I’d change… see the TIPs, both those written so
far and those to come. :^)
What is your favorite feature of Tcl? And from an
implementation point of view?
Donal: My current favorite is [interp
alias]; it lets you do some *very* cool things. Of the C
library part of Tcl, I remain thoroughly impressed by Tcl_Objs;
the name stinks and they could do so much more, but they are
still such an elegant solution.
Jeff: Hard to pick just one… I
think I have used just about every feature and nuance that Tcl
has to offer. I’ll pick function overloading. From the
implementation point of view, Tcl is so clean and well
implemented (it does have some API warts from growth over time),
I just constantly love all parts of it. One of the better ones
would be the stubs mechanism, which allows for binary
compatibility for extensions as the core changes.
Mark: It is very reliable and
bug-free.
What other open source projects are you
involved in?
Jeff: Lots. See my list at
SourceForge. [*]
Donal: My job is working on nominally
open-source software. But alas, I’ve not the time to really be
working on any open source software that anyone else has heard
of…
Explain what you think of how open source
communities work. What are their strengths and weaknesses. How
do you see Tcl fitting into the open source world at large?
Jeff: Open source communities run the
full gamut of characters. Tcl’s is a relatively solid and
stable community. Tcl hasn’t always fit in well with other
communities due to its success in the commercial area as well.
Notable extremists like RMS have called John a parasite for
having the audacity to make money on open source software.
Donal: I do open source because I
want to; it fits with my vaguely academic view of the world.
I’m none to fussed about everyone else’s motivations.
Emacs or Vi? What platforms do you use?
Jeff: I’m a long-term emacs addict.
Yes, I know elisp and have done my own modules, although not for
a while. I am starting to become addicted to Komodo (the
ActiveState IDE) [*], for
which I was responsible for several of the Tcl features. The
new version in development may see the end of emacs for me.
I am well-versed in Unix and Windows, and have had the
opportunity to get more than acquainted with OS X. My current
development environment is a Windows desktop running a rootless
X server with most of my dev work residing on a SuSE Linux
server that I manage myself.
Andreas: Emacs. I am able to use
vi, i.e. the base commands, but my day-to-day editor is most
undoubtedly emacs.
Donal: Emacs. And in case you hadn’t
heard, Emacs is the platform in itself. :^D (I’ve got access to
lots of different UNIXes, and I have IRIX and WinXP on my desk
right now.)
Mark: Vi. A large part of my career
has been spent telnetted into boxes I didn’t control, and Vi was
one of the few things we could count on being on every box. I
have to admit I was a bit befuddled when I heard my first
argument over which was the more intuitive way to exit a
program: ":q!" or "^X^C".
Have you ever met the other core people? How
important do you think it is to be able to work closely together
vs a distributed work environment?
Donal: Many of them. (I’d still like
to meet George Howlett and the itcl folks.) Being able to work
together (and especially see each others’ points of view) is
vital to the Tcl Core Team being able to function effectively.
Mark: Yes, at the various Tcl
conferences over the years.
Andreas: Yes. And quite
important. While communication by email, etc. is efficient, it
is only after meeting someone personally that one knows much
better how to interpret a message, because the person behind the
words is better known. While I am not well versed in
interpreting body language consciously I do believe that it does
influence me subconsciously, and email simply cannot transmit
this information.
Jeff: Yes, all of them. I believe the
core would benefit from the Tcl Core Team being able to meet in
person more often, but practical lives don’t permit that.
What do you think about open source, or
free software? What is its place in the world?
Donal: If commercial software can’t
beat free/open software, they don’t deserve to be making money
from it. But I’m perfectly happy for commercial entities to
leverage free/open software; if the infrastructure’s open,
there’s plenty of room for profit for everyone.
Jeff: It’s place is growing.
Mark: I think it will continue to
grow, especially for "infrastructure" types of software.
Do you "manage" other people as part of your
core team duties? What are your thoughts on managing people who
want to contribute?
Donal: I don’t manage anyone, though
I do occasionally chase people up with pending contributions
(e.g. where their TIP is accepted but they’ve not submitted an
implementation of sufficient quality.) But I’m usually too busy
for that…
Jeff: I currently manage Andreas
directly, and work with most others as I have to coordinate
release times for usable core releases. Managing people who
want to contribute isn’t hard – you just lay out the ground
rules and watch them for a bit to see that they follow them
(that related mostly to coding style for us). The hard part is
following up with those who have contributed something, but then
virtually disappear when key problems are found in the
contributions.
What successes has tclcore had?
Donal: In my humble opinion, TIPs are
a *great* success.
Jeff: Well, 8.4 made it out. TIPs are
nice. This is a very open question though.
Mark: The TIP system (http://www.tcl.tk/cgi-bin/tct/tip/)
has worked very well.
Who are your inspirations? Who or what inspired you when
growing as a programmer?
Mark: My first inspiration was my
father, who was also a programmer. In the 60s and 70s he worked
on a global information distribution system that could transmit
weather data to every U.S. military installation in the world in
under two minutes, with a downtime of less than five minutes per
year. This on a system with about the same computing power as a
Gameboy.
I was also inspired by Brian Kernighan’s writings. He is still
the model of exposition and clear thought I turn to when I try
to explain things to other people. It was a high point in my
career to work with him on our Tcl book.
Jeff: John Ousterhout has actually
been a big inspiration for me. He answered my questions (and
even promptly!) when I start using Tcl, which left a great
impression on me. He was also a good mentor.
Donal: Alas, I’m not someone who has
heroes. Though I’ll admit to wanting the respect of other Tcl
programmers…
What is the coolest thing you’ve seen Tcl used
for?
Mark: Two early Tcl projects that
totally blew me away were the Shell Auger Platform (in which Tcl
programs controlled all the wellhead operations for 32
drillheads on a floating oil well thing floating in the Gulf of
Mexico), and the use of Tcl in the Mars Explorer project (the
one that didn’t crash!).
Donal: Now that’s a hard question.
There were many cool things being done with Tcl at the last Tcl
conference (and there’s much impressive activity elsewhere too)
but the use of Tcl for the electronic version of the DWB (German
dictionary) is impressive because it is work by mostly
non-programmers and is highly exposed to the public too. And of
course the use of Tcl as an OS on a piece of hardware is
fantastically funky too. And then there’s Tclkit/Starkits… [*]
How can I make up my mind with so much radically-different cool
stuff about?
Jeff: Tux Racer, just because it’s
darn fun.
What has surprised you most about working with tclcore?
Donal: I really don’t know; it’s been
something of a learning experience.
Jeff: Nothing surprises me … ๐
What is your Vision for the future?
Mark: I think Tcl will continue to be
a useful embedded language.
My philosophy is to find a language designed and implemented by
super smart guys and use it.
Donal: Too busy to have visions right
now. :^/ However, I would like to get to a state where OO in
Tcl is a trivial derivation of existing core facilities. I
think we’re nearly there, but not quite.
Jeff: Now, I may live in BC, but that
doesn’t mean I have visions …
For the near term, I plan to work on projects surrounding Tcl,
and I have so much on my plate that the visions are all one on
top of the other just confusing the picture.
I would like to take the time, once again, to
publically thank Andreas, Donal, Jeff and Mark for participating
in this interview!
As this interview was in the final stages of being written up,
Tcl and Tk 8.4.2 were released: http://www.tcl.tk/software/tcltk/8.4.html
!
About the Interviewer:
David Welton lives
and works in the California Bay Area as a consultant with Linux,
Apache, Tcl, Python and other Free Software tools. He is a
member of the Apache Software Foundation, and a Debian package
maintainer.
About the Interviewees:
Donal K. Fellows
Donal is currently working on resource discovery and brokering on
the global Grid. Prior to joining John Brooke’s group at
Manchester Computing in 2002, Donal worked on various projects at
the Department of Computer Science in the University of
Manchester. Much of his work there was on developing software for
doing design and analysis of asynchronous hardware (including the
design and development of a network-enabled analysis engine, and a
major part of a large scale parallel model checker) though, as his
interests are in the production of elegant interfaces to computing
systems, he also worked on producing GUIs for software waveform
viewers and network-enabled examination-taking systems. Donal is
also a member of the Tcl Core Team, a core developer of Tcl/Tk and
editor of the TIP document series (the standardization process for
the Tcl language).
Home Page: http://www.cs.man.ac.uk/~fellowsd/
Mark Harrison
Mark Harrison works on distributed computing at Pixar Animation
Studios. Prior to this he was Chief Software Architect at AsiaInfo
Holdings, where he designed mission-critical software for the
China Internet Backbone. He has been programming in Tcl since 1991
and is co-author of “Effective Tcl/Tk Programming” and “Tcl/Tk
Tools”.
Home Page: http://www.markharrison.net/
Jeff Hobbs
Jeff is the Core Release Manager for the Tcl language. He has
maintained the TK Usage FAQ since 1996 and is a program committee
member for the USENIX Tcl/Tk Conference. Jeff comes to ActiveState
from Scriptics, where he was a Tcl Ambassador, responsible for
communications liaison between Scriptics and the Tcl community and
managing development of the Tcl core. Previously Jeff was also a
software engineer at both Siemens AG and CADIX International. At
ActiveState, Jeff is the tech lead for Tcl technologies.
Jeff is a member of the Association for Computing Machinery, the
Internet Society and USENIX. He holds a B.A. in Computer and
Information Sciences and an M.S. in Computer Science from the
University of Oregon.
Andreas Kupries
Andreas is a member of the Tcl Core Team, and has been employed by
ActiveState since early 2001 to work on Tcl, development tools,
and the standard Tcl library, tcllib. He has been involved with
Tcl development since the Tcl 7 days, and is credited with several
innovative Tcl extensions, such as Trf, Memchan, and a number of
tcllib packages. Andreas has a degree in Computer Science from
the Northrhine Westphalia Technical University at Aachen.
Home Page: http://www.oche.de/~akupries/welcome.html
About TCL/TK:
More information about Tcl and the Tk toolkit can be found at
http://www.tcl.tk/ . Other useful Tcl resources include the
Tcl’ers Wiki, at http://wiki.tcl.tk/ and the comp.lang.tcl
newsgroup, which is a very friendly place to ask questions and get
answers from Tcl experts, including the core developers.
At the moment Iยดm 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 Iยดm 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 donยดt 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 Iยดm happy about every speedup-tip I can get. Thanks.
Greetings from Anton and long live and prosper TCL.
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.
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!
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…
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.
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
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.
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.
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…
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
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.
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.
fun stuff!
Fortran + tcl/tk is an excellent combination for portability.
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).
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.