Why TCL?
rea...@yahoo.com
2 weeks ago I found out about TCL for the first time, and I've fallen
for it since. It turned out to be very easy to learn, and seems to do
what I want it to do so far.
I have to hold a speech on any arbitrary technical subject soon for a
room of techies and I've thought about introducing them to TCL, since
many have heard of Expect, but don't realize it's built on top of TCL.
Since 2 weeks has not been enough for me to know all ins and outs, I
wonder how I can convince them of the benefits of TCL. By testing the
waters, the first responses I got were:
"Why yet another language to learn? I can do everything I want with
Perl, and has a greater userbase".
So, help me here..
1. why use TCL and not Perl for example? (my answer was the legibility
but they just say it's a matter of taste and what you're used to)
2. what are its (dis)advantages?
3. what's on the outlook? Is it going to remain a tool used by a few,
while the rest of the world moves on with Perl, PHP, Bash and Java?
What else? I know these are same old typical questions, but they are
asked. I've been around a lot of experienced programmers, most on linux
platform, and nobody, including myself, had heard of TCL before, even
though some knew about Expect. How come? What does PHP or Perl have
that TCL does not? If TCL is a specialized tool for a particular
purpose, then what is it?
I know the idea of TCL, why re-invent the wheel for every tool that
supports some kind of scripting when you can use TCL libs, but why
Perl. PHP and all the other? What's TCL's flaw? It seems faster to me
than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
is there another reason?
Lisa
jo...@swri.edu
> 1. why use TCL and not Perl for example? (my answer was the legibility
> but they just say it's a matter of taste and what you're used to)
I'm a firm believer in picking the right tool for the job so I go between
PERL and Tcl fairly often. I pick Tcl for scripting functions in which I
want GUI attached. I also use Tcl for GUI programs that would take too
long to implement in C++/Qt; usually this occurs when I don't have to
interface to legacy C code.
I know you can use Tcl for those, I just choose not to.
> 2. what are its (dis)advantages?
To me, there are too many competing technologies which all have their
pluses and minuses. Lots of table widgets, notebooks, object oriented
facilities, etc...
> 3. what's on the outlook? Is it going to remain a tool used by a few,
> while the rest of the world moves on with Perl, PHP, Bash and Java?
All tools have a place. We use Tcl to get a job done and it just works!
I really like it for that.
Joey
suchenwi
public fashion, although to those who know it it is extremely simple
and extremely powerful.
For a family tree, think of Tcl as having sprung from Lisp, C, and
(Unix) shells.
There is a mid-sized community which usually is very helpful and can be
reached at
news:comp.lang.tcl (here)
IRC #tcl
Also, there's a quite rich Wiki about Tcl/Tk at http://wiki.tcl.tk
One point of interest might be the "Advocacy" pages there at
http://wiki.tcl.tk/references/9855! (the exclamation mark is part of
the URL). One of my own testimonies says:
Tcl matters to some (to me very much), and doesn't to the vast majority
of the Earth's population... As a linguist, I've been interested in
programming languages for thirty years, from Assembler to Lisp to C++,
but haven't found another one that gives me more power to do almost
anything, including very unexpected things. We have FP, and we can have
most any flavor of OO with little effort, need it or not :)
We're not trying to proselytize friends of other languages, but we're
glad to help all who have questions about Tcl/Tk.
Michael Schlenker
> Hi,
> "Why yet another language to learn? I can do everything I want with
> Perl, and has a greater userbase".
Probably they have a greater userbase knowing that they use Perl, its
hard to hide the ugly..., Tcl is more of a chameleon, see your own
Expect example...
>
> So, help me here..
>
> 1. why use TCL and not Perl for example? (my answer was the legibility
> but they just say it's a matter of taste and what you're used to)
They are right. Its a matter of taste. Perl is better for some low level
Unix work, while Tcl makes cross platform stuff (unix,win,mac) much
easier than perl, as it hides the complexity.
> 2. what are its (dis)advantages?
Basically quote the advocacy pages from www.tcl.tk
http://www.tcl.tk/about/features.html
http://www.tcl.tk/about/highlights.html
> 3. what's on the outlook? Is it going to remain a tool used by a few,
> while the rest of the world moves on with Perl, PHP, Bash and Java?
Tcl surely isn't the hippest thing in the universe. So there will be
more hype around PHP, Java and others like Python or Ruby. But its a
solid, mature tool. If your following the hype, try Ruby, or some other
of the current marketing bubbles.
>
> What else? I know these are same old typical questions, but they are
> asked. I've been around a lot of experienced programmers, most on linux
> platform, and nobody, including myself, had heard of TCL before, even
> though some knew about Expect. How come? What does PHP or Perl have
> that TCL does not?
Lots of noisy advocats and better marketing.
PHP is a crap language, getting better slowly with each major version,
but its widely installed on web hosters and easy to get basic things
done. (but the trouble starts when you want more than the basics).
But PHP is visible as hell, you can't hide it as easily as Tcl. You have
to configure a zillion things, have a zillion dependencies because PHP
includes everything but the kitchen sink in its distribution (just
because it doesn't have something smart like Tcl Stubs it has to do it
that way, otherwise PHP deployment would be even worse than it is). Add
the fact that PHP is used as a web tool, so you have the huge and noisy
web designer crowd out there producing nice looking webpages with
documentation, examples and other things, even if there code is substandard.
Perl, no idea. Its a nice tool if your fluent with it, otherwise its
hell. Part of the toolkit for true hackers or so, the same people that
believe in self documenting code...
Part of the marketing problem may be Tcl's BSD license: You do not have
to admit that you use Tcl, you can simply embed Tcl into your product,
software, appliance and no one will notice it on a cursory look. Similar
embedding is a lot harder with Perl (and the license for EmbPerl is
somewhat more confusing legally) and at least as hard with PHP.
> If TCL is a specialized tool for a particular
> purpose, then what is it?
Its in a way specialized to handle strings and glue things together. It
is used as a specialized tool in lots of contexts, see Expect, most ECAD
applications, etc. etc.
> I know the idea of TCL, why re-invent the wheel for every tool that
> supports some kind of scripting when you can use TCL libs, but why
> Perl. PHP and all the other? What's TCL's flaw? It seems faster to me
> than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
> is there another reason?
Main reason really is marketing.
Michael
Arjen Markus
On the one hand, Tcl to me is a tool that fills a gap between a
language like C or Fortran where speed is important (big computational
programs, database systems, sophisticated graphical presentations) and
a shell scripting language to chain programs together (bash, ...).
On the other hand, Tcl is also a tool for me to explore new programming
ideas, to create lightweight programs (scripts if you like) to do a
small job perfectly well.
Mind you: I have used it and continue to use it for big jobs too.
If I am to name my favourite languages: Tcl for the lightweight stuff
and gluing things together, Fortran for the numerical stuff and (yes,
surprise, surprise) for doing that sort of programs in an elegant way!
I know, FORTRAN (note the capitals) has an ill reputation - but it has
evolved into something much more sophisticated than the first public
standard that everybody still has in mind. I love them both for being
as platform-independent as they are, even though they may by themselves
not be sufficient for everything.
And the best part perhaps: both communities are usually unusually
helpful :)
Regards,
Arjen
Kaitzschu
> What does PHP or Perl have that TCL does not?
> why Perl. PHP and all the other? What's TCL's flaw? It seems faster to
> me than PHP, more legible than Perl, .. so what's lacking? Advertising?
Integration. When you install some UN*X variant you get hunders of Perl
scripts, starting from hellbent initscripts and ending to system wide log
examination and stuff. Even debconf requires perl-base.
When you install web server you get tens of Perl and PHP examples that let
you do cool things in next to no time.
When you install Tcl you have nothing to play with. Nothing requires it,
nothing even suggests it, you get nothing to start playing with, it is not
necessary. Fortunately, same applies to Python that I never install. But I
can't get rid of Perl, nothing works if I do, and PHP is just so cool toy.
So yes, you could say Tcl is lacking advertising, and pl2tcl system script
converter.
> Or is there another reason?
There is one more reason: none is asking these questions about those other
languages :)
--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done
sleb...@gmail.com
Standard answer for this is at: http://wiki.tcl.tk/590
As to why Tcl is not as popular, basically some people didn't like Tcl
and they turned out to be very influential *cough*RMS*cough*. And there
was a war waged against Tcl and detractor's polularity won against the
supporter's reason. The rest, as they say, is history.
BTW, Tcl tend to sneak its way into popular use. Expect is a good
example. After playing with expect most people can't think of an easier
way to achieve what expect can do. Or of a simpler language to script
expect. Another good example is AOLserver.
I'm guilty of staging such sneak attacks myself. I kind of forced my
former employer to let Tcl co-exist with VB not by being stubborn. But
by prototyping software very quikly in Tcl. The VB guys would take a
whole day to prototype something and I can whip up a prototype in my
spare time during lunch. The prototypes eventually grew and got shipped
to the end user. I was able to implement so many features so quickly
that the prospect of porting my "hack" to VB became very challanging.
It was easier to re-train the VB guys to write Tcl than to port the app
to VB.
Cameron Laird
<rea...@yahoo.com> wrote:
.
.
.
>I have to hold a speech on any arbitrary technical subject soon for a
>room of techies and I've thought about introducing them to TCL, since
>many have heard of Expect, but don't realize it's built on top of TCL.
.
.
This is *very* common, and does indeed deserve mention.
lvi...@gmail.com
According to <rea...@yahoo.com>:
:1. why use TCL and not Perl for example?
Why use Perl instead of Java or C or C++?
I mean, if you use C, you should be able write any code you want.
The reason people use scripting languages at all is that it improves the
speed of getting to the goal quicker.
So why use Tcl instead of some other scripting language? Most of the
major scripting languages have similar capabilities. Learning one is
generally enough. There's no technical reason for needing to learn
dozens of scripting languages if someone is writing original code.
Pick one that has a lot of support for easy to write code, good documentation,
lots of extensions/modules/ways to leverage code written by others so you
don't have to re-invent the wheel, and which has a great user community and
maintenance team.
If someone feels that Perl has all of that, why fight them over it? Let
them stay there. If someone doesn't currently know a scripting language,
or is unsatisfied with the scripting language they are using, then Tcl
becomes a tool to suggest.
One other reason to learn Tcl. Probably the most important reason for
a programmer to learn Tcl is to be able to use things written to be used
with Tcl. For instance, the Perl and Python Tk bindings depend on the
Tcl underneath. So learning Tcl makes using those tools easier. Other
people know, or want to know, Expect, or Scotty, or some other useful
tool written in Tcl. Learning Tcl allows them to enhance and extend
(and sometimes, the extendability is built into the tool).
:2. what are its (dis)advantages?
Few, if any, books sitting on the neighborhood bookstore shelves.
:3. what's on the outlook? Is it going to remain a tool used by a few,
:while the rest of the world moves on with Perl, PHP, Bash and Java?
Define "used by a few". For instance, users of AOL's web sites are using web
servers written in Tcl. Do those people count? I don't have a list of
the current popular web sites using Tcl - perhaps someone else here does.
Then there are other popular Linux tools written in Tcl and Tk. And
Tcl and Tk are shipped with MacOS X. Anyone know of any highly used Tcl/Tk
apps on Windows?
:What else? I know these are same old typical questions, but they are
:asked. I've been around a lot of experienced programmers, most on linux
:platform, and nobody, including myself, had heard of TCL before, even
:though some knew about Expect. How come?
Because most of the people writing articles, etc. these days are writing
about Java, and most of the schools don't teach scripting - if they
do, they generally teach Perl because it is used on many web sites.
:What does PHP or Perl have
:that TCL does not?
In general, neither have "something" that one cannot download or code
for Tcl. However, at least Perl comes with more functions "out of the
box" as well as a pretty slick interface to a world wide, supported,
repository of add on functionality. While at least one or
two people have written repositories for Tcl, none of them have set the
tcl community on fire to join in and support.
:If TCL is a specialized tool for a particular
:purpose, then what is it?
It isn't a specialized tool.
:I know the idea of TCL, why re-invent the wheel for every tool that
:supports some kind of scripting when you can use TCL libs, but why
:Perl. PHP and all the other?
It's the "not invented here" syndrome, in my opinion. Different
people resonate with different languages. Same reason there are hundreds,
if not thousands, of human languages. Why doesn't everyone speak just
one human language?
:What's TCL's flaw? It seems faster to me
:than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
:is there another reason?
Oh, there was a bit of advertising. But it has always been drowned out
by the popular press for perl, then python, then java. Shrug. For me,
Tcl works just as well as it would if there were 10 times more users.
And I suspect I get quicker answers to my questions now ... because it
doesn't seem that the size of the community involvement increases
geometrically, let alone exponentially, as the user base increases.
--
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
Cameron Laird
>wonder how I can convince them of the benefits of TCL. By testing the
>waters, the first responses I got were:
>
>"Why yet another language to learn? I can do everything I want with
>Perl, and has a greater userbase".
>
>So, help me here..
>
>1. why use TCL and not Perl for example? (my answer was the legibility
>but they just say it's a matter of taste and what you're used to)
>2. what are its (dis)advantages?
>3. what's on the outlook? Is it going to remain a tool used by a few,
>while the rest of the world moves on with Perl, PHP, Bash and Java?
>
>What else? I know these are same old typical questions, but they are
>asked. I've been around a lot of experienced programmers, most on linux
>platform, and nobody, including myself, had heard of TCL before, even
>though some knew about Expect. How come? What does PHP or Perl have
>that TCL does not? If TCL is a specialized tool for a particular
>purpose, then what is it?
>I know the idea of TCL, why re-invent the wheel for every tool that
>supports some kind of scripting when you can use TCL libs, but why
>Perl. PHP and all the other? What's TCL's flaw? It seems faster to me
>than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
>is there another reason?
.
.
You do NOT have to know everything about Tcl to make a good
presentation--although it often helps.
Your colleagues are right: to zeroth order, Perl and Tcl *are*
the same language, and much of the difference in practice is a
matter of taste.
How does Tcl compare to Perl? <URL: http://wiki.tcl.tk/1330 >
has details.
In these terms, I don't particularly expect Tcl ever to be other
than "a tool used by the few". On the other hand, I *do* expect
Tcl to be around for a long time into the future, arguably longer
than Perl or PHP. In any case, <URL: http://wiki.tcl.tk/1887 >
might interest you.
Why have people, including you, heard of PHP and Perl, but not
Tcl? I suspect that the true answer is a subtle one,
involving a conjunction of marketing and technical realities
that few have the experience to synthesize. I can assure you
that the ethos of Tcl practitioners is characteristically less
... aggressive than that which has prevailed in the Perl and
PHP communities. For a variety of historical reasons, pugna-
cious zealotry hasn't been Tcl's style.
Tcl is a specialized tool for tasks which are hard to character-
ize in Perl and PHP terms: high reliability, convenient
interfacing, technical flexibility, ...
Tcl *is* faster than PHP, and more readable than Perl. Why
isn't it known, or even dominant? I repeat: there are a
variety of historical reasons, many of the most prominent
having to do with vagaries of The Web's evolution.
I was an early adopter and advocate for both Perl and PHP,
incidentally.
You have correctly identified that Tcl originated as a
technology for implementation of extension languages. As
of 2005, though (or even 1995, for that matter), it's most
appropriate to present it as a potent general-purpose
language which happens to be particularly successful in
embedded situations.
Ray
"Why have people, including you, heard of PHP and Perl, but not
Tcl? I suspect that the true answer is a subtle one,
Aside from Scriptics - perhaps even that can be ignored, was Tcl ever
marketed?
Larry W. Virden
touting articles about Tcl on the sun.com front page count? Does
articles in various magazines, from Dr. Dobbs, to various Linux
magazines, to Computerworld count? Does major companies like Oracle and
Vignette using and advertising they use Tcl count?
Cameron Laird
My congratulations, by the way, to the PHPers. The project has
been on the verge of collapse at least a couple of times, and
received serious non-help at crucial times from organizations
that might have made a difference. Despite these obstacles, it
has flourished. Along with its intimacy with Apache, its early
collaborative documentation was essential, in my view.
Eckhard Lehmann
> but they just say it's a matter of taste and what you're used to)
Because you often need to read and *understand* your code 6 or 12
months later - this is complicated with perl.
> 2. what are its (dis)advantages?
- It does not appear in manager magazines, and seldomly on the shelves
of book stores.
- The documentation is sometimes hard to grab, if you are used to the
per-class-or-method documentation that is employed in Java, python and
modern pure OO languages. This is indeed a problem: developers don't
want to read entire manpages just to find out how a command works -
they want a short description on exact this command with all arguments
(options) and want to find this within a few seconds when they need it.
- really the lack of momentum. No one knows Tcl, no one knows how
successful projects with Tcl can be. But everyone has heard something
about Java somewhere. So, just because of this fact, Java gains more
confidence in projects. It is really necessary to advertise successful
projects written in Tcl/Tk, and tell the world what is inside.
> 3. what's on the outlook? Is it going to remain a tool used by a few,
> while the rest of the world moves on with Perl, PHP, Bash and Java?
Tcl will always have its niche as embeddable scripting language and in
testing environments. Tk will always be included as Widget set in other
scripting languages. But I doubt that Tcl will ever be as widely spread
as Python or PHP.
A new environment could be these embedded handheld/PDA systems and the
like. When I see it right, Tcl is one of the first _scripting_
languages that runs on these systems - and that is great ;-).There
should be more of such efforts... how about bringing Tcl to the .Net
platform, for instance a Tcl-> .Net compiler?
> What else? I know these are same old typical questions, but they are
> asked.
Tell them about Tclkit (http://wiki.tcl.tk/2?Q=tclkit). IMHO, this is
one of the best technologies available.
Eckhard
Andreas Leitgeb
> Probably they have a greater userbase knowing
> that they use Perl, its hard to hide the ugly...
QOTW ?
Eckhard Lehmann
Kaitzschu schrieb:
> necessary. Fortunately, same applies to Python that I never install. But I
you don't get around Python when you install recent releases of
OpenOffice or GNOME. It seems to make it's way as scripting environment
in these platforms.
What brings up another question: Why did Sun choose to integrate clumsy
and slow Python as scripting language in OO and not slim and fast Tcl
(which, I think, was developed directly at Sun)? What is the reason
that Tcl was not prefolding into OO scripting at all? That would have
been a great chance to gain popularity...
> There is one more reason: none is asking these questions about those other
> languages :)
No one needs to ask them.
But for Tcl, I see its non-popularity as a real problem. I really think
that something should be done to attract new developers, otherwise the
language evolution will stagnate at some point in time...
Just my 2c
Eckhard
Donal K. Fellows
> What is the reason that Tcl was not prefolding into OO scripting at all?
I take it by "OO" you mean OpenOffice? The answer is probably a
combination of "Large Organization Politics" and "Someone Hacked Around
with Python and Made it Work with OOo, but Nobody Did That with Tcl".
Donal.
Cameron Laird
Eckhard Lehmann <eck...@web.de> wrote:
.
.
.
>What brings up another question: Why did Sun choose to integrate clumsy
>and slow Python as scripting language in OO and not slim and fast Tcl
>(which, I think, was developed directly at Sun)? What is the reason
>that Tcl was not prefolding into OO scripting at all? That would have
.
.
Did Sun have any role? I thought the company just picked up work
that had already been done by outsiders.
Bryan Oakley
> What brings up another question: Why did Sun choose to integrate clumsy
> and slow Python as scripting language in OO and not slim and fast Tcl
> (which, I think, was developed directly at Sun)?
Tcl was not "developed directly at Sun". Tcl only vacationed there for a
few years. Tcl started in the fall of 1987 and didn't show up at Sun
Microsystems until mid 1994, where it stayed through 1997. The influence
of Sun Microsystems therefor lasted only three and a half years, give or
take a month or two.
Eckhard Lehmann
Yes, I do...
> combination of "Large Organization Politics" and "Someone Hacked Around
> with Python and Made it Work with OOo, but Nobody Did That with Tcl".
Someone should have done that with Tcl - probably it would have been
even easier ;-).
Now it is too late, PyUno is rolled out and gets accepted as "the
standard"...
Eckhard
Neil Madden
>>I take it by "OO" you mean OpenOffice? The answer is probably a
>
>
> Yes, I do...
>
>
>>combination of "Large Organization Politics" and "Someone Hacked Around
>>with Python and Made it Work with OOo, but Nobody Did That with Tcl".
>
>
> Someone should have done that with Tcl - probably it would have been
> even easier ;-).
There is TclUno: http://wiki.tcl.tk/tcluno
Robert Hicks
A great "full stack" web framework in the vein of Rails, TurboGears,
Django, Catalyst would be something to show. These frameworks have high
visibility right now. We have Rivet and several db abstraction layers.
Marry them, throw some weight behind Rivet to get it on more platforms
and build a framework around it.
A CPAN implementation "blessed" and used by the community would be
nice.
There was a recent comparison on the Tcl wiki about db abstraction
layers. It would be nice to "pick one" and work to extend it to be a
"defacto" abstraction layer ala the Perl DBI.
Magazine articles...
Web articles...all over...also O'Reilly might be willing to create a
Tcl space like the other have where we could post articles and then
anyone visiting the O'Reilly site would see the blurbs on the main page
and might just read the article and be curious enough to try Tcl.
I would be willing to talk with O'Reilly about a Tcl section if we
could get articles posted. Really some of the little apps that show up
on the wiki would be great little articles that could show how easy
things are in Tcl.
There might be other things as well.
The problem is usually the "someone" problem. "Someone needs to or
should do it but nobody does".
Robert
MH
Robert Hicks <sig...@gmail.com> wrote:
>What do you think should be done?
>
>A great "full stack" web framework in the vein of Rails, TurboGears,
>Django, Catalyst would be something to show. These frameworks have high
>visibility right now. We have Rivet and several db abstraction layers.
>Marry them, throw some weight behind Rivet to get it on more platforms
>and build a framework around it.
>
>A CPAN implementation "blessed" and used by the community would be
>nice.
>
>There was a recent comparison on the Tcl wiki about db abstraction
>layers. It would be nice to "pick one" and work to extend it to be a
>"defacto" abstraction layer ala the Perl DBI.
I don't know if I can find the time, but I'd be interested in something like
this..
Mattias
Robert Hicks
Robert
MH
Robert Hicks <sig...@gmail.com> wrote:
>Which one? : )
>
>Robert
The DB part.
Mattias
Ian Bell
> What do you think should be done?
>
> A great "full stack" web framework in the vein of Rails, TurboGears,
> Django, Catalyst would be something to show. These frameworks have high
> visibility right now. We have Rivet and several db abstraction layers.
> Marry them, throw some weight behind Rivet to get it on more platforms
> and build a framework around it.
>
Don't get me wrong, I think Tcl/Tk is the best thing since sliced bread, but
IMHO it is not going to make an serious impact until the appearance of the
widgets is improved.
Ian
Michael Schlenker
I know from preparing the Tcl database abstraction layer comparision (
http://wiki.tcl.tk/14972 ) that at least the author of Tcldb is looking
for help (and it is my favorit currently, for nicest set of
functionalities, followed by Tclodbc, nstcl-database and DIO). I heard
Michael Cleverly talking about updating nstcl with 8.5 features once 8.5
comes out, and others seem to be interested too.
As most of the Tcl database abstraction layers are somehow OO style i
would propose to pick one of the available ones and port it to the new
Tcl core OO style once it is available, enhancing and including the
missing/nice features of the other into the system.
Michael
Bryan Oakley
>
> Don't get me wrong, I think Tcl/Tk is the best thing since sliced bread, but
> IMHO it is not going to make an serious impact until the appearance of the
> widgets is improved.
Are you aware of the tile project? You wanna talk sliced bread? Tile is
the whole loaf, a jar of jelly and a jar of peanut butter! And a knife.
Coming soon to an 8.5 tcl/tk core near you.
Eckhard Lehmann
> Tcl space like the other have where we could post articles and then
> anyone visiting the O'Reilly site would see the blurbs on the main page
> and might just read the article and be curious enough to try Tcl.
>
> I would be willing to talk with O'Reilly about a Tcl section if we
> could get articles posted. Really some of the little apps that show up
> on the wiki would be great little articles that could show how easy
> things are in Tcl.
This would be *very* effective, IMHO. I would try to participate in
that as good as I can, by submitting articles or anything else..
Eckhard
Donal K. Fellows
> http://wiki.tcl.tk/14972 ) that at least the author of Tcldb is looking
> for help (and it is my favorit currently, for nicest set of
> functionalities, followed by Tclodbc, nstcl-database and DIO). I heard
> Michael Cleverly talking about updating nstcl with 8.5 features once 8.5
> comes out, and others seem to be interested too.
I strongly urge people interested in doing database APIs to take a look
at how SQLite does its higher-level APIs. Richard Hipp's got it right
(and whether or not you use cursors underneath is almost immaterial to
most programmers; do the "Right Thing" instead of overwhelming people
with options with subtle effects).
Donal (the parenthetical part is an attempt to stop the usual complaint
that comes up when this sort of thing is discussed!)
Donal K. Fellows
> Are you aware of the tile project? You wanna talk sliced bread? Tile is
> the whole loaf, a jar of jelly and a jar of peanut butter! And a knife.
QOTW!
Donal.
Adrian Ho
> Why have people, including you, heard of PHP and Perl, but not
> Tcl? I suspect that the true answer is a subtle one,
> involving a conjunction of marketing and technical realities
> that few have the experience to synthesize. I can assure you
> that the ethos of Tcl practitioners is characteristically less
> ... aggressive than that which has prevailed in the Perl and
> PHP communities. For a variety of historical reasons, pugna-
> cious zealotry hasn't been Tcl's style.
You may be on to something there. IMO, Tcl practitioners are often
phlegmatic engineering-mindset types who "just want to get things done".
Consider the following pattern, which I seem to see quite often:
A problem needs to be solved. A team gets assembled to discuss how
to solve it. Much heated discussion about technologies to use, etc.
Meanwhile, Person A (often me 8-) sits quietly in the corner, hacking up a
Tcl script that solves the problem. When everyone pauses from exhaustion
(or someone finally notices that A hasn't said a word and draws everyone's
attention to that fact), A says "well, how about this then?" and shows
everyone the finished script. A long silence and several dirty looks
later, the script gets adopted, the problem is solved, the meeting is
adjourned.
(Personally, I've hardly ever had to defend my choice of Tcl as a primary
scripting language in my daily work, perhaps because, when challenged,
I simply show them the (usually short) Tcl programs that I write and
ask them, "How would *you* do this in Perl/PHP/whatever...and how long
would it take you?" 8-)
Another opinion: Works of Perl/Python/etc. art often evoke cries of
"Wow, that's amazing, how did you do that, you are a programming GOD!",
probably due to various obscure tricks that are hard for the average
eye and brain to follow. Works of Tcl art, OTOH, often elicit an "Oh,
that's obvious." To be a zealot, methinks one needs a better battle
cry than "Tcl's the BOMB coz it's so OBVIOUS!" 8-)
=====
From the technical marketing perspective, I'd argue that Tcl is *too*
simple and easy-to-use for the current crop of "technical marketers"
to make much money on. As I'm writing this, I'm looking at my
bookshelf, which contains, among many other things:
* a dozen C++ books
* 3 dozen Java books
* 10 Tcl books (Welch, Libes, Flynt, etc.)
(The above list is in chronological order of my use of said languages
over the last 10 years.)
If you were standing beside me, you'd notice one odd thing about the
books: The C++ and Java books are well-thumbed, but the Tcl books are
still in pristine condition, because I've hardly had to refer to them.
In fact, I bought them long *after* I started using Tcl[*] (unlike the
other books that I needed just to get started), not because I needed to
look them up, but because their comparative rarity to the quintillions
of Java/C++/.NET/etc. books stirred some bizarre collector's urge in me.
[*] Again, but by that time, I'd pretty much forgotten everything about
Tcl. It's a testament to Tcl's utter simplicity that I could hit the
ground running 12 years after, without resorting to a single "how-to" book.
Lisa Pearlson
I can do everything with it, and doesn't seem all that hard or complex to
me.. I moved to windows platform years ago for commercial reasons (feeling
not so much as a collaborater, but rather a victim.. fortunately I've moved
more than half of my efforts back to linux platform).
I never liked VB, never bothered to learn Perl, used but disliked ASP, and
settled with PHP for web stuff.
But I've embraced TCL.. in just 2 weeks time.. why?
Well, I agree, if you want power, use C, you want glue, use the best glue
there is..
When I got a new PC, I never bothered to upgrade to the next one out.. I
made the jump from 486 to Pentium II en then to Pentium 4. In other words,
the change should be significant enough for me to make the big leap.
Everything in between is not significant enough.
I never liked, for wrong reasons (laziness to learn, choosing alternatives I
was already familiar with) scripting languages, but TCL does it all.. can be
used for DHTML (Rivet?), shell scripting, windows (Tk), VERY easy to use,
very quick to learn, powerful, extendible, ..
But I know I can't be a good judge since I am too unfamiliar with the
alternatives.. but TCL looks pretty on the inside and outside, .. the other
ones not on the outside, perhaps they do on the inside.. dunno.
What I do feel lacking is indeed something like CPAN, or aptitude/apt-get to
easily add/delete modules and upgrade them.
And installing the MD5 package for TCL was too painful for me. Still not
sure what steps are exactely required to install/remove a package (but I
know there is documentation available.. just have to read it).
Should be more plug and play to make setup just as convenient as the actual
tcl coding itself.
And I don't understand Tk yet.. that looked like chinese to me at first
sight.. haven't looked at it since.. and I don't understand the relationship
between TCL en TK yet.. TK is not part of or dependent on TCL, but a thing
of its own, that can be scripted with TCL, but Perl or any other language
that supports TK, do I understand that correctely?
Lisa
<lvi...@gmail.com> wrote in message news:dmkf8h$mdo$1...@mailhost.cas.org...
Lisa Pearlson
Recently I upgraded to Apache2.. just a new Debian setup, I thought "why not
get the latest and greatest version on this new install?". Only to have
problems with PHP.. because it doesn't work with the DEFAULT apache2 setup,
that uses mpm-worker thread... had to install apache2-mpm-prefork instead.
I read about it, and.. found the depate about Apache and PHP shoving off
blame to eachother.. PHP is not thread safe, and is declared that PHP has no
intention to ever support Apache2 in its multithreaded mode that actually
boost Apache2 performance and memory requirements, but that it isn't their
problem.. And Apache2 doesn't see it as their problem either.
This is just stuff I picked up on the news group.. now, I love PHP.. and use
it plenty, however, can't TCL take adventage of this current issue to 'catch
up' and perhaps even surpass PHP's popularity?
Is TCL thread safe? Does it support Apache2's new threading model?
I've used PHP for a few years and TCL only for 2 weeks and I'm already
willing to make the switch.. no, of course you should not present PHP as the
enemy, and with that, all of its addicts.. keep them a friend, get them to
use it side by side first.. TCL doesn't have to rule the world, as long as
it's known as well as the other alternatives.
Lisa
"Cameron Laird" <cla...@lairds.us> wrote in message
news:ss6163-...@lairds.us...
Lisa Pearlson
and Apache2's new threading model.
Does TCL suffer the same issues, or could TCL take advantage of the fact
that Apache and PHP have come to a point of weakness, to a point where they
point fingers at eachother (from what I read in some news groups, in an
effort to find out why PHP5 wasn't working with Apache2 with
apache2-mpm-worker on Debian Sarge)
Lisa
"Robert Hicks" <sig...@gmail.com> wrote in message
news:1133477674.5...@g44g2000cwa.googlegroups.com...
Michael Schlenker
> Michael Schlenker wrote:
>> http://wiki.tcl.tk/14972 ) that at least the author of Tcldb is looking
>> for help (and it is my favorit currently, for nicest set of
>> functionalities, followed by Tclodbc, nstcl-database and DIO). I heard
>> Michael Cleverly talking about updating nstcl with 8.5 features once 8.5
>> comes out, and others seem to be interested too.
>
> I strongly urge people interested in doing database APIs to take a look
> at how SQLite does its higher-level APIs. Richard Hipp's got it right
> (and whether or not you use cursors underneath is almost immaterial to
> most programmers; do the "Right Thing" instead of overwhelming people
> with options with subtle effects).
I can just agree with Donal on this. SQLites API is really a nice fit
for Tcl, some of the abstraction layers move in similar directions, but
non of them really has this smooth set of interlocking features
introduced in SQLites Tcl API. The SQLite eval method with its variable
binding and autoquoting in querys, the flexible way to get the result
set with no fuzz (the only thing thats missing is returning nested
lists, but thats trivial to do.), the really good transaction support,
the callbacks for progress and transactions, all really nice.
The basic DB functionality is done really good in the SQLite API and
others could benefit from picking it up instead of basically porting the
C API exposed by their database to Tcl without adapting the API.
What some of the Tcl DB Abstraction Layers offer are things like support
functions for portable table constructions, table objects to use for
easy handling of the result sets and other nice extras. But those are
extra, on the basic database access API all DB abstraction layers are so
close to each other (see the above mentioned comparision) that they
could simply unify on something very similar to the SQLite API and just
put their cool extras into addon packages.
Michael
Ian Bell
I had heard of the tile project but was *not* aware it was feted for
inclusion in 8.5. I am off to that URL RIGHT NOW!!
Ian
Lisa Pearlson
Apache2 from Apache 1.3 because of the incompatibility issue. To make PHP
work with Apache2 requires the use of the prefork model instead of the
default, which is said to actually make Apache slower and more resource
hungry and thus defeats much of the purpose to upgrade.
So this PHP/Apache2 issue is working against the two instead of helping each
other it seems.
I read and understand too little about the threading issues of PHP and
Apache2, but I wonder if TCL, if it doesn't suffer the same constraints as
PHP, could initially used as some kind of stub/proxy to process PHP scripts
on behalf of Apache2 so that it sits between PHP and Apache and perhaps this
was resolves the threading issue? Perhaps I'm talking crap, but such thing
would sneak TCL into the PHP world, and soon enough take it over.
Lisa
"Lisa Pearlson" <n...@spam.plz> wrote in message
news:43906955$0$13786$e4fe...@dreader17.news.xs4all.nl...
Michael Schlenker
> Hmmm.. interesting point..
> Recently I upgraded to Apache2.. just a new Debian setup, I thought "why not
> get the latest and greatest version on this new install?". Only to have
> problems with PHP.. because it doesn't work with the DEFAULT apache2 setup,
> that uses mpm-worker thread... had to install apache2-mpm-prefork instead.
>
> I read about it, and.. found the depate about Apache and PHP shoving off
> blame to eachother.. PHP is not thread safe, and is declared that PHP has no
> intention to ever support Apache2 in its multithreaded mode that actually
> boost Apache2 performance and memory requirements, but that it isn't their
> problem.. And Apache2 doesn't see it as their problem either.
>
> This is just stuff I picked up on the news group.. now, I love PHP.. and use
> it plenty, however, can't TCL take adventage of this current issue to 'catch
> up' and perhaps even surpass PHP's popularity?
>
> Is TCL thread safe? Does it support Apache2's new threading model?
> I've used PHP for a few years and TCL only for 2 weeks and I'm already
> willing to make the switch.. no, of course you should not present PHP as the
> enemy, and with that, all of its addicts.. keep them a friend, get them to
> use it side by side first.. TCL doesn't have to rule the world, as long as
> it's known as well as the other alternatives.
AFAIK Rivet also has problems with the Apache2 threading model. WebSH
supports Apache2, but i do not know if there are problems with threads.
Contact David N. Welton on the rivet mailing if your interested in all
the gory details of Threads + Rivet. AFAIK Rivet does not blame Apache
for their new thread model, it was just not yet ported to the new thread
model.
But to Tcl is thread safe, see for example the massive use of multi
threaded Tcl inside aolserver (which had a threaded instead of a fork()
based model from the start, unlike Apache). So yes, you can do high
performance web stuff with Tcl in threaded environments, there needs
just to be someone to do the work and port Rivet to multi threaded Apache.
Michael
Robert Hicks
I don't agree with that. Just about every "dynamic" language has Tk
bindings and I have never seen anything about "I chose Python because
of Tkinter". We might as well shock the world and say we are going to
focus on a "Wx" implementation instead of "Tk". Wx is starting to show
up on all the major OS's (Widows, Linux, OSX, BSD's). I don't think
Tk+Tile is going to create an influx of users for Tcl because all the
other languages that tie into Tk will get that benefit as well.
All of the things I mentioned were outside of Tk. Python is in the news
because of TurboGears and Django. Ruby is in the news because of Rails.
Java goes without saying but most of the things I see about it are
about frameworks that make developing web applications easier. Even
Perl is starting to come on with its framework Catalyst.
Let's suppose that we do those 4 things I mentioned (a full stack
framework, a more visible blogspace like O'Reilly, a db abstraction
layer, and a CPAN like repository). Now let's suppose that we
implemented them and it didn't do anything to bring Tcl into the
limelight. The one thing it would do is give the current community some
really good tools to work with that people have posted over and over
about wanting. That can only be a good thing for the community.
Those are my thoughts...
Robert
Cameron Laird
Lisa Pearlson <n...@spam.plz> wrote:
.
.
.
>And I don't understand Tk yet.. that looked like chinese to me at first
>sight.. haven't looked at it since.. and I don't understand the relationship
>between TCL en TK yet.. TK is not part of or dependent on TCL, but a thing
>of its own, that can be scripted with TCL, but Perl or any other language
>that supports TK, do I understand that correctely?
.
.
<URL: http://wiki.tcl.tk/487 >
Ian Bell
> Bryan Oakley wrote:
>
>> Ian Bell wrote:
>>>
>>> Don't get me wrong, I think Tcl/Tk is the best thing since sliced bread,
>>> but IMHO it is not going to make an serious impact until the appearance
>>> of the widgets is improved.
>>
>> Are you aware of the tile project? You wanna talk sliced bread? Tile is
>> the whole loaf, a jar of jelly and a jar of peanut butter! And a knife.
>>
>> Coming soon to an 8.5 tcl/tk core near you.
>>
>> http://tktable.sourceforge.net/tile
>
I have had a good look at tile. It is certainly an improvement over the
standard widget set. At least the default scroll bars look decent at last
but why oh why do we still swap the mouse pointer direction when a menu is
selected????? I notice the Keramik theme manages to avoid this behavior in
a menu button but all themes seem to retain it in the main menu bar. The
only other prog I know of that still does this is Xemacs.
Ian
Ian Bell
I don't disagree with anything you have said. However I want to create GUI
apps that look as good as any other and with the current Tk widget set they
don't. I am not interested in eye candy but I am interested in relaxing my
end users by presenting them with a familiar looking/acting interface ( or
rather not sensitising them to think this is somehow an odd app. simply
because the UI looks odd). Tk is a very visual interface and its appearance
is very important.
Ian
Malcolm Dew-Jones
: can't TCL take adventage of this current issue to 'catch
: up' and perhaps even surpass PHP's popularity?
No.
Bryan Oakley
> I have had a good look at tile. It is certainly an improvement over the
> standard widget set. At least the default scroll bars look decent at last
> but why oh why do we still swap the mouse pointer direction when a menu is
> selected?????
You're probably just seeing the remnants of old standards at play. You
don't see a different cursor on MacOSX or Windows. Though, tile will
likely do nothing to solve this particular problem. I think the plan is
that tk apps will still use the tk menu widget for menubars.
If you want this behavior changed, perhaps you can submit a feature
request to sourceforge.
Lisa Pearlson
list!
Easy install, update and upgrade lowers the barier greatly for somebody to
install and use it.. with the thought that it only takes a second to
install, and uninstall if they don't like it.. but they will.. especially if
there are some samples to play with.
TCL is nice, cool, and quality will sell itself, but not if it remains
unseen en thus unknown.. CPAN lowers the barrier significantly. TCL allowes
quick and easy development of code, but this ease should also be part of the
entire TCL experience, including its install.
For example, I struggled to get MD5 installed.. I tried it manually from a
sourceforge tar, and got all kinds of errors and crap.. fortunately I also
found a debian package libtcl or something with some standard stuff
including MD5, so I got that working.. but my next problem is getting MySQL
support.. and I found no Debian package for it..
We shouldn't have to depend on Debian or RPM or whatever, to easily install
TCL packages.
Lisa
"Robert Hicks" <sig...@gmail.com> wrote in message
news:1133538880.5...@g47g2000cwa.googlegroups.com...
Lisa Pearlson
effort (technically it already can, but it's unknown.. and much easier to
learn.. Organize a programming competition between tcl programmers and
perl/php programmers, just for fun.. or send in a comparison chart to
existing popular computer/linux/programming magazines en start a flame war..
after the dust settles, they will all be known and accepted side by side..
any fame is better than no fame in this case).
But the most interesting part here is, embedded systems.. indeed.. I used to
be a PalmOS programmer.. I abandoned it because programming for it was too
cumbersome.. the tools were primitive and a palm 'database' is just a flat
file, and reading a 'record' meant reading from a certain offset in this
file.. if you wanted a free compiler, you had a seperate resource compiler
and primitive compiler, linker, etc.. took forever to write a decent
application and it drew many of the old Amiga hardcore assembler
programmers, due to its Motorola CPU.
PalmOS was small, fast, battery efficient, simple, plain, minimalistic, and
application was just a few Ks, while WindowsCE on a pocket pc was like a
typical microsoft SUV that guzzles all of the world's natural resources, it
was very nice and easy to develop software for.. for commrecial reasons I
made the switch en now I develop on SmartPhone (Windows Mobile) platform..
But still, lacking frameworks like MFC, it takes quite some effort to
develop apps for it, that would be a breeze with TCL/Tk. And since
smartphones are becoming common place, with a huge userbase (well, mobile
phones with java anyay), it would be a great platform for tcl. It could be
the easiest tool on that platform, with little competition (Except java).
I for one would love to be able to write internet applications on my I-Mate
SP5 Windows Mobile smart phone, but TCL would make a far bigger difference
on the PalmOS platform.. because it would make palm programming easy..
perhaps much has changed on that platform since I abandoned it (multimedia
features), but tcl ports to palm, windows ce, symbian and linux based PDA's
could change the world. Java is slow on these platforms..
Write 1 video game, that runs on all these platforms, requiring tcl, free
download, and all the kids will be indoctrinated in no time.
Lisa
"Eckhard Lehmann" <eck...@web.de> wrote in message
news:1133385884.1...@z14g2000cwz.googlegroups.com...
>> 1. why use TCL and not Perl for example? (my answer was the legibility
>> but they just say it's a matter of taste and what you're used to)
>
> Because you often need to read and *understand* your code 6 or 12
> months later - this is complicated with perl.
>
>> 2. what are its (dis)advantages?
>
> - It does not appear in manager magazines, and seldomly on the shelves
> of book stores.
> - The documentation is sometimes hard to grab, if you are used to the
> per-class-or-method documentation that is employed in Java, python and
> modern pure OO languages. This is indeed a problem: developers don't
> want to read entire manpages just to find out how a command works -
> they want a short description on exact this command with all arguments
> (options) and want to find this within a few seconds when they need it.
> - really the lack of momentum. No one knows Tcl, no one knows how
> successful projects with Tcl can be. But everyone has heard something
> about Java somewhere. So, just because of this fact, Java gains more
> confidence in projects. It is really necessary to advertise successful
> projects written in Tcl/Tk, and tell the world what is inside.
>
>> 3. what's on the outlook? Is it going to remain a tool used by a few,
>> while the rest of the world moves on with Perl, PHP, Bash and Java?
>
> Tcl will always have its niche as embeddable scripting language and in
> testing environments. Tk will always be included as Widget set in other
> scripting languages. But I doubt that Tcl will ever be as widely spread
> as Python or PHP.
> A new environment could be these embedded handheld/PDA systems and the
> like. When I see it right, Tcl is one of the first _scripting_
> languages that runs on these systems - and that is great ;-).There
> should be more of such efforts... how about bringing Tcl to the .Net
> platform, for instance a Tcl-> .Net compiler?
>
>> What else? I know these are same old typical questions, but they are
>> asked.
>
> Tell them about Tclkit (http://wiki.tcl.tk/2?Q=tclkit). IMHO, this is
> one of the best technologies available.
>
>
> Eckhard
>
Joe English
>I don't disagree with anything you have said. However I want to create GUI
>apps that look as good as any other and with the current Tk widget set they
>don't.
It's possible to make Tk apps look better with little effort --
Jeff Hobbs has a great tutorial on how to do this, check the
Tcl'2005 conference proceedings -- and with a *lot* of effort
you can make a truly spectacular Tk GUI (see e.g., Coccinella).
As for making apps that look "as good as any other", I think
the main problem is simply one of age. Tk's default look and feel
actually *was* a lot better than the industry standard on X11
(Motif), but that was 10 years ago, and fashions have changed
since then. (The Tile widget set attempts to address this issue).
It's true, Tk "out-of-the-box" doesn't look very modern; that's
largely due to the core maintainers' strong commitment to backwards-
compatibility (just *try* to provide a button widget that doesn't
have a '-bg' option and watch how many existing users complain :-)
But it's certainly *possible* to make a good-looking Tk app;
and with the 8.5 release it will (we hope) even be *easy*.
--JE
Joe English
>[...] if you want power, use C, you want glue, use the best glue
>there is..
QOTW nomination!
[...]
>And I don't understand Tk yet.. that looked like chinese to me at first
>sight.. haven't looked at it since..
You are due for a very pleasant surprise. Take a second look
at Tk, it is (still!) the best/easiest UI toolkit around.
(IMO, of course).
> and I don't understand the relationship
>between TCL en TK yet.. TK is not part of or dependent on TCL, but a thing
>of its own, that can be scripted with TCL, but Perl or any other language
>that supports TK, do I understand that correctely?
Tk *is* dependant, to a degree, on Tcl -- it's a UI toolkit
done "the Tcl way". Which is what makes it the best (IMO, again).
Other languages (Perl, Python, probably Ruby, don't know) have
Tk modules, but those bindings tend to be second-class citizens;
(maybe Jeff will chime in with further details). But to fully
appreciate how great Tk is, you really need to use it from Tcl.
--je
Mike Rogers
them the following:
Tcl IS significantly different from Perl (or Python, or Ruby, or PHP,
...) because I can turn it into anything that I like. If I don't like
any of the existing OO extensions, then I make my own (I have make two
different ones, which each have their own advantages). If a new
languagle construct will make problem solving in the current domain, I
simply add it (and I do mean simply).
Doing such dynamic things in other languages is MUCH more difficult
(simply not worth it, effortwise, in most cases).
You can look on the Tclers Wiki for countless examples (Try...Catch
that looks like Java, playing other languages page, multiple OO
extensions, ...)
Mike
Cameron Laird wrote:
> In article <1133358188.3...@g14g2000cwa.googlegroups.com>,
> <rea...@yahoo.com> wrote:
> .
> .
> .
> >Since 2 weeks has not been enough for me to know all ins and outs, I
> >wonder how I can convince them of the benefits of TCL. By testing the
> >waters, the first responses I got were:
> >
> >"Why yet another language to learn? I can do everything I want with
> >Perl, and has a greater userbase".
> >
> >So, help me here..
> >
> >1. why use TCL and not Perl for example? (my answer was the legibility
> >but they just say it's a matter of taste and what you're used to)
> >2. what are its (dis)advantages?
> >3. what's on the outlook? Is it going to remain a tool used by a few,
> >while the rest of the world moves on with Perl, PHP, Bash and Java?
> >
> >What else? I know these are same old typical questions, but they are
> >asked. I've been around a lot of experienced programmers, most on linux
> >platform, and nobody, including myself, had heard of TCL before, even
> >though some knew about Expect. How come? What does PHP or Perl have
> >that TCL does not? If TCL is a specialized tool for a particular
> >purpose, then what is it?
> >I know the idea of TCL, why re-invent the wheel for every tool that
> >supports some kind of scripting when you can use TCL libs, but why
> >Perl. PHP and all the other? What's TCL's flaw? It seems faster to me
> >than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
> >is there another reason?
> .
> .
> .
> You do NOT have to know everything about Tcl to make a good
> presentation--although it often helps.
>
> Your colleagues are right: to zeroth order, Perl and Tcl *are*
> the same language, and much of the difference in practice is a
> matter of taste.
>
> How does Tcl compare to Perl? <URL: http://wiki.tcl.tk/1330 >
> has details.
>
> In these terms, I don't particularly expect Tcl ever to be other
> than "a tool used by the few". On the other hand, I *do* expect
> Tcl to be around for a long time into the future, arguably longer
> than Perl or PHP. In any case, <URL: http://wiki.tcl.tk/1887 >
> might interest you.
>
> Why have people, including you, heard of PHP and Perl, but not
> Tcl? I suspect that the true answer is a subtle one,
> involving a conjunction of marketing and technical realities
> that few have the experience to synthesize. I can assure you
> that the ethos of Tcl practitioners is characteristically less
> ... aggressive than that which has prevailed in the Perl and
> PHP communities. For a variety of historical reasons, pugna-
> cious zealotry hasn't been Tcl's style.
>
> Tcl is a specialized tool for tasks which are hard to character-
> ize in Perl and PHP terms: high reliability, convenient
> interfacing, technical flexibility, ...
>
> Tcl *is* faster than PHP, and more readable than Perl. Why
> isn't it known, or even dominant? I repeat: there are a
> variety of historical reasons, many of the most prominent
> having to do with vagaries of The Web's evolution.
>
> I was an early adopter and advocate for both Perl and PHP,
> incidentally.
>
> You have correctly identified that Tcl originated as a
> technology for implementation of extension languages. As
> of 2005, though (or even 1995, for that matter), it's most
> appropriate to present it as a potent general-purpose
> language which happens to be particularly successful in
> embedded situations.
Eckhard Lehmann
> because of TurboGears and Django. Ruby is in the news because of Rails.
> Java goes without saying but most of the things I see about it are
> about frameworks that make developing web applications easier. Even
> Perl is starting to come on with its framework Catalyst.
There is AOLserver with much Tcl functionality. If all the small
commands and libraries were aggregated into an abstract and powerful
web development framework, that would be an option, wouldn't it?
I would not start something completely new - it usually takes ages
until new projects are usable and customers are more confused, when too
many options/libraries/programs are available (what of the 34 web
development frameworks for Tcl should I use, which is the best one?)...
Let's rather extend and improve things that already exist here.
The problem is always the question "who should do it?". It is almost a
full time job for someone, and this person(s) has to draw a sallary...
I've seen at the page of RubyOnRails, that they provide hosting, and a
fraction of the hosting income goes into Rails development. Would this
be an option, maybe in addition to other things?
Eckhard
Eckhard Lehmann
big and provides much functionality... but obviously, a HTML template
library is missing.
And I meant "salary", not "sallary" (non-native-speaker-error ;-)).
Eckhard
David N. Welton
> I for one would love to be able to write internet applications on my I-Mate
> SP5 Windows Mobile smart phone, but TCL would make a far bigger difference
> on the PalmOS platform.. because it would make palm programming easy..
> perhaps much has changed on that platform since I abandoned it (multimedia
> features), but tcl ports to palm, windows ce, symbian and linux based PDA's
> could change the world. Java is slow on these platforms..
They just aren't fast platforms, first of all. Tcl isn't likely to beat
Java in the speed arena.
That said, have a look at Hecl (www.hecl.org) - it's still in the
initial stages, but you can write small programs for any J2ME system
with it!
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
David N. Welton
> For example, I struggled to get MD5 installed.. I tried it manually from a
> sourceforge tar, and got all kinds of errors and crap.. fortunately I also
> found a debian package libtcl or something with some standard stuff
tcllib, the standard Tcl library. Although if it's standard, it's a
pity it doesn't ship with Tcl...
> including MD5, so I got that working.. but my next problem is getting MySQL
> support.. and I found no Debian package for it..
There are several. 'mysqltcl' for instance.
> We shouldn't have to depend on Debian or RPM or whatever, to easily install
> TCL packages.
The best that we're likely to attain anytime in the near future is to
have a 'batteries included' distribution that includes all kinds of
stuff like tcllib.
Robert Hicks
anything. I am very excited about Tile myself.
Robert
Robert Hicks
a separate section goes to those who get high enough traffic.
So if you are a Tcl'er, I would start to submit articles to O'Reilly.
That is one easy way to get some Tcl exposure.
Ian Bell
>
> It's possible to make Tk apps look better with little effort --
> Jeff Hobbs has a great tutorial on how to do this, check the
> Tcl'2005 conference proceedings -- and with a *lot* of effort
> you can make a truly spectacular Tk GUI (see e.g., Coccinella).
>
I have searched but I cannot find the proceedings anywhere. I have found a
reference to the topic in the tutorials section and I have even checked
Jeff Hobbs' web page but the article is not there either.
Ian
Ian Bell
I would like it changed, more so because I had not realised it was limited
to Linux/Unix platforms. I'll do as you suggest.
Thanks
Ian
Donal K. Fellows
> I have searched but I cannot find the proceedings anywhere. I have found a
> reference to the topic in the tutorials section and I have even checked
> Jeff Hobbs' web page but the article is not there either.
As they were content you had to pay extra for, the tutorials are not
available online anywhere (well, not unless the people giving them have
put the material up!)
Donal.
Donal K. Fellows
> Tcl IS significantly different from Perl (or Python, or Ruby, or PHP,
> ...) because I can turn it into anything that I like. If I don't like
> any of the existing OO extensions, then I make my own (I have make two
> different ones, which each have their own advantages). If a new
> languagle construct will make problem solving in the current domain, I
> simply add it (and I do mean simply).
Good point. This sort of thing puts Tcl much more in the same sort of
class of languages as Lisp, Forth and ML. It comes at that sort of thing
from quite a different direction to those languages, but that is
elevated company indeed.
The other highly distinguishing factor is the fact that the core
language constructs are on the same linguistic basis as code you write
yourself. I can remember (from years ago when I was learning) that it
was amazing to me that you could replace something fundamental like
[while] with your own version *and* that that new version could be
written in the language itself. That's a very rare combination indeed.
Donal.
Ian Bell
I guessed as much. Proceedings of previous year's are there but I do not
really want to wait that long ;-) I'll email Jeff.
Ian
David N. Welton
I kind of thought they didn't really like Tcl there. Maybe it's not
"Web 2.0" enough;-)
Eckhard Lehmann
> "Web 2.0" enough;-)
Where I really think it is time for "Web 2.0" from a technical and
users point of view. Probably that is the reason why Rails and those
frameworks are so successful... Tcl should catch up here, before it is
too late.
Eckhard
David N. Welton
It is already too late, unless someone descends from the heavens and
starts producing lots of code, and I don't see that happening. As it
is, there aren't enough people working on projects like tclhttpd and Rivet.
The comment about "Web 2.0" is in reference to the fact that it is
basically a marketing term invented by O'Reilly and friends to sell
books about "Web 2.0". I'd rather see book sellers spotting trends and
writing about them, rather than trying to create them.
I like Paul Graham's take on it: http://www.paulgraham.com/web20.html
Eckhard Lehmann
> starts producing lots of code, and I don't see that happening. As it
> is, there aren't enough people working on projects like tclhttpd and Rivet.
No, I don't think so. It is not too late to actually *start* producing
code. I don't know how long it took for Rails to become a usable
framework, but I estimate the _technical_ work involved for a similar
thing in Tcl to be around one year or one and a half - given at least
one person working on it full time.
We should not forget, that there are already very good and stable
building blocks available: Rivet, AOLserver, oratcl (mysqltcl...),
tDOM... and (hopefully) the built in object system in 8.5. It is not
about starting something completely new from scratch, it is about
bringing all these tools together into an usable and abstract framework
(see my other post above). The design patterns are given as well, so
there is not even this to redesign - except for consideration of some
Tcl specific aspects.
Another thought is, that this could give new momentum to projects like
rivet and tclhttp.
This would really rock and show the world that Tcl is alive. I am
certainly not the person who works fulltime on this project (although I
could imagine, if I was currently unemployed ;-)), but I would be happy
to contribute as much as I can.
Eckhard
Nicolas Boretos
> Eckhard Lehmann wrote:
>
>>>I kind of thought they didn't really like Tcl there. Maybe it's not
>>>"Web 2.0" enough;-)
>>
>>
>>Where I really think it is time for "Web 2.0" from a technical and
>>users point of view. Probably that is the reason why Rails and those
>>frameworks are so successful... Tcl should catch up here, before it is
>>too late.
Hello,
I am not really familiar w/ the "Web2.0" phrase, it kinda sounds like
"scubbing bubbles..."
My interpretation of a Web2 might be along the Seaside/Rails
implementations...very OO very pattern based.
WRT "being too late for cl..." and coding from scratch, IMHO, this does
not have to be.
A few years ago, Dr. Neumann and co created their "Actiweb" framework,
which I believe ships with the XOTCL distro.
AFAIU from reading the papers, Actiweb uses a "modern", layered,
patterns based OO approach to web development.
I feel that this framework is a sound foundation for further development...
The architecture consists of the following components,
xoAWO Active Web Objects
xoComm OO implementation of HTTP server
xoReg Object Registry Service
xoRDF RDF parser for matadata
xoXML XML parser
xoStore Persistence layer for active objects
xoMOS Mobile object system
From what I see, there's some similarity with the Rails framework....
RAILS ACTIWEB
Webrick HttpPlace/xoComm
Dispatcher HttpWorker
ActiveRecord xoAWO, xoStore
ActionWebService xoXML xoRDF, xoMOS
Looking at the Rails cookbook tutorial
http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html
1. I noticed that Rails adds the web application tree in one shot...
2. One command maps a class to a db table,
class Recipe < ActiveRecord::Base
end
The corresponding controller is also created..
Kinda cool, I thought, although there seem to be alternative ORM's than
direct class to table mappings...
XOTcl from what I gather, has automatic persistence for objects, and not
necessarily in an RDBMS. I dont know what kind of ORM is in there...
3. The "scaffold" method automatically creates "list, show, edit, and
delete" actions and corresponding view templates...
If one were to also use the tcl plugin, one could also load XOTclide in
the browser and inspect/change the running server
just as one does in Seaside...(or Tclhttpd for that matter...)
While I am not necessarily proposing to copy the Rails framework, I do
think that the foundation of a new(er) web framework for tcl
is there in Actiweb. A templating system would need to be adopted (.tml,
.rvt anyone...)
Might also fit in and showcase the recent OO/XOTcl TIP
Actiweb might need to be christened "Tcl-on-Track" or something catchy
to gain some exposure...
Maybe Dr. N could fill in/comment on the feasilbility of this or some
applications of Actiweb...
regards,
nikos
Robert Hicks
be better. Rivert+db abstraction+whatever-is-cool would be the best
approach.
The problem isn't really "time", it's "people". I know Rivet itself
would be need some help (and lots would be better) to get it going on
Apache2 and on different operating systems. Who is going to step in to
do this when, in a real sense, there is apathy about it in the first
place?
Robert
Christopher Nelson
sleb...@yahoo.com wrote:
> ...
> It was easier to re-train the VB guys to write Tcl than to port the app
> to VB.
Eckhard Lehmann
> implementations...very OO very pattern based.
That's my interpretation, too ;-).
> [ActiWeb]
This sounds very well. I did not actually evaluate it yet, but it seems
like it is exactly what is needed. Thanks for pointing this out...
Eckhard
David N. Welton
>>It is already too late, unless someone descends from the heavens and
>>starts producing lots of code, and I don't see that happening. As it
>>is, there aren't enough people working on projects like tclhttpd and Rivet.
>
>
> No, I don't think so. It is not too late to actually *start* producing
> code. I don't know how long it took for Rails to become a usable
> framework, but I estimate the _technical_ work involved for a similar
> thing in Tcl to be around one year or one and a half - given at least
> one person working on it full time.
So - while Ruby on Rails, Django, and company mature, improve, and add
users and developers in this year and a half, some magic Tcl elf is
going to pop up and dedicate a bunch of time to doing something that
matches what those guys have already? I think that's wishful thinking.
> This would really rock and show the world that Tcl is alive. I am
> certainly not the person who works fulltime on this project (although I
> could imagine, if I was currently unemployed ;-)), but I would be happy
> to contribute as much as I can.
It's a nice thought, but I guess I'm a bit burnt out and disappointed in
what I've seen already. And it's not just Rivet - I follow most of the
other Tcl/web stuff, and none of it really gets the attention it deserves.
I would love to be proven wrong, of course:-)
Robert Hicks
TurboGears just glues together other Pythonic things.
The problem is DEVELOPERS. Who is going to help with Rivet? Who is
going to help with the db abstraction? Those others frameworks are
using some kind of ORM, does Tcl even have an ORM?
I know David would love to have lots of help with Rivet but with none
coming...???
So to end this thread...it is another of those "Tcl should" but "Tcl
can't" because of lack of "developers" and "time".
Robert
P.S. I just want to make it a point. This isn't about David W. as I
think he is doing a good job with Rivet. Nobody is there to help is all
and being the lone man toting the rope gets tiring.
David N. Welton
> P.S. I just want to make it a point. This isn't about David W. as I
> think he is doing a good job with Rivet. Nobody is there to help is all
> and being the lone man toting the rope gets tiring.
There have been lots of people who have helped over the years, and of
course major portions of the code came from people like Damon Courtney
and Karl Lehenbauer.
Anyway, to put a positive spin back on things, here's a suggestion:
If we accept the fact that Tcl is not going to compete with Ruby on
Rails, maybe we can be creative and think of ways that we can still do
cool stuff that they can't.
Here's one idea off the top of my head:
Hack Rivet to use starkits, so that you can put an entire app on your
webserver as a starkit. You could even put sqlite in it and have the
database and everything all wrapped up in one nice tidy package.
There are probably better ones lurking out there, but I guess the point
is that Tcl does some things pretty well... it's best to play off those
strengths rather than chase taillights.
Eckhard Lehmann
David N. Welton schrieb:
> So - while Ruby on Rails, Django, and company mature, improve, and add
> users and developers in this year and a half, some magic Tcl elf is
> going to pop up and dedicate a bunch of time to doing something that
> matches what those guys have already? I think that's wishful thinking.
What about the Actiweb thing or AOLserver? I didn't know about ActiWeb
before, now I would reconsider my time estimation and say it is less
than a year (full time) work on ActiWeb to make it usable. Well, I
didn't evaluate Actiweb yet, still...
It is a matter of having a stable core that is company mature, e.g.
Actiweb on AOLserver. More features and extensions would follow fast, I
think (e.g. Actiweb on Apache).
> It's a nice thought, but I guess I'm a bit burnt out and disappointed in
> what I've seen already. And it's not just Rivet - I follow most of the
> other Tcl/web stuff, and none of it really gets the attention it deserves.
I think the main reason for that is, that there is too much to code
with Tcl. For instance, making a webshop in Tcl would involve coding
several hundret lines in Tcl - and who should do that, when you can
just pick and adopt a ready-to-run system in PHP?
The existing web building blocks are relatively low level and have not
much functionality, although the quality of existing functionality is
very high. Exactly that is the reason for this discussion. We need a
*high level* Web development framework, something where you can just
drag together the building blocks for problems that appear every day
and everywhere, over and over again in web development.
Once this is done and made popular, people will use it more frequently.
I see very big advantages of Tcl in web development. Consider just, how
easy it would be to have web applications as starkits that don't need
the installation horror of PHP scripts - just place them on your server
web space. You could have a simple persistence layer based on Metakit,
without the overhead of RDBMS if you don't need a complete RDBMS. You
could interface the application with Tclplugin, local standalone Tk
clients or Hecl-scripts on mobiles!
If it was just possible to built web application with Tcl as *easy* as
with PHP...
Eckhard
Dan Smart
> The existing web building blocks are relatively low level and have not
> much functionality, although the quality of existing functionality is
> very high. Exactly that is the reason for this discussion. We need a
> *high level* Web development framework, something where you can just
> drag together the building blocks for problems that appear every day
> and everywhere, over and over again in web development.
The thing is that "Ruby on Rails", "Django" and the the rest happend
because someone (usually, occasionally a couple of people) went away and
did it. They didn't talk about it, or try and design the system up
front, or try to rally a group of people to work on it, they just did it.
The same is true in the TCL space, "Rivet" happened because David went
away and did it, etc. The only way that TCL is going to compete against
the various web development frameworks is if someone goes away and
develops such a framework, endlessly discussing why such a framework is
valuable or how TCL will die without it is pointless. If someone is
going to develop such a framework, they'll do it because they want to,
and prompting is unnecessary, if no-one wants to do it, it aint going to
get done, and no amount of prompting will change that.
It seems to me that even if "we" do "need a *high level* web development
framework", none of us has yet needed it enough to develop it. We've
been through several "TCL will die if it doesn't do X" crusades, very
few (if any) of those X's have been done, and TCL doesn't appear even to
be unwell.
So if you want a web development framework, make it happen, doesn't have
to be perfect in it's first iteration, use the really nice sqllite
bindings that DKF mentioned (because a good db abstraction will use
something similar), build it on top of rivet (which will get ported to
Apache 2.0 if someone needs it to be and the existence of your framework
makes this more likely) or websh or tclhttpd. In short, build it and
they will come, and all the bits that aren't perfect that you were
convinced needed to be, will be perfected. If that is "we" really do
need a high level web development platform.
It's all about scratching itches...
Dan "Something that people taking pain killers know all about" Smart
Michael A. Cleverly
> Michael Schlenker wrote:
>> http://wiki.tcl.tk/14972 ) that at least the author of Tcldb is looking
>> for help (and it is my favorit currently, for nicest set of
>> functionalities, followed by Tclodbc, nstcl-database and DIO). I heard
>> Michael Cleverly talking about updating nstcl with 8.5 features once 8.5
>> comes out, and others seem to be interested too.
>
> I strongly urge people interested in doing database APIs to take a look
> at how SQLite does its higher-level APIs. Richard Hipp's got it right
As the author of one of the Tcl database abstraction layers, I've got to
say I agree 100% with Donal. I wrote nstcl to be compatible with
AOLserver & ACS/OpenACS, and I do intend to update nstcl to take advantage
of 8.5 once it's released.
However now that my day-to-day job doesn't have me working with
AOLserver/OpenACS I find myself using SQLite almost exclusively in new
projects, and it's Tcl API is just wonderful. Absolutely wonderful.
I think I'll have a go at writing an SQLite-style wrapper for other
databases at some point in the next month or two if someone doesn't beat
me to it. (SQLMedium? ;-)
Michael
Eckhard Lehmann
Dan Smart schrieb:
> The thing is that "Ruby on Rails", "Django" and the the rest happend
> because someone (usually, occasionally a couple of people) went away and
> did it. They didn't talk about it, or try and design the system up
> front, or try to rally a group of people to work on it, they just did it.
They liked Ruby etc., and wanted to be it on the web - and they did it,
yes... These people work(ed) in the webdev area and have substantial
knowledge of what is needed and should be done.
If I was in the webdev area, I would immediately start to do it for Tcl
(remember, *Tcl*, not TCL). But I am unfortunately not in this
position. I am just a consumer who occasionally needs some HTML based
presentation of some data - usually not my data, not my web server and
not my decision about whatever technology is to be used. So it just is
not feasible for me to get into devlelopment of such a framework - at
least not at the moment.
> The same is true in the TCL space, "Rivet" happened because David went
> away and did it, etc. The only way that TCL is going to compete against
> the various web development frameworks is if someone goes away and
> develops such a framework, endlessly discussing why such a framework is
> valuable or how TCL will die without it is pointless.
You are right (except the TCL, rather than Tcl ;-). But what should
come out if I go for it in the few hours that I call my spare time? Do
you really think that such a relatively big project can be done with
approx 2-3hours work per week? Definitely not! It would take ages to
get something done, and Rails, Django etc. will be kicking it at
longitudes.
No, such a project needs full time work, I stressed that out several
times in previous posts. And full time work can either be invested by
someone who actively works in the field and want's Tcl to be on the web
or by a company specialized for things around (Tcl) scripting, when
this company decides to do it.
To come to the point: I would love to see a powerful webdev framework
for Tcl. I like the language and I do many things in it, so it would be
nice to do webdev with it too.
But I for myself don't need this webdev framework desperately. There is
PHP, and I don't care about using PHP for Web based things. I also
don't care about using Java for these things or whatever - the only
thing I care about is, that I can deliver my projects fast and with
high quality, regardless of the language and regardless of whether it
involves web development or anything else.
And since I do not work actively as web developer, I am not in the
position to start the webdev thingy for Tcl. And - I won't do that just
for fun in my spare time. When it is done 'just for fun', it will stay
'fun' forever.
Just my 2c.
Eckhard
Andreas Leitgeb
> When it is done 'just for fun', it will stay 'fun' forever.
I'm glad, that some famous project that started in the early
nineties 'just for fun' did not stay just 'fun' forever.
Although, otoh., for me it's also a pleasure(fun) to work
with Linus T's "just for fun" project. So, what's so bad
about "staying fun forever" ?
Donal K. Fellows
> They just aren't fast platforms, first of all. Tcl isn't likely to beat
> Java in the speed arena.
Heh. For that, you need Tk. :-D
Donal (AWT, Swing and SWT are *all* sloooooow...)
suchenwi
(http://wiki.tcl.tk/14530), like before on my iPaq. Pity only is that
[socket] is not available either in Keuchel's port or JCW's Tclkit
Mobile, so I can only use it for stand-alone things like games or
little apps.
The PocketPC page http://wiki.tcl.tk/8688 has links to many of those
that have been "ported" (mostly, just tweaked in geometry) to Windows
CE. My "killer app" on CE is iFile http://wiki.tcl.tk/8540 which is
useful in many ways :)
rea...@yahoo.com
Eckhard Lehmann
Andreas Leitgeb schrieb:
> I'm glad, that some famous project that started in the early
> nineties 'just for fun' did not stay just 'fun' forever.
>
> Although, otoh., for me it's also a pleasure(fun) to work
> with Linus T's "just for fun" project. So, what's so bad
> about "staying fun forever" ?
Linux isn't 'just fun' anymore. It came at the right time, when enough
people were upset about the win3.1/dos stuff and the expensivenes of
other platforms. It got momentum there and now it is in the commercial
area as well as other platforms. I use Linux for 6 years now, long
before Sun, IBM & co entered the field - and I really feel that the
development (especially kernel-development) is pushed by those and
other companies (Novell, RedHat..) much more than it was before.
The point is: Linux came at the right time, addressing the right
problems and attracting the right people. Tcl did this too, by the way
- with Expect and Tk a long time ago. And PHP did it for web
development. There is a long history of such events, usually it happens
when there is immediate need and currently no really good alternatives.
But it is a hard time to invent a new web development framework for fun
- there are heaps of high quality web frameworks available, and they
are used. That implies that, if I would start a new framework in Tcl
for fun, it would be hard to find people who help me with it, because
there are other - ready to use - platforms. And since I don't have a
really potential benefit from the framework by myself, I don't need to
do it at all.
Eckhard
lvi...@gmail.com
According to Lisa Pearlson <n...@spam.plz>:
:What I do feel lacking is indeed something like CPAN, or aptitude/apt-get to
:easily add/delete modules and upgrade them.
Yep - this has been discussed for years. These kinds of things, unfortunately,
require more time and resources than generally people have available.
The typical reason you see other languages have things like this is
that the alternates are so painful/frustrating for someone that they
go off and do something about it.
Note that people HAVE gone out and done things. Jean Claude Wippler and
Steve Landers have done marvelous work on starkits. This provides a nice
method of distributing either scripts or binary within a single file.
Steve Cassidy created Cantcl < http://wiki.tcl.tk/Cantcl >, code that
provides the ability to upload package descriptions and files into a
repository. The code is available online, and provides the ability for
someone to upload starkits. Also, there's SDarchive, the starkit archive at
http://mini.net/sdarchive/ , where people can also access these starkits.
I suspect that Debian and other Linux distributions have a variety of
Tcl extension packages available as well.
However, it is going to take staff and resources to provide bandwidth,
disk maintenance, verification that submissions are virus free, probably
some sort of authentication so that Joe Hacker doesn't submit a Tk download
that is really code that steals your credit cards, etc. and so forth.
In other words, there's a LOT of work and liability that one must be
prepared to take on. And people looking at such work would rather
write code or have a life with their family...
:And installing the MD5 package for TCL was too painful for me. Still not
:sure what steps are exactely required to install/remove a package (but I
:know there is documentation available.. just have to read it).
I'm uncertain what you mean here. What MD5 package? The one in Tcllib,
or one of the many others? There are not set steps to install or remove
a package. It depends on what kind of package you are working on, what
platform, etc. And of course, that's part of the issue - differing
platforms, different authors mean different steps to take. And the
result is a mess. However, note that there IS a standard (see
< http://wiki.tcl.tk/TEA > - doesn't mean that everyone uses it (some
people don't like it, or haven't learned how to use it, or can't
use it because of their environment), but many packages use it and it
should work on POSIX command line type systems (which exist even
on Windows).
:Should be more plug and play to make setup just as convenient as the actual
:tcl coding itself.
Perhaps - but as I mentioned before, the hurdle is great, and there has
yet to be a champion whose work has taken hold as a community standard.
:And I don't understand Tk yet.. that looked like chinese to me at first
:sight.. haven't looked at it since.. and I don't understand the relationship
:between TCL en TK yet.. TK is not part of or dependent on TCL, but a thing
:of its own, that can be scripted with TCL, but Perl or any other language
:that supports TK, do I understand that correctely?
Nope. There's two issues here. Number 1 - Tk is a C based library that
attempts to provide a Tcl interface to graphical user interfaces. People
in other scripting language camps wanted something similar. So some languages
wrote a very thin layer that just talks to tcl and tk. Other languages,
such as Perl, attempted to write a deeper interface, so they massage a copy
of the Tk code so that instead of being tcl and tk, the library becomes their
scripting language and tk. As I said, Perl/Tk is one of those types of efforts.
The supposed upside is that the script developer using the converted library
doesn't have to code in Tcl.
The downside is that updates to Tk take longer to make it back to the
community. And bugs that they discover may take longer to make their way
back into Tk.
--
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
Tom Poindexter
Michael A. Cleverly <mic...@cleverly.com> wrote:
>On Fri, 2 Dec 2005, Donal K. Fellows wrote:
>> I strongly urge people interested in doing database APIs to take a look
>> at how SQLite does its higher-level APIs. Richard Hipp's got it right
>
>As the author of one of the Tcl database abstraction layers, I've got to
>say I agree 100% with Donal. I wrote nstcl to be compatible with
>AOLserver & ACS/OpenACS, and I do intend to update nstcl to take advantage
Me three - SQLite's API is nice (I've used it often as of late.) I
originally wrote Sybtcl's & Oratcl's API to be closer to the C API of
each database, which certainly served my purposes at the time.
--
Tom Poindexter
tpoi...@nyx.net
http://www.nyx.net/~tpoindex/
Dan Smart
>
> They liked Ruby etc., and wanted to be it on the web - and they did it,
> yes... These people work(ed) in the webdev area and have substantial
> knowledge of what is needed and should be done.
> If I was in the webdev area, I would immediately start to do it for Tcl
> (remember, *Tcl*, not TCL). But I am unfortunately not in this
> position. I am just a consumer who occasionally needs some HTML based
> presentation of some data - usually not my data, not my web server and
> not my decision about whatever technology is to be used. So it just is
> not feasible for me to get into devlelopment of such a framework - at
> least not at the moment.
means it won't get done, which means discussing it ad-infinitum is
spectactularly pointless.
As for the capitalisation nit-pick, (1) it's an acronym, everyone else
(and I mean everyone JO) is spelling it wrong :-) (2) as I repeatedly
point out (adittedly not in this post) my spelling is fried due to the
not insignificant number of pain-killers I'm ingesting.
>
> You are right (except the TCL, rather than Tcl ;-). But what should
> come out if I go for it in the few hours that I call my spare time? Do
> you really think that such a relatively big project can be done with
> approx 2-3hours work per week? Definitely not! It would take ages to
> get something done, and Rails, Django etc. will be kicking it at
> longitudes.
I think that unless someone starts it, nothing will ever happen. I also
think that if you started it you might be surprised by how quickly you
had something that might attract other people to work on it. The saying
is "A journey of a thousand miles begins with but a single step", not "A
journey of a thousand miles begins with a long discussion about how
desireable it would be to be a thousand miles away". (p.s. you did the
Tcl/TCL thing already, it wasn't that funny the first time).
> No, such a project needs full time work, I stressed that out several
> times in previous posts. And full time work can either be invested by
> someone who actively works in the field and want's Tcl to be on the web
> or by a company specialized for things around (Tcl) scripting, when
> this company decides to do it.
As I pointed out, there demonstrably isn't anyone who fits that bill,
and if there was, they wouldn't need your encouragement, they would
already be working on it.
>
> To come to the point: I would love to see a powerful webdev framework
> for Tcl. I like the language and I do many things in it, so it would be
> nice to do webdev with it too.
I would love to see world peace, and a billion dollars in my bank
account (and if I had a billion dollars, I'd pay someone to develop this
cursed framework if only to kill this thread).
> But I for myself don't need this webdev framework desperately. There is
> PHP, and I don't care about using PHP for Web based things. I also
> don't care about using Java for these things or whatever - the only
> thing I care about is, that I can deliver my projects fast and with
> high quality, regardless of the language and regardless of whether it
> involves web development or anything else.
If you don't need it, and obviously noone else needs it (at least not
enough to actually develop it), then what is the point in going on about it?
> And since I do not work actively as web developer, I am not in the
> position to start the webdev thingy for Tcl. And - I won't do that just
> for fun in my spare time. When it is done 'just for fun', it will stay
> 'fun' forever.
>
Hmm, I seem to remember this chap called Linus was working on something
just for fun, what ever happened to that, I'll have to go look when I've
finished this post...
And earlier, there were these chaps called Dennis and Brian and the
other one (my apologies "other one", memory like a wossname) wanted to
play spacewar on a PDP, I can't remember what happened to that project
either...
You know I do believe you might be entirely wrong on that point...
> Just my 2c.
>
>
> Eckhard
>
Go on, surprise yourself...
Dan "You have no idea how long it takes to produce this drivel[1]" Smart
[1] peobably long enough to develop a web development framework if I
could concentrate long enough to remember why I had started the editor
once it had actually started :-).
Donal K. Fellows
> And since I do not work actively as web developer, I am not in the
> position to start the webdev thingy for Tcl.
Only if you insist on not doing anything about it. If you want it to
happen, code something *simple* up that is a bit useful to you (and yes,
standing on the shoulders of a few giants can help here) and put a
decent license on it. Then tell the rest of us about it and we'll see
where we go from there. But sitting there moaning about the fact that
nobody's doing anything about it, well, that's just unproductive (and
that applies to _everyone_, OK?)
> And - I won't do that just
> for fun in my spare time. When it is done 'just for fun', it will stay
> 'fun' forever.
Not necessarily. My Tcling started out as "just for fun" but didn't stay
that way. My first serious Tcl app was a small tool I put together to
help me make pictures for some documentation I was writing, and when
other people saw it in operation (over my shoulder) it snowballed.
(Other people have pointed out Linux as a more commonly known example,
but I usually prefer to use examples from personal experience.)
Donal.
Cameron Laird
.
.
.
>Note that people HAVE gone out and done things. Jean Claude Wippler and
>Steve Landers have done marvelous work on starkits. This provides a nice
>method of distributing either scripts or binary within a single file.
>Steve Cassidy created Cantcl < http://wiki.tcl.tk/Cantcl >, code that
>provides the ability to upload package descriptions and files into a
>repository. The code is available online, and provides the ability for
>someone to upload starkits. Also, there's SDarchive, the starkit archive at
>http://mini.net/sdarchive/ , where people can also access these starkits.
>I suspect that Debian and other Linux distributions have a variety of
>Tcl extension packages available as well.
>
>However, it is going to take staff and resources to provide bandwidth,
>disk maintenance, verification that submissions are virus free, probably
>some sort of authentication so that Joe Hacker doesn't submit a Tk download
>that is really code that steals your credit cards, etc. and so forth.
>In other words, there's a LOT of work and liability that one must be
>prepared to take on. And people looking at such work would rather
>write code or have a life with their family...
.
.
... and that's not all. Already fossilized are several earlier efforts
to build public repositories, extending back, I think, even before CPAN
was prominent: ones hosted by NeoSoft, Alcatel (?), ...
Cameron Laird
>attempts to provide a Tcl interface to graphical user interfaces. People
>in other scripting language camps wanted something similar. So some languages
>wrote a very thin layer that just talks to tcl and tk. Other languages,
>such as Perl, attempted to write a deeper interface, so they massage a copy
>of the Tk code so that instead of being tcl and tk, the library becomes their
>scripting language and tk. As I said, Perl/Tk is one of those types of efforts.
>The supposed upside is that the script developer using the converted library
>doesn't have to code in Tcl.
>The downside is that updates to Tk take longer to make it back to the
>community. And bugs that they discover may take longer to make their way
>back into Tk.
.
.
There are even other technical possibilities now, as Jeff's work has
demonstrated the Perl/Tk people can, if they choose, enjoy both lower
maintenance costs *and* higher performance while retaining a Perlish
programming interface.
Robert Hicks
Whether to continue with Tk or put their energies into another toolkit
where time and talent could be shared/split.
Robert
Eckhard Lehmann
OK,there you are - I will see what can be done!
I think, I'll start to look at rivet + apache2 integration first... no
idea what's going on there at the moment and how they play together -
no clue about the apache nor the rivet sources, and no guarantee that
something get's done... But lets stop this discussion now and start to
do something.
You will hear from me, if I have something to announce - eventually at
some time in the future.
Eckhard
Robert Hicks
available. Talk with David Welton about who currently does the current
Windows Rivet binary and that may help as well.
Robert
Robert Hicks
David N. Welton
I would love it if someone did a Rivet module for Apache 2. I'm
available for questions, of course, so you don't have to do it
completely on your own:-)
It's probably not all that hard if you want to ignore the threaded MPM's
in Apache 2. If you want to tackle those, though, you need to figure
out a way of making sure that one Tcl interpreter is created and used
per-thread. Perhaps one way of doing this would be to delay creation of
the Tcl interpreter until a request has come in and you are in a thread.
It means the first request would be slow, but probably not even all
that bad. There may be better ways... I haven't looked at Apache 2 for
a while - maybe 2.2 has some better stuff?
lvi...@gmail.com
According to Robert Hicks <sig...@gmail.com>:
:Let's suppose that we do those 4 things I mentioned (a full stack
:framework, a more visible blogspace like O'Reilly, a db abstraction
:layer, and a CPAN like repository). Now let's suppose that we
:implemented them and it didn't do anything to bring Tcl into the
:limelight. The one thing it would do is give the current community some
:really good tools to work with that people have posted over and over
:about wanting. That can only be a good thing for the community.
You are right that if these things were done, it would be good for the
existing developer community.
I won't, however, make the claim that these are the highest priority for
the majority of the community. I have no idea what the majority want -
I've not taken a survey on the topic.
And, then there is one more thing. Who is going to work on these things.
It looks like, to my novice eye, that at least 3 of the 4 items above would
each require several years of concentrated effort by 3 or more people .
How many readers of this posting are interested in devoting the majority of
your time over the next year or so to at least one of the four projects
proposed by Robert?
The steps would be, at a minimum, to come up with:
o a detailed vision of what you want for the project
o detailed requirements
o design documents
o coding of a prototype
o verification that user interface and functionality really meets user needs
o a move from prototype to production quality code, in cycles of deliverables,
so that people can use the tool over time and refine requirements
as necessary
o user documentation
o one or more host machines that will commit to long term support of the
system
o support and improvements to the system
lvi...@gmail.com
:> We shouldn't have to depend on Debian or RPM or whatever, to easily install
:> TCL packages.
:
:The best that we're likely to attain anytime in the near future is to
:have a 'batteries included' distribution that includes all kinds of
:stuff like tcllib.
Well, activetcl is a distribution that includes all kinds of stuff. And
there is a tcllib starkit, I think, at the SDarchive.
lvi...@gmail.com
According to David N. Welton <dav...@dedasys.com>:
:I kind of thought they didn't really like Tcl there. Maybe it's not
:"Web 2.0" enough;-)
I don't know why you would think that. They are one of the few
publishers still printing a book relating to Tcl, and they publish
articles about Tcl in the Linux and MacOS sections occasionally.
More articles submitted might even result in a Tcl section.
lvi...@gmail.com
:webserver as a starkit. You could even put sqlite in it and have the
:database and everything all wrapped up in one nice tidy package.
You'd even have 2 choices of databases, since metakit comes in tclkit
already...
lvi...@gmail.com
:other Tcl/web stuff, and none of it really gets the attention it deserves.
Which Tcl stuff of any sort gets the attention that it deserves?
Other than, of course, the core and Tk? The one package I know of
is ActiveTcl - those wonderkins at ActiveState just keep coming out
with updates on a regular basis.
But nearly all of the other mailing lists for extensions are comatose,
and many of the extensions have minimal releases.
Robert Hicks
Robert
Cameron Laird
David N. Welton <dav...@dedasys.com> wrote:
.
.
.
>> We shouldn't have to depend on Debian or RPM or whatever, to easily install
>> TCL packages.
>
>The best that we're likely to attain anytime in the near future is to
>have a 'batteries included' distribution that includes all kinds of
>stuff like tcllib.
.
.
Better than ActiveTcl <URL: http://wiki.tcl.tk/activetcl >?
I'll be more explicit: when people ask me about a "batteries-
included Tcl", I urge them to install ActiveTcl (let's leave
MacOS aside for the moment). With rare exceptions, my inter-
locutors express satisfaction. I conclude that ActiveTcl is
a correct answer to this question. It happens to be a fact
that ActiveTcl includes, among several other highlights,
tcllib.
How do you see it, David?
Don Porter
> I'll be more explicit: when people ask me about a "batteries-
> included Tcl", I urge them to install ActiveTcl (let's leave
> MacOS aside for the moment).
Huh?
Either you mean Mac OSX, in which case there's no reason to leave
it aside; the ActiveTcl releases for Mac OSX work great.
Or you really mean the "classic" Mac OS 9, in which case I have
to ask "who cares?"
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|