How much does TCL cost?
tcl hell
package I had to post the following observation:
TCL is one of the most expensive languages to use. Why?
Even though all of TCL packages are free to download and use, many of
them are not (clearly or at all) documented, hence you have to "pay"
for them with your time, often coming to realization that it would be
cheaper (time-wise) to create your own package than to figure out how
to use someone else's.
Hence, it is cheaper to use another (less powerful, less friendly, not
so exciting etc etc) language that gets code contribution from
developers that have some self-respect and also respect other
developers. It looks like developers that do not document their code
in human readable fashion are the "open source" pretenders. They get
to pretend to be open source supporters while mostly nobody gets to
use their code.
Note that I do not demand to get the code documented but if you
release it to the public, please, have some heart and document it,
with lots of examples.
This probably is the major reason why Tcl has almost no visibility.
Please do not tell me about the tcl.tk wiki or other obscure sources
of documentation. It is all over the place, with packages being
renamed, similarly named, packages that are misnamed (do something
other that you would think they should do) etc. I have been using Tcl
for years and the problem is only getting worse.
Although I am letting off some steam right now, I do hope that this
could spark some genuine desire to change things around and (perhaps
at the upcoming Tcl conference) we could discuss what can be done to
fix it. In my mind this is more important than developing new features
into Tcl. This issue should be considered as a major BUG in Tcl.
Óscar Fuentes
> Having spent countless hours researching how to use yet another TCL
> package I had to post the following observation:
>
> TCL is one of the most expensive languages to use. Why?
>
> Even though all of TCL packages are free to download and use, many of
> them are not (clearly or at all) documented, hence you have to "pay"
> for them with your time, often coming to realization that it would be
> cheaper (time-wise) to create your own package than to figure out how
> to use someone else's.
Please name a popular language that does not suffer from this problem
too.
--
�scar
tcl hell
Hmm, the first one that comes to my mind is PHP, then Python and Perl,
Ruby. Tcl has the worst problem, there is absolutely no question about
it. And I mean that if I have to spend hours searching the Internet to
find out how to use something as simple as XMLRPC in Tcl, that's not
only bad, it is shameful for a modern language. In Tcl, the research
often required is an equivalent of learning how to build a car in
order to learn how to drive a car. Which is insane.
Nick Hounsome
So according to your reasoning I can improve Tcl relative to other
"languages" that you have used by the simple process of writing a lot
of undocumented packages for the other languages! (or by somehow
removing packages that you don't understand from the entire internet)
Conversely, I can make Tcl worse by writing a new, undocumented Tcl
package even though I have no authority for anything to do with Tcl.
Who's insane???
tom.rmadilo
> On Aug 24, 6:28 pm, Óscar Fuentes <o...@wanadoo.es> wrote:
> > Please name a popular language that does not suffer from this problem
> Hmm, the first one that comes to my mind is PHP, then Python and Perl,
> Ruby. Tcl has the worst problem, there is absolutely no question about
> it. And I mean that if I have to spend hours searching the Internet to
> find out how to use something as simple as XMLRPC in Tcl, that's not
> only bad, it is shameful for a modern language. In Tcl, the research
> often required is an equivalent of learning how to build a car in
> order to learn how to drive a car. Which is insane.
There is no reason to use XMLRPC in Tcl. Efficient use of that ancient
protocol requires a typed language.
Use something modern like WSDL. Check out WS::Client and WS::Server
(current url?)) or my tWSDL stuff. Examples:
Examples of the code developers have to write are located at the
service url + index.txt:
http://junom.com/ws/datetime/index.txt
http://junom.com/ws/mywebservice/index.txt
http://junom.com/ws/openacs/index.txt
http://junom.com/ws/stockquoter2/index.txt
etc.
I use working examples as documentation.
Each of the above services also provides a browse feature for all the
code currently running.
You can also test the services using a web form to provide data to
generate SOAP request documents. Each test request is converted into
an actual SOAP request and POSTed back to the server (like a proxy).
Everything you can access at the service url is generated based upon
what is in the index.txt file.
Full code is downloadable at http://junom.com/gitweb/gitweb.perl?p=twsdl.git
(see perl is good for something after all)!
Neil Madden
I sympathise with this point of view. It can be very frustrating trying
to locate a package for a particular problem, and then finding that the
documentation is either non-existent or out of date. Unfortunately, the
effort required to bring such packages up to scratch is quite daunting.
It does happen from time to time -- for instance, the work that
ActiveState (Jeff and Andreas) have done on bringing old packages up to
date and well documented, and making them available in ActiveTcl and the
teapot repository.
More can always be done, but that requires commitment of time and
effort. If everyone could find the time to update a package, or write
new ones, when required, then things would soon improve. However, that's
a big ask. Other languages also suffer in the same way: there are
hundreds of packages for Java and Perl and so on that have fallen into
an unmaintained state. Admittedly Tcl probably has things worse because
there is a smaller critical mass of people prepared to update these
things. It would be sad if people abandoned the language for these
reasons, but if you need a particular package and another language
provides it, then by all means pick the best tool for the job. Specific
notes in comp.lang.tcl also help to galvanise the community: rather than
a general moan (I know it's cathartic), try a post like "ISO: well
documented XMLRPC package" or similar. If nobody has anything
immediately, it might prod a maintainer into updating the documentation.
-- Neil
dkf
> TCL is one of the most expensive languages to use. Why?
>
> Even though all of TCL packages are free to download and use, many of
> them are not (clearly or at all) documented, hence you have to "pay"
> for them with your time, often coming to realization that it would be
> cheaper (time-wise) to create your own package than to figure out how
> to use someone else's.
Half the problem is that the standard of *curated* collections of
extensions is distinctly variable. The comp.lang.tcl FAQ isn't very
good here because it refers to far too many things; I should know
because it refers to things that I just threw out there and which are
definitely not actively maintained or well-documented (at least one
thing I wrote hasn't been touched for over 10 years). The collections
that I *would* recommend are ActiveState's teapot (though there is an
issue there with documentation) and Joe English's Gutter <URL:http://
www.flightlab.com/~joe/gutter/>. In particular, ActiveState are very
good at doing and distributing builds (saving so much effort when
you're developing!), and Joe's been good at linking to documentation
where it exists (and isn't on the main webpage).
I would personally prefer to see examples mainly on the Wiki, since
then they can be added to by the community without needing the package
author to bless them. :-)
Donal.
Gerald W. Lester
> On Aug 24, 6:28 pm, Óscar Fuentes <o...@wanadoo.es> wrote:
>> tcl hell <tclh...@gmail.com> writes:
>>> Having spent countless hours researching how to use yet another TCL
>>> package I had to post the following observation:
>>> TCL is one of the most expensive languages to use. Why?
>>> Even though all of TCL packages are free to download and use, many of
>>> them are not (clearly or at all) documented, hence you have to "pay"
>>> for them with your time, often coming to realization that it would be
>>> cheaper (time-wise) to create your own package than to figure out how
>>> to use someone else's.
>> Please name a popular language that does not suffer from this problem
>> too.
>>
>> --
>> Óscar
>
> Hmm, the first one that comes to my mind is PHP, then Python and Perl,
> Ruby. Tcl has the worst problem,
Having looked in CPAN it is obvious this thread is just troll bait.
--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Bryan Oakley
wrote:
> On 25 Aug, 03:19, tcl hell <tclh...@gmail.com> wrote:
>
>
>
> > On Aug 24, 6:28 pm, Óscar Fuentes <o...@wanadoo.es> wrote:
>
> > > tcl hell <tclh...@gmail.com> writes:
> > > > Having spent countless hours researching how to use yet another TCL
> > > > package I had to post the following observation:
>
> > > > TCL is one of the most expensive languages to use. Why?
>
> > > > Even though all of TCL packages are free to download and use, many of
> > > > them are not (clearly or at all) documented, hence you have to "pay"
> > > > for them with your time, often coming to realization that it would be
> > > > cheaper (time-wise) to create your own package than to figure out how
> > > > to use someone else's.
>
> > > Please name a popular language that does not suffer from this problem
> > > too.
>
> > > --
> > > Óscar
>
> > Hmm, the first one that comes to my mind is PHP, then Python and Perl,
Seeing python on your list makes me chuckle. Within the last few
months I've started using wxPython pretty much full time in a
professional context (not by choice, mind you!) and the documentation
for that package is awful (not to mention the fact that wxPython is
rather buggy). Only part of the wxPython library has any documentation
at all and that's mostly along the lines of "here are the arguments to
that method". Often times the answer to the question "where are the
docs for X" is "read the C API documentation and translate that to
python".
So maybe parts of Python has good documentation, but there are
significant lapses. Much like Tcl and Tk -- the core is exceptionally
well documented but third party stuff is not. I think that's the
nature of an extensible, free system.
Personally, I'd still choose tcl/tk over python every day of the week
and twice on Sundays for most tasks. There are some things to like
about python but, well, that's a discussion for another thread...
Torsten Berg
> TCL is one of the most expensive languages to use. Why?
You don't actually mean Tcl here. Tcl, the language, is well
documented both in manual pages and in printed books.
> Even though all of TCL packages are free to download and use, many of them are not (clearly or at all) documented
This is what you mean: 3rd party contributed packages. I share this
view to a certain degree, but I know from myself how much working a
good documentation is compared to writing the code. What I do is to
only use those packages that are well-documented and well-maintained
and this has worked well. If I find a package I want to use and that
is difficult to understand, then I try to contact the author and ask
for help. If that doesn't work, I abandon the package and try writing
the stuff myself. So, although I can see a point in your post, I don't
share your conclusion:
> into Tcl. This issue should be considered as a major BUG in Tcl.
It is not a bug in Tcl (or Tk or Tile or the core packages or ...), it
is the normal problem of any contributed open source package: time is
limited and is most often invested in coding, not in documentation. So
please, don't blame Tcl, blame all these people, that give away their
packages for free, because they think, these might be useful for
someone.
Torsten
Les Cargill
> Having spent countless hours researching how to use yet another TCL
> package I had to post the following observation:
>
> TCL is one of the most expensive languages to use. Why?
>
> Even though all of TCL packages are free to download and use, many of
> them are not (clearly or at all) documented, hence you have to "pay"
> for them with your time, often coming to realization that it would be
> cheaper (time-wise) to create your own package than to figure out how
> to use someone else's.
>
> Hence, it is cheaper to use another (less powerful, less friendly, not
> so exciting etc etc) language that gets code contribution from
> developers that have some self-respect and also respect other
> developers. It looks like developers that do not document their code
> in human readable fashion are the "open source" pretenders. They get
> to pretend to be open source supporters while mostly nobody gets to
> use their code.
>
I have a 100% successful track
record of finding Tcl extensions by using this newfangled
"Google" thing - if I need http support, I Google "http Tcl"
and presto - there it is.
Compared to what some languages require developers
to go through....
And almost by definition, documentation is never, ever
good enough.
Hope this helps.
<snip>
--
Les Cargill
schlenk
> On Aug 25, 1:08 am, Nick Hounsome <nick.houns...@googlemail.com>
> wrote:
>
>
>
> > On 25 Aug, 03:19, tcl hell <tclh...@gmail.com> wrote:
>
> > > On Aug 24, 6:28 pm, Óscar Fuentes <o...@wanadoo.es> wrote:
>
> > > > tcl hell <tclh...@gmail.com> writes:
> > > > > Having spent countless hours researching how to use yet another TCL
> > > > > package I had to post the following observation:
>
> > > > > TCL is one of the most expensive languages to use. Why?
>
> > > > > Even though all of TCL packages are free to download and use, many of
> > > > > them are not (clearly or at all) documented, hence you have to "pay"
> > > > > for them with your time, often coming to realization that it would be
> > > > > cheaper (time-wise) to create your own package than to figure out how
> > > > > to use someone else's.
>
> > > > Please name a popular language that does not suffer from this problem
> > > > too.
>
> > > > --
> > > > Óscar
>
> > > Hmm, the first one that comes to my mind is PHP, then Python and Perl,
>
> Seeing python on your list makes me chuckle.
Python has a ton of problems with its documentation (even of the
standard library) and constantly struggles with getting its packaging
system right.
Not to mention all the caveats you have to worry about when doing X-
platform stuff in python (it improves in recent versions) compared to
Tcl.
One thing you see a lot in the Python world are those 'just wrap the C-
API' kind of packages, where your fine if you know the C-API but close
to hell when not, as its usually 'read the C-API docs and figure out
the random differences we added yourself'...
Python has some good things to offer though, cheeseshop is nice, you
find a ton of packages for all kind of stuff. But the quality is often
pretty
bad if you try more than trivial stuff.
Seeing PHP in that list is even more funny, the PHP docs and APIs are
usually seriously ugly.
Michael
Lan
I completely sympathize and mostly agree with the OP. I also consider
the observation that other languages have the same problem not
pertinent. My mother would never let me get away with the "everybody
does it" justification.
I'm a great believer in dead-tree books. Tcl/Tk has many quite good
books, but they're all[0] constructed the same: an introduction/
tutorial fleshed out by one or more apps of the author's used as
examples. Another book like that isn't what Tcl needs.
IMO the missing book would be half up-to-date man pages of the core
functions, followed by chapters documenting the major extensions like
tcllib, tile, etc. "Documenting" is the key word here. Also perhaps
tutorials on advanced issues like megawidget creation and design. We
don't need yet another book that devotes a chapter to if, while, and
case and then develops a GUI DVD filer. Those books are important but
we already have them.
I realize that such a book would be quite hard to pitch to a publisher
and would never make its author(s) enough money to justify the effort.
I also realize that I personally am eminently unqualified to write
such a book.
In my dreams I fantasize that the Tcl community and its fine authors
(you know who you are and I'm not gonna point at you) might decide to
work this up as a co-op project. Start with the wiki's material and
the man pages, build an outline, primp and puff, and then offer it to
O'Reilly or such. But dreaming up work for other people is an
unproductive and basically selfish activity.
Did I just write a TIP?
[0] There are exceptions like "Expect" and "[incr tcl]". And of
course, the "Tcl/Tk Programmer's Reference," which dates but remains
one of my most prized computer books precisely because it's man pages
on steroids.
dkf
> I completely sympathize and mostly agree with the OP. I also consider
> the observation that other languages have the same problem not
> pertinent. My mother would never let me get away with the "everybody
> does it" justification.
It's a justification that doesn't let anyone off the hook. It just
increases the number of people that you're sharing the hook with. :-)
It also points out that documentation problems can't be the actual
difference between Tcl and other languages as they're endemic. (Now,
the stupid flamewar with RMS from 15 years ago, that's probably the
key source of the damage. And all his points that had any value then -
I exclude the fact that we're not Guile - are utterly moot now.)
> IMO the missing book would be half up-to-date man pages of the core
> functions, followed by chapters documenting the major extensions like
> tcllib, tile, etc. "Documenting" is the key word here. Also perhaps
> tutorials on advanced issues like megawidget creation and design. We
> don't need yet another book that devotes a chapter to if, while, and
> case and then develops a GUI DVD filer. Those books are important but
> we already have them.
You mean like the _Tcl/Tk Tools_ book? (It needs a substantial update
by the way, as many of the extensions it talks about are now not ones
that you would use in new code.)
> I realize that such a book would be quite hard to pitch to a publisher
> and would never make its author(s) enough money to justify the effort.
> I also realize that I personally am eminently unqualified to write
> such a book.
Writing a book (and writing the examples to go in the book) would be a
great way to become most thoroughly qualified. :-D
> Did I just write a TIP?
No. ;-) TIPs aren't used that way.
A book is better done with fewer authors funnily enough, since that
makes it far easier to maintain a consistent style throughout.
Donal.
tom.rmadilo
> A book is better done with fewer authors funnily enough, since that
> makes it far easier to maintain a consistent style throughout.
Unfortunately, books usually cover applications or the base languages,
books written about libraries are rare. Books written about ancient
stuff that shouldn't be used anymore (XMLRPC) are even more rare (go
figure).
But the main problem is the idea that a book written about library
code would help the language newbie. The won't. They assume that you
have a basic familiarity with the language itself and they are aimed
at those who intend to spend more than a few hours of research into
the subject. It would even take a few hours to locate such a book at a
local bookstore, drive over and buy it. Such books are somewhat
valuable and are not available for free on the internet.
What is available on the internet is a lot of hints for those who
already know something about the subject, plus basic tutorials.
Neil Madden
[...]
> In my dreams I fantasize that the Tcl community and its fine authors
> (you know who you are and I'm not gonna point at you) might decide to
> work this up as a co-op project. Start with the wiki's material and
> the man pages, build an outline, primp and puff, and then offer it to
> O'Reilly or such. But dreaming up work for other people is an
> unproductive and basically selfish activity.
You may be interested in my project to update the Tcl tutorial into a
book, somewhat along the lines you mention. It's available at
http://www.cs.nott.ac.uk/~nem/tcl/tcltutorial/book/html/tutorial.html
and is being written as a free Creative Commons licensed resource for
the community. Unfortunately, I'm just one rather busy person, so
progress comes in dribs and drabs when I find time. Arjen Markus has
also contributed the beginning Tk chapters, and some material has been
adapted from the original Tcl tutorial (itself based on TclTutor).
A high-quality PDF version is also available for printing:
http://www.cs.nott.ac.uk/~nem/tcl/tcltutorial/book/pdf/tutorial.pdf
Feedback and contributions welcome.
Cheers,
Neil
Arjen Markus
>
> You may be interested in my project to update the Tcl tutorial into a
> and is being written as a free Creative Commons licensed resource for
> the community. Unfortunately, I'm just one rather busy person, so
> progress comes in dribs and drabs when I find time. Arjen Markus has
> also contributed the beginning Tk chapters, and some material has been
> adapted from the original Tcl tutorial (itself based on TclTutor).
>
... something I should be picking up again!
Regards,
Arjen
Lan
> Lan wrote:
>
> [...]
>
> > In my dreams I fantasize that the Tcl community and its fine authors
> > (you know who you are and I'm not gonna point at you) might decide to
> > work this up as a co-op project. Start with the wiki's material and
> > the man pages, build an outline, primp and puff, and then offer it to
> > O'Reilly or such. But dreaming up work for other people is an
> > unproductive and basically selfish activity.
>
> You may be interested in my project to update the Tcl tutorial into a
> and is being written as a free Creative Commons licensed resource for
> the community. Unfortunately, I'm just one rather busy person, so
> progress comes in dribs and drabs when I find time. Arjen Markus has
> also contributed the beginning Tk chapters, and some material has been
> adapted from the original Tcl tutorial (itself based on TclTutor).
>
> A high-quality PDF version is also available for printing:http://www.cs.nott.ac.uk/~nem/tcl/tcltutorial/book/pdf/tutorial.pdf
>
> Feedback and contributions welcome.
>
> Cheers,
>
> Neil
You are my hero(es).
I will review it and even contribute as I can.
~L
rocket777
> Having spent countless hours researching how to use yet another TCL
> package I had to post the following observation:
>
> TCL is one of the most expensive languages to use. Why?
>
As is the case with all software, especially free software,
documentation is very difficult to create. Do you create complete
stuff that even a novice can understand (i.e. someone who doesn't even
know what a package statement does) or do you try for the expert. Will
the reader understand what you are writing, or is it better to
concentrate on providing good sample code.
If you create too much, it can be as bad as too little.
However, documentation is one of those things that when done well is
easy to recognize, but difficult to define.
I do a lot of windows xp stuff and I use twapi. This, in my opinion is
one of the best examples of a well documented extension. It is all on-
line, hyper linked well, and includes good sample code, which often
makes things trivial. And its author is often seen on this board with
help. For a free extension, I think it's about as good as it gets. So,
I use this quite a bit.
I also use bwidgets, but I find that is harder to understand, and
although the OP objects, I usually try to find a sample in the wiki.
I've used microsoft visual C/studio and I found their online
documentation to be pretty good as well, but then that is a very
expensive commercial product.
What this proves is that writing reusable code is much more difficult
than people think. I remember when I first came across the C language
some 30 years ago and thought it was incomprehensible. Only after I
discovered some primers written by the legendary Brian Kernighan, did
I say, "Oh, that's how it works". It's still an art to create good
documentation. OOP was supposed to solve this, but when I see what
some people have done in this area, I am not much impressed here
either.