Goodbye TCL

32 views
Skip to first unread message

Ed Suominen

unread,
Apr 15, 2004, 3:38:31 AM4/15/04
to
I have debated about the wisdom of posting this message, knowing that a lot
of people whom I respect may not like what I have to say. On the other
hand, I wish that the person who told me "TCL is dead, try Python" two
weeks ago had somehow been able to get that message through to me much
earlier. As a longtime member of comp.lang.tcl who reluctantly considered
that advice but wound up finding its results incredibly illuminating and
productive, it seems only fair to pass it on.

I am dictating this posting into a Linux application window using speech
recognition software that is running under Windows in a VMware virtual
machine. Every time I dictate a bit of text into a Tk text widget on the
Windows side, that text is transmitted via a (virtual) TCP connection to a
daemon on the Linux side that generates fake keystrokes via X events. I
wrote the software that accomplishes this [1] over the course of the last
week or so, one week after beginning my study of object-oriented and
test-driven programming in general, more specifically of Python, and even
more specifically of the Twisted network application framework for Python
[2]. There was a lot of reading and head-scratching involved, but it was a
fascinating experience.

I have had extensive experience doing network application development with
TCL, most visibly with Privaria [3]. That experience involved a great deal
of low-level programming using the socket built-in function and its
companions. In both cases, I searched far and wide for suitable TCL
packages to do what I wanted but wound up just writing the stuff at a low
level because the packages seemed inactive, demonstrated buggy behavior, or
just didn't seem to do what I wanted. I spent many interesting but
frustrating hours sniffing packets and working out the details of TCP-level
communications -- buffer flushing, newline inconsistencies, blocking vs.
non-blocking reads, etc.

With this latest project, I was determined to see if Python was as widely
supported and powerful as its advocates claimed. I was not disappointed.
After quite a few hours of intense study (my first real exposure to
object-oriented programming, see above) I found the language itself
incredibly powerful, without the need for any external packages (which do
you choose, itcl, snit, or what?) to tack OOP capability onto a language
that is as procedural as the name of its function construct ("proc")
implies.

Namespaces in Python just happen; they don't need definition. If you
"import" a "module," all of its "attributes," which are classes, methods
(few), and variables (fewer) live in that module's name space unless you
indicate otherwise (which you can easily do). The number of globals
floating around is truly minimal, because defining classes that instantiate
objects making things happen in methods of objects is the default in the
way the language and its documentation (current and extensive) encourage
you to program.

But most significantly, I found, is that trying to reuse code that others
have written is no longer a frustrating exercise in skipping past "Error
404: Page Not Found" messages, pages that are found but haven't been
updated in three years and feature code that only links to tclsh8.1, and
packages that are TCL-only or manage to link but seem dangerously inactive,
buggy, and unused. For my first Python application (written just before the
one I'm using to dictate this) I needed to generate highly structured,
highly specialized HTML from various bits of data in text files here and
there. I found the HTML generation package in Python's standard library
(yes, there is one, is extensive, and it comes with the interpreter) to be
intuitive and powerful, in contrast to the tcllib tool that I wound up
having to extend with my own hacks on too many occasions. (There's a more
powerful TCL tool, but it doesn't seem to be active or widely used...)

For this dictation application, I used the twisted application framework,
which turns Python into an incredibly powerful networking and multitasking
machine. It was very difficult to learn because its documentation does not
keep up with its depth, and I wound up having to print and pore over a lot
of source files to understand how it works. But once I overcame that
learning curve I found that I could do amazing things with a few lines of
highly modular code. I never even got close to the TCP packets. I just
invoked a method of the "reactor" object that runs the whole show to listen
for TCP connections on one side and make connections on the other and
implemented various methods to send the data I needed. When new text
materializes in the text widget, a periodically-polled method senses it and
sends it to the other side. The other side tells its keystroke-typing
object about the new text and lets that object take care of calling its own
objects. All those objects' classes and method were unit tested
concurrently with their development, based on a testing framework someone
else wrote and is supporting. The whole things takes up about 800 lines of
code, including extensive "docstrings" (essentially
documentation-generating comments).

I'm not writing all of this to rub it in, to thumb my noses at those left
behind. But I think at some point people (like me, two weeks ago) should
question why their particular programming language, operating system kernel
(see, e.g., the Hurd), editor, etc. does not seem to be receiving as much
attention as they would like. Sure, such people can tout the benefits of
their particular choice and shake their heads in wonder at why others
haven't discovered it or have left it behind, but they might well take an
honest look at the question "why"? Perhaps there is a reason why Python has
several dozen books with recent publication dates and nothing new seems to
have been written about TCL for years. Perhaps there is a reason why the
comp.lang.python newsgroup has several times the volume of this one and the
typical Linux distribution has many times more Python-based applications
than TCL-based ones. The reason may be that many people are finding one
choice superior to the other.

Finally, let me add that some of my observations may be inaccurate. Any such
inaccuracies are unintentional and open to correction here. Hopefully this
lengthy message will be received in the constructive spirit in which it was
written.

Ed Suominen

[1] Very much in pre-release state, but available at
http://www.ossri.org/projects.php
[2] http://www.twistedmatrix.com/
[3] http://www.privaria.org

mjk...@cs.helsinki.fi

unread,
Apr 15, 2004, 4:47:54 AM4/15/04
to
In comp.lang.tcl Ed Suominen <ed...@spam-eepatents.com> wrote:

[Lot of interesting reading snipped]

> (see, e.g., the Hurd), editor, etc. does not seem to be receiving as much
> attention as they would like. Sure, such people can tout the benefits of
> their particular choice and shake their heads in wonder at why others
> haven't discovered it or have left it behind, but they might well take an
> honest look at the question "why"? Perhaps there is a reason why Python has
> several dozen books with recent publication dates and nothing new seems to
> have been written about TCL for years. Perhaps there is a reason why the
> comp.lang.python newsgroup has several times the volume of this one and the
> typical Linux distribution has many times more Python-based applications
> than TCL-based ones. The reason may be that many people are finding one
> choice superior to the other.

I thought a lot about your post and tried to decide, if it is a troll
or not. But I think that the post is just about enthusiasm of the
discovery of a new language.

OK, first I have to remind you, that "if the only tool is a hammer,
all problems start to look like a nail" or something... There is a
place for Tcl and there is a place for Python. Both languages are more
or less general-purpose programming languages and can be utilized for
lot of different tasks.

I'm using Tcl/Tk for different kinds of tasks. The reason for using
Tcl/Tk over other languages is the simplicity of the language and easy
extensibility. Tcl also works as a brilliant glue-language between
different kinds of applications. But the power of Tcl is in its
extremely simple specification and structure.

About the publication industry and newsgroup traffic. If it seems that
some programming language isn't grabbing the attention it deserves, or
there doesn't seem to be as much of development around the language
(or language specification), it doesn't necessarily mean that the
language is dying. It just tells that the language is mature enough to
be self-confident and suitable for majority of tasks it was meant to
be used. A good example of this kind of language is (in my opinion)
Scheme.

I'm happy for you that you enjoy the features of Python. But don't
forget that if there is a tool which fits perfectly for you, that
doesn't automatically mean that the other similar languages become
obsolete for everybody else.


Sorry my bad English.


--
Sincerely,
Matti J. Kärki

Salvatore Sanfilippo

unread,
Apr 15, 2004, 5:18:35 AM4/15/04
to
On Thu, 15 Apr 2004 00:38:31 -0700, Ed Suominen wrote:

> honest look at the question "why"? Perhaps there is a reason why Python has
> several dozen books with recent publication dates and nothing new seems to
> have been written about TCL for years. Perhaps there is a reason why the
> comp.lang.python newsgroup has several times the volume of this one and the
> typical Linux distribution has many times more Python-based applications
> than TCL-based ones. The reason may be that many people are finding one
> choice superior to the other.

Hello Ed,

first, thank you for your email, I appreciated it because to just leave is
simpler, instead your email can help the other people to reflect on Tcl's
problems.

My feeling is that Tcl's main idea (but possibly not all the extensions to
the core languages done in "recent" times like namespaces design to
mention one) is more powerful than Python, because I like more something with
simple semantic that can be extended a lot in itself, instead of something
that is specifically designed to solve a given set of problems in a smart
way (the Python's design seems like this to me). At the same time, I
experimented problems with Tcl, in nature similar to your problems.

So my question is "why?", why something that is basically better for me to
program in, is not always effective when I need to face real-world problems?

This is what I think:

1) In Tcl, extensions are not considered part of the language. We are here
in 2004 without an UDP extension shipped in the core. This politic over
the time resulted in abandoned extensions, and people redoing the same
work over and over instead to improve in some "official" code.
Instead I think that for every "big task", for example UDP, SSL, Image
manipulations, OOP, and so on, Tcl should have a standard library that is part
of Tcl in every respect. Like what happens with Tk.

2) Pure-Tcl extensions that are very important for the language are inside
Tcllib, that is not considered part of the language itself. This IMHO
means to trash most of the advantage that an extensible language brings.
There are parts of the Tcllib that are IMHO very good code, with good
documentation, and useful in many cases. This should be organized to be
shipped with the core, and to be part of any Tcl install. This is what
happens with Python for example.

3) I generally saw a lot of resistance or lacks of interest for 1) and 2) in Tcl,
but at the same time TIPs that possibly alter the semantic of the
language in some case can pass without too problems.
It seems more reasonable to avoid to change the language itself,
and instead try to bind it with more interesting code. That's also the
original idea of Tcl.

4) There is a "it works for me" syndrome around. This will help people
that are using it for their particular stuff to get the work done and
go home with less problems, and it's a good point. But will not help
Tcl to survive.

5) There is, from what I can see, little focus on the "what is happening
to Tcl" problem. I think that interested parties (in Tcl of course) should
meet together and discuss what is possible to do to improve the language
in a "it works for the rest of the world also" way, and create a new image
to present the language, more in line with the fact that Tcl is opensource
and not proprietary. It's crucial to present the language in a way that
attract very young programmers: they are free of paywork, full of new
ideas, in other words who can inject massive amount of interesting code
and fresh ideas into Tcl.

If there is little interest in the rest of the world, probably it's better
to say it explicitly in the home page. Maybe someone interested in Tcl
can get the message and start to work to a fork. But I hope it's not the
case.

--
Salvatore Sanfilippo <antirez at invece dot org>
"Minimalism, simplicity and consistency are better guides (...) We suspect
that many of today's object-oriented languages could profit by dropping
features" -- Randall B. Smith and David Ungar, Programming as an Experience.

David Gravereaux

unread,
Apr 15, 2004, 6:13:30 AM4/15/04
to
Salvatore Sanfilippo <ant...@nospam.invece.org> wrote:

>1) In Tcl, extensions are not considered part of the language. We are here
>in 2004 without an UDP extension shipped in the core. This politic over
>the time resulted in abandoned extensions, and people redoing the same
>work over and over instead to improve in some "official" code.
>Instead I think that for every "big task", for example UDP, SSL, Image
>manipulations, OOP, and so on, Tcl should have a standard library that is part
>of Tcl in every respect.

<soap_box>

Having worked deeply in the network code recently, I feel the need address
your point. All I/O in Tcl (ie. Tcl_CreateChannel) is for streaming data
(buffered or not, uni or bidirectional). Any hacks done in a channel
driver itself to force it into a message-oriented behavior (UDP) is doomed
to be re-written over and over again. In this I agree strongly, but for a
different reason. Any UDP channel driver JUST CAN'T be added to the core
due to the forced nature it operates in. Whether it adds a boundary
character or forces eof on each read or whatever, it is unacceptable to
embrace it into the core.

Though, unbuffered with eof after each read is not a bad comprise,
buffering is the job of the generic layer not at the driver layer. The
only sticky point left is underflow for when a read is sized too small for
the chunk it is trying to read (ie. -buffersize < MTU of the link layer)

Where the effort should go, is into the generic I/O layer to enable
message-oriented channel types. Only from this core change can UDP be
embraced.

Andreas Kupries wrote a paper on his thoughts for how a message-oriented
generic layer should be designed. I don't have a link to it handy. It is
very detailed.

If you want UDP, DO NOT make yet another channel driver for it. Go add
the highly desired message-oriented mode to the generic I/O layer instead.
Then make a new channel driver for that new operational mode.

</soap_box>

Will IOCPSOCK (http://sf.net/projects/iocpsock) get UPD?... nope. not
for how the generic layer works currently. hacks are for the youths, I'm
getting too old and like well structured architecture better.
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]

Salvatore Sanfilippo

unread,
Apr 15, 2004, 6:47:14 AM4/15/04
to
On Thu, 15 Apr 2004 03:13:30 -0700, David Gravereaux wrote:

> different reason. Any UDP channel driver JUST CAN'T be added to the core
> due to the forced nature it operates in. Whether it adds a boundary
> character or forces eof on each read or whatever, it is unacceptable to
> embrace it into the core.

[snip]

> If you want UDP, DO NOT make yet another channel driver for it. Go add
> the highly desired message-oriented mode to the generic I/O layer instead.
> Then make a new channel driver for that new operational mode.

I fully agree. If this paper is still available, please point me to it.

Thanks,
Ciao,
Salvatore

lvi...@yahoo.com

unread,
Apr 15, 2004, 8:59:26 AM4/15/04
to

According to Salvatore Sanfilippo <ant...@nospam.invece.org>:
:1) In Tcl, extensions are not considered part of the language. We are here

:in 2004 without an UDP extension shipped in the core. This politic over
:the time resulted in abandoned extensions, and people redoing the same
:work over and over instead to improve in some "official" code.
:Instead I think that for every "big task", for example UDP, SSL, Image
:manipulations, OOP, and so on, Tcl should have a standard library that is part
:of Tcl in every respect. Like what happens with Tk.

I wonder - for years, people have commented on the fact that Perl and Python
come with so much more functionality than Tcl. Finally, the Tcl core team
create a process by which new functionality could be added. There is
still a lot of resistence to adding new functionality. But if people
want to see functionality added, that can be added in a cross platform
and legally safe manner, they should tighten their belts and get to work.

--
<URL: http://wiki.tcl.tk/ > In God we trust.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >

Kevin Kenny

unread,
Apr 15, 2004, 9:27:04 AM4/15/04
to
Salvatore Sanfilippo wrote:
> 1) In Tcl, extensions are not considered part of the language.
>
> 2) Pure-Tcl extensions that are very important for the language
> are inside Tcllib, that is not considered part of the language
> itself.
>
> 3) I generally saw a lot of resistance or lacks of interest for
> 1) and 2) in Tcl

These are points that I see very widely expressed, and ones that,
frankly, I have trouble understanding.

The Tcl core is similar to the Linux kernel in that the TCT, like
the kernel team, makes no integrated distributions of its own.
Instead, releases are tagged and branched in the SourceForge CVS
repository, and distributors are free to go on and pick them
up and make full distributions out of them.

By far the most popular of these full distributions is ActiveTcl.
It has a number of popular extensions and all of Tcllib
preinstalled. (Admittedly, it hasn't got any of the UDP
extensions built-in. Perhaps the Activators can do something
there...) But even with ActiveTcl fairly ubiquitous, there is
a set of Tcl'ers that simply won't use "extensions." By
contrast, most Perlites and Pythoneers aren't even aware whether
something from the archives is in the "core" or not. Strangely
enough, the objection to using "extensions" seems to come
most strongly from those that use only the packaged distributions
that have them. Those that build from source and therefore
might not have the common extensions also seem not to have
a problem with getting the extensions and building them.

In short, where did you get the distribution that is missing
the pieces you complain about?

There appears to be a fairly widespread misconception that
extensions are second-class code. There are a number of
reasons that a piece of code may be an extension rather than
part of the Core, most of which have nothing to do with
the quality of the code or the availability of support.

* The extension is released under a different license.

The Tcl Core license has been agreed to by a great many
contributors over the years. Even if we wished to license
the core differently, we would have little hope of tracking
down all the rightsholders and securing permission. Hence,
code attached any license like the GPL that demands that
all code linked to it bear the same license simply cannot
go into the core. (Example: mpexpr, Img)

* The extension is relevant only to a single product such
as a third-party database.

There are a lot of extensions that serve simply as "glue"
to attach Tcl to third-party products. These glue modules
would simply clutter the core for those that don't use them.
An exception is made for a very few Windows-specific extensions
without which it's insanely difficult to deal with Windows at
all.

* The extension maintainers have never proposed it for
inclusion.

The TCT doesn't simply grab other people's code and shovel
it in. Since everything "in the core" is under the TIP
process, it's understandable that the maintainers of an
extension may want a different process for deciding on
its API and may want to maintain a different release cycle.
Moreover, we TCT'ers don't *want* to have to vote on
API changes to all the extensions!

* There's nobody to do the work.

There are a lot more feature requests than implementors.
Sorry.

I'm willing to listen here. I really have had trouble understanding,
though, just why it's a problem that "the extensions aren't in the
core." It was a serious problem until 7.3; 7.4 fixed it, and 8.1
did an even better job at it. Is this another case where the world
is laboring under the belief that Tcl still has a problem that we
fixed ten years ago?

--
73 de ke9tv/2, Kevin

Donal K. Fellows

unread,
Apr 15, 2004, 9:32:14 AM4/15/04
to
Salvatore Sanfilippo wrote:
> 1) In Tcl, extensions are not considered part of the language. We are
> here in 2004 without an UDP extension shipped in the core. This
> politic over the time resulted in abandoned extensions, and people
> redoing the same work over and over instead to improve in some
> "official" code.

But extensions are no big deal.

> Instead I think that for every "big task", for example UDP, SSL,
> Image manipulations, OOP, and so on, Tcl should have a standard
> library that is part of Tcl in every respect. Like what happens with
> Tk.

UDP could go in the core if we could get a good abstraction for it (but
it needs something like a messaging abstraction instead of a the core's
current streaming abstraction. UDP doesn't fit with channels without a
gross kludge.)

SSL is easily done with the addition of the Tls extension. It's not
part of the core because it is fairly big and many core users don't need
it. If you're doing sophisticated networking though, Tls is pretty much
one of the first things to add. IME it's really easy to use (compared
with other languages where SSL support is "built in"...)

Improving Tk's image manipulation code is an ongoing project of mine. I
only wish I could work on it full time. OTOH, the code to handle the
myriad image formats that exist is probably best kept out of the core
because it is not at all easy to build.

Oh, and many people do not agree with each other over what is the best
way to do OOP in Tcl. :^)

> 2) Pure-Tcl extensions that are very important for the language are
> inside Tcllib, that is not considered part of the language itself.
> This IMHO means to trash most of the advantage that an extensible
> language brings. There are parts of the Tcllib that are IMHO very
> good code, with good documentation, and useful in many cases. This
> should be organized to be shipped with the core, and to be part of
> any Tcl install. This is what happens with Python for example.

If tcllib was part of the core, everyone would be grumbling that it is
hard to get code into it. :^)

> 3) I generally saw a lot of resistance or lacks of interest for 1)
> and 2) in Tcl, but at the same time TIPs that possibly alter the
> semantic of the language in some case can pass without too problems.
> It seems more reasonable to avoid to change the language itself, and
> instead try to bind it with more interesting code. That's also the
> original idea of Tcl.

Well, surely things that can't be done without core changes should
involve changes to the core if they are going to be supported? IMHO
you're too resistant to some of the things that you label "altering the
semantics of the language". But then you already know that I really
disagree with you on this point. :^)

If something can be done without core modifications, why put it in the
core? (The answer, often, is either "performance" or "it's very useful
to a very large fraction of Tcl users." It's a judgement call.)

> 4) There is a "it works for me" syndrome around. This will help
> people that are using it for their particular stuff to get the work
> done and go home with less problems, and it's a good point. But will
> not help Tcl to survive.

Care to expand on this point? I don't yet understand what you're saying
here to enough detail to be able to either agree or disagree.

> 5) There is, from what I can see, little focus on the "what is
> happening to Tcl" problem. I think that interested parties (in Tcl of
> course) should meet together and discuss what is possible to do to
> improve the language in a "it works for the rest of the world also"
> way, and create a new image to present the language, more in line
> with the fact that Tcl is opensource and not proprietary. It's
> crucial to present the language in a way that attract very young
> programmers: they are free of paywork, full of new ideas, in other
> words who can inject massive amount of interesting code and fresh
> ideas into Tcl.

Physical meetings are quite difficult to arrange. We're geographically
distributed and many of us are not funded in such a way as to allow
jetting off to some meeting at the drop of a hat.

Virtual meetings work better; the Tcler's Chat is often used like this.

IMHO the main problem is that too many of us don't have the time to work
on Tcl anything like as much as we want to. You mention that you want
to attract young programmers; that's both a good idea (they do have the
free time) and a bad idea (they don't have the experience - you *really*
wouldn't have wanted my programming in the core until not that much
before I started contributing to the core anyway. :^D) By the time they
have got the experience, they don't have much free time.

> If there is little interest in the rest of the world, probably it's
> better to say it explicitly in the home page. Maybe someone
> interested in Tcl can get the message and start to work to a fork.
> But I hope it's not the case.

Well, I don't think there's a need to fork the language. But then I
would say that, wouldn't I? :^)

Donal.

tony summerfelt

unread,
Apr 15, 2004, 10:06:31 AM4/15/04
to
On Thu, 15 Apr 2004 at 12:59 GMT, lvi...@yahoo.com wrote:

> I wonder - for years, people have commented on the fact that Perl and Python
> come with so much more functionality than Tcl. Finally, the Tcl core team

perl is becoming a bit of a pig...it can do a lot because of all the
modules available for it...but that just adds to the size. right now my
perl installation on my win2k box is taking up 88 megs.

i have my freewrap.exe renamed to tk.exe. it occupies a wee bit over 600k
on a foppy i can carry around...

i can probably sum up why i use tcl/tk in two lines:

button .b -text "tkblog" -command { tkblog }
pack .b


--
http://home.cogeco.ca/~tsummerfelt1

Kevin Kenny

unread,
Apr 15, 2004, 10:04:11 AM4/15/04
to
Ed Suominen wrote:

> Hopefully this lengthy message will be received in the constructive
> spirit in which it was written.

Indeed. You'll be missed.

Are you still supporting Privaria? If so, for its sake can you
continue to favor us with specifics about what you find wanting
in Tcl? (I realize that your message has some - but more details
always help; details are important.)

Please correct me if I've misunderstood. My biggest takeaway from
your message is that you found that Python's object-orientation
enabled its extension writers to produce a framework that was
easily adapted to your needs.

The fact that Twisted requires
so few lines of code in Python suggests to me that it would not
actually be that hard for a committed group of Tcl'ers to build
from spare parts that we've already on the shelf. I am acutely
aware, though, that such a project would be likely to founder on
the differences of the object models used.

One advantage that both Python and Java have over Perl and Tcl
is that the object-oriented programming model is fundamental
to those languages, and hence all extensions can depend on it.
That advantage is also a grievous disadvantage, however, in that
it makes it impossible to experiment with different models
for object-oriented programming. Tcl has had a number of
experiments done in that vein; I have seen systems that are
prototype-based as well as class-based; systems with explicit
delegation as opposed to inheritance; systems with covariant
and contravariant inheritance, and so on. This experimentation
would not have happened as readily in languages that are not
"O-O neutral" as I've liked to express it.

Nevertheless, it appears that our neutrality may have been
our downfall. The world seems to have defined "object oriented"
to be "Simula67-like class-based object programming."
Had we chosen that as the standard model, and placed classes
in the Core, we might be better off. Then again, we might
be worse off, since many users of alternative models - or
even simply alternative implementations of the Simula67 model -
might well have voted with their feet after their particular
implementations were not chosen.

It's a tough call, and I think that we may well have fallen off
that particular tightrope. Perhaps in retrospect, "pick an
O-O technology, however flawed, and go with it" would have
been a better choice. Here, even my hindsight isn't 20/20!

I'm curious about your assertion that namespaces in Python
"just happen"; in what way do they not "just happen" in Tcl?
I ask because the internals of namespaces are in considerable
disarray, and several of us are thinking seriously about changes
to the resolution mechanism. If there's a fundamental issue
that can be fixed readily, perhaps we can do something.

Michael Schlenker

unread,
Apr 15, 2004, 10:20:45 AM4/15/04
to
Salvatore Sanfilippo wrote:
> On Thu, 15 Apr 2004 03:13:30 -0700, David Gravereaux wrote:
>
>
>>different reason. Any UDP channel driver JUST CAN'T be added to the core
>>due to the forced nature it operates in. Whether it adds a boundary
>>character or forces eof on each read or whatever, it is unacceptable to
>>embrace it into the core.
>
>
> [snip]
>
>
>>If you want UDP, DO NOT make yet another channel driver for it. Go add
>>the highly desired message-oriented mode to the generic I/O layer instead.
>>Then make a new channel driver for that new operational mode.
>
>
> I fully agree. If this paper is still available, please point me to it.
Ask Andreas Kupries for it, he'll probably send it to you.

Michael

David N. Welton

unread,
Apr 15, 2004, 11:11:57 AM4/15/04
to
Kevin Kenny <ken...@acm.org> writes:

> The Tcl core is similar to the Linux kernel in that the TCT, like
> the kernel team, makes no integrated distributions of its own.
> Instead, releases are tagged and branched in the SourceForge CVS
> repository, and distributors are free to go on and pick them up and
> make full distributions out of them.

Problems that I see with this approach:

1) Is not well understood for a system like Tcl. Python, Perl, PHP,
Ruby, et al. come with pretty big _standard_ libraries, package
repositories, or both. People do Linux distributions, not Python,
Postfix, Postgres, or Apache distributions (with a few not so well
known exceptions to prove the rule)

2) The marketing (communication, let's say) of this approach has been
next to non-existant. What are the advantages of this approach?
Why does Tcl do this and no one else in the same problem space? If
we are going to do something different from what people expect, it
had better be spelled out in big red letters.

> By far the most popular of these full distributions is ActiveTcl.

No way. By far the most popular "distribution" of Tcl is the plain
old core, which people fetch from SourceForge. If you count all the
Linux machines that have that, not to mention MacOS X setups, they
outnumber ActiveTcl installs by, I'm guessing, orders of magnitude.

Now, say someone finds that on their system as well as Python and
maybe Perl. The latter two are going to do way more out of the box.

> In short, where did you get the distribution that is missing the
> pieces you complain about?

> There appears to be a fairly widespread misconception that
> extensions are second-class code.

Well, they are, because while the core goes strong, they disappear and
reappear from different web sites, with different licenses, different
ways of doing things. The best reference we have, the wiki, can
appear pretty chaotic to a newcomer. Navigating all that is no
picnic, when one could have most of the same things with their
standard Python install.

> There are a number of reasons that a piece of code may be an
> extension rather than part of the Core, most of which have nothing
> to do with the quality of the code or the availability of support.

I think an important distinction is "part of the core" vs "shipped
with the core". I don't want to see the core itself bloated up with
lots of code, but I would like to see more things shipped with it.

> * The extension is released under a different license.

If things have to have a compatible license to get into the core, that
actually encourages license compatiblity. Seeing your software
shipped with Tcl is a powerful incentive to use that particular license.

> The Tcl Core license has been agreed to by a great many
> contributors over the years. Even if we wished to license the
> core differently, we would have little hope of tracking down all
> the rightsholders and securing permission. Hence, code attached
> any license like the GPL that demands that all code linked to it
> bear the same license simply cannot go into the core. (Example:
> mpexpr, Img)

A bit tangential, but Img is under the following license, as far as I
can tell:

The authors hereby grant permission to use, copy, modify,
distribute, and license this software and its documentation for
any purpose, provided that existing copyright notices are retained
in all copies and that this notice is included verbatim in any
distributions. No written agreement, license, or royalty fee is
required for any of the authorized uses. Modifications to this
software may be copyrighted by their authors and need not follow
the licensing terms described here, provided that the new terms
are clearly indicated on the first page of each file where they
apply.

Which looks pretty bsdish to me.

> * The extension is relevant only to a single product such
> as a third-party database.

> There are a lot of extensions that serve simply as "glue" to
> attach Tcl to third-party products. These glue modules would
> simply clutter the core for those that don't use them. An
> exception is made for a very few Windows-specific extensions
> without which it's insanely difficult to deal with Windows at
> all.

But having them grouped together in one place might be handy... they
should be, if nothing else, closer to the core. I load up PHP and I
have a bunch of DB drivers right there. With Tcl (and Rivet, say), I
have to hunt around for them.

> * There's nobody to do the work.
>
> There are a lot more feature requests than implementors.
> Sorry.

This one is dangerous. Sooner or later, will we hit a downward
spiral, where no one does the work, so Tcl is less attractive, and
less people use it? I don't think we're at that point yet, but we
need to attract developers.

> I'm willing to listen here. I really have had trouble
> understanding, though, just why it's a problem that "the extensions
> aren't in the core." It was a serious problem until 7.3; 7.4 fixed
> it, and 8.1 did an even better job at it. Is this another case
> where the world is laboring under the belief that Tcl still has a
> problem that we fixed ten years ago?

No. The problems are that:

1) People get Tcl and it doesn't do much, because they just got the
core. Compared with Python (or Perl, but I think Python is "the
one to beat" these days), they see that it doesn't have much...

2) Maybe they're moderately interested, so they decide to go install
some stuff. It's hard, because the web site is badly out of date,
there is no standard repository, and things just seem kind of hit
or miss in general.

Now... maybe you don't agree with some of my points, but can you see
where I'm coming from?

I don't have the answers either, but I think Ed's post was reasonable,
polite, and expressed problems that he genuinely had with Tcl. It is
our task to figure out what we can do to fix either the problems or
perceptions that he (and others who he is probably representative of)
has.

--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/

David N. Welton

unread,
Apr 15, 2004, 11:18:52 AM4/15/04
to
"Donal K. Fellows" <donal.k...@man.ac.uk> writes:

> IMHO the main problem is that too many of us don't have the time to
> work on Tcl anything like as much as we want to.

The vicious circle again... the less popular it is, the fewer people
will be paid to even work with it.

> You mention that you want to attract young programmers; that's both
> a good idea (they do have the free time) and a bad idea (they don't
> have the experience - you *really* wouldn't have wanted my
> programming in the core until not that much before I started
> contributing to the core anyway. :^D) By the time they have got the
> experience, they don't have much free time.

Other groups manage to manage and integrate inexperienced coders. I
think Tcl has a lot to offer someone learning. I have learned a lot
from the core team on how to manage a serious project in terms of
testing and management of changes.

> > If there is little interest in the rest of the world, probably
> > it's better to say it explicitly in the home page. Maybe someone
> > interested in Tcl can get the message and start to work to a fork.
> > But I hope it's not the case.

> Well, I don't think there's a need to fork the language. But then I
> would say that, wouldn't I? :^)

Maybe we should pick a new name for it, pretend to have a big fight,
publicizing it on slashdot and all go to work on the "new, exciting
fork";-)

David N. Welton

unread,
Apr 15, 2004, 11:22:54 AM4/15/04
to
Kevin Kenny <ken...@acm.org> writes:

> The fact that Twisted requires so few lines of code in Python
> suggests to me that it would not actually be that hard for a
> committed group of Tcl'ers to build from spare parts that we've
> already on the shelf. I am acutely aware, though, that such a
> project would be likely to founder on the differences of the object
> models used.

I actually had the impression that Twisted is something that attempts
to copy Tcl's event loop. Evidently, they do a pretty good job of it.

I'm curious what specific problems he had too, because I've generally
found Tcl's networking to be more pleasant, and faster to use, than
Python's. It does the standard things easily, and let's you
fconfigure other options.

> This experimentation would not have happened as readily in languages
> that are not "O-O neutral" as I've liked to express it.

Sure, but Tcl is not an academic language where experimentation is the
name of the game (Scheme). It's for people who want to get things
done, and one thing people need to get done is organize large bodies
of code. OO helps one to do that, and not having it within easy reach
is detrimental.

> It's a tough call, and I think that we may well have fallen off that
> particular tightrope. Perhaps in retrospect, "pick an O-O
> technology, however flawed, and go with it" would have been a better
> choice. Here, even my hindsight isn't 20/20!

Well, what can we do to fix or at least improve the current situation?

Bryan Oakley

unread,
Apr 15, 2004, 11:50:21 AM4/15/04
to
David N. Welton wrote:

> Kevin Kenny <ken...@acm.org> writes:

>>This experimentation would not have happened as readily in languages
>>that are not "O-O neutral" as I've liked to express it.
>
>
> Sure, but Tcl is not an academic language where experimentation is the
> name of the game (Scheme). It's for people who want to get things
> done, and one thing people need to get done is organize large bodies
> of code. OO helps one to do that, and not having it within easy reach
> is detrimental.

I can't buy that last statement. I've used Tcl for a number of years on
medium sized projects (roughly 20,000-50,000 lines of tcl code depending
on the project) and never needed OO to help me organize my code.

Having OO *may* have helped me do my job even better, perhaps, but I
hardly see how the lack of OO was a detriment.


Michael Schlenker

unread,
Apr 15, 2004, 12:04:26 PM4/15/04
to
David N. Welton wrote:
> Kevin Kenny <ken...@acm.org> writes:
>
>>This experimentation would not have happened as readily in languages
>>that are not "O-O neutral" as I've liked to express it.
>
>
> Sure, but Tcl is not an academic language where experimentation is the
> name of the game (Scheme). It's for people who want to get things
> done, and one thing people need to get done is organize large bodies
> of code. OO helps one to do that, and not having it within easy reach
> is detrimental.
>
Correct. If i think how much tcllib code for example hand codes some
kind of object interface over and over again, because there wasn't a
widely accepted OO extension inside tcllib... (maybe snit will be used
for some newer things now).

>
>>It's a tough call, and I think that we may well have fallen off that
>>particular tightrope. Perhaps in retrospect, "pick an O-O
>>technology, however flawed, and go with it" would have been a better
>>choice. Here, even my hindsight isn't 20/20!
>
> Well, what can we do to fix or at least improve the current situation?

Include XOTcl, Snit, Stooop and IncrTcl within the core distribution...
(not in the core libs , but at the same level as http and msgcat and
registry).

Basically we probably need a stronger stdlib. Tcllib is nice, but there
isn't as yet a standard bundle for c coded extensions.
(typical examples: tclxml/tdom, XOTcl/IncrTcl, TclX, a generic db
interface, ...)

As i see the current situation there is a lot of code floating around,
that would be part of a standard library of some kind for other
languages, but isn't for tcl, because there simply isn't a real
StandardLibrary.

Radical Restrukturing would be like this:

Core Tcl:
tclsh, libtcl.so, libtclstub.a, the core scripts in the lib/tcl dir

Core Tk:
wish(?), libtk.so, libtkstub.a, the core scripts in the lib/tk dir

Tcl Stdlib Packages:
http, msgcat, kbk's new clock package, thread, tclx, registry
probably large parts of tcllib
an xml parsing package
generic database api
tclvfs
xotcl and incrtcl

an other Tk Stdlib Package could be assembled.

The advantage of such a structure would be the looser structure of a
stdlib package (as with the current tcllib) in contrast to the stricter
core guarded by TCT.

Michael


David N. Welton

unread,
Apr 15, 2004, 11:56:37 AM4/15/04
to
Bryan Oakley <br...@bitmover.com> writes:

> David N. Welton wrote:

> > Kevin Kenny <ken...@acm.org> writes:

> >>This experimentation would not have happened as readily in
> >>languages that are not "O-O neutral" as I've liked to express it.

> > Sure, but Tcl is not an academic language where experimentation is
> > the name of the game (Scheme). It's for people who want to get
> > things done, and one thing people need to get done is organize
> > large bodies of code. OO helps one to do that, and not having it
> > within easy reach is detrimental.

> I can't buy that last statement. I've used Tcl for a number of years
> on medium sized projects (roughly 20,000-50,000 lines of tcl code
> depending on the project) and never needed OO to help me organize my
> code.

How did you organize it then?

> Having OO *may* have helped me do my job even better, perhaps, but I
> hardly see how the lack of OO was a detriment.

Some places where OO is a good fit are the logger and irc modules I
wrote for tcllib. They are object oriented in nature, but I have to
do the mechanics of that myself, rather than use one standard
framework.

OO has its place, like everything else. It's not the answer to
everything, but it's a good tool for a lot of situations. The fact
that so many OO extensions have been written for Tcl is a testament
that I'm not the only person who needs this - a lot of people have put
their money where their mouth is to get this feature.

So I'll stand by this: a standard extension (not welded into the core,
but maybe shipped with it) would be beneficial to Tcl.

"I never needed it myself" is not the best of arguments against
things, either. Read Ed's post again... hardly the words of an OO
fanatic, but he's finding it quite useful.

David N. Welton

unread,
Apr 15, 2004, 11:59:51 AM4/15/04
to
Michael Schlenker <sch...@uni-oldenburg.de> writes:

Good post...

> Basically we probably need a stronger stdlib. Tcllib is nice, but
> there isn't as yet a standard bundle for c coded extensions.
> (typical examples: tclxml/tdom, XOTcl/IncrTcl, TclX, a generic db
> interface, ...)

> As i see the current situation there is a lot of code floating
> around, that would be part of a standard library of some kind for
> other languages, but isn't for tcl, because there simply isn't a
> real StandardLibrary.

> Radical Restrukturing would be like this:

> Core Tcl:
> tclsh, libtcl.so, libtclstub.a, the core scripts in the lib/tcl dir

> Core Tk:
> wish(?), libtk.so, libtkstub.a, the core scripts in the lib/tk dir

> Tcl Stdlib Packages:
> http, msgcat, kbk's new clock package, thread, tclx, registry
> probably large parts of tcllib
> an xml parsing package
> generic database api
> tclvfs
> xotcl and incrtcl

> an other Tk Stdlib Package could be assembled.

> The advantage of such a structure would be the looser structure of a
> stdlib package (as with the current tcllib) in contrast to the
> stricter core guarded by TCT.

This seems like an intelligent way to put something down on paper and
subsequently act on it.

se...@fishpool.com

unread,
Apr 15, 2004, 12:20:34 PM4/15/04
to
mjk...@cs.helsinki.fi wrote:
>
> OK, first I have to remind you, that "if the only tool is a hammer,
> all problems start to look like a nail" or something... There is a
> place for Tcl and there is a place for Python. Both languages are more
> or less general-purpose programming languages and can be utilized for
> lot of different tasks.

Oh, I much prefer the line "if all you have is a hammer, everything looks
like a skull" ;->


>
> I'm using Tcl/Tk for different kinds of tasks. The reason for using
> Tcl/Tk over other languages is the simplicity of the language and easy
> extensibility. Tcl also works as a brilliant glue-language between
> different kinds of applications. But the power of Tcl is in its
> extremely simple specification and structure.

Agreed. As pointed out on IRC, Tcl matches my way of thinking. It's how
I would design a programming language. I want that way of thinking to
survive and I still have enough inspiration in me to try to do something
about it. I tell people about Tcl, develop stuff for it (when I can) and
take part in the community.

I never like the "give up and die" attitude. If there's something I like, I
want to do what I can to push it onwards. If everyone thought that way,
nothing would ever change in the world and nothing worthwhile would remain.
I don't listen to Britney because half the world jerk off to her.

Actually, I did a bit of Pythoning as well and it's easy to see areas where
Tcl's beauty really works in comparison. I'm glad there are choices.

--
/ http://www.fishpool.com/~setok/

Andreas Leitgeb

unread,
Apr 15, 2004, 12:20:37 PM4/15/04
to
Kevin Kenny <ken...@acm.org> wrote:
> One advantage that both Python and Java have over Perl and Tcl
> is that the object-oriented programming model is fundamental
> to those languages, and hence all extensions can depend on it.
> That advantage is also a grievous disadvantage, however, in that
> it makes it impossible to experiment with different models
> for object-oriented programming.

This last sentence in this context chokes a smile on my face:

I wonder, how many java, C++ or python- *programmers* (rather than
language-designers) have ever wondered, what it would be like to
have a different Object-system...

I think hardly any has. They use the one object-system and rather
than thinking about other possible object-systems, they simply
"get their work done"(tm).

I find this funny, because regularly some quote gets appointed as
QOTW, that claims that Tcl-programmers prefer to get their work
done, rather than <whatever>

Is the lack of "choice of object-systems to experiment with" in
other languages really that "grievous" ? I think not.

> Nevertheless, it appears that our neutrality may have been
> our downfall.

So, you consider it, too.

> Then again, we might be worse off, since many users of

> alternative models [...] might well have voted with their

> feet after their particular implementations were not chosen.

The number of feet that have voted against the current object-
models of C++, Java, ... seems to be small enough to not endanger
these languages.

PS: I don't see, how the existence of one particular object-model
in the Tcl-core would necessarily thwart any other. It might
however result in alternative object-systems having to replace
the global command "class", or simply use different command-names
themselves ...

se...@fishpool.com

unread,
Apr 15, 2004, 12:29:53 PM4/15/04
to
mjk...@cs.helsinki.fi wrote:

> Sorry my bad English.

Oh, was going to say that it's nice to see someone here from the same
CS Dept as me ;->

--
/ http://www.fishpool.com/~setok/

Steve Lidie

unread,
Apr 15, 2004, 12:43:25 PM4/15/04
to
David N. Welton <dav...@dedasys.com> wrote:
> Kevin Kenny <ken...@acm.org> writes:
>

>> This experimentation would not have happened as readily in languages
>> that are not "O-O neutral" as I've liked to express it.
>
> Sure, but Tcl is not an academic language where experimentation is the
> name of the game (Scheme). It's for people who want to get things
> done, and one thing people need to get done is organize large bodies
> of code. OO helps one to do that, and not having it within easy reach
> is detrimental.

Having one OO implementation is really important for Tk, particularly
with respect to mega-widget creation. Having new widgets as distinct
objects turns out to be very nice ...


se...@fishpool.com

unread,
Apr 15, 2004, 12:49:49 PM4/15/04
to
David N. Welton <dav...@dedasys.com> wrote:
>
>> This experimentation would not have happened as readily in languages
>> that are not "O-O neutral" as I've liked to express it.
>
> Sure, but Tcl is not an academic language where experimentation is the
> name of the game (Scheme). It's for people who want to get things
> done, and one thing people need to get done is organize large bodies
> of code. OO helps one to do that, and not having it within easy reach
> is detrimental.

I'd love to see Tcl be both. I find it is easier to get things done with
Tcl than it is with Scheme (others may disagree), but Tcl also offers a lot
when I'm in an experimental mood. I just love it that I can load up Snit
to do some delegation -style OO programming.

It would take a lot of work to convince me that Tcl's minimalistic kernel is
not the way to go. I think the most important work is in getting that
minimalistic core to do the coolest things possible, to allow as many
options on top of it as we can (different extensions, programming paradigms
etc.). That's what I like about Tcl and if it loses that, I'll be looking
for something else. After all, Tcl is the extension language. That is what
could allow it to survive for a very long time.

That isn't to say we shouldn't do a lot of work to make sure extensions are
distributed more easily than now and that the core distribution couldn't be
larger. Just that I don't want to see Tcl's philosophy changed drastically.

--
/ http://www.fishpool.com/~setok/

Iain Findleton

unread,
Apr 15, 2004, 12:54:08 PM4/15/04
to
Ed Suominen wrote:

...snip....

Sigh! Must be Easter. People all over the world engage in self
flagelation for some strange reason...

Having written stuff in a large number of languages over many years, I
find that I drift to the languages that I find convenient for the task
at hand. I get my OO fix doing C++ for stuff, but when I want to
generate a GUI application in a few minutes, nothing beats Tcl/Fltk.

OO is a state of mind. Its a convenient paradigm. You can do it in any
language, its just somewhat more convenient in some languages than in
others.

Tcl is a string substitution language. In skilled hands, you can do
stuff in Tcl in minutes that would take weeks in C++, FORTRAN or COBOL.
I appreciate it for its benefits, but its not a religion.

Of course, real programmers do everything in shell script. Using
anything else is just a confession of personal limitations...

David N. Welton

unread,
Apr 15, 2004, 1:17:15 PM4/15/04
to
se...@fishpool.com writes:

> It would take a lot of work to convince me that Tcl's minimalistic
> kernel is not the way to go.

I agree with that, but there is a difference between "minimalistic,
shipped bare", and "minimalistic, but shipped with all the goodies",
or "minimalistic, but very closely associated with a couple of large
library packs that give you the goodies".

> I think the most important work is in getting that minimalistic core
> to do the coolest things possible, to allow as many options on top
> of it as we can (different extensions, programming paradigms
> etc.). That's what I like about Tcl and if it loses that, I'll be
> looking for something else. After all, Tcl is the extension
> language. That is what could allow it to survive for a very long
> time.

Sure, experimentation is fun, but for those "get it done" times, it's
nice to have standards, even if they are kind of rough. It also keeps
code bloat down in other ways - as another poster cited, all the
different semi-OO stuff floating around could be consolidated into one
system. Having a standard doesn't completely kill innovation either,
you still have a flexible language that you can play with when you
want that.

Like your math commands TIP, for instance... sure it's easy to
implement that, but why have everyone do it halfway instead of doing
it once, well, and making it available everywhere.

Bryan Oakley

unread,
Apr 15, 2004, 1:21:38 PM4/15/04
to
David N. Welton wrote:

> Bryan Oakley <br...@bitmover.com> writes:
>
>
>>David N. Welton wrote:

>>>Sure, but Tcl is not an academic language where experimentation is
>>>the name of the game (Scheme). It's for people who want to get
>>>things done, and one thing people need to get done is organize
>>>large bodies of code. OO helps one to do that, and not having it
>>>within easy reach is detrimental.
>
>
>>I can't buy that last statement. I've used Tcl for a number of years
>>on medium sized projects (roughly 20,000-50,000 lines of tcl code
>>depending on the project) and never needed OO to help me organize my
>>code.
>
>
> How did you organize it then?

I'm not sure how to answer that because I'm not entirely sure what
you're asking. We had libraries of reusable code that used simple naming
conventions to keep the data and procedures from stepping over each
other. Our products are then built by concatenating the various libs
together into a single file.

Works like a charm, no OO required. In fact, that's how I'm working
today (on a 20,000ish line project). These days I prefer putting each
logical set of work in its own namespace, but the powers that be prefer
naming conventions instead (proc frabbitz_start vs. ::frabbitz::start).

Does that answer your question, or did I misunderstand what you were asking?

>
>>Having OO *may* have helped me do my job even better, perhaps, but I
>>hardly see how the lack of OO was a detriment.
>
>
> Some places where OO is a good fit are the logger and irc modules I
> wrote for tcllib. They are object oriented in nature, but I have to
> do the mechanics of that myself, rather than use one standard
> framework.
>
> OO has its place, like everything else. It's not the answer to
> everything, but it's a good tool for a lot of situations.

Hmmm, but in an earlier post you said a lack of OO was a detriment. Was
I wrong to infer you thought OO was important for all projects?

> The fact
> that so many OO extensions have been written for Tcl is a testament
> that I'm not the only person who needs this - a lot of people have put
> their money where their mouth is to get this feature.
>

Indeed. I'm not arguing OO isn't useful. I'm just saying a lack of OO
isn't necessarily a detriment.

> So I'll stand by this: a standard extension (not welded into the core,
> but maybe shipped with it) would be beneficial to Tcl.

I think I can agree to that. I know having a standard OO-like
infrastructure would have helped me write my combobox and mclistbox
widgets. A large chunk of that code exists just to manage instance
variables and options and so forth.

>
> "I never needed it myself" is not the best of arguments against
> things, either. Read Ed's post again... hardly the words of an OO
> fanatic, but he's finding it quite useful.

I'm not saying "I never needed it so neither does anyone else". I'm just
saying I'm proof that the lack of OO doesn't make it impossible to
manage one's code.

These days I'm all for adding some sort of object oriented capabilties
in the core distribution. Specifically I want something that makes it
easy to create "objects" (specifically in my case, megawidgets) that
have options and methods. I don't need (nor do I want) inheritance or
polymorphism or some other OO buzzwords.

lvi...@yahoo.com

unread,
Apr 15, 2004, 1:14:07 PM4/15/04
to

According to David N. Welton <dav...@dedasys.com>:
:So I'll stand by this: a standard extension (not welded into the core,

:but maybe shipped with it) would be beneficial to Tcl.

And in fact, a TIP was approved to ship itcl with the core, once the
the TCT is satisfied that the issues of implementation and deployment
were resolved.

Perhaps it is time for someone to step forward and ask the TCT what
they wish to see in place so that that TIP can be finalized.

David N. Welton

unread,
Apr 15, 2004, 1:27:55 PM4/15/04
to
Bryan Oakley <br...@bitmover.com> writes:

> Hmmm, but in an earlier post you said a lack of OO was a
> detriment. Was I wrong to infer you thought OO was important for all
> projects?

I have plenty of code where I don't even think about OO, it's not
necessary. Other stuff where I am quite frustrated by the lack of a
standard one.

> > The fact that so many OO extensions have been written for Tcl is a
> > testament that I'm not the only person who needs this - a lot of
> > people have put their money where their mouth is to get this
> > feature.

> Indeed. I'm not arguing OO isn't useful. I'm just saying a lack of
> OO isn't necessarily a detriment.

Well if it's useful in a particular case and you don't have
it... that's bad:-)

> > So I'll stand by this: a standard extension (not welded into the
> > core, but maybe shipped with it) would be beneficial to Tcl.

> I think I can agree to that. I know having a standard OO-like
> infrastructure would have helped me write my combobox and mclistbox
> widgets. A large chunk of that code exists just to manage instance
> variables and options and so forth.

> > "I never needed it myself" is not the best of arguments against
> > things, either. Read Ed's post again... hardly the words of an OO
> > fanatic, but he's finding it quite useful.

> I'm not saying "I never needed it so neither does anyone else". I'm
> just saying I'm proof that the lack of OO doesn't make it impossible
> to manage one's code.

No, of course not. But it's a "best tool for the job" kind of thing,
which we seem to agree on.

> These days I'm all for adding some sort of object oriented
> capabilties in the core distribution. Specifically I want something
> that makes it easy to create "objects" (specifically in my case,
> megawidgets) that have options and methods. I don't need (nor do I
> want) inheritance or polymorphism or some other OO buzzwords.

Inheritance is nice, because it lets you do some cool things in given
situations (the logger module has a sort of hacked in inheritance if
you want an example), but I think I agree that I mostly just want a
way to encapsulate a more complex object to pass around.

lvi...@yahoo.com

unread,
Apr 15, 2004, 1:24:44 PM4/15/04
to

:> Well, what can we do to fix or at least improve the current situation?
:
:Include [and a list of various OO extensions is listed...]

:Basically we probably need a stronger stdlib. Tcllib is nice, but there

:isn't as yet a standard bundle for c coded extensions.

:(typical examples: [a list of a number of popular compiled extensions]

:As i see the current situation there is a lot of code floating around,

:that would be part of a standard library of some kind for other
:languages, but isn't for tcl, because there simply isn't a real
:StandardLibrary.


This thread has now moved into the "define a Batteries Included distribution"
phase.


Before we move into everyone chiming in with their favorite extensions,
why don't we do a bit of meta-discussion?


1. What is the real goal for this effort - to have one downloaed file
containing all the useful Tcl code available on the internet?

2. I have heard several times on comp.lang.tcl "I don't want to use ActiveTcl
because the download is so large" ... but yet, adding in all these extensions
into a single source .zip or .tar is going to result in something about
the same size - probably even larger.

3. Who, specifically, is going to take on the roles of creating the tar files,
determine when to update an extension that is included, determining what
goes into the files, etc.? Where will these files reside?

4. Would people be satisfied to have a single tar file in which all
extensions reside in a series of parallel directories - but which they
would still have to cd into each directory, deal with having to
configure , build, test, and install each one seperately, etc.?
Otherwise, now what is being discussed is "work with the authors off all
extensions (and applications) to achieve a interoperable build environment",
which means that said environment has to be figured out and agreed upon,
and that someone then has to work with all the authors to get their
code changed to use the new framework.

5. Will this effort specifically ignore all extensions and applications which
currently are not changing or supported? If not, then who will be
taking on the responsibility for managing all this code?

I suspect there are some additional meta-questions which should be answered
so that everyone can understand the process being proposed.

Bryan Oakley

unread,
Apr 15, 2004, 2:17:22 PM4/15/04
to
David N. Welton wrote:

> No, of course not. But it's a "best tool for the job" kind of thing,
> which we seem to agree on.
>

I'm pretty sure I agree with that. I'm definitely of the opinion one
should use the best tool for the job. That's why I choose Tcl more often
than not :-)

Yes, sometimes OO is the right tool. Definitely not all the time, but
sometimes, for some people, yes.

>
>>These days I'm all for adding some sort of object oriented
>>capabilties in the core distribution. Specifically I want something
>>that makes it easy to create "objects" (specifically in my case,
>>megawidgets) that have options and methods. I don't need (nor do I
>>want) inheritance or polymorphism or some other OO buzzwords.
>
>
> Inheritance is nice, because it lets you do some cool things in given
> situations (the logger module has a sort of hacked in inheritance if
> you want an example), but I think I agree that I mostly just want a
> way to encapsulate a more complex object to pass around.
>

I see some benefits of inheritance and know why it's cool from a
theoritical point of view. But I've seen the dark side of inheritance,
too. For the work I've done over the past (*ahem* <cough> <cough>)
years it has been entirely unnecessary. YMMV.

David N. Welton

unread,
Apr 15, 2004, 2:21:59 PM4/15/04
to
lvi...@yahoo.com writes:

> This thread has now moved into the "define a Batteries Included
> distribution" phase.

Maybe... sort of. There are a couple ideas floating around, including
that, or the idea of having something like tcllib, but for binaries.

As others have pointed out, part of the problem is the marketing and
comunication of this stuff via the web site. There is, for example,
no link to tcllib, the standard tcl library, from the Tcl download
page!

> Before we move into everyone chiming in with their favorite
> extensions, why don't we do a bit of meta-discussion?

Ok, this is good stuff.

> 1. What is the real goal for this effort - to have one downloaed
> file containing all the useful Tcl code available on the internet?

No, that's not possible. The goal is to have few files... 1..2..3
maybe, that contain a ton of useful stuff.

> 2. I have heard several times on comp.lang.tcl "I don't want to use
> ActiveTcl because the download is so large" ... but yet, adding in
> all these extensions into a single source .zip or .tar is going to
> result in something about the same size - probably even larger.

I have more often been thankful that it exists, especially for clients
who use windows. I can develop stuff on linux, knowing what packages
are in there, and have it pretty much "just run" on windows. Very
cool.

> 3. Who, specifically, is going to take on the roles of creating the
> tar files, determine when to update an extension that is included,
> determining what goes into the files, etc.? Where will these files
> reside?

I assume it will be a group of people, like with tcllib. Andreas does
a lot of the leg work there, which is appreciated, but others do
things too.

> 4. Would people be satisfied to have a single tar file in which all
> extensions reside in a series of parallel directories - but which they
> would still have to cd into each directory, deal with having to
> configure , build, test, and install each one seperately, etc.?

Probably not.

> Otherwise, now what is being discussed is "work with the authors off
> all extensions (and applications) to achieve a interoperable build
> environment", which means that said environment has to be figured
> out and agreed upon, and that someone then has to work with all the
> authors to get their code changed to use the new framework.

Yep.

> 5. Will this effort specifically ignore all extensions and
> applications which currently are not changing or supported? If not,
> then who will be taking on the responsibility for managing all this
> code?

Maybe we can leverage some momentum to update a few of the cruftier
ones. Maybe that's optimistic, but a little of that never hurt
either:-)

> I suspect there are some additional meta-questions which should be
> answered so that everyone can understand the process being proposed.

--

Stephen Huntley

unread,
Apr 15, 2004, 2:57:38 PM4/15/04
to
Ed:

I think your post is valuable. Instead of trying to invalidate your
arguments, I will outline my reasons why I stick to Tcl. Then we can
perhaps glimpse how strengths and weaknesses counterbalance.

The main reasons I stick with Tcl are:

1. Rock-solid stability. I'm too old to spare time wondering if
frequent crashes in my software are my fault or the underlying
technology's fault. Tcl largely removes this consideration from the
equation. America Online's web server is written in Tcl. It is
highly unlikely I will ever need to scale a product of mine to that
level, so there's a lot of headroom for me.

I have occasionally looked into new technologies, like Python, PHP,
Ruby, etc; but I've noticed that if you look beyond the FAQ's deep
into the developer mailing lists, you'll generally find statements
like: 'development of the core is going really really well, and within
the next few releases we actually expect it to be stable!' Hold me.

I frequently use Tcl to write wrappers for other products to catch and
compensate for their shortcomings. This would be pointless if it
weren't for the fact that Tcl is at least an order of magnitude more
stable and reliable than any other technology I've tried.

2. Freedom from bugs. For years after college I did almost no coding
because I was sick of the fact that I would have to rewrite literally
everything I wrote two or three times to find a syntactically correct
version that didn't hit a deadly bug. Imagine my surprise when my
first Tcl scripts Just Worked. And the docs were accurate and
complete too, so I didn't have to spend half my time
reverse-engineering (another new experience). For this reason alone
Tcl is almost single-handedly responsible for the fact that I am still
working in the computer world.

In ten years of Tcl scripting, I think I've encountered three bugs in
the core. I found upon reporting that each one was already fixed in
the latest version. I just don't bother to upgrade my core very often
because of 1. and 2.

3. Platform agnosticism. Since Tcl was originally designed to be
embedded it play no favorites in terms of platform features. It's
available on a wide variety of platforms and I suspect will be there
on the platforms of the future in equally reliable forms. I started
with computers on Unix as a student, as a professional worked first
with Macintosh v 7, then on to Windows, and now a bit of everything
(five *nix versions, four Win*s and handheld devices). AS/400 was in
there somewhere. Tcl has been there every step of the way. I'm too
old to relearn my chops every time a new OS fad blows through, and I
don't want to have to predict winners and losers. I feel Tcl
minimizes the likelihood I will have to.

Here at work I suggested we use a free Tcl installer program rather
than a for-pay Java one. Management chose the Java option. Why?
Because the Java company officially supported all the platforms we
needed to be on, and management felt they couldn't take the risk of
going without assurances. It's turned out that the installer has
required special handling or patches for every OS (and almost every OS
version) we've tried it on, resulting in numerous gotchas and
release-note warnings for our customers. And "official support" is a
bulletin board where their engineers' response is always "we're
working on it." Meanwhile my build and test scripts run merrily and
without alteration everywhere.

Alternative technologies tend nakedly to favor *nix, and seem only to
offer a subset of function on other OS's grudgingly. Python and
similar technologies treat platform-specific issues like pathnames and
line terminators as special cases with their own commands or
compensating strategies to handle them. Tcl largely handles them
tranparently. It was years before I was even aware of some of these
issues because Tcl handled them so well. Python uses ASCII as a
default string encoding, but recently managed to bolt on a Unicode
library (same with PHP I think). I haven't looked into its Shift-JIS
suppport, which I need for work (and is included with Tcl).

4. Tk. Other technologies say 'We don't have a native GUI interface,
but there's a binding to the Tk library.' For all intents and
purposes, Tk is the only game in town for cross-platform GUI
scripting. When I'm using Tcl I know I have access to 100% of Tk's
features and the latest Tk version. Is that true with other
languages' bindings? I don't know, but if I had to bet money I'd say
no.

Tk follow's Tcl's logic, and it's a lot easier to program Tk
interfaces when in the Tcl mindset then try to access Tk's features by
switching gears from another language's mindset. I don't do GUI
programming very often, but when I have to, it's nice to know that I
can do it as a trivial extension of my existing Tcl skills.

Ed, your voice-recognition project looks very interesting, and I look
forward to using it when it's ready for prime time. I spend 90% of my
time in front of a Windows computer (my boss's choice, not mine): how
does it run on Windows? How stable is it? How does Twisted's event
architecture compare to Tcl's?


Steve Huntley

Gerald W. Lester

unread,
Apr 15, 2004, 3:01:22 PM4/15/04
to
Bryan Oakley wrote:
> David N. Welton wrote:
>> Kevin Kenny <ken...@acm.org> writes:
>>> This experimentation would not have happened as readily in languages
>>> that are not "O-O neutral" as I've liked to express it.
>> Sure, but Tcl is not an academic language where experimentation is the
>> name of the game (Scheme). It's for people who want to get things
>> done, and one thing people need to get done is organize large bodies
>> of code. OO helps one to do that, and not having it within easy reach
>> is detrimental.
> I can't buy that last statement. I've used Tcl for a number of years on
> medium sized projects (roughly 20,000-50,000 lines of tcl code depending
> on the project) and never needed OO to help me organize my code.

And over the last 12 years have used Tcl on some larger sized projects
300,000 - 600,000 lines of Tcl code. None of which used an OOP extension
or threading.

Since we were running on Unix, we implemented the project as cooperating tasks.

Our system had a OO design since our database was a network OO model.

I remain firmly convinced that the TIP appoved OOP would have hampered us.

> Having OO *may* have helped me do my job even better, perhaps, but I
> hardly see how the lack of OO was a detriment.

Particularly since it is only a package require away.

--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is |
| Gerald...@cox.net | the man who is alive." -- Cervantes |
+--------------------------------+---------------------------------------+

Gerald W. Lester

unread,
Apr 15, 2004, 3:05:41 PM4/15/04
to
Andreas Leitgeb wrote:

>...


> PS: I don't see, how the existence of one particular object-model
> in the Tcl-core would necessarily thwart any other. It might
> however result in alternative object-systems having to replace
> the global command "class", or simply use different command-names
> themselves ...

Because then other packages could not rely on the "core" OO being there to
work.

Thus you are back where you have to use all of one (and know which packages
use which ones) or never use anything but the "core" -- guess which one
will happen.

Gerald W. Lester

unread,
Apr 15, 2004, 3:07:39 PM4/15/04
to
Iain Findleton wrote:

> ...


> Of course, real programmers do everything in shell script. Using
> anything else is just a confession of personal limitations...

Nah, REAL PROGRAMMERs do everything use in machine language and use the
patch utility to write their code. No need to edit it, it works right the
first time!

Steve Lidie

unread,
Apr 15, 2004, 2:55:17 PM4/15/04
to
David N. Welton <dav...@dedasys.com> wrote:

>> These days I'm all for adding some sort of object oriented
>> capabilties in the core distribution. Specifically I want something
>> that makes it easy to create "objects" (specifically in my case,
>> megawidgets) that have options and methods. I don't need (nor do I

Agreed.

>> want) inheritance or polymorphism or some other OO buzzwords.
>
> Inheritance is nice, because it lets you do some cool things in given
> situations (the logger module has a sort of hacked in inheritance if
> you want an example), but I think I agree that I mostly just want a
> way to encapsulate a more complex object to pass around.

As I have noted in the past, the benefits of encapsulation are quite
amazing. Uncounted times I have wanted to reuse a Tcl/Tk
"mega-wiget", yet retrofitting it into my code led to a tangled mess of
spaghetti code and globals galore. But once it was made into an object
I could reuse it with ease. The first time I did it I sat back in awe
and realized just how simple and consistent matters had become.

Tcl (if for only Tk's sake, but I find uses for it outside of GUI
development) needs one supported, built-in, OO mechanism, Look at the
source code for Tcl/Tk, it's the best, most readable, easiest to
maintain, C code I've ever seen. That's because there are coding
conventions that people actually use. For that same reason you want
one OO style that everyone who wants to write *sharable* code can use.

Cameron Laird

unread,
Apr 15, 2004, 4:13:36 PM4/15/04
to
In article <87ekqpp...@dedasys.com>,

David N. Welton <dav...@dedasys.com> wrote:
.
.
.
And some of us, at least occasionally, also want changes
down on the small end, that is, structure that helps make
Tiny Tcl or similar more maintainable/practical/...

In saying so, I don't want to distract from the main theme
of how to do stdlib correctly.
--

Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net

Cameron Laird

unread,
Apr 15, 2004, 4:23:29 PM4/15/04
to
In article <407E965B...@acm.org>, Kevin Kenny <ken...@acm.org> wrote:
.
.
.

>The fact that Twisted requires
>so few lines of code in Python suggests to me that it would not
>actually be that hard for a committed group of Tcl'ers to build
>from spare parts that we've already on the shelf. I am acutely
.
.
.
Twisted is actually quite a substantial module; maybe
I'll make time to report on its line count. The biggest
value it provides is to expose what Tcl has in the core:
nicely-programmable event-oriented TCP/IP. A close second
is that Twisted packages high-quality protocol interfaces
for SMTP, DNS, and a bunch of other services.

Gerald W. Lester

unread,
Apr 15, 2004, 4:42:03 PM4/15/04
to
Cameron Laird wrote:
> In article <407E965B...@acm.org>, Kevin Kenny <ken...@acm.org> wrote:
> ...
>>The fact that Twisted requires
>>so few lines of code in Python suggests to me that it would not
>>actually be that hard for a committed group of Tcl'ers to build
>
>>from spare parts that we've already on the shelf. I am acutely
> ...
> Twisted is actually quite a substantial module; maybe
> I'll make time to report on its line count. The biggest
> value it provides is to expose what Tcl has in the core:
> nicely-programmable event-oriented TCP/IP.

So what does it have in this area that Tcl does not - packet oriented items
like UDP?

> A close second
> is that Twisted packages high-quality protocol interfaces
> for SMTP, DNS, and a bunch of other services.

Please compare and contrast against Tcllib's SMTP, DNS, etc services.

John Roth

unread,
Apr 15, 2004, 7:20:01 PM4/15/04
to

"Stephen Huntley" <blac...@usa.net> wrote in message
news:f82c8ae7.04041...@posting.google.com...

> Ed:
>
> I think your post is valuable. Instead of trying to invalidate your
> arguments, I will outline my reasons why I stick to Tcl. Then we can
> perhaps glimpse how strengths and weaknesses counterbalance.
>
> The main reasons I stick with Tcl are:

What's amusing is that every one of your arguements in favor
of TCL are also arguements in favor of Python. This is, after
all, 2004, not 1994. Languages don't get widespread use
today unless either 1) some mega-mastodon is pushing them,
like Java or C#, or 2) they just work out of the box, and
solve real problems for the people using them.

John Roth

Michael Schlenker

unread,
Apr 15, 2004, 8:14:45 PM4/15/04
to
> And some of us, at least occasionally, also want changes
> down on the small end, that is, structure that helps make
> Tiny Tcl or similar more maintainable/practical/...
>
> In saying so, I don't want to distract from the main theme
> of how to do stdlib correctly.

I think that is exactly the point.

Tcl has two competing groups in the discussion: The embedders that are
concerned about startup time, library size, memory footprint and things
like that on the one side, the
"batteriers-included-huge-stdlib-in-the-core" fraction on the other side.

Those targets are impossible to reach at the same time.

So instead of making it a problem, try to create a virtue.

a) Let the embedders factor out as much functionality as possible from
the core into a modular stdlib

b) Let the batteries group add as much useful functional as required
into a modular stdlib

In my point of view the stdlib should consist of those fundamental
extensions one can built on. Most C extension that define their own
stubs table probably fall into this category.

A primary example is the current tcllib. Many of the modules inside
existed before, where coded before and just adopted for tcllib, some are
entirely new. Inclusion in tcllib led to a minimal coding standard
(code, docs, testsuite), a documentation in a unified format, easy
installation, tests on many platforms, more eyes to look for and fix
bugs, and last but not least much higher visibility of those modules in
the community.

The ease of extension writing for small things in Tcl compared to Perl
and Python is a big plus. But only if you can see and use the tried and
true extensions. Tcllib reaches this goal for many tcl coded extensions
(just think about the times tcllib ftp is mentioned when someone asks
about automating ftp via expect...)

Tcllib was lots of work to create, but it works. Now we have a tcl based
installer (sak), tcl based documentation tools (doctools), some extra
test tools, and lots of useful modules (one or two duds remain, i would
consider the javascript module in tcllib rather dead in the water).

What do we have for other C coded extensions?
TEA................................... so what?

A huge benefit for a standard library is the infrastructure. It's hard
to create a good build system, its much easier to adapt an existing one.

If i would have to formulate criteria for selection of extensions to
form a Tcl stdlib, i would choose things like the following:

- Integrated, cross platform build system (TEA or better)
- Useful documentation, probably doctools based
- Stubs enabled if at all possible
(sometimes hard or near impossible to achieve)
- Export their own stubs table if their functionality could be useful
- BSD license
- Provides fundamental extra functionality (Thread, msgcat, XML, ASN1,
TclX/Registry/ffidl/Twapi, KBK's localized clock, Datastructures, One or
more OO-Systems, RPC-Support, TLS/Crypto,... )

Probably i missed some points, but just by harmonizing some build
systems we make the world easier for anyone trying to get an extension,
and just providing a TEA config via the sampleextension just isn't
enough to keep things going.

Inclusion into a stdlib does not make maintenance automatic for the
single package or module, but by using coding standards, documentation
standards and a common build system, many people look at the
infrastructure.

Extensions are just cool if the can be just pkg required and work, but
if you have to build them first, your basically lost in space. TEA is
nice, but just by using TEA it doesn't mean the package author used it
in a non stupid way.

There are some extensions that are notoriously hard to build, just
because for their authors it just works. (TclXML and consorts, XOTcl,
fill in your special friend).

Please raise your hands if one of you really contributes to TEA in any
way, afaik most work is done by Jeff Hobbs, no good docs for TEA are
ever written (due to lack of time), no test suite for TEA compliance
exists, basically no Tools for creation of TEA config exist (TEApot is
an exception, but probably not up to date).

Putting it under a common name like tcllib did, will surely help to
improve TEA, find and eradicate build bugs and generally improve ease of
build. It's similar to DEB or RPM, those formats exist, are widely used
and someone does the work to get _their_ personal favorite into the format.

I don't want a zillion extension in a stdlib, or in the core, i just
want extensions that build without causing major headache.

This is explicitly not about a binary extension repository or something.
That would be nice and a natural extension to this, but without the
basic problems solved, we shouldn't even think aloud about a binary
repository.

Michael

rob loggia

unread,
Apr 15, 2004, 10:21:50 PM4/15/04
to
On Thu, 15 Apr 2004 09:27:04 +0000, Kevin Kenny wrote:

> Salvatore Sanfilippo wrote:
> > 1) In Tcl, extensions are not considered part of the language.
> >
> > 2) Pure-Tcl extensions that are very important for the language
> > are inside Tcllib, that is not considered part of the language
> > itself.
> >
> > 3) I generally saw a lot of resistance or lacks of interest for
> > 1) and 2) in Tcl
>
> These are points that I see very widely expressed, and ones that,
> frankly, I have trouble understanding.

However, it is true that in many cases perception *is* reality. If the
points are "very widely expressed" then there is a problem. It may be
that the problem is only a perception problem, but it is a problem
nonetheless.

A problem for whom? Well, anyone that likes TCL and TK and wants to see
support for the language increase rather then decrease and usage increase
rather then decrease. Those that like the TCL "way" want to see it
applied to the problems of *tomorrow* AS WELL AS the problems of
yesterday.

TCL *isn't* Perl and isn't Python and THAT is a virtue in itself in many
cases. Many people perfer TCL's source -level clarity to Perl, and TCL's
straightforward and simple way of setting up what otherwise would be
reasonably complex code. However, if these people cand USE the language,
they will switch; their companies will switch.

This discussion keeps coming up, and I would suggest that there is a
reason, and a valid reason, for that, and that it is an important part of
the reason why when you say TCL to many people, they see tumbleweeds in
their minds eye. Far from the truth, but does it matter if only the TCT
knows it?

While I respect your contributions to TCL, and while I take you at your
word that you don't understand why these points keep arising, I cannot
help but suspect that there are those who *do* understand fully and yet do
not wish to have the discussions. I would suggest to these people that
whatever their reasons, they do not serve themselves best by simply
stating, "Well, this is the way its been done and this is the way we'll
continue to do it." Clearly *something* is less then optimal if this same
line of discussion keeps arising.

> The Tcl core is similar to the Linux kernel in that the TCT, like
> the kernel team, makes no integrated distributions of its own.
> Instead, releases are tagged and branched in the SourceForge CVS
> repository, and distributors are free to go on and pick them
> up and make full distributions out of them.

> By far the most popular of these full distributions is ActiveTcl.
> It has a number of popular extensions and all of Tcllib
> preinstalled.

Unfortunately it is not the TCL core, it comes with restrictions, anf it
is not what people *should* think when they reference TCL. Promoting this
line of thought does not even benefit Active State in the end. It is the
opinion, at least of a few "outsiders", that TCL has always been
"shadowed" by a particular company. And while Jeff Hobbs [rightly] goes
out of his way to point out TCL!=ActiveTCL, pointing to Active TCL as an
answer to a request for "batteries included" TCL does the opposite in terms of
public perception of the language.

It should be clear that if any company wants to derive *real* and
*enduring* benefit from TCL the language, they must remain at all times
overshadowed by the language, and never the other way around. It is hard for
them to maintain a low profile if the burden of providing the
"distribution of record" for what clearly many users want - an extension
rich one-time installation that will make the tcl software they want to
use and write "Just Work".

> (Admittedly, it hasn't got any of the UDP
> extensions built-in. Perhaps the Activators can do something
> there...) But even with ActiveTcl fairly ubiquitous, there is
> a set of Tcl'ers that simply won't use "extensions." By
> contrast, most Perlites and Pythoneers aren't even aware whether
> something from the archives is in the "core" or not.

And TCL should *never* become like either of these. There is great
benefit IMO, to the extension model, to the segregation from the core, and
to a definable solid subset [the core] that is more then just a set of
semantics.

However, the present state of affairs is also, IMO, suboptimal. That a
library of functions or (in the case of TCL) binary extensions should be
well organized, ubiquitous and easy to reference does not imply that they
should be blended into the language to the point you suggest.

TCL is on the right track. TCL needs to make it easy to *supply*
compliant extensions rather then, as with Python and Perl, ensuring they
are supplied along with the core language. But agree with the sentiments of
others that not enough is done along these lines, and that the present
course is not good enough of a plan.

> Strangely
> enough, the objection to using "extensions" seems to come
> most strongly from those that use only the packaged distributions
> that have them. Those that build from source and therefore
> might not have the common extensions also seem not to have
> a problem with getting the extensions and building them.
>
> In short, where did you get the distribution that is missing
> the pieces you complain about?
>
> There appears to be a fairly widespread misconception that
> extensions are second-class code.

Some are, but that's another story, and not the responsibility of the TCT.

> There are a number of
> reasons that a piece of code may be an extension rather than
> part of the Core, most of which have nothing to do with
> the quality of the code or the availability of support.
>
> * The extension is released under a different license.
>
> The Tcl Core license has been agreed to by a great many
> contributors over the years. Even if we wished to license
> the core differently, we would have little hope of tracking
> down all the rightsholders and securing permission. Hence,
> code attached any license like the GPL that demands that
> all code linked to it bear the same license simply cannot
> go into the core. (Example: mpexpr, Img)

And it is one of TCL's selling points. Look, Stallman and his GPL have
accomplished a lot, but there are detriments to it, especially when you
are looking to redistribute software. The BSD license is, IMO, the
premier Free Software Licence.

I don't think the GPL needs to sound the deathknell for an extension,
either. A set of well defined standards would be beneficial. I
understand that this is what TEA and such-and-such are for, but I'm not
just talking about the engineering side of the question. The extension
interface remains too murky for many, and obtaining and installing an
extension is still too much work/bother/complication for many potential
users.

CANTCL is a step in the right direction; so are starkits and the
distribution model there. However, *neither* are definitive and neither
solution is adequate in itself.

> * The extension is relevant only to a single product such
> as a third-party database.
>
> There are a lot of extensions that serve simply as "glue"
> to attach Tcl to third-party products. These glue modules
> would simply clutter the core for those that don't use them.


Indeed. "Where do I get it?" won't be much of a problem for these people
anyway, as they would expect to have it supplied by the vendor of the
product addressed.

> An exception is made for a very few Windows-specific extensions
> without which it's insanely difficult to deal with Windows at
> all.


> * The extension maintainers have never proposed it for
> inclusion.
>
> The TCT doesn't simply grab other people's code and shovel
> it in. Since everything "in the core" is under the TIP
> process, it's understandable that the maintainers of an
> extension may want a different process for deciding on
> its API and may want to maintain a different release cycle.
> Moreover, we TCT'ers don't *want* to have to vote on
> API changes to all the extensions!

And I agree - there is no reason why these things should enter the core.
But there seems to be a mentality among some in the TCL community that
things must either be black or white, and if they're not black, then
surely they must be white. This is not always (or even often, IMO) the
case. And the fact that pumping extensions into the core is indeed not a
good answer *does not* alleviate the original problems that the suggestion
was attempting to address. And there are many other solutions, that can
be applied at different intensities, and together can chip away at the
larger problem.


> * There's nobody to do the work.
>
> There are a lot more feature requests than implementors.
> Sorry.

Tendering "Official Approval" isn't a fraction of the work of "Officially
Supporting" a particular implementation of a particular extension, yet no
such approval system exists. Such a system would almost certainly provide
for a higher level of extension conformity without the proportional
increase in workload. The concept is used throughout industry and
computing with good success.

Even providing a compatibility reference framework (a chart, in the most
rudimentary form) for software and extensions would help match up users
with tools would help the current situation. Not a "fix-all" but another
"stepping-stone".

Coralling extension writers, providing them with a sub-community of
their own that addresses their particular focus and supports their needs,
and channels their energies in a unified direction. Again, not a
"fix-all" but another "stepping-stone".

> I'm willing to listen here. I really have had trouble understanding,
> though, just why it's a problem that "the extensions aren't in the
> core."

I don't think that this is the problem either. I think one needs to read
between the lines a little bit to percieve the underlying problems behind
people's complaints. This is why I'm willing to beleive that you honestly
don't understand the origin of the complaints.

> It was a serious problem until 7.3; 7.4 fixed it, and 8.1
> did an even better job at it. Is this another case where the world
> is laboring under the belief that Tcl still has a problem that we
> fixed ten years ago?
>

No, my opinion is that the problems are real and they are current. I have
tried to put forward some convinving arguments. I think that too much of
this is put by the wayside by the TCL community. The TCT wants to
[rightly] focus on engineering issues, yet seemingly doesn't want anyone
else to address any of the other issues facing the promotion, improvement and
survivability of a language in an age when languages are a dime-a-dozen.


I honestly don't think that those charged with the actual engineering and
design of a language are the best people to be shaping its direction in
other areas, defining packaging requirements, supporting extension
writers, handling PR, promoting usage, or any of the other ingredients of
success that in most companies would have their own department.

Marc Spitzer

unread,
Apr 16, 2004, 1:47:43 AM4/16/04
to
dav...@dedasys.com (David N. Welton) writes:

> lvi...@yahoo.com writes:

>> 5. Will this effort specifically ignore all extensions and
>> applications which currently are not changing or supported? If not,
>> then who will be taking on the responsibility for managing all this
>> code?
>
> Maybe we can leverage some momentum to update a few of the cruftier
> ones. Maybe that's optimistic, but a little of that never hurt
> either:-)

Just to put in my 2 cents here, the first version does not have to
be great(it would be nice) but better. I was thinking something like
CPAN or the *BSD ports collection, centeralized regestry of supported
packages that will recursivly make/install things they need. You can
down load a full version of the ports tree and keep it current with
CVS. Both are successful projects after all.

marc

Arjen Markus

unread,
Apr 16, 2004, 2:50:59 AM4/16/04
to
"Gerald W. Lester" wrote:
>
> Cameron Laird wrote:
> > In article <407E965B...@acm.org>, Kevin Kenny <ken...@acm.org> wrote:
> > ...
> >>The fact that Twisted requires
> >>so few lines of code in Python suggests to me that it would not
> >>actually be that hard for a committed group of Tcl'ers to build
> >
> >>from spare parts that we've already on the shelf. I am acutely
> > ...
> > Twisted is actually quite a substantial module; maybe
> > I'll make time to report on its line count. The biggest
> > value it provides is to expose what Tcl has in the core:
> > nicely-programmable event-oriented TCP/IP.
>
> So what does it have in this area that Tcl does not - packet oriented items
> like UDP?
>
> > A close second
> > is that Twisted packages high-quality protocol interfaces
> > for SMTP, DNS, and a bunch of other services.
>
> Please compare and contrast against Tcllib's SMTP, DNS, etc services.
>

This sounds to me like a "partia contra toto" problem (*):

- Apparently Python advertises a large single module, Twisted, that
does all that you need. So: Python offers you a total solution.

- Apparently Tcl offers you the various parts of its equivalent to this
module,
as, well, parts. So: Tcl offers you the building blocks.

What seems to be missing in the information that the Tcl community gives
to
the outside world is this bigger picture. Both a matter of perception
and
of a lack of documentation.

I am not the person to write such documentation, as I know very little
about these matters. But to me the real problem is:

We have all these wonderful parts, how do we combine them into
some useful bigger building blocks that people can use "out of the
box"?

Regards,

Arjen

(*) okay, I did learn Latin at school and like to show that ;) -
it is a paraphrase on a figure of speech known as "pars pro toto".

Andreas Leitgeb

unread,
Apr 16, 2004, 4:15:36 AM4/16/04
to
Gerald W. Lester <Gerald...@cox.net> wrote:

> Andreas Leitgeb wrote:
>> PS: I don't see, how the existence of one particular object-model
>> in the Tcl-core would necessarily thwart any other. It might
>> however result in alternative object-systems having to replace
>> the global command "class", or simply use different command-names
>> themselves ...
>
> Because then other packages could not rely on the "core" OO being there to
> work.
I think you misunderstood me:

Say, if OO-system "X" is selected as the future primary firstclass
OO-system for tcl, and package "P" was written for OO-system "Y",
then it would have to be adapted as to not assume global "class" be
Y's class, but explicitly use ::Y::class instead.

If it assumes, that ::class is the same as ::Y::class, then it is
already broken, by forcing the user of that package to use OO-system
Y exclusively (and thus be unnecessarily incompatible with unrelated
packages that chose to use yet another OO-system Z).

> Thus you are back where you have to use all of one (and know which packages
> use which ones) or never use anything but the "core" -- guess which one
> will happen.

Any package using OO-systems Y,Z,... would (and should even now)
access their OO-systems in a qualified way.

If one OO-system gets appointed, then future packages could rely on
that one in the core, or explicitly demand a certain one to be
extra installed (as it happens now).

Andreas Leitgeb

unread,
Apr 16, 2004, 5:35:00 AM4/16/04
to
lvi...@yahoo.com <lvi...@yahoo.com> wrote:
> This thread has now moved into the "define a Batteries Included distribution"
> phase.

The "Batteries-Included distribution" is the subject of the oldest,
still-draft TIP (except for the meta-TIPs).
--> <http://www.tcl.tk/cgi-bin/tct/tip/12.html>
Btw, that TIP was written in response to a similar "goodbye TCL" posting.

From the intestines of this chocolat-easter-bunny I can clearly
read, that the first release of this BI-distribution will coincide
with hurd-1.0 ...

David N. Welton

unread,
Apr 16, 2004, 5:47:05 AM4/16/04
to
Michael Schlenker <sch...@uni-oldenburg.de> writes:

> Tcl has two competing groups in the discussion: The embedders that
> are concerned about startup time, library size, memory footprint and
> things like that on the one side, the
> "batteriers-included-huge-stdlib-in-the-core" fraction on the other
> side.

> Those targets are impossible to reach at the same time.

> So instead of making it a problem, try to create a virtue.

> a) Let the embedders factor out as much functionality as possible from
> the core into a modular stdlib

> b) Let the batteries group add as much useful functional as required
> into a modular stdlib

Very well put.

> In my point of view the stdlib should consist of those fundamental
> extensions one can built on. Most C extension that define their own
> stubs table probably fall into this category.

> A primary example is the current tcllib. Many of the modules inside
> existed before, where coded before and just adopted for tcllib, some
> are entirely new. Inclusion in tcllib led to a minimal coding
> standard (code, docs, testsuite), a documentation in a unified
> format, easy installation, tests on many platforms, more eyes to
> look for and fix bugs, and last but not least much higher visibility
> of those modules in the community.

Once again, spot on.

> A huge benefit for a standard library is the infrastructure. It's
> hard to create a good build system, its much easier to adapt an
> existing one.

> If i would have to formulate criteria for selection of extensions to
> form a Tcl stdlib, i would choose things like the following:

> - Integrated, cross platform build system (TEA or better)
> - Useful documentation, probably doctools based
> - Stubs enabled if at all possible
> (sometimes hard or near impossible to achieve)
> - Export their own stubs table if their functionality could be useful
> - BSD license
> - Provides fundamental extra functionality (Thread, msgcat, XML, ASN1,
> TclX/Registry/ffidl/Twapi, KBK's localized clock, Datastructures, One
> or more OO-Systems, RPC-Support, TLS/Crypto,... )

Sounds like a good place to start. So, what shall we call it?
tclstandardlib? tclstdlib? Let's start a wiki page for it, and after
that maybe we can create a SF project and start putting code in it.

What will our policy be regarding:

1) Tk code - do we need a separate tkstandardlib in addition to
tclstandardlib?

2) How self contained do packages need to be? In other words, what to
do about things that depend on or interface with (potentially)
large external systems. Examples like Img and database drivers
readily come to mind.

Clipped the rest of the post, but... <aol> :-)

Adrian Bowen

unread,
Apr 16, 2004, 6:58:24 AM4/16/04
to

"Iain Findleton" <ifind...@yahoo.com> wrote in message
news:n5zfc.33059$VA1.1...@weber.videotron.net...

>
> Tcl is a string substitution language ...
>

My sentiments exactly. That's what made me laugh out loud with pure delight
when I first encountered it about ten years or so ago, it was such a
beautifully clever, simple, original and elegant idea. Plus the library was
small enough and portable enough to link in to anything you happened to be
writing, and (joy of joys) the source itself could be used as a master class
demonstration of 'best practice' in coding style.

As I recall the original goal for Tcl was to be a lightweight 'glue'
language for driving scriptable subsystems, and to be honest that is how I
have used it ever since. It embodies control flow and variable management,
which is (in my view) all it needs. I appreciate that it is possible to
write quite large software modules in Tcl, but I have never quite understood
why one would want to, apart from as a demonstration.

OK, OK, I've read the Expect book, and I can see there might be some valid
reasons. But for me, Tcl is Tcl, and not the extensions written in it. There
are plenty of things that can do what the various extensions do, but nothing
is quite like Tcl.

Adrian

David N. Welton

unread,
Apr 16, 2004, 7:03:33 AM4/16/04
to
"Adrian Bowen" <rap...@gotadsl.co.uk> writes:

> As I recall the original goal for Tcl was to be a lightweight 'glue'
> language for driving scriptable subsystems, and to be honest that is
> how I have used it ever since. It embodies control flow and variable
> management, which is (in my view) all it needs. I appreciate that it
> is possible to write quite large software modules in Tcl, but I have
> never quite understood why one would want to, apart from as a
> demonstration.

Because it is vastly more efficient in terms of programmer time to
write the whole application in a scripting language, and add a few
bits and pieces in C, than to write the whole thing in C and add a few
scriptable bits. I think there are times when it's appropriate to do
embedding rather than extending, but doing the initial app in Tcl
itself is a very fast way to get something working.

This wiki page is a bit inflamatory, but captures the idea:

http://mini.net/tcl/9303

Jochem Huhmann

unread,
Apr 16, 2004, 7:27:30 AM4/16/04
to
"Adrian Bowen" <rap...@gotadsl.co.uk> writes:

> As I recall the original goal for Tcl was to be a lightweight 'glue'
> language for driving scriptable subsystems, and to be honest that is how I
> have used it ever since. It embodies control flow and variable management,
> which is (in my view) all it needs. I appreciate that it is possible to
> write quite large software modules in Tcl, but I have never quite understood
> why one would want to, apart from as a demonstration.

There are quite a lot of real world apps which are nothing else than a
few subsystems (user interface, database, some kind of server, data in
files, ...). Tcl often fits in here fine and depending of how much logic
you need to implement these apps can get largish easily. You are right
though that selling Tcl as a general purpose language (is there such a
beast actually?) may fire back. But the transition from "glue some
subsystems together" over to "write an additional subsystem in Tcl" just
happens. I guess there are many apps that actually outgrow what Tcl was
meant to be, but often these apps would never have been written to begin
with if not in Tcl and rewriting them in another language isn't
worthwhile, too.

I see Tcl much more in the same tradition as Unix shell scripts. It has
its uses and it will stay around for a long time. I don't see the point
of comparing it with Python at all.


Jochem

--
"A designer knows he has arrived at perfection not when there is no
longer anything to add, but when there is no longer anything to take
away." - Antoine de Saint-Exupery

lvi...@yahoo.com

unread,
Apr 16, 2004, 8:06:59 AM4/16/04
to

According to rob loggia <der_p...@killspammers.com>:

[I dropped the wonderful preceeding discussion, not because I disagreed with
with points in it, but because I want to focus on these remarks...]

:No, my opinion is that the problems are real and they are current. I have


:tried to put forward some convinving arguments. I think that too much of
:this is put by the wayside by the TCL community. The TCT wants to
:[rightly] focus on engineering issues, yet seemingly doesn't want anyone
:else to address any of the other issues facing the promotion, improvement and
:survivability of a language in an age when languages are a dime-a-dozen.

I'm uncertain why you believe that the TCT doesn't want anyone else to
address any of the other issues. The TCT has practically begged the
community to get to their feet and become involved for years. They
have asked for people to write code, documentation, file bug and
feature requests, write test cases, write demo programs, volunteer to
work on http://www.tcl.tk/ , organize wiki pages, contribute information
on wiki pages, attend conferences, etc. And there are many people who
participate in this way.

When people see other issues they feel need address, I want to encourage
those people to become involved in the process of setting the issue through
to resolution. Understand that one developer CAN make a difference, by
investing their own time and talents and finding others with similar
interests and comittment to seeing that the positive changes that are
needed occur.

:I honestly don't think that those charged with the actual engineering and


:design of a language are the best people to be shaping its direction in
:other areas, defining packaging requirements, supporting extension
:writers, handling PR, promoting usage, or any of the other ingredients of
:success that in most companies would have their own department.

:

Then please, help us find the right people and help us convince them to
contribute back to the community by taking on these tasks.

lvi...@yahoo.com

unread,
Apr 16, 2004, 8:10:50 AM4/16/04
to

According to Steve Lidie <lu...@Dragonfly.cc.lehigh.edu>:
:Tcl [...]
:needs one supported, built-in, OO mechanism, Look at the

:source code for Tcl/Tk, it's the best, most readable, easiest to
:maintain, C code I've ever seen.

Do you agree that for tcl to move towards this goal, the community should
also be aware that not everyone agrees on an OO model, and so the result of
this action should be such that other models are not eliminated?

Is it your believe that such a mechanism has to be inserted pervasively
though all the existing core code? Basically, that Tcl has to be redesigned,
so that said support is "built-in"?

lvi...@yahoo.com

unread,
Apr 16, 2004, 8:29:20 AM4/16/04
to

According to Michael Schlenker <sch...@uni-oldenburg.de>:
:Tcl has two competing groups in the discussion: The embedders that are
:concerned about startup time, library size, memory footprint and things
:like that on the one side, the
:"batteriers-included-huge-stdlib-in-the-core" fraction on the other side.


I tend to think of Tcl having this set of groups:

1. a large group of proposers of many various changes/improvements/fixes to tcl
2. a relatively small group of implementors of changes/improvements/fixes to
tcl, done typically individually, in their spare time.
3. an even smaller group of maintainers of the core, who have as a job
making certain that the code that goes in 'does no harm'.
4. the smallest group - the Tcl Core Team - who take a look at the TIPs
(Tcl's equivalent of the Request For Comment), and provoke
discussion over alternative methods of achieving the goal in
question, help refine the proposal, and, finally, approve the
incorporation of the work of groups 2 and 3 into the core
distribution.

Discussions such as this tend to stall because the number of people in
group 1 is so much larger than the number in group 2 and 3 that the
ideas just languish.

It isn't that these are terrible ideas. It is a supply and demand issue -
the demand for functionality is greater than the supply of developers.

So, the community is faced with alternatives such as needing to get
more of the people in group 1 to develop enough interest or need to
make the transition to group 2 or 3.


:Please raise your hands if one of you really contributes to TEA in any

:way, afaik most work is done by Jeff Hobbs, no good docs for TEA are
:ever written (due to lack of time), no test suite for TEA compliance
:exists, basically no Tools for creation of TEA config exist (TEApot is
:an exception, but probably not up to date).

:This is explicitly not about a binary extension repository or something.

:That would be nice and a natural extension to this, but without the
:basic problems solved, we shouldn't even think aloud about a binary
:repository.

This is great! Here's an example of some work that people could become
involved with and not have to worry whether they can write pretty enough
code.

What such a effort would take would be help from technical writers as
well as some people familar with designing software configuration
managment. Also valuable will be input from developers who have
attempted to use TEA (both successfully and unsuccessfully) as well as
from people who attempt to build said packages.

David N. Welton

unread,
Apr 16, 2004, 8:42:14 AM4/16/04
to
lvi...@yahoo.com writes:

> 1. a large group of proposers of many various changes/improvements/fixes to tcl
> 2. a relatively small group of implementors of changes/improvements/fixes to
> tcl, done typically individually, in their spare time.
> 3. an even smaller group of maintainers of the core, who have as a job
> making certain that the code that goes in 'does no harm'.
> 4. the smallest group - the Tcl Core Team - who take a look at the TIPs
> (Tcl's equivalent of the Request For Comment), and provoke
> discussion over alternative methods of achieving the goal in
> question, help refine the proposal, and, finally, approve the
> incorporation of the work of groups 2 and 3 into the core
> distribution.

> Discussions such as this tend to stall because the number of people
> in group 1 is so much larger than the number in group 2 and 3 that
> the ideas just languish.

Sure, it's a problem common to a lot of open source projects, not just
Tcl.

It would be really interesting to find some metrics for this and
measure how many blabbers, casual committers and hard-core developers
different projects have. Something worrying about Tcl is that I don't
see too many people moving along that chain to add more to the
project.

I wonder if there is anything that could be done differently to move
people along in this chain from talkers to helpers to more involved
coders. It is a path that people manage to walk in other projects.

One way might be

tcllib->stdlib->tcl itself

Just thinking out loud...

lvi...@yahoo.com

unread,
Apr 16, 2004, 8:43:59 AM4/16/04