Goodbye TCL
Ed Suominen
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
[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
> 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
>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
> 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
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
> 1) In Tcl, extensions are not considered part of the language.
>
> are inside Tcllib, that is not considered part of the language
> itself.
>
> 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
> 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
> 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
Kevin Kenny
> 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
> 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.
Michael
David N. Welton
> 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
> 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
> 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
> 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
>>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.
>
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
> 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
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
>
> 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.
Andreas Leitgeb
> 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
> Sorry my bad English.
Oh, was going to say that it's nice to see someone here from the same
CS Dept as me ;->
Steve Lidie
>> 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
>> 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.
Iain Findleton
...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
> 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
> 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
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
> 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
:> 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
> 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
> 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
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
> 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
>...
> 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
> ...
> 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
>> 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
.
.
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
.
.
.
>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
> 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
"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
> 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
> 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
> 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
>
> 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
> 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.
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
> 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
> 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
"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
> 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:
Jochem Huhmann
> 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
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
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
According to Michael Schlenker <sch...@uni-oldenburg.de>:
:Tcl has two competing groups in the discussion: The embedders that are
: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
> 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
According to Marc Spitzer <mspi...@optonline.net>:
: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
So then this suggestion - with which I fully agree - is that the only
extensions to go into this library are to be submitted by a current
maintainer of the software.
What should happen when an extension maintainer 'disappears', retires from
maintaining, etc.?
It seems to me that, like CPAN, some sort of extension status is needed
anyways. The status would apply to each version of an extension that
is added to the repository. An extension status might be:
'alpha' (this is code I want people to try, but I know doesn't
work right yet, and in fact the interface probably will
change if I didn't get things wrong)
'beta' (the interfaces here are frozen unless there is some
emergency; code is making its way towards release,
but some bugs may still remain)
'production' (a milestone has been reached, code is being packaged
as 'production use quality')
'maintenance' (this release includes bug fixes and new functionality
which does not create any incompatibilities with
the production release)
'frozen' (this release no longer has a maintainer, and is provided
only for historical purposes).
'withdrawn' (this release was found to be flawed and should not
be used)
There may be other status values that make sense as well
Volker Hetzer
<lvi...@yahoo.com> schrieb im Newsbeitrag news:c5oiga$apj$2...@srv38.cas.org...
>
> 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?
looks like that matters.
> 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"?
I think that with
1) locally scoped procedures
2) some mechanism to associate clientData on the tcl level
most of the prerequisites for OOP would be done with the only user visible
change being two options (-local, -clientData ...) for the proc command.
Lots of Greetings!
Volker
Volker Hetzer
<lvi...@yahoo.com> schrieb im Newsbeitrag news:c5okef$eif$2...@srv38.cas.org...
> So then this suggestion - with which I fully agree - is that the only
> extensions to go into this library are to be submitted by a current
> maintainer of the software.
>
> What should happen when an extension maintainer 'disappears', retires from
> maintaining, etc.?
for over a year, the package should be called desupported.
Lots of Greetings!
Volker
Michael Schlenker
> 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.
Most Open Source projects develop this inverse pyramid of workforce. But
that isn't really the point here.
Tcl has a certain amount of workforce available. Increase of this
workforce is probably good and what you propose.
My observation looks at two proposed solutions to make Tcl more popular:
a) Shrink the core to compete better with embedded languages like LUA
and Forth, enhancing the popularity in Tcl's native domain
b) Enlarge the core to compete better with batteries-included style
languages like Java, Python, Ruby, Perl
I think, get both, install a kind of satellite collection around the
core, modules that are directly available, unless your in an embedded
environment and know what you want.
Michael
Kevin Kenny
> 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.
Yes, indeed! Alas, it's a problem that I don't know how to fix.
I'm a pretty fair programmer, but a terrible marketeer. :(
And you're entirely right that:
> Clearly *something* is less then optimal if this same
> line of discussion keeps arising.
Indeed. But I've seen enough of it to be fairly confident that it's
a marketing problem rather than an engineering one. (Or if it's
an engineering problem, it's something utterly trivial.) And I don't
know how to overcome the perception that Tcl has not done anything
in the last ten years.
Rob went on to say:
> Unfortunately [ActiveTcl] is not the TCL core, it
> comes with restrictions, anf it
> is not what people *should* think when they reference TCL.
Hmm, the additional restrictions of the ActiveTcl license never
really troubled me, since all of ActiveTcl is actually built from
the open source. If I'm packaging to redistribute, I can always
go back to original sources. But I get your point.
> 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.
Inadequacies can be addressed by engineering; the assertion that
"neither is definitive," however, is troubling. Again, I'm a
dreadful marketeer, so I'm a terrible person for convincing the
community that something is "definitive" -- and what is definitive
is defined by what the community accepts.
> 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.
I'd prefer not to get the TCT involved into blessing certain extensions
and not others. Even auditing that the damned things build and pass
their regression tests on all the platforms is a fair amount of work.
If there are volunteers interested in taking on the job of performance
testing, I'd be happy to come up with the "Good Tcl Housekeeping Seal of
Approval," and I'm sure that I could argue the rest of the TCT into
agreeing with me.
> 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.
What on Earth gives you that idea? We've practically begged for help
with advocacy, documentation, publicity, packaging, release integration,
repository management, and all the onerous tasks that engineers are
notoriously bad at. We just seem to be really, really bad at
attracting the people that are good at it. We suffer, I fear, from
the lack of a Charismatic Leader. (And from the fact that another
community's Charismatic Leader has labeled us "parasites.")
> 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 [...]
Amen! But we're asking for help, and in the meantime trying to make do
with the people we have.
--
73 de ke9tv/2, Kevin
David N. Welton
> rob loggia wrote:
> > 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.
> Yes, indeed! Alas, it's a problem that I don't know how to fix.
> I'm a pretty fair programmer, but a terrible marketeer. :( And
> you're entirely right that:
> > Clearly *something* is less then optimal if this same line of
> > discussion keeps arising.
> Indeed. But I've seen enough of it to be fairly confident that it's
> a marketing problem rather than an engineering one. (Or if it's an
> engineering problem, it's something utterly trivial.) And I don't
> know how to overcome the perception that Tcl has not done anything
> in the last ten years.
Problem Number One is probably the web site. It's badly out of date
and not well maintained.
Is that because no volunteers are available? I know I don't have a
lot of time for it, and it's maybe hard for people to pick a place to
get started.
If so, maybe we should reduce the contents to a manageable size?
Is it because it's too hard to do anything with it and only people
with intimate knowledge of it can affect changes?
If so, maybe we should consider simplifying the functionality?
Is it worth starting over from something small and simple, copying
from the old one?
Can anyone really promise much time to do much about it? I like Tcl a
lot and have a tendency to try and get involved in too many
things... this is one where I think I can't make a big commitment to
it, because it's not a small weekend project.
Don Porter
point:
David N. Welton wrote:
> 1) Tk code - do we need a separate tkstandardlib in addition to
> tclstandardlib?
No you don't.
A separate package collection may have made some sense when Tk
meant wish, and you'd have one package collection "for tclsh"
and another "for wish".
Nowadays, Tk is always just a [package require Tk] away, so dependency
on Tk is not fundamentally different from dependency on, say, msgcat.
Is anyone proposing a msgcatstdlib for just those package that make
use of msgcat to do localized messages?
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Donal K. Fellows
> I think, packages should have a lifetime. If no developer visits the package
> for over a year, the package should be called desupported.
Sometimes nobody edits code for ages just because there isn't much if
anything that needs doing. :^)
Donal.
Marc Spitzer
> According to Marc Spitzer <mspi...@optonline.net>:
> :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
>
> So then this suggestion - with which I fully agree - is that the only
> extensions to go into this library are to be submitted by a current
> maintainer of the software.
Well they are submitted by someone, BSD ports tree.
>
> What should happen when an extension maintainer 'disappears', retires from
> maintaining, etc.?
leave it alone it should still work, when/if it stops working mark
it as broken.
>
> It seems to me that, like CPAN, some sort of extension status is needed
> anyways. The status would apply to each version of an extension that
> is added to the repository. An extension status might be:
> 'alpha' (this is code I want people to try, but I know doesn't
> work right yet, and in fact the interface probably will
> change if I didn't get things wrong)
> 'beta' (the interfaces here are frozen unless there is some
> emergency; code is making its way towards release,
> but some bugs may still remain)
> 'production' (a milestone has been reached, code is being packaged
> as 'production use quality')
> 'maintenance' (this release includes bug fixes and new functionality
> which does not create any incompatibilities with
> the production release)
> 'frozen' (this release no longer has a maintainer, and is provided
> only for historical purposes).
> 'withdrawn' (this release was found to be flawed and should not
> be used)
>
> There may be other status values that make sense as well
that I do not really care about too much in the system, it could be
defered to the package as an optional bit. Scotty3 is "alpha" code
the last time I looked and it is anything but. I would be more
interested in getting a way of making binary packages from the
source, not just get it installed on one box after compiling. TCL
already does most of this since different versions of most packages do
not step on each other. In all this I am thinking more along the lines
of BSD's ports tree. And also centrally hosting a precompiled set of
packages for various OS's in one place that is more or less up to date
for a given OS, ie /pkg/binaries/OS/tree_of_compiled_packages
that you can just grab and install along with dependancys.
I think one goal of the system is that it should help answer the
"I need a ..." question that people keep asking. They just go to
a web site and brows or poke around in their local copy to see
whats there.
marc
Marc Spitzer
just leave it alone until it breaks then mark it broken, Scotty3 has not
been touched in a long time but it still works so why discourage people
from using it?
marc
>
> Lots of Greetings!
> Volker
Ville Vainio
>> 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)
rob> And it is one of TCL's selling points. Look, Stallman and
rob> his GPL have
It's hardly a selling point, because the competitors are taking the
same route. All the code in Python standard library is under the
Python license, which is as free as BSD.
A language that bundled with GPL libraries would be widely shunned,
and would probably change the license sooner or later.
rob> are looking to redistribute software. The BSD license is, IMO, the
rob> premier Free Software Licence.
Agreed.
--
Ville Vainio http://tinyurl.com/2prnb
Michael Schlenker
> Not much interested in all the blah blah blah. But on one technical
> point:
>
> David N. Welton wrote:
>
>>1) Tk code - do we need a separate tkstandardlib in addition to
>> tclstandardlib?
>
>
> No you don't.
>
> A separate package collection may have made some sense when Tk
> meant wish, and you'd have one package collection "for tclsh"
> and another "for wish".
>
> Nowadays, Tk is always just a [package require Tk] away, so dependency
> on Tk is not fundamentally different from dependency on, say, msgcat.
>
Agreed. It's basically a dependency tree and a large class of packages
has a dependency on Tk. So one could think about separating those,
because some people only want the Tcl part (or the Tk part), but in
general Tk is just another extension (and could be moved to the stdlib
too for a really radical statement, but it is a special extension
because it's governed by the TCT).
Michael
Donal K. Fellows
> most of the prerequisites for OOP would be done with the only user visible
> change being two options (-local, -clientData ...) for the proc command.
I think you'll actually find that those options are not necessary. If
you use the ensemble support in 8.5, you model your object as an
ensemble command, and you use the advanced features of the 8.5 ensemble
code to add an argument to each "method" that identifies the object to
the method's implementation procedure (which might be an index into an
array that holds the state or something.) It should be pretty easy to
wrap that up neatly, and the ensemble engine would itself provide both
the hiding and the per-object data control. Add in 8.4's command traces
so you know when to delete the object's state, and you will find that
Bob is your uncle.
Donal.
Donal K. Fellows
> 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.
Easy. [incr Tcl] needs to be buildable without [incr Tk] or iWidgets.
We also need to agree how/where that code is going to be stored in CVS.
Everything else can be fixed further down the line.
Donal.
Phil Dietz
TCL still doesn't have a standard database API in the core yet....
David N. Welton
> Forget OO... TCL still doesn't have a standard database API in the
> core yet....
That could go in this lib too. nstcl and DIO are probably the
contenders here.
Volker Hetzer
"Donal K. Fellows" <donal.k...@man.ac.uk> schrieb im Newsbeitrag news:c5op54$18n4$1...@godfrey.mcc.ac.uk...
has to press once a year.
Lots of Greetings!
Volker
Volker Hetzer
"Marc Spitzer" <mspi...@optonline.net> schrieb im Newsbeitrag news:863c741...@bogomips.optonline.net...
this in the docs.
Lots of Greetings!
Volker
Volker Hetzer
"Donal K. Fellows" <donal.k...@man.ac.uk> schrieb im Newsbeitrag news:c5oqv8$1a10$1...@godfrey.mcc.ac.uk...
> Volker Hetzer wrote:
> > most of the prerequisites for OOP would be done with the only user visible
> > change being two options (-local, -clientData ...) for the proc command.
>
> I think you'll actually find that those options are not necessary. If
> you use the ensemble support in 8.5,
>you model your object as an
> ensemble command, and you use the advanced features of the 8.5 ensemble
> code to add an argument to each "method" that identifies the object to
> the method's implementation procedure (which might be an index into an
> array that holds the state or something.) It should be pretty easy to
> wrap that up neatly, and the ensemble engine would itself provide both
> the hiding and the per-object data control. Add in 8.4's command traces
> so you know when to delete the object's state, and you will find that
> Bob is your uncle.
I'll definitely have a look at this.
Lots of Greetings!
Volker
Steve Lidie
>
> 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"?
>
First, let me re-phrase "built-in" as "preferred". Built-in implies
many things, one of which is lots of core code re-design, which is not
what I meant when I talked about Tcl's quality C code.
In a previous post in another thread you listed all the OO extensions
available, something like 15-ish. That's a lot. So the demand for an
OO interface is clear, yet they were simple extensions, the core
remained uncluttered. So pick one ;).
But I'd imagine "the one" would take the best features of many, but
you, the Tcl folks, must do that. All I want as a *user* is a way to
do objects when I need/want too. I will not always code using objects
because they're not always required. But when I want to write a Tk
mega-widget, using an object to define and contain it characteristics
and behaviors is surely the way to go, particularly if I want others
to use it.
The key is 1) objects are not required, 2) I can reply on one model
always being available in the standard distribution, and 3) if I want
to use some other model I may freely install that extension and use
it.
But in case #3, be advised that by rolling your own others may not be
able to reuse your work. But that's their choice, which is no
different than today.
Stephen Huntley
> "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
I'm certain that Python is a lovely language with many uses. You're
right saying that since 1994 many new technologies have just worked
out of the box. The gotcha I have encountered is the problems you run
into a year or so down the line, when you want to move to a new
platform, or use an exotic character encoding, or scale up by an order
of magnitude. This is where Tcl has shined for me.
I would be curious to know what is the biggest-capacity Python network
application in use? How does it scale in comparison with AOLServer?
Any ideas?
Roy Smith
blac...@usa.net (Stephen Huntley) wrote:
> I would be curious to know what is the biggest-capacity Python network
> application in use? How does it scale in comparison with AOLServer?
> Any ideas?
How about the one you're using to post your articles -- Google.
Volker Hetzer
"Donal K. Fellows" <donal.k...@man.ac.uk> schrieb im Newsbeitrag news:c5oqv8$1a10$1...@godfrey.mcc.ac.uk...
> so you know when to delete the object's state, and you will find that
> Bob is your uncle.
I don't think, command traces are the thing. Also, I don't think
it's as simple as I had imagined.
Basically, what I'd like to is a function that has a string representation like any tcl
object and takes arguments. Assume, every (really *EVERY*) script has an
args variable:
set X {puts [lindex $args 0]}
then I could say
$X A B C
and it would print "A"
Obviously I could also say
{puts [lindex $args 0]} A B C
So much for the wish list. The problem, of course is, that tcl has no way to
figure out that {puts [lindex $args 0]} is not some stupid command name but a script
meriting special treatment.
Ok, so forget about that thing.
OTOH, what about a single command, called oo which takes the object, the arguments,
sets args (or, ooargs) and there are our objects?
then we could have:
oo {puts [lindex $args 0]} A B C
the object ({puts [lindex $args 0]}) can be passed around,
we could make oo do a concat step in the middle, enabling us to
have [list {puts [lindex $args 0]} A B] as an object and A and B
as the first arguments of ooargs and hey, that's it.
Now the question is, how to do inheritance?
Do we need it?
Any ideas on how to fit it into this oo command stuff?
Also, here's a little prototype implementation I've cobbled together
in half an hour:
proc mkoo {Script args} \
{
set OO [list $Script]
foreach Arg $args {lappend OO $Arg}
return $OO
}
proc oo {Object args} \
{
#Create a temporary function, taking just one argument,
#calles ooargs
set Script [lindex $Object 0]
set FunctionName "This needs some work, possibly a namespace"
proc $FunctionName {args} $Script
#Creates the arglist
set ArgList [lrange $Object 1 end]
foreach Arg $args {lappend ArgList $Arg}
return [uplevel [list $FunctionName] $ArgList]
}
set X [mkoo {puts [lindex $args 0]} a]
oo $X A B C
oo [list {puts [lindex $args 0]}] A B C
So, would a special oo command count as "oo support"?
Lots of Greetings!
Volker
Skip Montanaro
Stephen> I would be curious to know what is the biggest-capacity Python
Stephen> network application in use? How does it scale in comparison
Stephen> with AOLServer? Any ideas?
Off the top of my head I have no concrete examples, but you might want to
skim these pages:
http://www.twistedmatrix.com/services/success
http://pythonology.org/success
http://www.python-in-business.org/success/
http://www.python.org/Quotes.html
http://www.zope.org/Resources/ZopePowered/
I believe people find solutions using the twisted framework scale very well.
There's obviously some significant overlap between those pages (Google, ILM
and NASA pop up multiple times), and clearly not all of them are using
Python to develop large-scale websites but there are lots of interesting
entries in a number of fields.
the-whole-world-isn't-yet-a-website-ly, y'rs,
Skip
se...@fishpool.com
> 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 agree. The confusion is in terminology. By "kernel" I mean what I
get when I load up tclsh. I don't want OO or too much of anything in that.
I do want a core distribution (let's please think of good terms for this...)
with the most useful, working stuff included.
Then, if someone wants minimalism, they can simply remove all the fluff,
or DL a minimalistic version.
Will Duquette
> 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.
Bryan, of course you need and want polymorphism. The thing is, you
get polymorphism for free in Tcl. Every time you write code that
uses "cget" or "configure" on a widget without worrying about
what kind of widget it is, you're using polymorphism.
Salvatore Sanfilippo
>>>>>> "rob" == rob loggia <der_p...@killspammers.com> writes:
>
> rob> And it is one of TCL's selling points. Look, Stallman and
> rob> his GPL have
>
> It's hardly a selling point, because the competitors are taking the
> same route. All the code in Python standard library is under the
> Python license, which is as free as BSD.
>
> A language that bundled with GPL libraries would be widely shunned,
> and would probably change the license sooner or later.
Actually I spent a lot (probably too much) time talking about licenses
with GPL fans, and after some discussion even most of they agreed
that for a language the BSD license is the best choice. The idea's root
is that a language is only incidentally it's implementation, but that is a
crucial part in real-world, you actually want that the language is
used, not to preserve the implementation from companies that
want to do business with it, and so on. So what's the point in limiting
a programming language implementation license to GPL?
And if 50% of all this discussion is about a programming language being
also libraries, probably even libraries should not be BSD for the same
reasons.
Note that I'm not against GPL, I use it because it makes sense for a
lot of projects, but not for programming languages.
Salvatore.
--
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.
Salvatore Sanfilippo
> also libraries, probably even libraries should not be BSD for the same
sorry, typo. It's:
"even libraries should be BSD for the same"
Salvatore
Iain Findleton
CAREFUL! You will let the secret out of the bag! If it became widely
known that Tk is built on an OO design, then there would be nothing to
discuss on the news group. The reaction could be severe! The next thing
that will come out is that:
set MyStruct.address 10
set MyStruct.street "Wonder Lane"
set MyStruct.apt ""
set MyStruct.city "Wonderland"
works! People might then stumble on the fact that one can write:
namespace eval MyClass {
proc A { } { }
...
}
}
and like things. People will KNOW that Tcl is an OO language! The entire
news group will implode! Realizing that there is nothing missing in the
implementation, hordes may take the elevator to the top floor of their
respective work places and hurl themselves into oblivion!
I implore you to guard the inner secrets of the Tcl language closely!
The consequences are just too horrific to all them to become general
knowledge. UNDER NO CIRCUMSTANCES SHOULD YOU LET IT ME KNOWN THAT
MESSAGE IMPLEMENTATIONS ARE POSSIBLE, EVEN TRIVIALLY EASY, USING TCL!!!
Larry Smith
> "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.
Clever - yes. Simple - yes. Elegant - absolutely. Original?
I think not. TCL shows a considerable family resemblance to TRAC. See
http://www.tracfoundation.org/ and in particular
http://www.tracfoundation.org/trac64/handling.htm. Also see
http://www.tracfoundation.org/trac64/procedure.htm for a description
of TRAC's parsing algorithm, then look at Cricket or Tinker to see
how it adapts easily to TCL syntax. http://www.smith-house.org/open.html.
--
.-. .-. .---. .---. .-..-. | Experts in Linux/Unix: www.WildOpenSource.com
| |__ / | \| |-< | |-< > / | "Making the bazaar more commonplace"
`----'`-^-'`-'`-'`-'`-' `-' | Check out my new novel: "Cloud Realm" at:
home: www.smith-house.org | http://www.smith-house.org/books/list.html
Bryan Oakley
You can call it polymorphism if you like. I call it a consistent API.
This is starting to split hairs, though.
Larry Smith
Would you still feel that way if Microsoft adopted your code
and came out with an incompatible version without providing
the source? They actually did this with Kerberos. It was
allowed to languish during the US trial, but it's clear how
they plan to exploit the BSD license to kill free software.
Neil Madden
"Volker Hetzer" <volker...@ieee.org> wrote:
> "Donal K. Fellows" <donal.k...@man.ac.uk> schrieb im Newsbeitrag
> news:c5oqv8$1a10$1...@godfrey.mcc.ac.uk...
> > Add in 8.4's command traces
> > so you know when to delete the object's state, and you will find that
> > Bob is your uncle.
> Ok, I just had a look.
> I don't think, command traces are the thing. Also, I don't think
> it's as simple as I had imagined.
> Basically, what I'd like to is a function that has a string representation
> like any tcl
> object and takes arguments. Assume, every (really *EVERY*) script has an
> args variable:
>
> set X {puts [lindex $args 0]}
>
> then I could say
> $X A B C
> and it would print "A"
>
> Obviously I could also say
> {puts [lindex $args 0]} A B C
This would be an anonymous function (or "lambda"). You might like to look at
some of the pages on the wiki devoted to this:
http://wiki.tcl.tk/519 (Lambda in Tcl)
http://wiki.tcl.tk/11141 (More Functional Programming)
and others linked to from there. The latter page is my own take on doing this.
This is (partly) what inspired me to create TIP 181 "Create a [namespace
unknown] Command" (http://www.tcl.tk/cgi-bin/tct/tip/181). Take a look at some
of the OO-ish examples given in that TIP. Combined with ensembles (which are
very nice), you can do some really interesting things. I'd really appreciate
feedback on this TIP. I don't think it ever made it onto c.l.t. (at least, it
hasn't turned up on my server, while TIPs either side of it have). Some of the
TCT have given me useful feedback and helped hash out the idea, but it still
needs more eyes looking at it to check that it's the Right Thing, I think.
In the absence of everyone agreeing on the One True Object System for Tcl (and I
can't see that happening any time soon), I think there is still quite a lot that
can be done to make writing object systems in Tcl easier. I don't think there is
a problem with people using different object systems. That's an implementation
detail. What would be cool, would be if all these object systems used a common
interface of some sort, so that I can write an object in XOTcl (say) and inherit
functionality from an object coded in Itcl. snit tries to do this, and is one of
the reasons I like it so much. It relies on explicit delegation (rather than
inheritance), and works well with object systems that follow the Tk object
conventions (objects as commands, methods as subcommands, options with
configure/cget methods etc). Occasionally, however, I really would like
inheritance.
As for whether we need OO at all (*), that's a different question, and one I
think is increasingly irrelevant. It may be possible to code large systems
without OO, and may even be better in some ways. However, as a young programmer
who has only recently completed an undergraduate degree in Computer Science, OO
is the prevailing software design methodology right now. That's what new
graduates have been taught. Most of the books, tutorials and software being
written now have an OO slant. If we want new recruits to the Tcl cause, it is
only going to become more important for Tcl to appear to do OO "out of the box".
For most coming from Java, etc, this probably means that there should be a
"class" command in the global namespace in every tclsh, without having to do a
package require. It's ok bundling OO systems with the core (like Itcl) as
packages, but I suspect for many people, unless "class" becomes a core command
(on a par with "set" or "proc"), and unless the core itself is refactored to
make use of this object system, the perception is always going to be that "Tcl
doesn't do OO". I don't know what to do to fix this perception (and it is the
perception which needs fixing).
A lot of words seem to have been spent over this topic over the years. Some
great OO extensions have been written. Tcl programmers are now spoilt for choice
in this area, and it becomes ever easier to "roll your own". However, this
perception remains (that Tcl doesn't do OO). Perhaps we'll never manage to
change that perception. I fear the only way to do it would be to pick one OO
extension and make that the favoured child, and bless it with actual integration
in the core (as ::class or whatever). I don't think that will happen, and I
don't particularly want it to happen (I can't even decide for myself which
system I like the best). So perhaps we just need to accept the fact that we will
never change this perception, and move on?
Snit and stooop are now in tcllib, and so turn up in most of the Tcl
distributions I have seen (Aqua BI, ActiveTcl, linux distros etc). Incr Tcl
might someday actually get bundled with the core. I'd like to see XOTcl in there
too. You can do a lot with [namespace ensemble] in 8.5. The engineering problems
are mostly solved.
To summarize:
1. In order to "impress the kids" and expand Tcl's user population, especially
with new graduates, we need to convince people that Tcl does OO (which it does).
2. Most of these people will want a single officially-blessed, standard OO
system which is "always on" (i.e. ::class is always there) to be convinced of 1.
3. 2 is unlikely to ever happen, and probably would be a Bad Thing.
Perhaps we need a poster campaign and ads on Slashdot? I'm only half-joking...
My two-penneth,
Neil.
(*) Drifting off-topic for this post, but I noticed some comments along those
lines elsewhere in this thread, IIRC.
Bryan Oakley
> CAREFUL! You will let the secret out of the bag! ...
That was an amusing post with a fairly large amount of truth.
Still, much as I believe "OO" development is pretty easy with core tcl
(and do it fairly regularly), I wish there were some built-in
convenience procedures to transition it from "pretty easy" to "obviously
easy".
What I wish for is two new core commands that work something like this:
class Foo {
-background background Background #ff0000
-bg -background
-font font Font {Helvetica}
-whatever whatever Whatever "default"
}
proc Foo::doit {...}
...
new foo myFoo -background red ...
set x [myFoo cget -whatever]
myFoo doit
...
I'd then want [info class foo] to return "Foo", and have [info class]
also know about widgets and images so we could have a single way to
fetch the class of the most common objects. There's some other syntactic
sugar we could add (eg: inside a method we could do something like
"[self] configure ...), but the big effort is in managing the options
and option db.
Yeah, I can do most of that in pure tcl very easily, but the amount of
code to make "myFoo conf -backg #ffffff" work well is relatively large
and distracts one from the real task at hand (that is, writing an app).
That, to me, is the biggest headache in creating pure tcl objects when
starting a new project.
If I thought such a simple object system had a chance of making it into
the core soon, I'd whip up a tcl based implementation post haste.
Note that this wouldn't preclude other object systems. If anything, it
might facilitate the development of other object systems because authors
could concentrate on the interesting bits (inheritance, delegation, etc)
and not have to deal with all of the mundane option handling and such.
Snit and all the other packages might become even more lightweight and
thus, more desireable.
Jean-Luc Fontaine
I'd be interested in finding the sources of Scotty version 3.
Is there a web site?
--
Jean-Luc Fontaine mailto:jfon...@free.fr http://jfontain.free.fr/
Mark Roseman
any other feature, package, etc.) in Tcl?
Approach #1. We make it easy in Tcl for you to take all the things
you already know about and use them right away. See, there's an
object system in Tcl that's automatically there that works just like
what you're used to using in Java [classes, methods, objects,
inheritance, public/private/protected, etc.]. Where things are
different we'll try to make it easy for you to map what you already
know into this new syntax. After you've been using Tcl for a while,
you'll discover that Tcl is so powerful that you can do things in
many different ways, and you may decide you want to explore some of
those options.
Approach #2. Tcl is really different from what you know. You should
understand the Tcl way of doing things from the start. Tcl is so
powerful that there are lots of ways to do things, and its really up
to you to decide what's best for your project. Even better, why not
design your own object system? You can do it!
I'd suggest that gurus, language designers and Tcl veterans
like #2, normal programmers like #1, and we're short of normal
programmers.
I can just see the Slashdot article now. "After 12 years, Tcl finally
gains an official object system as part of the language, but it's
too brain dead to even do inheritance".
Cameron Laird
Phil Dietz <ped...@west.com> wrote:
>Forget OO...
>TCL still doesn't have a standard database API in the core yet....
Was this intended as a contrast with Python?
'Different way to say this: "database", in this sense,
is a dirty subject, in that it's far more tied to grungy
details of specific implementations than the masses
generally realize, or than either Python or Tcl, both of
which prize purity in their own ways, generally support.
A general database abstraction is about as rarefied as a
general GUI abstraction.
--
Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net
Marc Spitzer
here is the location from freebsd's ports tree
ftp://ftp.ibr.cs.tu-bs.de/pub/local/tkined/devel/scotty-00-02-24.tar.gz
and the pkg-descr file:
$ cat pkg-descr
scotty is a tcl extension which allows to set up TCP and UDP
connections, to send various ICMP packets, to query the domain name
system (DNS), to check clock skew using the NTP protocol and to query
various SUN RPC services (like rstat and mountd).
WWW: http://wwwhome.cs.utwente.nl/~schoenw/scotty/
marc
rob loggia
> rob loggia wrote:
>> 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.
>
> Yes, indeed! Alas, it's a problem that I don't know how to fix.
> I'm a pretty fair programmer, but a terrible marketeer. :(
> And you're entirely right that:
I generally think it is true. And there's no shame in being best at what
you're best at, so to speak. Isn't that how its supposed to work? I'm
not saying that it is impossible for programmers to also be visionaries,
business leaders, and even (as you reference below) charismatic leaders.
John Ousterhout is, in my mind's eye, an example of a visionary engineer.
In my estimation, several others in TCL's past and present have this
quality as well.
The recurring "bad habit" of TCL seems always to come on the heels of great
innovation. Ideas are implemented and "put out there" but never fully
harnessed or leveraged. It isn't long before these things are implemented
in other languages with greater success. Before long, people are telling
you something about Python, and you have to tell them TCL already does
that:
"Oh, you mean it does that too?"
"No, I mean that not only does it also offer that, it offered it first"
Often one might add:
"...and implements it better and with clearer source results."
Or:
"...and we have several other ways of doing it too."
TK is the glaring example here. Few if any other languages that could be
said to be in the same genre as TCL offer a native toolkit optimized to
the language itself. Yet most seem to offer some sort of binding to TK.
Will it be long before the average programmer off the grill doesn't know
that TK is native to TCL, just that its a toolkit for his language of
choice?
When one looks at the coalesence of tcllib, onme can see a natrual and
right headed response to the state of affairs I'm discussing. Here, it
was seen that much coding had been done to supply a nice set of non-core
extended functionality. Yet all of it was fragmented and disparate. What
was done with tcllib is an excellent example of that should be universally
done...reorganization, consolidation, integration of an already existing
codebase to strengthen the language in an enduring way.
>> Clearly *something* is less then optimal if this same
>> line of discussion keeps arising.
>
> Indeed. But I've seen enough of it to be fairly confident that it's
> a marketing problem rather than an engineering one. (Or if it's
> an engineering problem, it's something utterly trivial.) And I don't
> know how to overcome the perception that Tcl has not done anything
> in the last ten years.
Well, that is only one of several misconceptions that hurt TCL. Indeed,
that might even be one of the easiest to deal with when you get down to
it. But I agree 100% that the problem of TCL today could be better
characterized as a marketing one then as an engineering one. One might
even say that TCL has an image problem, like a celebrity or politician.
But there are also organizational problems and some technical problems as
well. Most have already been discussed. None are fatal *if* a proactive
stance is adopted.
All are detrimental to the future of TCL - the future ability of the TCL
community to have enough mass to sustain itself. The problem should not
be unfamiliar to students of science. And the BSD licence also exposes
the community to additional dangers despite being, IMO, the best licence
and the one TCL should keep *and* promote.
> Rob went on to say:
>> Unfortunately [ActiveTcl] is not the TCL core, it
> > comes with restrictions, anf it
>> is not what people *should* think when they reference TCL.
>
> Hmm, the additional restrictions of the ActiveTcl license never
> really troubled me, since all of ActiveTcl is actually built from
> the open source. If I'm packaging to redistribute, I can always
> go back to original sources. But I get your point.
They don't trouble me either, in a vacuum. They won't trouble many users,
and that is one reason that a userbase for it exists. I certainly don't
criticize Active State for using it, and agree with the principles of
diversified and strategic licencing the company uses. However, it is *not
enough* for the TCT to supply source and consider their job done.
The core really should include a representative "batteries included" binary
release for platforms for which this is possible. Even if everyone uses
Active State's distribution, the ability to reference something as the
stock "userland" distribution will, IMO, clear up a lot of confusion among
those interested but not yet initiated.
>> 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.
>
> Inadequacies can be addressed by engineering; the assertion that
> "neither is definitive," however, is troubling. Again, I'm a
> dreadful marketeer, so I'm a terrible person for convincing the
> community that something is "definitive" -- and what is definitive
> is defined by what the community accepts.
Actually, I would differ with that definition. I think that the goals and
beliefs, the needs and wants, and the technical direction ought to be
clearly definied by the community, and that this should indeed shape the
direction and implementation of TCL. But I think that what is
"definitive" in a particular area is better defined by what it takes to achieve
success on that particular subgoal.
In the area of packaging, I don't beleive that any technical mechanism
will solve the complete set of equations necessary for a successful
packaging and delivery system. Protocol, integration and compatibility
identification are three areas where a clever update mechanism won't
suffice. I don't want to get off into details at this point, but I stand
by my troubling assertation that the two distribution mechanisms refrenced
are not a definitive answer to the packaging problem by themselves.
All that you need to convince the community of, if indeed this is
something you wish to do, would be that the problems of TCL *must* be
examined from a macro-perspective and progress must continue in a
multi-disiplined way under a charted course. Mobilizing volunteers is
easy *if* stock is taken of who they are and what their contribution might
be, what kind of time they care to contribute, and how structured they
would like their work to be.
TCL has no shortage of manpower, and more would I'm sure collect as
momentum builds. The community just needs to be able to figure out what
this support is and how to harness it. This adds up to much more then
simply a list of maintainers for various collections of code, or even a
voting body.
>> 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.
>
> I'd prefer not to get the TCT involved into blessing certain extensions
> and not others. Even auditing that the damned things build and pass
> their regression tests on all the platforms is a fair amount of work.
> If there are volunteers interested in taking on the job of performance
> testing, I'd be happy to come up with the "Good Tcl Housekeeping Seal of
> Approval," and I'm sure that I could argue the rest of the TCT into
> agreeing with me.
The "Good Tcl Housekeeping Seal of Approval" was the concept I was trying
to get across. If you put the burden on extension builders to show
compliance with a set of well defined standards, then support those same
extension builders and offer incentives to qualify, you will gain much at
a cost that will work out in the end to be very little. I agree that the TCT
itself shouldn't be burdened with this, but it seems that the authority to
make it "official" will need to come, at least initially, from the TCT.
That's one problem - there is not a clear place where one can easily and
quickly gain authority to proceed on a non-technical and specific step
even if it corresponds to a well-defined goal of the community. Further, it is
up to volunteers to innovate - little specific information is held out as
to what is needed by the community and what the work will entail. I've
read the details of the TIP system, and realize there is a mechanism to
accomplish things quickly, but find it a murky solution to the kinds of
problems I've been describing.
>> 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.
>
> What on Earth gives you that idea? We've practically begged for help
> with advocacy, documentation, publicity, packaging, release integration,
> repository management, and all the onerous tasks that engineers are
> notoriously bad at. We just seem to be really, really bad at
> attracting the people that are good at it. We suffer, I fear, from
> the lack of a Charismatic Leader. (And from the fact that another
> community's Charismatic Leader has labeled us "parasites.")
It seems others are saying the same thing. I suggest to you that there is
some kind of disconnect. If this is what is indeed happening, then
people, as you say, aren't getting the message. This in itself is one of
the problems facing the TCL community. Its not getting what it needs
because the call for help is not going out clearly, to the right people,
or with the proper urgency.
A "Charismatic Leader" is always helpful. But in themselves they are often
feared. People resent them, rather then looking at their own qualities
and being proud. So there are advantages but difficulties there too.
However, one need only look at projects like the GNU project, the Linux
Kernel, and hosts of commercial endeavours to see the benefit of a
charasmatic leader. A charasmatic leader often acts as an exponent on the
abilities of the community members, and the output of a community.
But there is much more to it. Advocates and gurus are important for a
programming language - in many ways it is how the torch is passed to the
next generation of programmers that determines whether a language
survives. Sometimes, it is other things, like the language itself.
Personally, I think Richard Stallman *really* hated TCL because he didn't
think of it. TCL is a wonderful language and a remarkable concept. TK as
well. Thats why the advocates and gurus should be well mobilized, not a
collection of "coding cowboys" or a loosly bound voting body. They should
have their talking points and sufficient resources as are available.
>> 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 [...]
>
> Amen! But we're asking for help, and in the meantime trying to make do
> with the people we have.
>
But some of the best people TCL has cannot even best help TCL because they
cannot use TCL during the course of their work, or find themselves in
awkward arrangements involving business obligations. Some find themselves
on the verge of want. The TCL community has the potential to carry some
of its best and brightest, and steps should be taken to bring about
such a state of affairs. Again, the effect on TCL would be exponential.
Those that benefit the most from TCL from the user end of things also
need to be made aware of the needs of the TCL community and the TCT and
how they can help keep the language they love vital and evolving. Those
that want to volunteer but cannot contribute code need to be grabbed a
hold of and put to work. The userbase of TCL applications holds within
it a vast and largely untapped source of fresh volunteers.
I am in the process of determining what my own contribution will be.
There are a lot of factors on which this depends, not the least of which
is the receptiveness of the TCL community. You seem to understand some of
the areas TCL could use help. The best thing you can do right now is to
not let the issue die. Otherwise, it will be another 4 months before the
next wave of the same, seemingly untrue yet endemic complaints about the
"essence" of TCL.
I Think that there are some open minded people on the TCT, and some that
are not. The law of averages would certainly suggest that, and I make
this assessment only based on these people's own public writings - I do
not know any of them personally. I certainly don't seek to offend anyone,
or imply that anyone was doing "a bad job". Rather, I beleive the
enviornment in which TCL must exist has changed, and that this must be
recognized if it is not to become a dead, or a "for-all-practical-purposes
dead" language at some time in the not too distant future. What I hope is
that the pros can adequately convince the cons that something must be
done. Hopefully, I have convinced you to some extent.
rob loggia
> Problem Number One is probably the web site. It's badly out of date
> and not well maintained.
Absolutely true.
> Is that because no volunteers are available? I know I don't have a
> lot of time for it, and it's maybe hard for people to pick a place to
> get started.
They're out there.
> If so, maybe we should reduce the contents to a manageable size?
Without sacrificing useful content, yes. Restructure is probably better
then reduce.
> Is it because it's too hard to do anything with it and only people
> with intimate knowledge of it can affect changes?
>
> If so, maybe we should consider simplifying the functionality?
If this is the case, it needs to be addressed. One problem I've noticed
it has is that no matter how new the information is on the page, it always
looks pretty much the same. I don't mean the consistent l-n-f is bad.
Rather, there is not enough bold content to accentuate the changes in
information. Major bits of news are scarcely distinguished from minore
version releases of obscure extensions.
Furthermore, it should be easy for a programmer to be able to submit an
article and have it published without worrying about HTML or obscure
markup requirements. I'm sure *many* people that don't have the time to
"maintain the website" could quite easily contribute some content...the
wiki is proof of this. The website should offer a more formalized
presentation of new ideas proven in the wiki. Much can be automated, but
some of it will at least need two eyes to keep things in line. But I
guarantee if the structures and needs are defined the help can be found.
> Is it worth starting over from something small and simple, copying
> from the old one?
>
> Can anyone really promise much time to do much about it? I like Tcl a
> lot and have a tendency to try and get involved in too many
> things... this is one where I think I can't make a big commitment to
> it, because it's not a small weekend project.
I think that what you're talking about can be accomplished without even
bothering anyone that doesn't want to help with it. Starting from scratch
might be best, but then the old site should continue to "run 'till
midnight" so to speak, anyway. Even if it take a few people a year to
implement the fully functional works, it is worthwhile. Of course, TCL
should be used wherever possible...showcased wherever possible on the
server and client sides.
rob loggia
>
> 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.
I agree with what you've said, and I stand corrected by two people on the
subject of the request for help going out. Unfortunately, I think the
message is being lost on too many people, and I think that people that are
being mobilized are being mobilized badly by no one in particular.
Again, I have nothing but respect for the people involved with TCL, or
beleive me I'd be doing any number of other things ;-)
rob loggia
>> rob> are looking to redistribute software. The BSD license is, IMO, the
>> rob> premier Free Software Licence.
>
> Would you still feel that way if Microsoft adopted your code
> and came out with an incompatible version without providing
> the source?
Yes. I'm not a sour grapes kind of guy. In my opinion, if you are
releasing or developing something that you intend to be free, then you
should expect others to use it in different ways. I understand why the
GPL needed and in some ways needs to continue to exist. I think it is
more suited to applications then libraries or languages. The LGPL may be
more free, but still creates headaches for the distributor members of the
community. Then there are the obnoxious spam clauses. BSD is, IMO, more
desirable and perfectly acceptable. If someone closes the code, the
copyright is still retained, and therefore others are *always* free to
reopen the code with the sources I released. This, to me, is adequate
protection for the sourcebase from what you describe.
rob loggia
> "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"?
Hello again. Sorry I never got back to you about PMG. Needless to say,
things came up. In any event, You're comments here are absolutely on
point. Please see my reply below to Kevin Kenny. I mention briefly the
problem that you a referencing here. Perception and packaging are major
problems with TCL. There is so much fragmentation that it is no longer
representative of *merely* the healthy boundry between TCL and extensions
that is indeed a positive element to TCL's design.
Unfortunately, I think that the pieces are not in place for an adequate
solution. Certainly, a few radical changes in policy would need to be
adopted. I outlined some of them to Mr. Kenny, as I have read of his
longtime involvement with and contributions to TCL. He wants to see this
language live and stand on its merits in the computing problems of the
future, as I believe do you and many others. Hopefully, a sense of
urgency will take root among enough people to effect change, for what I
envision as a successful strategy could not be imposed and must be
embraced in order to be successful.
rob loggia
> "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.
...until it no longer has enough mass to sustain itself. No one with time
and resources invested in dead languages (and there are plenty examples of
this) meant to get into that jam. TCL could still go this route, and to
belive otherwise would be foolish.
>> 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.
TCL offers MORE then other languages, in my opinion, in so many fields of
endeavor that its laughable. It is so well suited to bind together the
disparate binary pieces that make up todays enviornments...nothing can
beat it here. Its tight integration with TK makes the TCL/TK combo the
most effecient and robust way to utilize the TK toolkit. Easy to learn,
configurable access to GUI programming. This alone puts so much within
reach to even the beginner or casual desktop user.
>> > 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";-)
It does need a facelift, but I wouldn't think it needs a fork. Some
people just need some convincing that things need to be addressed
proactively and a little differently then they have in the past.
rob loggia
>
> 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.
>
Or to define more groups. If you look at the needs of a programming
language, little is addressed by the groups you mention. Merely the
design, testing and production of the language. That was good 10, even 5
years ago. But the climate is changed and changing rapidly. Resources
and time need to be focused in many more directions then the one you
mention. Group 1 has, IMO, plenty of potential energy, but you will not
be able to harness it all by trying to usher these people into groups 2 or
3. I would say that a "Group 5" needs to be created to handle those areas
not within the realm of 2 or 3, and to harness the energies of Group 1
more fully.
rob loggia
> 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.
More important would be to gauge everyone involved with TCL's various
projects, and redistribute energies where possible. More must be done to
solicit, and more must be done to support. And I don't believe it
involves a greater burden foe core coders, but could be a potential load
reducer.
The language would benefit from clear leadership and some measure of
centralization. It would also benefit from a reconsolidation of current
resources. It would also benefit from an image facelift.