TCL is an awesome, powerful programming language, but I didn't know a thing
about it until I did a fairly detailed Web search three months ago for a
scripting language alternative to Windows Scripting Host.
What gives?
Ed Suominen
TCL programmer for all of 3 months
Author, TK Secure Comm Suite (Much-improved v 0.4 due soon!)
http://sourceforge.net/projects/tksec
Did you ask your B&N manager where the Tcl books were? If there's no
perceived demand, they aren't going to stock anything.
Chris
--
The Best Parent is Both Parents http://www.gocrc.com
It's actually more extreme than you realize. Big
important organizations like IBM, Oracle, GE, ...
depend on Tcl crucially; they've repeatedly made
strategic decisions to use Tcl. They all give the
appearance of being utterly ignorant about how to
educate their employees and customers about Tcl,
though.
It's a remarkable situation.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
The reality is probably related to that statement at least slightly: book
stores stock what publishers publish, and publishers publish books that
sell, and tcl books don't sell.
At least some books exist. When I started learning tcl (walking to school up
hill both ways in the snow...) there was only one book. So things have
improved a bit since then.
I sometimes lament the fact tcl isn't so popular, but then I wonder why that
matters. It's not like the language is going to stop being a good language.
Whether one person or a million uses it, it still allows me to get my job
done with stunning efficiency, relatively speaking.
Of course, finding jobs that are open minded enough to pick the right tool
for the job rather than the most popular tool is another matter entirely...
"S> This past weekend I went to my local Barnes and Noble bookstore, which for
"S> me involves a 40 mile drive. As I wandered past the endless shelves of
"S> computer books, with entire racks devoted to C++, Java, Javascript, Perl,
"S> PHP, HTML, XML, and even some apparent 80's throwback called "visual" BASIC
"S> (heh), I wondered where the TCL/TK books were. There weren't any.
"S>
"S> TCL is an awesome, powerful programming language, but I didn't know a thing
"S> about it until I did a fairly detailed Web search three months ago for a
"S> scripting language alternative to Windows Scripting Host.
"S>
"S> What gives?
Your local Barnes and Noble appearently sucks. Check out
www.amazon.com:
"S>
"S> Ed Suominen
"S> TCL programmer for all of 3 months
"S> Author, TK Secure Comm Suite (Much-improved v 0.4 due soon!)
"S> http://sourceforge.net/projects/tksec
"S>
"S>
"S>
"S>
--
\/
Robert Heller ||InterNet: hel...@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || hel...@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153
Yeah. Where I was at IBM, Tcl was used quite extensively _internally_.
However, nothing Tcl-based made it into the outside world. The main
product in my department even has it's own built in language
(State-Tables) built from scratch, which would be soooo much more
flexible if someone had had the common sense to use Tcl instead. If I go
back, I might try and convert it! (Although Java Beans are the new
preferred language - <look of horror and disgust>)
Unfortunate on the last part, but on the former, WebSphere's
scripting language is Tcl, and that's a pretty major product
from IBM.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Where I work, there is a relatively small community of designers that
are aware of the wonders of TCL. Sometimes, when a designer visits my
desk, he/she will see my copy of the bible ("Practical Programming in
Tcl and Tk"), and we will exchange that knowing look, content in the
knowledge that *we* have seen the light. Periodically, I do battle with
managers, intent on using <language/development-system-of-the-day/crap>.
It is always an uphill battle.
Unless we start getting more evangelical writers, we will be that little
church my grandma goes to, with the dwindling set of smiling old people.
Ian McMissionaryman
>This past weekend I went to my local Barnes and Noble bookstore, which for
>me involves a 40 mile drive. As I wandered past the endless shelves of
>computer books, with entire racks devoted to C++, Java, Javascript, Perl,
>PHP, HTML, XML, and even some apparent 80's throwback called "visual" BASIC
>(heh), I wondered where the TCL/TK books were. There weren't any.
If it's anything like the last B&N I was in,
the shelves were full of *crappy* books devoted
to C++, JavaScript, HTML, et cetera.
>What gives?
My guess: none of the available Tcl/Tk books are of
low enough quality to find a home in the Barnes & Noble
"Computers and Technology" section next to all the
other garbage :-)
--Joe English
Interesting, I support WebSphere servers and didn't know. Of course,
they die a lot too. Wonder if there's an issue with Vignette, as the
current *also* uses tcl inside.
ciao!
leam
Also note that there has been no new book in exactly 2 years. The only
one I know of coming is an update of "Tcl/Tk for Real Programmers" by
Clif Flynt.
ciao!
leam
I hope somebody will devote some time & effort to the index!
>
>ciao!
>
>leam
*** To reply by e-mail, make double u single in address ***
FWIW, Vignette is deprecating Tcl. The company's stance seems to be "the
faster we get rid of Tcl the better". Tcl is still in their current product
(V6) but I wouldn't be surprised if it was completely gone by the next major
release.
Yeah, my C skills are getting rustier, because my copy of K&R's
C book is over 10 years old. What am I to do?! ;^)
OK, Tcl has progressed a bit, but Welch's book covers 8.3,
which is still the stable version of Tcl.
>Ed Suominen wrote:
>>
>> This past weekend I went to my local Barnes and Noble bookstore, ...
>> ....
>
>Also note that there has been no new book in exactly 2 years. The only
>one I know of coming is an update of "Tcl/Tk for Real Programmers" by
>Clif Flynt.
Sounds like an opportunity for me to write a book. I'll call it "Extreme Tcl:
Intermix with the C API in powerful ways". I'll show people what Tcl used to
be and why it's called "Tool Command Language" and revive the old concept of
glueing compiled components together. I'll devote at least 2 chapters to
threading... maybe even 4 if I talk about the event loop and embedding with
threading. And I'd even have a reason to finish that DirectDraw asteroids game
and my all platform IRC client I started.
Ok... Back to reality and paying bills and such.
--
David Gravereaux <davy...@pobox.com>
Tomasoft Engineering, Hayward, CA
Send a note to the author!
ciao!
leam
Go for it! I'll buy a copy.
>Ok... Back to reality and paying bills and such.
Jeff Hobbs wrote:
>
> Neil Madden wrote:
> ...
> > Yeah. Where I was at IBM, Tcl was used quite extensively _internally_.
> > However, nothing Tcl-based made it into the outside world. The main
> > product in my department even has it's own built in language
> > (State-Tables) built from scratch, which would be soooo much more
> > flexible if someone had had the common sense to use Tcl instead. If I go
>
> Unfortunate on the last part, but on the former, WebSphere's
> scripting language is Tcl, and that's a pretty major product
> from IBM.
Oh yeah. I was talking specifically about my old department (Voice
Systems, formerly Corepoint). The products there don't have Tcl in them,
but use it for testing (for some stuff, also a big use of rexx and trexx
(a telephony-based variant)). Some of the products we interfaced to did
have Tcl interfaces (ViaVoice telephony being the one I saw). Actually,
I believe pretty much _all_ departments in IBM have something to do with
Websphere now, at least in branding.
>
> Go for it! I'll buy a copy.
Me too !
I started to love TCL/TK because the above.
My only book is a C. Nelson's hard copy of TCL/TK Man : "TCL/TK,
programmers reference", first edition. Notwithstanding, I have learnt
to make things with TCL/TK that I could not made with other
programming language (like C++ or Java) even I had expended weeks on
studying. TCL is really great !
Thanks for the support of the idea, but I was just dreaming out loud. It would
be great if there was such a book, though, one that showed odd ways of using Tcl
and introduced different models. Embedding Tcl in the presence of event loops
provided by other GUI toolkits would be an interesting topic.
Larry
Writing an OS totally centred around Tcl - now that would be cool.
Imagine - scripted kernal modules...
ETLinux goes part of that way - in a tiny (2MB) Linux, a Tcl interpreter
is central and even rus 'init'... Used to be at
http://www.linuxcare.it/etlinux/papers/linuxandc.en.html
but currently the link fails me.
Re book: I have a dream called "Arts and crafts of Tcl-Tk programming",
and I'm adding little bits and pieces to it almost every day ;-) If all
Tclers that have nice explanations, algorithms, (or other material a
good Tcl book would contain) put that on the Wiki, the dream would come
true even faster...
--
Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
Siemens Dematic AG, PA RC D2, Buecklestr.1-5, 78467 Konstanz,Germany
Personal opinions expressed only unless explicitly stated otherwise.
> Neil Madden <nem...@cs.nott.ac.uk> wrote:
> > Writing an OS totally centred around Tcl - now that would be cool.
> > Imagine - scripted kernal modules...
> ETLinux goes part of that way - in a tiny (2MB) Linux, a Tcl
> interpreter is central and even rus 'init'... Used to be at
> http://www.linuxcare.it/etlinux/papers/linuxandc.en.html but
> currently the link fails me.
Yes, because Linuxcare fired their remaining European staff a bit more
than a year ago, in the midst of their downward spiral.
It is available, and should be in the future, from www.etlinux.org
Ciao,
--
David N. Welton
Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
Just for the fun of it, I've been thinking about trying 湣
(http://www.ucos-ii.com/) on some undetermined processor for some playing around
with engine management systems like ignition and fuel injection and driving
output to gauges. Some Motorola MPC500 might be a good choice. The evaluation
board is around $600 and it's on my christmas list...
load crank_position.dll
load oxygen_sensor.dll
load map.dll
load tp_vane.dll
load knock_sensor.dll
load head_temp.dll
load injector_rail.dll
load oil_temp.dll
....
I wish I knew more about designing embedded systems as there are some hobby
projects I'd love to do.
I promised you notes on set-theoretical digressions - well, they are on
their way! Would these make it to your dream book?
Regards,
Arjen
Yes! We have another missionary.
When I go preaching, I like to take along:
- simple/powerful example scripts
- references to good books
- references to web sites
- a chocolate bar (Java disciples can be very trying)
- hints of the gloryland (this usually involves a fantastic expectk
script)
There will be temptation to use methods from the Dark Side. Resist. Be
True.
My belief is that we need more focus on getting The Message out in
universities/schools (plant the seed early). Most of the people that I
interview tell me about being taught Java. Most have never seen TCL. I
have seen postings here from folks in education, so I know that we are
getting to some people. The more the better.
Anyway, good luck.
Ian McPreachy
OH MAN!!! Threading, event looping, and embedding! That would be great! All
that and you still need a regular job to pay the bills? ;-)
Mike Dooley
Agere Systems
http://tcl.apache.org/presentations/
It is available under a free license (basically, I want some of the
credit:-), and all you need to use it is a stylesheet compliant HTML
browser (I created it with Mozilla). If you want to create local
versions, it runs on mod_dtcl, although it might be possible to
substitute that with something else without much trouble.
> One argument we smugly submit from time to time is that to learn those other
> languages one needs a multitude of books, whereas with Tcl you can almost
> get by just with man pages.
No. The thing that makes tcl hard to learn is that it is so easy.
> The reality is probably related to that statement at least slightly: book
> stores stock what publishers publish, and publishers publish books that
> sell, and tcl books don't sell.
>
> At least some books exist. When I started learning tcl (walking to school up
> hill both ways in the snow...) there was only one book. So things have
> improved a bit since then.
Nah, bookstores don't stock tcl books because tcl programmers have
figured out how to search for and order books on the web.
-jeff
Like, well, yeah!
Maybe somebody can educate Davy and me. I'm a bit
grumpy on this subject. Both of us have offered to
people to implement/document/... such Tcl goodies as
Expect-on-Windows, the plugin, embedded Tcl,
threaded Tcl, Tcl-for-Oracle, Tcl-for-WebSphere,
Tcl-with-Qt, ... It's no way to get rich quickly.
Prospects *say* they want such things, but, with few
exceptions, they show more interest in talking than
achieving definite results.
Understand, this is a criticism of no one likely to
read this follow-up, because, among other things
all of us already have more-or-less clear ideas
about what we want from Tcl.
So, yes, there need to be other ways to pay the bills.
"McGarva, Ian" wrote:
<snip>
>
> My belief is that we need more focus on getting The Message out in
> universities/schools (plant the seed early). Most of the people that I
> interview tell me about being taught Java. Most have never seen TCL. I
> have seen postings here from folks in education, so I know that we are
> getting to some people. The more the better.
You got it dead right there. Here at uni we get Java, Java, Java and a
pinch of Haskell last year. We get the chance to learn others like C/C++
and prolog in seperate modules we can sign up for. Tcl, on the other
hand was crammed in with Perl and VB (yes, really - like there is any
comparison). And, do you know what the small piece of Tcl experience
that students here get? Building a GUI to run Perl scripts... I dispair.
I think this is the key point! I would love to find a job where I
programmed in Tcl. I use to "sneak" it in for my previous job, but
with my current job, I do not even get that luxury.
What's funny is sometimes they have the Tcl books in the Unix section
of the book store, instead of the programming section. This is very
odd if you are at all familar with Tcl...
There are different issues, which seem to get mixed up at times:
- helping those who want to learn Tcl (yell: man pages! Amazon! wiki!)
- increasing awareness of Tcl for those who've never heard of it
- strengthening the perception that Tcl is a valid and sound choice
The second would benefit from bookshelves filled with the acronym "TCL".
Or articles describing its use. Or innovative use to find new listeners.
There's a lot of (Windows!) people who have no idea what Tcl/Tk is about.
The third needs marketing oomph, showcases, testimonials, and in fact an
entire industry (whatever that means in the special case of open source)
built around the Tcl theme: add-ons, businesses sticking out their necks
by - proudly - admitting that they use Tcl. And rely on it, and want to.
Or books. Or a CD. Or a CD-on-the-web: a comprehensive code repository?
-jcw
> >>threading. And I'd even have a reason to finish that DirectDraw asteroids game
> >>and my all platform IRC client I started.
> >>
> >
> >Go for it! I'll buy a copy.
> .
> .
> .
> Typical publisher reaction: yeah, you and the
> fifteen other people who understand want an
> "event loop" is. Why take a risk on esoterica,
> when *Tcl/Tk Tools* (for example) sold so poorly,
> and I can put liverwurst between covers with the
> title *Java and XML*, and it flies off the shelves?
With all that dead weight, these books can still fly?
Has anyone told Boeing or Aerospatial?
Well, more seriously now: substitute Tcl for one of the
buzzwords in the title, replace the liverwurst with
actual content and, hey presto, the book just might make it
to the local newspaper stand. (No need to tell Boeing, Tcl
being as easy as we all know, just a hundred or so pages
should suffice.)
Regards,
Arjen
I'm hoping to prepare an on-line update to the Tcl/Tk Prog. Ref. in the
first quarter. The update will bring the book up to date for 8.4 (such
as it may be then). It will also be the basis for revisions to create a
second edition hard copy if OMH ever sells out the first edition.
Chris
--
[Bill Gates'] definition of "open" and "innovation" are so divergent
from mine, I have to assume that he might define "protect my privacy" a
bit differently, as well. -- Ralph Barker, HP World, June 2001
Indexing is a sore point and a hard job. As I understand it, Brent
Welch did his own index for the first edition (or first couple of
editions) of his book. The index being poorly reviewed, he hired it out
for the third edition and, I believe, was happy with the result.
Indices are often done in a rush near the end of the development cycle.
And there's a weird bit of business where -- at least in my case -- the
publisher hires an indexer for the author and charges the author against
royalties for the indexer's fees. The fee was per page of manuscript
and doesn't take into account at all how good or bad the final product
may be. I can't recall now whether or not I even had a chance to review
the index before printing. I know I didn't have a change to not pay for
shoddy work. I've got numerous notes on bad or missing index entries
for my book and may include an addendum to the index with my 8.4 update.
Chris
--
Never doubt that a small group of thoughtful, concerned citizens
can change the world. Indeed, it's the only thing that ever has.
--Margaret Mead
I'll speak bluntly. In the US, ORA has the best brand
for this sort of thing. Don's Expect book is in the
catalogue, and limps along, from what I can tell, even
though it's one of the easiest books to recommend--a
real industry classic. They had *Tcl/Tk Tools*, which,
despite a few imperfections, remains valuable, and a
good buy--except that you can't get it now, as ORA let
it lapse. While I don't know the details of this item,
another part of ORA's general reputation is that they're
absolutely tops at nurturing books that take a long time
to establish themselves. I summarize: if ORA can't
sell *Tcl/Tk Tools*, then no conventional book with Tcl
in the title has a hope of paying off the paper on which
it's printed.
Really.
My conclusion is that it's time to move on, and strate-
gize about a direction that doesn't involve being like
other languages.
My University prided itself on teaching pragmatic skills that would get you
a job when you graduated. I'd never even heard of TCL until I started
working at my current company and I've worked for IBM.
The problem would seem to be a vicious circle - until TCL gains recognition,
no one will want to learn it at school or University because it will not
help you at a job interview. Even my own company, that does mostly TCL
development, advertises for Java and C++ developers, who are then re-trained
to use TCL. No one wants to employ TCL developers, so no one wants to be a
TCL developer.
If no one is trained to develop TCL and no one wants to be a TCL developer
because there are no TCL jobs, who will suggest TCL as a solution? No one
has the skill set to recommend it. The language gets killed by inertia.
TCL is a fantastic language, powerful, elegant and efficient. But it lacks
critical mass and may be doomed to the sidelines. I can not imagine any
large company championing a language it can not control or dominate and the
open source community already has numerous alternatives, heavily defended by
people with carefully cultivated skill sets. Unless it finds a niche market
that suddenly balloons, it may never become much more than it is now.
I hope I'm wrong...
Jim Rennison.
> Writing an OS totally centred around Tcl - now that would be cool.
> Imagine - scripted kernal modules...
http://www.etlinux.org/ is a fairly hefty step in that
general direction.
--
.-. .-. .---. .---. .-..-. | Wild Open Source Inc.
| |__ / | \| |-< | |-< > / | "Making the bazaar just a
`----'`-^-'`-'`-'`-'`-' `-' | little more commonplace."
home: www.smith-house.org | work: www.wildopensource.com
For my money a school which teaches you directly applicable skills is a
trade school. I've often noted that I directly use very little of what
I learned in college but having been taught basic principles,
engineering discipline, and critical thinking I am prepared to learn to
do a job. My present job and my last job both started with me not
knowing the system I was hired to work on.
I would put directly-applicable skills _way_ down the list of
qualifications for new hires straight out of college and not too high on
the list of more senior employees. If I _need_ specific skills *right*
*now*, I'll hire a contractor or consultant.
Chris
--
Given infinite time, everything will happen.
I was originally inspired by debates I've read on various comp.lang.*
groups. Rather than pointing out which language is the best, I'm
aiming to point out why the various scripting languages covered ({Perl,
TCL, PHP, Python, Ruby and REBOL) each have powerful advantages and
why each has a proper niche.
So learn them all!
I don't know when I'll be finished with this - writing is a more
challenging job than I anticipated.
Harold
har...@1st-spot.net
My University struggled to teach underlying principles and widely applied
skills using the most commonly applied solutions in industry. They used this
as much to ensure there course was current as to give their students the
edge in interviews after graduating.
> I would put directly-applicable skills _way_ down the list of
> qualifications for new hires straight out of college and not too high on
> the list of more senior employees. If I _need_ specific skills *right*
> *now*, I'll hire a contractor or consultant.
Unfortunately, the brief perusal I give to the jobs lists once a week would
suggest you are in the minority. My current company, due to the fact it must
teach most of its new employees TCL from scratch, takes a very similar
attitude to you. As a result it has one of the best development teams I have
ever encountered. But my company is also the only one I know still
recruiting due to a surfeit of work from customers in this time of little.
Perhaps the problem is in persuading people to recruit 'developers' rather
than 'Java/C++ developers'. I suspect you will encounter the same
protectionism and lack of interest as you find when explaining the benefits
of Tcl/Tk to Java devotees... Many recruiters are looking for boxes to tick.
Just look at how you search most appointment websites for a new role. I do
not know of any where 'Development' is a recognised skill.
I don't want to sound too pessimistic. I thoroughly enjoy programming in Tcl
and I recognise the advantage it has provided my company over its
competitors. However, persuading talented developers to give up their
perceived advantage in a particular field and start out with a new language
which provides few immediate employment prospects strikes me as very
difficult.
Cheers, Jim.
Jim Rennison.
> Rather than pointing out which language is the best, I'm aiming to
> point out why the various scripting languages covered ({Perl, TCL,
> PHP, Python, Ruby and REBOL) each have powerful advantages and why
> each has a proper niche.
What's PHP got that the others don't or couldn't have in some way?
> [snip]
> So, yes, there need to be other ways to pay the bills.
> --
>
> Cameron Laird <Cam...@Lairds.com>
> Business: http://www.Phaseit.net
> Personal: http://starbase.neosoft.com/~claird/home.html
Well, having written a few published things in magazines in the distant past, I
understand that they talk a good line, but really only want what they percieve to
be popular. And I've fought the battle to keep using TCL for what we do here
(software/hardware testing) since some prefer Java/Perl/etc. Actually the battle
is usually fought against management... or those who've never used TCL. Most just
considered it a scripting language, then I'd hand them a gui to do some task and
my (and TCLs) popularity would take a bounce upward for awhile. ;-) Couldn't have
done it without this groups help, though!
Mike
[snip]
ooooo! [all please stand by while ego inflating praise ensues]
Your book was the first one I bought and is MUCH more dog-eared than any of
the rest.
[praise mode off]
AND, I'm looking forward to an update... web page, or whatever...
preferrably hard copy since that's the easiest to take to the reading room
where the MOST diverse and difficult problems are truly solved.
Mike
: Indexing is a sore point and a hard job. As I understand it, Brent
: Welch did his own index for the first edition (or first couple of
: editions) of his book. The index being poorly reviewed, he hired it out
: for the third edition and, I believe, was happy with the result.
How much does something like LaTeX help? I've done a limited amount of
index generation with it and it seems really easy. How broadly used is
LaTeX by authors? Should it be?
--
- ---------- = = ---------//--+
| / Kristoffer Lawson | www.fishpool.fi|.com
+-> | se...@fishpool.com | - - --+------
|-- Fishpool Creations Ltd - / |
+-------- = - - - = --------- /~setok/
I don't know; I've never touched any flavor of TeX. To hear an indexer
or editor tell it, the skill in indexing is knowing _what_ to index.
Either I had an indexer inexperienced in technical or programming
concepts or I had a poor indexer. I put a bunch of notes in my
manuscript ("ls, see glob") that mostly made it into the index but other
things are sorely missing. <SIGH>
Er, uh, Brent and John have made the two top selling Tcl
books to date, and neither is an O'Reilly title. Except
for Expect, which doesn't really allude to Tcl except on
the inside, O'Reilly's stable of Tcl books is extremely
poor (and I've told them so).
The publishing of Tcl/Tk Tools was poorly executed. By
the time the book got published, it was a legacy title.
Sure, it's still good for the basics, as John's book is
to Tcl now, but publishing a book that is already based
on older versions of all the tools mentioned ... It also
suffered from the fact that there was no BI distribution
that one could get with all the described extensions
ready to play with. I dare say that repeating the effort
today (not likely, BTW) with some extended version of
ActiveTcl would fare better.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
The trick with things like LaTeX is to index what you're writing
as you're writing it. You should know best after all.
Jochem
While I think I know better, the editor and publisher think otherwise.
Brent's experience (and maybe Clif's) would bear that out. I don't
know what to think. <shrug>
Chris
--
Clarity comes from the [programmer], not the syntax. -- Roland Hough
What is the customer's stance?
"the faster we get rid of Vignette the better".
Just kidding.
Seriouly. Vignette made a simple mistake that many software companies have
made: throw your old code to trash. There are no needs to explain more, but
I guess the CTO did not play an important role in the company.
> Tcl is still in their current product
> (V6) but I wouldn't be surprised if it was completely gone by the next major
> release.
Chang
I visited <URL: http://www.barnesandnoble.com/ > . I type in
"tcl" in the books search engine.
I got back 36 titles . These are the 'in print' titles I guess as
I am told that there are more titles I can search for from their out of
print book dealer network.
Sorting by most recent publication date, they list:
Chad Smith's [incr Tcl] 1999
David Maggiano's CGI programming with Tcl 1999
Venkat Sastry's Sams Teach Yourself Tcl/Tk in 24 hours 1999 (not presently stocked)
Brent Welch's Practical Programming in Tcl and Tk 1999 (3rd edition)
Chris Nelson's Tcl/Tk Programmer's Reference 1999
Paul Raines Tcl/Tk in a Nutshell 1999
Steve Holzner's Web Development in Tcl/Tk 1999
Clif Flynt's Tcl/Tk for Real Programmers 1998
J. A. Zimmer's Tcl/Tk for Programmers 1998
There's 4 books to teach general programming, 2 reference books,
2 web books, an itcl book.
However, because of the age and low sales of the books by the community,
there's no motivation for book stores to carry them in the store gathering
dust.
Trust me - if people were hammering their bookstores for books, the book
stores would carry what are in print (all but one of the above apparently)
but the publishers would be after the authors for updates.
--
"I know of vanishingly few people ... who choose to use ksh." "I'm a minority!"
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Ever pop over into those environments and ask how good most of those titles
are? I know that in the Perl community, the last time I checked (1 yr ago)
there were less than a dozen of the multiple dozens of titles which were
recommended as being worth while purchases.
I'd expect the same for the other environments. Do we really NEED another
Tcl/Tk for Dummies experience?
"Xtreme Programming with XTCL and XTK"
"What's that XML? Document Parsing Made Easy with XTCL"
"XXXTCL, All The Things You've Always Wanted To Know But Were Afraid To Ask"
and, for the current season,
"How Does Santa Know What You Xpect: an Xmas xcript"
FYI,
Legato Systems product GEMS Console uses tcl, though you would never
know it.
We needed an embedded http server so that the customer would not have
to install one in order to download the java UI: so I embedded tcl and
used tclhttpd!
The daemon that provides the services displayed by the UI has a nifty
little message passing scheme where modules register for messages to
process. So, I wrote a tcl module and an httpd module. The httpd
module sends the tcl module a 'run the tclhttpd' script when it loads
to start the server. The tcl module, of course, can send and receive
all kinds of messages, so the entire system is scriptable (in safe
mode, of course!).
The biggest problem with the project was learning how to actually
embed tcl as a scripting language for an application. For all the
talk in every book and everywhere else about how that is what tcl is
for, I could find nary and example anywhere! With some study and help
here, though, it turned out fine; I might have even done it correctly
;-).
I particularly liked using TclPRO to debug things on another machine.
And, of course, tclhttpd is a fantastic product all on it's own. Just
starting to embed it at my current firm. ;-)
Byron
Our industry certainly supports sillier things.
I don't know, though, if we Tcl-ers have the
kinds of brains to pull off such stunts.
'Thing is, he's right. That's how the advertisers-and-their-
readers think, so, that's the reality. Welcome to Phase IV
of the Open Source chronology.
Hmmmmmmmmmmm - we've occasionally discussed issues
for tcl 9.0. What if we changed the language's
name when 9.0 comes out? eXtended Tool Language,
XTL?
Actually, I've thought that having tcl read and
understand HTML would be darned useful - that is,
an html document is a valid program, and tcl can
read and understand <sub>, <sup> and so on. That
would legitimately call for a new name: Hypertext
Tool Language - HTL? Hypertext Command Language,
HCL? Source programs would be edited with netscape
or amaya...
I've also run into the same problem at various bookstores...
Sometimes I think that one of the main problems is
that the people working in the bookstore just don't
have a clue about where to stock books about Tcl.
By that, I mean that several times I seen Tcl books
on the shelf in the "TCP/IP" section...
Not exactly where I would normally look for them.... :)
--Mark
MarK Stucky wrote:
> ... I mean that several times I seen Tcl books
Also how to turn a tcl extension into a thread safe one
or how to use swig to generate a tcl extension of
C/C++ code:-)
George
That is one view. I would argue that the person writing something may
know what _they_ would want to look up in the index. Whether that matches
what the audience using the books wants to look up is a second question.
And a third question is whether the audience would use the same terms / words
that the indexer uses...
If something relatively brief would be of interest, Dave Bodenstab's
update to the Raines/Tranter Tcl quick reference guide covers early
Tcl/Tk 8.4, with some talk of an update to something newer in the air...
See <URL: http://www.purl.org/NET/Tcl-FAQ/part3.html> 's reference to
that document.
I wonder if we need a PDF containing some of this material - a tract so to
speak.
Marty's daily PDFification of <URL: http://purl.org/tcl/wiki/> would be
a bit heavy.
Of course, what would REALLY be cute would be a floppy with tclkit and
a something like <URL: http://mini.net/cgi-bin/wikit.gz > ... if it were not
larger than current floppies...
How to Thread-Safe an Extension in 10 minutes:
http://sourceforge.net/docman/display_doc.php?docid=8359&group_id=10894
Being a technical writer for much of my career, I attended an
"indexing bootcamp" several years ago. The instructor, a professional
indexer, mentioned that for most reference books she commonly used,
she compiled her own personal index. I don't know many others who'd
go through that much trouble, but on occasion I've been tempted to do
it with some really useful books with really lousy indexes.
And in one class I taught recently, a student brought in their own
copy of Don Libes's "Exploring Expect" which they had dismantled,
extensively tabbed and annotated, and then re-bound.
And lvi...@yahoo.com wrote:
>
> According to Jochem Huhmann <j...@gmx.net>:
> : You should know best after all.
>
> That is one view. I would argue that the person writing something may
> know what _they_ would want to look up in the index. Whether that matches
> what the audience using the books wants to look up is a second question.
> And a third question is whether the audience would use the same terms/words
> that the indexer uses...
That's the real art of compiling indexes, and why automated index
systems are of little use in creating truly useful indexes. It isn't
just a matter of marking where certain keywords appear in the text.
You first need to identify all of the interesting and important
topics, which requires a fair understanding of the material in the
first place (which is why it's *very* difficult to find a good
technical indexer). You then need to find all *substantive*
references to those topics in the text, which requires both
identifying references that might not be obvious at first (e.g.,
different terminology) _and_ ignoring trivial references. And most
importantly, you need to present this material so that readers can
find the information quickly. This requires posting references
multiple places in the index (for example, referencing the action,
referencing the object, referencing key concepts, special consolidated
troubleshooting references, special consolidated command or class
references, etc.), anticipating synonyms (e.g., perhaps referencing
"deleting", "destroying", and "removing"), and using lots of
cross-references (e.g., "See" and "See also"). For dense, technical
material like you find in most computer manuals, an index should
really be about 1/10 the size of the primary text. But you rarely see
such comprehensive indexes because of the time, patience, and skill
required.
Only once in my life have I compiled an index I was truly proud of for
one of my technical manuals. That was thanks to a last-minute 1 week
slip in the product release, and I spent the entire week re-indexing
the book. It turned out the be the only manual that I ever got a
reader comment card back from, with a comment thnking me for making
"so much information so easily accessible."
- Ken Jones, President
Avia Training and Consulting
www.avia-training.com
866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax
Duh...
Now I understand... :)
Another way (which may take a bit longer than 10 minutes
depending on how the extension was written) is to avoid
using global variables altogether. Instead, wrap all the
global data inside a structure, allocate and initialize it
in the extension's Xxx_Init() routine, and pass it to command
procedures with Tcl_[SG]etAssocData() and/or the 'clientData'
parameter.
This way the extension is "thread-oblivious"; Tcl's
one-thread-per-interp policy ensures thread safety.
As a bonus, the extension is also "multi-interp-safe",
i.e., it can be loaded into multiple Tcl_Interps in the
same process.
Of course if the extension calls any third-party routines
which are not thread-safe then you'll still need to use mutexes.
But if not, the thread-oblivious approach is a good alternative.
--Joe English
> Jeff Hobbs wrote:
> >
> >How to Thread-Safe an Extension in 10 minutes:
> >
> >http://sourceforge.net/docman/display_doc.php?docid=8359&group_id=10894
> >
>
> Another way (which may take a bit longer than 10 minutes
> depending on how the extension was written) is to avoid
And then there are of course extensions which use global information
of the core itself. For example the infomration about registered
filesystems is global and FS drivers can be called from any
interpreter in any thread. This becomes especially important for FS
drivers which reflect operations back into the tcl level as they have
to access an interpreter to do their work.
--
Sincerely,
Andreas Kupries <akup...@shaw.ca>
Developer @ <http://www.activestate.com/>
Private <http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------
}
> Hmmmmmmmmmmm - we've occasionally discussed issues
> for tcl 9.0. What if we changed the language's
> name when 9.0 comes out? eXtended Tool Language,
> XTL?
Cool idea, but I think it would fit better to call the spelled-out
version "eXtensible Tool Language".
cu
Reinhard
> Sometimes I think that one of the main problems is
> that the people working in the bookstore just don't
> have a clue about where to stock books about Tcl.
> By that, I mean that several times I seen Tcl books
> on the shelf in the "TCP/IP" section...
> Not exactly where I would normally look for them.... :)
I can confirm that, but it does not only apply to Tcl.
Some years ago, I found a book on network management while browsing
the "new books" table of our university library. It was labeled to be
put into the economy section later.
I took it, asked for the responsive person, and told her that economy
was clearly the wrong section to put this book in. I explained, that
network management was something very technical, that nobody would
would actually look for a book on network management in the economy
section, and the book would fit much better in the computer science
section.
Her reply was -- "No. 'Network management' contains 'management' and
computer networks are used in offices by managers, so economy is the
right place to put it." So she really thought that network management
was about "networks for the management" :(
cu
Reinhard
This explains it all (a posting from postgreSQL mailing list about
pltcl):
Tom Lane <t...@sss.pgh.pa.us> writes:
> But I'm not sure that this has anything to do with Alvaro's
problem.
> The bogus choice of soname has doubtless been that way for
awhile,
> and yet we've not had other complaints.
Biggest reason: Hardly anyone uses tcl.
We've shipped it that way, and there was one complaint month after
we
shipped... Comparing that to feedback on other areas in the same
package, I just don't think the tcl functionality is used much.
Tcl is[n't]
exactly all the rage anymore.
--
Trond Eivind Glomsrød
Red Hat, Inc.
<sarcasm>
I better pack my bags now, and learn another language, since Tcl isn't
all the rage anymore. I'm just glad someone told me before it was too
late...
</sarcasm>
Thank you all for the info.
Actually the global variables are very few in my extension,
only one integer that is used to assign unique command
names.
The bad news is that I didn't wanted the C api to
have references to a tcl interp, so I have the notion
of an "error" interpreter where the messages are written
in case of errors that gets initialised when the
extension gets loaded.
This may not be thread safe but its too late to change it:-)
George
Of course, if we want to live dangerously, we could invoke a bit of
controversy in the name - call it "The ORIGINAL Tool Adaptive Language"
(TOTAL)...
> Of course, if we want to live dangerously, we could invoke a bit of
> controversy in the name - call it "The ORIGINAL Tool Adaptive Language"
> (TOTAL)...
I'm not sure. Who would like to tell their manager that they finished
»totaling« the company's flagship product that day?
Anselm
--
Anselm Lingnau .......................................... ans...@strathspey.org
I don't wake up for less than $10,000 a day.
-- Supermodel Linda Evangelista, on economics
> Tcl is[n't]
> exactly all the rage anymore.
>
> --
> Trond Eivind Glomsrød
> Red Hat, Inc.
>
> <sarcasm>
> I better pack my bags now, and learn another language, since Tcl isn't
> all the rage anymore. I'm just glad someone told me before it was too
> late...
> </sarcasm>
You also have to remember that many NC based Red Hat folks are rabid
Python lovers. They go out of their way to bash anything Tcl or Perl
based. I am not joking.
Mo
And of course you can spend *days* looking for the UNIX pretty-printing
program when it's indexed under "grind out elegance" instead of
something with "pretty" or "print" or "text" or "listing" or "format" or
....
Sometimes it seems like people *try* to be obtuse.
Then there's the AIA (American Institute of Architecture) standards
tome, which includes a reference to Hitler in the index, with the only
page number listed for it matching the page number of Hitler in the
index. :-)
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
"This wine goes good with feet."
What's wrong with this picture? ;-)
I can vouch for that. I have the scars to prove it.
Ah yes, a classic case of Tcl usage - works great, and nobody knows
it's there. Siemens uses Tcl in many ways, but with tclhttpd as a
default http server is definitely in 2 projects I know of.
Now we have to wonder why they bothered with Java for the UI. ;^)
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
You have to be rabid to love Python. ;^)
>The biggest problem with the project was learning how to actually
>embed tcl as a scripting language for an application. For all the
>talk in every book and everywhere else about how that is what tcl is
>for, I could find nary and example anywhere!
I agree. The art of embedding has been lost to the DIY crowd.
--
David Gravereaux <davy...@pobox.com>
Tomasoft Engineering, Hayward, CA
But that's copy protection!
e.
> bser...@yahoo.com (Byron Servies) wrote:
> >The biggest problem with the project was learning how to actually
> >embed tcl as a scripting language for an application. For all the
> >talk in every book and everywhere else about how that is what tcl
> >is for, I could find nary and example anywhere!
> I agree. The art of embedding has been lost to the DIY crowd.
Which is a pity, because this is where Tcl really shines. Write it,
and they will come...;-)
--
David N. Welton
Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
> You have to be rabid to love Python. ;^)
Not to pick on you, of course, Jeff, as you are one of the people who
is actually doing something (well, a whole lot, actually) to improve
Tcl.
However, I think we need to pull our heads out of the sand to some
degree. There are lots of smug comments on how Tcl does this and
that, but frankly, there are also a lot of things it can't do, or at
least not easily or without performing ugly hacks.
Python does most of what Tcl does simply, quickly, and very, very
clearly.
For instance, in Andreas' very nice implementation of graphs in
tcllib, he is using slave interpreters. Most comp sci books won't
tell you about using slave interpreters to create data structers:-/
I think Tcl has a *lot* to offer, and I definitely think it's the
right solution for a certain set of problems, but to make it keep
evolving, we can't get complacent.
> Jeff Hobbs <Je...@ActiveState.com> writes:
>
> > You have to be rabid to love Python. ;^)
>
> Not to pick on you, of course, Jeff, as you are one of the people who
> is actually doing something (well, a whole lot, actually) to improve
> Tcl.
Seconded.
> However, I think we need to pull our heads out of the sand to some
> degree. There are lots of smug comments on how Tcl does this and
> that, but frankly, there are also a lot of things it can't do, or at
> least not easily or without performing ugly hacks.
>
> Python does most of what Tcl does simply, quickly, and very, very
> clearly.
>
> For instance, in Andreas' very nice implementation of graphs in
> tcllib, he is using slave interpreters. Most comp sci books won't
> tell you about using slave interpreters to create data structers:-/
>
> I think Tcl has a *lot* to offer, and I definitely think it's the
> right solution for a certain set of problems, but to make it keep
> evolving, we can't get complacent.
Touche again.
-jcw
> Jeff Hobbs <Je...@ActiveState.com> writes:
>
> However, I think we need to pull our heads out of the sand to some
> degree. There are lots of smug comments on how Tcl does this and
> that, but frankly, there are also a lot of things it can't do, or at
> least not easily or without performing ugly hacks.
Personally, I try to explore every language that I can get my hands
on. I work in a department where 90% of what we do is in Perl, but
sometimes it's not the right tool for the job so I explore other
languages to see if there's a better way. I have yet to find a "silver
bullet" language that is the right tool for the job 100% of the time,
regardless of what those on comp.lang.perl.misc will tell you. ;-)
This may sound strange coming from a Perl hacker, but I find some of
Tcl's syntax confusing, and I wonder why certain obvious things aren't
done automatically. For example, I was benchmarking it for a CPU
intensive task of calculating prime numbers. I found Tcl to be 2
orders of magnitude slower than Perl and Python. I informed a friend
of mine who works in Tcl all day, and he told me all about the double
evaluation problem between the Tcl compiler and expr, and helped me
optimize until the Tcl was running slightly faster than the
Python. Fixing that was pretty ugly though, with nested ['s inside of
{'s until it was quite hard to read. I wouldn't want to maintain that
code.
However, I later needed to do a simple event handling routine in Perl,
watching several file descriptors for data and handle them
accordingly. Using the select() system call like a C coder, it worked
fine but took a little while. A buddy told me that Tcl has a superior
system for handling arbitrary events built-in, and that with a simple
command he could bind a callback to a file descriptor and Tcl would
handle the whole thing transparently.
It seems to me that all languages offer something special. It is only
our familiarity with a given language, and resistence to change, that
causes these "holy wars" in the first place. As I explore Tcl, from a
Unix tool developer perspective, I find lots of cool features, and
some limitations. The fact that Perl and Python are being rewritten
almost daily is actually a PITA for me, and the relatively stable
development cycle of Tcl is pretty cool. I'd rather not look at
upgrading twice a year and run regression tests on all of our tools. I
think I'd want to use TclX though, as POSIX is a good thing.
Anyway, I just thought I'd chime in. :)
Mike
--
Michael P. Soulier <msou...@mcss.mcmaster.ca>, GnuPG pub key: 5BC8BE08
"...the word HACK is used as a verb to indicate a massive amount
of nerd-like effort." -Harley Hahn, A Student's Guide to Unix
> A buddy told me that Tcl has a superior system for handling
> arbitrary events built-in, and that with a simple command he could
> bind a callback to a file descriptor and Tcl would handle the whole
> thing transparently.
I think Tcl has some absolutely wonderful stuff in its implementation.
What's more, you get access to heaps of it at the C level, which is
fantastic if you are integrating it into another framework. Tcl has
been a joy to work with as I've created and made progress with
mod_dtcl.
But I'm a little less enthusiastic when working above the C level. It
works, and it does what I need, but there are things that feel crufty
or wrong to me. I think they are all quite fixable, and I don't
believe I'm being a naysayer, but I just felt it was necessary not to
hide ourselves from the fact that there are improvements to be made,
and that we don't hold all the advantages.
The reason I posted that quote, was because I hear far more often from
other programming camps smug comments than I ever do from the Tcl
community; not that being the lesser of 2 evils means that it is not
evil ;^)
Besides, the quote was just so off base, and unsubstantiated that I
thought it was absurd that anyone would post it.
In the past, I had starting learning Perl, Python and Java. I know
them a little bit. But, my learning of these languages is on the back
burner, since all I need to do, I can easily do in Tcl (note that I
don't do any hard core programming). And between work and my beautiful
5 month old son, I unfortunately don't have time to learn these
languages. If the day comes that Tcl can not do everything I need it
to do, than I will try learning another language. Until that day comes
though, Tcl is my language of choice...not because it is perfect, but
perfect for *me*.
--brett
[*] by we, I really mean the people that do the real work! I am trying
to contribute, because I think there is room for improvement, but it
is at such a small scale, it probably can be considered negligible!
dav...@dedasys.com (David N. Welton) wrote in message news:<87g0657...@dedasys.com>...
Actually, my indexing "boot camp instructor" commented on this
practice as well. She says that she likes to see one or two "easter
eggs" like this in an index, just to have some fun. In my "ultimate
index" that I mentioned previously, I included an index entry for my
hometown, Terre Haute, IN. The only place it appeared in the text was
in some example code.
> She says that she likes to see one or two "easter
> eggs" like this in an index, just to have some fun.
One that I like is (in the index on page 123):
Recursion ....... 123.
See also: Recursion
Anselm
--
Anselm Lingnau .......................................... ans...@strathspey.org
Back off, man, we're scientists! -- Peter Venkman (*Ghostbusters*)
Cheers,
Roy Terry