Dave's Unofficial Report from the Tcl/Tk Workshop
July 18, 1997
Well, here's the unofficial scoop on the 1997 Tcl/Tk workshop. Most
of these details are taken from my personal notes (which I think are
mostly legible). Approximately 200 people attended the workshop.
I hope these notes might be of interest to users who couldn't attend
the workshop and might be interested in where Tcl/Tk development is
headed in the future.
John Ousterhout presented the 'state of the language' talk. A few
highlights.
A final release is expected sometime in August. Major new improvements
to Tcl/Tk were presented. The most notable of these :
- The byte-code compiler which gives a 2-20x speedup on many
application.
- Tcl objects
- Binary I/O and data support.
- Namespaces
- HTTP module
- Native look and feel
- Application embedding (ability to embed Tk in other applications--
particularly browsers).
>From the standpoint of SWIG, the most interesting aspects is the use of
Tcl Objects. In the Tcl 8.0 release, only a limited subset of Tcl/Tk
will use Objects internally. In particular, most of Tk will still
continue to use strings, but will be converted over to objects for the
8.1 release.
John surveyed the audience about Tcl 8.0. Approximetly 30% of the
audience had tried Tcl 8.0, but only about a dozen people reported
using Tcl 8.0 as the primary platform. Most people are using Tcl
7.6/Tk4.2. When asking about reasons for 'not upgrading' to Tcl 8.0,
the following reasons were given (in decreasing order of importance)
Missing extensions (35)
Incompatibilities (20)
Product life cycle (20)
Other (10)
No Documentation (5)
No need (2)
Version 2.0 of the plugin is planned to finalized in Sep-Oct of this
year. The final version will be based on Tcl 8.0.
A final version of 1.1 is expected in July 1997. The success of
SpecTcl was reported as "disappointing" with the complaints of
taking too long to complete, not having enough functionality, and
inability to work with existing applications. The Tcl team will be
scaling back efforts after the 1.1 release. When asked how many
people used it, only about 10 people in the audience raised their hands.
A brief discussion of a web-server written entirely in Tcl was given.
This web-server has been serving all of sunscript.sun.com for the last
two months.
FTP downloads of Tcl are up 100-400% this year (5000-8000 per week).
The mix of downloads are 50% Unix, 40% Windows, and 10% Macintosh.
John estimates the number of Tcl users at around 500,000 (although
this is only a rough guess).
These were features people had requested at last years workshop, but
which have not been implemented or are supported yet :
- Megawidgets
- Revisions to image handling (ie. new formats).
- Threads.
- Debugger
- Drag & Drop.
- OLE/Active-X
- Text-widget improvements
John provided some interesting insight into SunScript. Apparently,
the original goal was to build a business unit around Tcl/Tk. This
was primarily motivated by the fact that Tcl/Tk didn't fit in well
with other units at Sun (SunSoft or JavaSoft). By having an
independent business unit, it was hoped that they could carve out a
niche for themselves.
Unfortunately, the SunScript unit was largely supported by Eric
Schmidt who has now left Sun and gone to Novell. John reports that
management support for Tcl/Tk is thin--mostly focused on Java related
issues. In recent months, the Sunscript group has concluded that
there is not enough support for a business group. As a result, the
group is discontinuing all commercial product development and support
activities to focus on the continued development of Tcl/Tk and related
tools. While this may sound bleak, John reports that the group is
strong (14 people) and has funding to work on new Tcl/Tk directions
(particularly Tcl integration with Java). For Tcl users, John reports
that all software will be made freely available in source form. This
includes the Netscape Plugin, SpecTcl, the WebServer, Java tools, and
any new products developed by the group. Apparently they're getting
rid of licensing agreements on the "Tcl Logo" as well.
A huge effort is underway to integrate Tcl and Java. The basic
consensus at the workshop was that Javascript is terrible and Tcl
would be much better. The Tcl/Java integration appears to have two
thrusts :
This is providing access to Java through the existing Tcl/Tk
implementation (in C). Mainly this would be hooks to JDK 1.1
and using reflection to access Java classes, invoke methods,
and perform other operations from Tcl scripts. There would
also be a new Java class to invoke scripts and define new Tcl
commands. Basically, this is the idea of 'embedding' the
Java virtual machine in a Tcl application.
This is the JACL project which is a reimplementation of Tcl
entirely in Java. This would allow Tcl to be used in a
100% pure java environment such as web-browsers and Javastations.
New Tcl commands would be implemented in Java just as they
are implemented in C now. It was also mentioned that the
Java version of Tcl would be able to interact with the C
version in some manner although they weren't too clear
on that---it may involve something with Tcl 8.0 objects.
John said that their eventual goal is to make Tcl capable of
gluing "everything." In passing he mentioned that they would like
to be able to support things like JavaBeans and OLE/Active-X
as well. I wasn't quite sure what to make of all of this to be
honest.
The goal is to release a 8.1 release in January of 1998. Here
are planned improvements :
1. Finish conversion to compiler.
2. Convert Tk to use Tcl 8.0 objects.
3. Internationalization. Tcl is switching to UTF8 Unicode
everywhere internally.
4. Modular parser for Tcl scripts. Apparently there will
be some sort of hook for accessing the Tcl parser
and getting compiled objects.
As a tradition, John asks the audience what changes they would like
to see. Here's how it broke down this year (in decreasing order of
popularity ):
1. Additional widgets (combo boxes, notebook tabs, etc...)
2. Thread support.
3. Splitting of the Tcl core into packages.
4. Better printing support
5. Overhaul of Tcl's image handling.
6. Better support for extension management
7. Drag and drop.
8. Rewrite of regular expressions (internationalization and
binary support). Also : "we want Perl features"
9. Canvas improvements
About 40 people attended a BOF to discuss Tcl's use with the OMG CORBA
standard. Currently, OMG has a call for proposals for a CORBA
scripting language standard (deadline : Nov 10, 1997). The Tcl team
is interested in proposing Tcl for this purpose, but admits that they
do not have much experience with CORBA. However, they see this as a
possible area in which Tcl can gain a foothold and make in-roads into
'mainstream' software development. Explicit references were made to
Javascript and Visual Basic as possible contenders in this arena.
A few interesting comments were made---many CORBA vendors already use
Tcl in their support tools. Some feel this might give Tcl a leg-up in
making a proposal. Others seem to feel that the Tcl team should
support CORBA regardless of what scripting language standard is
chosen. At this point, the Sun team is primarily trying to get an
idea if making a proposal is "worth the effort" and should be pursued
at all. Anyone interested in this effort should contact Brent Welch.
A common theme at this years conference was the difficulty of managing
Tcl extensions, namespaces, package installation, and other issues.
Some concerns included :
- There is no organized way of managing extensions.
- Keeping track of different versions of Tcl and its extensions
is difficult.
- The Tcl/Tk contributed archives are woefully out of date
and disorganized.
- How should people use the new Tcl 8.0 namespaces?
- Documentation on using packages is poor (if not almost
nonexistent).
- A desire to make the Tcl core smaller and rely more
upon dynamic loading.
A BOF was held to discuss these issues. While no total solution was
hacked out, a number of interesting points were made.
- An organized archival mechanism is needed for keeping
track of extensions. CPAN was singled out as a
model of how this might be accomplished.
- Configuration support should be bundled with the Tcl
distribution. In particular, a script that could be used
for configuring, building, and installing extensions in
a uniform manner should be included. Perl's 'MakeMaker'
module was singled out as an example of this kind of thing--
again keeping with the CPAN theme.
- There should be a way to uninstall modules.
- It should be possible to distribute binary-only
extensions.
- The Tcl directory structure should be standardized in a
way that is favorable to extension writers.
- A documentation standard should be adopted (something like
Perl's POD format). HTML was initially chosen by
the group as a good contender for this (some suggested
using SGML however).
While it is unclear what direction this will take, there seems to be
a clear consensus in the Tcl community that something needs to be done
to make extension management easier than it is now.
This was an interesting discussion concerning Tcl's future. In
particular, how does one promote Tcl in an era of Java, fierce
competition (Perl, Python, Javascript, Visual Basic), excessive hype,
and clueless managers? Some see Tcl as having the potential to
be "mainstream" like C,C++ and Java. Others think Tcl will
remain a 'niche' language with a strong following, but never really
gaining wide acceptance (ie. "it's just a hacker language").
The discussion focused on ways to promote Tcl--particularly to managers
(most felt that Tcl already enjoyed a certain level of success among
engineers and developers).
Some ideas :
- Write Tcl articles for Dr. Dobbs, Wired, and various
trade-rags--increased visibility for Tcl.
- Integration with Java, ActiveX, CORBA, etc...
- Try to influence consulting firms to support Tcl.
- Focus on Windows related issues.
- Try to boot-strap off other areas. For example, many felt that
Perl had done quite well for itself by being associated
with CGI programming.
19 technical papers were presented. Of possible interest to SWIG
users was a paper on ImageTcl which includes some automated GUI-based
tools for building Tcl extensions (http://devlab.dartmouth.edu/imagetcl).
Don Libes also described a namespace registry database project at NIST.
Basically, the idea here is to consolidate information about symbols,
TCP ports, and other resources in various software packages. When
writing new software, developers can check the database to see if a
symbol has been used and if so, what it has been used for. Check it
out at http://pitch.nist.gov/nics.