is tcl/tk dying out?!
sas...@gmail.com
I used to be very active in Tcl/Tk programming back in 2001. I was just
trying to get back into it and I started looking around but couldn't
find much recent development (other than work at ActiveState). I found
the roadmap for tcltk 9.0 on www.tcl.tk being promised for 2003
specially disturbing! How worried should I be about tcl/tk's future?
Thanks.
S
Robert Hicks
The "future" is fine I think. However, I think you need to think about
what you are looking for in a language. Tcl isn't one of the current
"popular" ones but it might be in the "future"; who knows.
If you like Tcl, use it.
If you like Tcl, tell people you use it and why.
Robert
Robert Joy
Tcl is alive and well. It's extremely popular as a testing language and
is growing in popularity as a general purpose language as well. Tcl will
be around for a long time.
Robert Joy
Bryan Oakley
The answer: not at all.
Tcl/tk is actively being developed and actively being used by all sorts
of companies for all sorts of things. It is solid, robust, and mature,
and continues to evolve. Version 8.5 is a very significant upgrade and
is just around the corner. It is chock full of new features people have
been clamoring for for years: Tk enhancements, OO, dicts, ensembles,
arbitrary precision integers, the list goes on ...
(http://wiki.tcl.tk/10630)
To me, Tcl is a bit like the Apple Macintosh of programming languages.
People have proclaimed its death for a decade, it's market share is
small, and it is greatly misunderstood by everyone on the other side of
the fence. Yet it continues to evolve, and is used by professionals all
over the world for some really amazing things.
--
Bryan Oakley
http://www.tclscripting.com
Helmut Giese
>People have proclaimed its death for a decade, it's market share is
>small, and it is greatly misunderstood by everyone on the other side of
>the fence. Yet it continues to evolve, and is used by professionals all
>over the world for some really amazing things.
Should be QOTW.
Helmut Giese
Stephan Kuhagen
I'm afraid, people around here will hate and flame me for this, but I'm VERY
worried about the future of Tcl. And this is not, because, I do not like
Tcl, but because, I love it so much. I never found any language as much
interesting and simply... mind blowing cool as Tcl. It is the beauty of
programming. Said this, I hope you don't push me too hard... ;-)
1. But Tcl has the worst marketing of all languages I know. Yes, I know,
marketing should not be an argument against a language, because it counts,
what it is good for and how effective you can code with it. But marketing
_is_ important to the corporate and the real world. And the fact is simply,
that nearly nobody knows Tcl or some killer apps written and with Tcl as
extension (yes, I know, AOL server and such...). People here may wonder,
because _we_ all know Tcl, but we are a very little part of the world, look
outside and if people hear "tcl", they either do not know it, or they
think, you mean the chinese electronic company. Ask for Python, JavaScript
or Ruby instead...
2. One of the reasons for the bad marketing is, IMHO, the lack of a real
roadmap. Tcl 8.5 and some fantasies about 9.0 are around since... when was
Methusalem born? But although we can read here about whats going on and why
things need so long (and please, I do not blame anyone of the core team,
because I love Tcl and so I love, what they have done with and for Tcl in
the past), the implicit message to the outside world is, that Tcl has
simply stopped evolving somewhen in the late 90's. The Tcl-lib has become a
good replacement for many missing features and standard library things in
Tcl, and there are many other good packages to add missing core
functionality, too. But this is not a good replacement for a real standard
library as it comes with other current hype languages such as python. If
someone starts with Tcl, then there should be a set of standard libraries,
which are kind of part of the language, and not add-ons that you must
install later. Again Python: you may think about it, what you want, but if
you install Python, you will very likely have what ever you need in the
future. It simply works, is fast and has a very active community. Compare
the activity on comp.lang.python with comp.lang.tcl... And the postings
there are as high quality as the ones here. I need to program in both
languages, but I always prefer Tcl over Python, when it come to the beauty
of the language. But when it comes to productivity in using standard
libraries, mass awareness (which is important, if you try to convince
people, that Tcl is a good choice for a given problem), Tcl is no match for
Python. Sadly...
3. Tcl has no good central repository for extensions and external packages.
Again look at Python or other languages as Perl with CPAN. You can go to
the Python site and browse by category or whatever and find what you need.
You can find nearly all of it for Tcl too, but the usability and
"findability" of Tcl extensions is much worse that in most other languages.
The wiki is very cool and I spend much time reading there, just for the fun
of learning and thinking about Tcl. But for most people this is not a very
attractive place.
4. Compared to other languages there is very little good literature about
Tcl, I means books, paper... Again, the Tcl Wiki is a good place to find
everything you need, and if you do not find it there, you definitely find
help in this group because the people around here are friendly and
competent. But for newbies, usenet not only is a strange place as I
sometimes read in a signature here, but it is also an unknown place... What
is needed, to bring Tcl to the peoples mind and help them at their desk are
books. Think about that: where is OReilly's "Tcl in a nutshell" (this
series is really cool and sometimes I read C++ in a nutshell just for fun),
or where are "Tcl for dummies" and "Tcl unleashed" or whatever? Maybe you
say, paper is outdated and there is nothing attracting on dead trees, but
the truth is, that people read books about programming languages and they
like having books about them in their shelf. If you can't find recent books
about a language at amazon it simply does not exist for many people...
---
There should be much faster development to catch up with recent developments
in other parts of the world. I know, there are things going on, but they
are going on in half darkness, effectively hidden to the outside world. OO
should be part of the language, multithreading (for me) is even more
important, a modern GUI binding (Tk is cool in its simplicity, but it's so
much outdated...) or toolkit, a complete and comprehensive standard library
is needed (as integral part of the core language and not as an add on) to
give the programmer the tools she needs to get the every day things quick
and concentrate on the real problems. I do not agree, that performance is
such a problem as it is stated often when Tcl is compared to other
languages. But more and better support for programming environments and
debugging are needed desperately. I know, there are good tools from
ActiveState, but where is the standard Tcl-Plugin for Eclipse or KDevelop
(the IDE I like best). The best Tcl "Environment" for programming I know
(and which I'm using most time) is emacs. It's Tcl-Mode is really okay for
me, but tell that the people (read: new programmers), who you are trying to
convince, that Tcl is worth a look... Where is the image manipulation
framework for Tcl? TclMagick was a good start, but...
I like to know, what you are thinking about this. Maybe I'm just a whining
fool who sees his preferred language disappearing. But I really think, that
there is much too less effort in bringing Tcl to the people, to give them
really good reasons to consider Tcl when taking decisions and in active
development of the core and the needed peripherals of a modern and
effective language. People here in this group tend to think, that
everything will be okay, just because they "know" how superior Tcl is and
what a nice language it is. But this is a very small community compared to
others and nearly nobody outside is aware of Tcl. The Netscape people
(remember them...?) thought, they had a superior browser, so there is not
much need to fight for it... But awareness is important, and for awareness
some interesting developments are necessary. And I can't see any of them
recently, just plans to make it happen sometime in the future. Do it now! -
Tcl's community also needs refreshment from new and young programmers who
brings life to the community. For example in the Python (again...)
newsgroup there are many postings starting with "I'm a newbie, please
help..." - You might think, that those people are not a big help in
developing a language anyway, so there is no reason to miss them. But they
are: because they will be good programmers in the future, they learn Python
instead of Tcl and they will later contribute to the development of the
language and they will write cool scripts and apps. And everybody who sees
those cool extensions or apps will ask: wow, what's it made with? And the
answer then is not Tcl, which again is one step toward oblivion.
Currently Tcl is alive, but much less than most other languages, and it is
descending into oblivion for the wrong reasons. Tcl is a good language and
it could be much more effective and used all over the world. But to make it
happen and to keep Tcl alive (and make fresh and attractive for others)
there is much too less active and coordinated development of the language
core and its peripherals _and_ of the social or marketing component of it.
I don't have the solution to all the problem I see with Tcl's development.
But I hope, there will be more movement in the community soon, something
must happen... Maybe we simply need people like Linus Torvalds or Guido van
Rossum... Mr(s). Tcl who pushes it back to live and inspires people to use
and develop it.
-- Early in the morning here, and maybe I'm too emotional at this time, so
please be indulging with me. I simply want Tcl to have a future...
Regards,
Stephan
Eckhard Lehmann
Stephan Kuhagen wrote:
> 1. But Tcl has the worst marketing of all languages I know.
[...]
Yes, exactly.
> 2. One of the reasons for the bad marketing is, IMHO, the lack of a real
> roadmap. Tcl 8.5 and some fantasies about 9.0 are around since... when was
> Methusalem born? But although we can read here about whats going on and why
> things need so long (and please, I do not blame anyone of the core team,
There is a valid reason for that - and this is quality. Tcl stands for
API consistency and backwards compatibility, features that other
languages are not so aware of. And this justifies that things need
longer, IMO.
> The Tcl-lib has become a
> good replacement for many missing features and standard library things in
> Tcl, and there are many other good packages to add missing core
> functionality, too. But this is not a good replacement for a real standard
> library as it comes with other current hype languages such as python. If
The usual way for the average Tcl newbie is to install ActiveTcl, and
this comes with everything included. I don't see an action item here.
> 3. Tcl has no good central repository for extensions and external packages.
True, really. We had this discussion recently here. My offer is still
valid: if someone likes to put up a website based on AOLserver and
maybe OpenACS for the central repository, I will host in on my virtual
server. I just don't have the time to put the site together, otherwise
I'd do it myself.
> 4. Compared to other languages there is very little good literature about
> Tcl, I means books, paper...
There are a few good books: "Practical Programming in Tcl and Tk",
"Effective Tcl/Tk programming".. the latter is a little outdated,
right. It would be good to have more books (for newbies) but someone
has to write and publish them. Especially the "developers notebook"
series from Oreilly could be attractive - how about a "Tile/Tk - a
developers notebook" or "Tclhttpd - a developers notebook"?
"Tcl in a nutshell" is there, but I wouldn't recommend it.
> There should be much faster development to catch up with recent developments
> in other parts of the world. I know, there are things going on, but they
> are going on in half darkness, effectively hidden to the outside world.
There are good reasons for that sometimes. One is, that you find lots
of crappy, half finished free software everywhere (especially in the
Python and Java domain for some reason). Personally, I am always
deterred of the language when I try to use a program written in that
language and it just brings up lots of errors: "Hey, there are no
memory leaks in this language... so there is no need for bugfixing,
just throw the error - fine!".
I wouldn't release anything to the public when it is not finished, at
least to an extend where others will find it useful as well.
> OO should be part of the language,
Tcl 8.5. Many OO extensions available out of the box. It's just a
marketing problem again.
> multithreading (for me) is even more
> important,
Dito, mt is there since 8.4 at least.
> a modern GUI binding (Tk is cool in its simplicity, but it's so
> much outdated...) or toolkit
Tile is there, again a marketing problem. Tk is still fine.
> and concentrate on the real problems. I do not agree, that performance is
> such a problem as it is stated often when Tcl is compared to other
> languages.
Has improved continuously and will have a quantum jump in 8.5.
> But more and better support for programming environments and
> debugging are needed desperately.
Work in progress (Check out my website). Just a question of time,
currently delayed...
I know, there are good tools from
> ActiveState, but where is the standard Tcl-Plugin for Eclipse or KDevelop
> (the IDE I like best). The best Tcl "Environment" for programming I know
> (and which I'm using most time) is emacs. It's Tcl-Mode is really okay for
> me, but tell that the people (read: new programmers), who you are trying to
> convince, that Tcl is worth a look... Where is the image manipulation
> framework for Tcl? TclMagick was a good start, but...
There is a binding to libgd, google for "tcl gd". Also, there is the
Img extension (part of ActiveTcl)
> But I really think, that there is much too less effort in bringing Tcl to the people
That is true. People always complain about it... I am a little sad of
complainings, really. We need more people being active (still
complaining is important...)
Eckhard
Peter Dalgaard
>
> > The Tcl-lib has become a
> > good replacement for many missing features and standard library things in
> > Tcl, and there are many other good packages to add missing core
> > functionality, too. But this is not a good replacement for a real standard
> > library as it comes with other current hype languages such as python. If
>
> The usual way for the average Tcl newbie is to install ActiveTcl, and
> this comes with everything included. I don't see an action item here.
Whoops! I can't leave that one alone.
ActiveTcl, for all its virtues, is a single-platform proprietary item.
What it provides is not usable under e.g. Linux, or even on Windows if
you want to bundle Tcl/Tk with other software. This is a real problem
since one of the strong selling points of Tcl/Tk is that it is
cross-platform.
--
O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dal...@biostat.ku.dk) FAX: (+45) 35327907
Donal K. Fellows
You shouldn't be too worried. What happened was that we decided to do an
8.5 instead of a 9.0 (for various reasons that I don't quite remember at
the moment). And 8.5 has slipped quite a few times for assorted reasons;
in particular, many of the most pressing problems turned out to be
fixable without a new release, which took quite a bit of pressure off
people. I view that as a good thing. :-)
Donal.
Eckhard Lehmann
Peter Dalgaard wrote:
> > The usual way for the average Tcl newbie is to install ActiveTcl, and
> > this comes with everything included. I don't see an action item here.
>
> Whoops! I can't leave that one alone.
>
> ActiveTcl, for all its virtues, is a single-platform proprietary item.
> What it provides is not usable under e.g. Linux, or even on Windows if
> you want to bundle Tcl/Tk with other software. This is a real problem
> since one of the strong selling points of Tcl/Tk is that it is
> cross-platform.
It is usable for the average newbie to get started. Once you are at the
point when you need to integrate with other software, develop (C)
extensions, create starkits and so on, you don't get around to compile
the sources yourself.
I always keep two Tcl installations: ActiveTcl to quickly try out
things and because of the included documentation on Windows, and a self
compiled one (with --enable-symbols) for extension development. Real
program development and testing I do usually with Tclkit (which I build
by myself as well).
But when the newbie is at this point, he is on the train anyway ;-).
Eckhard
Uwe Klein
> "Eckhard Lehmann" <eck...@web.de> writes:
>
>
>>>The Tcl-lib has become a
>>>good replacement for many missing features and standard library things in
>>>Tcl, and there are many other good packages to add missing core
>>>functionality, too. But this is not a good replacement for a real standard
>>>library as it comes with other current hype languages such as python. If
>>
>>The usual way for the average Tcl newbie is to install ActiveTcl, and
>>this comes with everything included. I don't see an action item here.
>
>
> Whoops! I can't leave that one alone.
>
> ActiveTcl, for all its virtues, is a single-platform proprietary item.
> What it provides is not usable under e.g. Linux, or even on Windows if
> you want to bundle Tcl/Tk with other software. This is a real problem
> since one of the strong selling points of Tcl/Tk is that it is
> cross-platform.
>
( Though it does not include BLT (bad,bad,bad) and circumvents my package
managment ( on Linux, rpm )
From the ActiveState Page:
System Requirements
General
70MB hard disk space during installation only
50MB hard disk space for final install
Web browser for online help
AIX
PowerPC
Minimum AIX 5.1
HP-UX
PA-RISC
Minimum HP-UX 11
Linux
x86
Minimum 2.0 kernel
Mac OS X
PowerPC: Mac OS X 10.3, 10.4 on G4, G5 processors.
x86: Mac OS X 10.4
Solaris
SPARC: Minimum Solaris 2.6
x64/x86: Minimum Solaris 10
Windows
x86
Windows 2000, ME or XP: No additional requirements
Windows NT 4.0, 98: Internet Explorer 5+
Windows NT 4.0: Service Pack 5+
zwe
si...@whiteowl.co.uk
Eckhard Lehmann wrote:
> > 2. One of the reasons for the bad marketing is, IMHO, the lack of a real
> > roadmap. Tcl 8.5 and some fantasies about 9.0 are around since... when was
> > Methusalem born? But although we can read here about whats going on and why
> > things need so long (and please, I do not blame anyone of the core team,
>
> There is a valid reason for that - and this is quality. Tcl stands for
> API consistency and backwards compatibility, features that other
> languages are not so aware of. And this justifies that things need
> longer, IMO.
>
I agree that this justifies the longer release cycle but surely that
makes it more important to have a roadmap and a plan.
8.5 is going to be packed full of goodies which I for one an looking
forward to very much. Given how long it has been gestating I think that
some direction - contents and timetable should be put in place. It will
probably slip but at least it would give focus to the remaining effort.
Simon Geard
Michael Schlenker
dependencies. While members of the TCT do manage the releases for
Tcl/Tk, they depend on external contributions for some things (or would
probably like to have more external contributions).
Just look at a lot of TIP's which target 8.5 (but won't probably make it
because no implementation is done), lots of nice things, but somehow the
proposal has been dumped with the TCT and no real persistent action
followed. Anybody may adopt those and provide an implementation and push
for a vote.
A short selection of those:
try - catch :
http://www.tcl.tk/cgi-bin/tct/tip/89.html
better serial line/terminal control (stty like):
http://www.tcl.tk/cgi-bin/tct/tip/160.html
zlib in the core:
http://www.tcl.tk/cgi-bin/tct/tip/234.html
(adding PNG support to Tk depends on this one, the png code
is there: http://www.tcl.tk/cgi-bin/tct/tip/244.html)
IPv6 sockets for Tcl:
http://www.tcl.tk/cgi-bin/tct/tip/162.html
canvas improvements:
http://www.tcl.tk/cgi-bin/tct/tip/97.html
http://www.tcl.tk/cgi-bin/tct/tip/119.html
http://www.tcl.tk/cgi-bin/tct/tip/164.html
http://www.tcl.tk/cgi-bin/tct/tip/236.html
wm enhancements: frame to toplevel and back
http://www.tcl.tk/cgi-bin/tct/tip/125.html
Named colors for Tk:
http://www.tcl.tk/cgi-bin/tct/tip/154.html
And so on..., look at the drafts at the TIP site.
If _you_ want any of this to happen in Tcl 8.5 / Tk 8.5 get something
done, adopt a TIP write a ref implementation and push the TCT to vote on
the subject.
Michael
Neil Madden
[...]
> ActiveTcl, for all its virtues, is a single-platform proprietary item.
What do you mean by this? ActiveTcl is available on 6 different
platforms, as far as I can see (AIX, HP-UX, Linux, Mac OS X, Solaris,
and Windows according to
http://www.activestate.com/Products/ActiveTcl/?mp=1). I use it on 3 of
those myself.
> What it provides is not usable under e.g. Linux, or even on Windows if
> you want to bundle Tcl/Tk with other software.
Again, what do you mean by "not usable under ... Linux"? I use ActiveTcl
under Linux almost daily. ActiveTcl is an effective "batteries included"
distribution for end-users. Bundling/redistribution is a separate issue.
-- Neil
Larry W. Virden
Depends on the specifics of your worry.
If you are worried that the source code for tcl and tk might vanish
from the internet, then you should NOT be worried about that.
If you are worried that Tcl/Tk won't be mentioned on Entertainment
Tonite, or CNN, or in the pages of Computerworld, then you are
justified in your worry.
If you are worried that somehow you will write code in Tcl and Tk and
it won't run on a new platform - you in all likelihood won't need to
worry about that.
If you are worried that you might run into a problem that you can't
find help resolving... well, ActiveState continues to offer tools and
contracts for maintenance, and I suspect there are a few consultants
still around the newsgroup that might be able to be hired to help.
If you are worried that lots of neat software won't be appearing with
which could impress your friends, that I guess might be something to
think about.
If you are worried that you won't be able to find Tcl and Tk tee
shirts, text books, posters, etc. to buy, that's probably a legit
worry.
You've not detailed, yet, for us your concerns.
Certainly the progress towards Tcl 8.5 and 9.0 has been slower than
many expected. Some of that may be attributed to the efforts going on,
and some to the level of contributions back.
I occasionally wonder where Tcl would be if everyone predicting the
demise of Tcl had spent their time writing useful new programs, updated
Tcl's doc and training materials, etc. instead.
Larry W. Virden
Neil Madden wrote:
> Peter Dalgaard wrote:
> > What it provides is not usable under e.g. Linux, or even on Windows if
> > you want to bundle Tcl/Tk with other software.
>
> Again, what do you mean by "not usable under ... Linux"? I use ActiveTcl
> under Linux almost daily. ActiveTcl is an effective "batteries included"
> distribution for end-users. Bundling/redistribution is a separate issue.
Perhaps what the poster was trying to say was "If one builds
applications under ActiveTcl, and wish to distribute those applications
in a non-single file wrapped form, one needs to contact ActiveState to
get approval, or one has to tell users to download and install
ActiveTcl before using your application".
Note, Mr. Dalgaard, that if one was to use FreeWrap or Starkit, then
distribution of the application with the appropriate pieces of
ActiveTcl is permissible with the latest ActiveState license, according
to a recent posting by Jeff Hobbes.
Plebeian
become more determined. I stuck with trying to learn Tcl/Tk because it
made the most sense to me. From 1998 til now, I have not seen very many
articles on technical news sites. But the one 'killer' app that I saw
was the Eggdrop bot using Tcl for its scripting language. That's it.
What i'm getting at is that Tcl/Tk is a great language with lots to
offer. But Tk really needs a facelift. I am not talking about Tile, I
know about that, but Tk needs the face lift. It isn't that apparent on
Windows (No idea about TkAqua), but on FreeBSD/Linux it certainly looks
out of place! Maybe Tile will indeed fix this issue? Certainly not
without a tremendous amount of work on the developers end from what I
can see, atleast for mature apps.
Tcl/Tk needs better marketing. And good articles are a part of this.
The more articles that are written the more they'll end up on Tech
sites; the more people will join in developing Tcl/Tk. Now, isn't that
a big deal? Bryan Oakley writes Tclscripting.com; i've seen an article
from David Welton before on using TclTest.
But that was a year ago! You want/need more people to lend a hand in
updating the Wiki, writing new apps, etc. the visiblity has to be
there.
Now, having suggested this there is undoubtedly someone out there who
will say "put your money where your mouth is" and write an article,
update a wiki page or any other of the numereous suggestions. Well,
here's the problem: qualification. First, like everyone else there is a
time issue, second topics to write about, third probably a lot of
people don't feel their programming skills are good enough to be able
to post for the world to see.
So I propose this. Why not a mentoring system? A qualified tcl/tk
developer pairs with someone who does have the time, the motivation and
the desire to see the language get more publicity, who can write an
article, then have it reviewed by their mentor before publishing to a
website? I am unsure if this is the best way at this time, but it's the
only thing I can think of currently.
Kevin Walzer
technical standpoint. The language is flourishing. I've made Tcl/Tk
(with the important Tile extension) the basis of my own independent
software business--and this is on Mac OS X! I believe Tcl/Tk offers a
combination of rapid development, technical power, and ease of learning
curve that is comparable to commercial RAD tools such as REALBasic,
Delphi, and similar products. I also believe that Tcl/Tk is superior to
many other "scripting" or dynamic langauges for certain things. For
instance, I found trying to learn Python via its Tk bindings to be a
painful experience. While Python is a good langauge, its Tkinter GUI
module lags far behind what you can do with Tk via Tcl.
It's true that Tcl has an open-ended release process. Updates to 8.4.x
come regularly, so the language is continuing to progress, and new
features are also added via extensions (such as Tile). The
will/discipline to push out a major new version, though, lags behind
Python, for instance (which just released 2.5; 2.4 came out in late 2004
IIRC). (Though Perl is just as bad if not worse...how long has Perl 6.0
been under development?)
You should only be concerned about Tcl's "marketing" cachet if you are
trying to interest clients or employers in your Tcl skills. Languages
come in and out of popularity; it doesn't necessarily have anything to
do with how useful or powerful they are. Ruby is hot right now because
of Rails; but how easily can you do GUI programming with it? Python has
bindings to lots of GUI toolkits, but those toolkits (apart from Tk) are
almost all based on C++; great if you know C++, but not very helpful if
you don't know C++ (like me). I'm not familiar with Perl at all, so I
can't comment there. But Tcl/Tk is undergoing constant development, and
has a very supportive community.
Speaking from my own experience, Tcl/Tk offers a superb toolkit for GUI
programming: the tight integration between the two has greatly reduced
my learning curve, allowing me to develop a range of techniques and
library of code snippets that enhances my productivity. I've released
three shareware apps in the past year and am currently working on three
more. I don't believe that pace of development would be sustainable with
another environment, at least not for me. My goal is to build up a full
shareware development business, and Tcl/Tk is a crucial part of that goal.
I've evaluated lots of other languages: Python, C, Objective-C, C++, and
AppleScript (because I focus on the Mac). I always come back to Tcl/Tk,
except for some little Mac-specific things that are done more easily in
AppleScript. It's simply the best toolkit I've found for rapid
development of desktop GUI applications.
Hope this helps,
Kevin
--
Kevin Walzer
Poetic Code
http://www.kevin-walzer.com
Peter Dalgaard
> Peter Dalgaard wrote:
> [...]
> > ActiveTcl, for all its virtues, is a single-platform proprietary item.
>
> What do you mean by this? ActiveTcl is available on 6 different
> platforms, as far as I can see (AIX, HP-UX, Linux, Mac OS X, Solaris,
> and Windows according to
> http://www.activestate.com/Products/ActiveTcl/?mp=1). I use it on 3 of
> those myself.
Yes, should have checked that. However, the point was never that it is
not available, but that it is not what e.g. a standard Fedora or SuSE
user will have in hand.
> > What it provides is not usable under e.g. Linux, or even on Windows if
> > you want to bundle Tcl/Tk with other software.
> Again, what do you mean by "not usable under ... Linux"? I use
> ActiveTcl under Linux almost daily. ActiveTcl is an effective
> "batteries included" distribution for end-users.
I meant that you cannot assume that it is there.
> Bundling/redistribution is a separate issue.
No. It's _the_ _reason_ you cannot assume the presence of ActiveTcl.
ActiveTcl is something that you need to tell the end-user to go
download (and install and maintain by nonstandard methods, as far as I
can tell). On Windows, this is just "business as usual" - you also
need to tell people where to get a C compiler, perl, emacs, younameit,
but on the modern Unix-alikes things are usually done differently.
Victor Wagner
: > The usual way for the average Tcl newbie is to install ActiveTcl, and
: > this comes with everything included. I don't see an action item here.
: Whoops! I can't leave that one alone.
: ActiveTcl, for all its virtues, is a single-platform proprietary item.
It is wrong. There are ActiveTcl distributions for other platforms, such
as Linux, solaris, MacOS X etc.
They are not so widely used, because all Linux distributions do include
Tcl/Tk, and most of other stuff, although outdated, and most people who
use Tcl on HP/UX or Solaris typically know enough to build thing
theirselves.
Considering bundling Tcl with your product - main problem with ActiveTcl
here is that you need to buy OEM contract to distribute ActiveTcl with
your product. Other problem is that it is BI-I-IG.
Really, I've created distribution of one of our tcl-based products which
fits on single floppy - Tcl, Tk, all neccessary libraries and our
functionality. ActiveState Tcl is 21Mb for same platform.
I'd better use freewrap - it doesn't contain lot of things I don't need.
--
Larry W. Virden
> But to make it
> happen and to keep Tcl alive (and make fresh and attractive for others)
> there is much too less active and coordinated development of the language
> core and its peripherals _and_ of the social or marketing component of it.
Or, from another perspective, there are too few killer apps being
written in it.
Something interesting though, is that I do see a lot of questions, over
the months, from eggdrop users. That seems to be one place where new
programmers are aware of Tcl's possibilities.
Michael Schlenker
> Now, having suggested this there is undoubtedly someone out there who
> will say "put your money where your mouth is" and write an article,
> update a wiki page or any other of the numereous suggestions. Well,
> here's the problem: qualification. First, like everyone else there is a
> time issue, second topics to write about, third probably a lot of
> people don't feel their programming skills are good enough to be able
> to post for the world to see.
Many PHP and Java coders don't have such sings of good taste.
>
> So I propose this. Why not a mentoring system? A qualified tcl/tk
> developer pairs with someone who does have the time, the motivation and
> the desire to see the language get more publicity, who can write an
> article, then have it reviewed by their mentor before publishing to a
> website? I am unsure if this is the best way at this time, but it's the
> only thing I can think of currently.
>
I see a lot of 'my first try with language xyz' or framework xyz on
sites like reddit, where the languages vary usually between Ruby,
Python, Erlang, Lisp/Scheme, Haskell. The authors don't have a real
insight in the language they are writing about. But they write
nontheless...
In this bloggocentric world i would say, publish first then update when
the comments arrive. Its not bad to be wrong, its just bad to not fix
things if you notice. And sometimes its even the right thing to post
something grossly wrong, so you get the attention.
Mentoring and Proof-Reading is a lot of work, ok for dead wood
publication or if you want to write your opus major, but for some
marketing blog post? Not really worth the trouble.
Michael
Donal K. Fellows
> What i'm getting at is that Tcl/Tk is a great language with lots to
> offer. But Tk really needs a facelift. I am not talking about Tile, I
> know about that, but Tk needs the face lift. It isn't that apparent on
> Windows (No idea about TkAqua), but on FreeBSD/Linux it certainly looks
> out of place! Maybe Tile will indeed fix this issue? Certainly not
> without a tremendous amount of work on the developers end from what I
> can see, atleast for mature apps.
There's work ongoing to do a theme for Tile that is based on Qt. I don't
know how mature this code is (I'm currently using Windows XP, where Tile
makes apps look pretty much perfect) but it should make for a reasonably
integrated L&F on at least some Linux desktops.
> Tcl/Tk needs better marketing. And good articles are a part of this.
You're absolutely right here, but I'm terrible at doing this sort of
thing (and I've been up to my eyeballs in pay-work for most of the past
year too).
> Now, having suggested this there is undoubtedly someone out there who
> will say "put your money where your mouth is" and write an article,
> update a wiki page or any other of the numereous suggestions. Well,
> here's the problem: qualification. First, like everyone else there is a
> time issue, second topics to write about, third probably a lot of
> people don't feel their programming skills are good enough to be able
> to post for the world to see.
The second point isn't as big an issue as all that. Even just an article
on Eggdrop would be fine if that's what you know. If you're worried on
the third point, don't. Instead, ask your fellow Tcl'ers for help. Say
what you're doing ("writing an article on XYZ") and that you'd like a
little bit of an informal tech review. I've found over many years that
the Tcl community is helpful almost to a fault; I'm sure someone would
be happy to assist. In fact...
> So I propose this. Why not a mentoring system? A qualified tcl/tk
> developer pairs with someone who does have the time, the motivation and
> the desire to see the language get more publicity, who can write an
> article, then have it reviewed by their mentor before publishing to a
> website? I am unsure if this is the best way at this time, but it's the
> only thing I can think of currently.
... I'm happy to help review anything that anyone writes. If you have a
tech question, just ask. But bear in mind if you're writing about
Eggdrop that I really don't know it as an application, so I'll only be
able to offer "general experienced Tcl hacker" help. :-)
Donal.
Kevin Walzer
>
>> But to make it
>> happen and to keep Tcl alive (and make fresh and attractive for others)
>> there is much too less active and coordinated development of the language
>> core and its peripherals _and_ of the social or marketing component of it.
>
> Or, from another perspective, there are too few killer apps being
> written in it.
It would certainly be helpful from a marketing standpoint to see more
"killer apps" being written in Tcl/Tk. It's difficult to think of a
prominent Tcl/Tk app that fits this description. For desktop apps,
Python has BitTorrent, not to mention Google as a prominent users of
the language (Google has Guido van Russom as an employee now). When I
look at the wiki, I see lots of apps, but many of them are obsolete;
others are still active but are so specialized (scientific domains, for
instance) that they can't command general attention. And hardly any of
them make use of Tile, so they tend to have an Win32/Motif look about
them that gives off a whiff of "outdated"--even if they are not.
I try to put up screenshots of all of my Tile-based apps at the wiki. I
worry about seeming too self-promoting--but the goal isn't to spam the
wiki with my commercial releases, but to give some examples of what can
be done with both Tcl/Tk and the Tile widgets. I'd like to see more
examples of this from others.
---
Neil Madden
> Neil Madden <n...@cs.nott.ac.uk> writes:
>
>> Peter Dalgaard wrote:
>> [...]
>>> ActiveTcl, for all its virtues, is a single-platform proprietary item.
>> What do you mean by this? ActiveTcl is available on 6 different
>> platforms, as far as I can see (AIX, HP-UX, Linux, Mac OS X, Solaris,
>> and Windows according to
>> http://www.activestate.com/Products/ActiveTcl/?mp=1). I use it on 3 of
>> those myself.
>
> Yes, should have checked that. However, the point was never that it is
> not available, but that it is not what e.g. a standard Fedora or SuSE
> user will have in hand.
I think SuSE do actually ship many/most of the extensions that ActiveTcl
contains as part of their standard distro. No idea about Fedora. But, in
what way is the fact that ActiveTcl is not available everywhere a valid
criticism of ActiveTcl itself? Red Hat and SuSE *could* adopt ActiveTcl
as a standard set of extensions and bundle their own versions.
I think it's a bit much to criticise ActiveState -- who are doing the
Tcl community a great favour in distributing a *free* QA'ed batteries
included distro on many popular platforms -- on the grounds that they
can't guarantee that ActiveTcl or equivalent will be installed on every
machine you need to run on. Nobody could possibly guarantee that. Even
if the TCT blessed a standard set of extensions for distros to include,
you would still have to wait many years before any kind of guarantee
could be made (and even that is not very likely).
>
>>> What it provides is not usable under e.g. Linux, or even on Windows if
>>> you want to bundle Tcl/Tk with other software.
>
>> Again, what do you mean by "not usable under ... Linux"? I use
>> ActiveTcl under Linux almost daily. ActiveTcl is an effective
>> "batteries included" distribution for end-users.
>
> I meant that you cannot assume that it is there.
Again, this is hardly the same as "not usable".
>
>> Bundling/redistribution is a separate issue.
>
> No. It's _the_ _reason_ you cannot assume the presence of ActiveTcl.
> ActiveTcl is something that you need to tell the end-user to go
> download (and install and maintain by nonstandard methods, as far as I
> can tell). On Windows, this is just "business as usual" - you also
> need to tell people where to get a C compiler, perl, emacs, younameit,
> but on the modern Unix-alikes things are usually done differently.
What exactly is the problem, again? Most modern Unix-alikes (Mac OS X,
SuSE etc) seem to come with Tcl/Tk and many/most of the extensions that
are in ActiveTcl. As you say, on Windows it is fair enough to just ask
users to download ActiveTcl. So what is the problem, and what is your
proposed solution to it?
-- Neil
Mark Roseman
cracked and weather-beaten sign, obviously from the mid-90's, hangs over
a large boarded up window. It reads "Tcl and Tk Programming House and
Support Group". The word "Tk" has been recently updated on the sign,
and now is made up of a set of small shiny tiles of different colors, at
stark contrast to the rest of the sign.
Inside, a number of generally older men shuffle around quietly, mumbling
to themselves. Jeff Hobbs stands behind the counter near the front,
slowly sipping from a stained coffee mug full of fine whisky. A small,
half-empty bookshelf of dust-covered books is on the wall behind him.
All of a sudden, there is a loud noise, and a young, bright-eyed skinny
college student tumbles down what looks like an oversized laundry chute,
conspicuously located where most stores would have a door, and lands in
the shop. He gets up, looks around and approaches Jeff at the counter,
who looks up.
Newbie: Hi! I'm in computer science at the local university. My
grandfather told me that I should learn Tcl and Tk because it'll allow
me to do all kinds of cool stuff. But when I mention that to my friends
at school, they all laugh at me and tell me that Tcl is totally obsolete
and for losers. Now I'm worried! Is Tcl dying out?
Jeff sighs, and picks up a desk calendar from the shelf behind him. He
looks down, quietly says "right on time", and puts a big check mark next
to a handwritten note on the current day. He then makes another entry
on the calendar three months later.
Larry Virden walks up from the back of the shop towards the young
programmer.
Larry V.: I couldn't help overhearing your concerns. Don't you worry,
Tcl and Tk are fully open source, so how can they die? There are copies
of it everywhere, so it will last forever! It's indestructible!
Newbie: But what if nearly everyone stops using it?
Larry V.: As long as there's one programmer left in the world still
working with it, Tcl will live on! And think of all the people running
Eggdrop - Tcl is thriving!
Richard Suchenwirth pops his head briefly through a window.
Richard S.: You should see this cool AS/400 simulator I wrote in Tcl;
here, it runs on my phone. All it took was one weekend!
Newbie: But what about web applications? That's really important today,
and I don't hear much about Tcl.
Dave Welton, who's been working at a desk nearby, looks up. Around him
are several Ruby and Rails books, a large stack of money from his
clients, and a bunch of neat demos of Hecl that he's been having fun
working on.
Dave: He does have a point. Tcl is a pretty nice language for web
applications, especially embedded things and where you're deploying to
customers, but it does seem to have fallen behind for a lot of
mainstream uses. Tools like Rails do make a lot of common things pretty
easy.
An angry voice from the back screams at Dave: You idiot! What do you
know about web programming and Tcl anyway? Haven't you heard of the Tcl
Apache project? And there are other web servers you know!
On cue, two groups of hackers in the back line up on either side of the
shop and face each other. One group repeatedly yells "AOLserver!" at
the other, who repeatedly respond with "tclhttpd!".
Jeff: Besides, if we had a tool like Rails it would run a heck of a lot
faster than in Ruby, and I18N would work right. Sure, we don't have
something like Rails, but it's just a small matter of programming, I'm
sure I could put it together in a weekend.
Richard S. (popping his head in again): Me too!
Jean-Claude Wippler, who has just finished an enormous plate of sushi,
wanders over.
Jean-Claude: Besides, Tcl gives you all kinds of novel choices for
databases for your web application or anything else. And look here,
I've just rewritten Metakit again using Simula-67. Makes the Tcl
binding much cleaner and more straightforward, and that'll certainly be
easier to get compiled than C++.
Jeff: (groans)
Newbie: That's interesting. I'd heard that SQLite even had a Tcl
binding, and that's the coolest thing I've ever seen.
Richard Hipp, who's been frantically bouncing around the room the entire
time, steers himself in that direction.
Richard H.: Well gosh darn, nobody will believe me when I tell them that
I really love Tcl, and that SQLite was really
made for Tcl. But they never listen to me, they're just too busy
shoving money in my face to do work for them. Boy
it's tough.
Jean-Claude: Hey, I just got Metakit working on this vacuum tube I
found. This time I know I've got it!
Richard S.: Hey, last weekend I used Tcl to turn a vacuum tube into a
space shuttle. How cool is that?
Newbie: Wow, there certainly do seem to be a lot of neat things that
people are doing with Tcl. It must be really useful. I don't see it on
job postings a lot though. What kind of jobs do you guys get?
Jeff: You'd be surprised how many companies use Tcl internally,
especially for things like testing and internal tool development. But I
can't tell you about any of them or I'd be shot.
Someone else pipes up: Besides, a lot of us just start our own
companies. It's not like we could get hired anywhere since we're not up
on all the latest buzzwords. Hey, had you heard of this brand new
language that's just come out called Java?
Dave: But it would help a bit if a few more people were doing some more
marketing. That web site really needs some work.
Richard S.: No need, everything is on the wiki. What more do you want?
Larry V.: Exactly, it's fine, what difference does it make? And it
works with Lynx!
Richard S.: Did I mention the weekend when I rewrote Lynx in Tcl but
made it 3D?
Newbie: That's pretty cool! So what are you guys working on now?
What's next for Tcl?
Jeff: Well, we've got some pretty cool stuff - an improved, modern user
interface and a brand new object system. I think it's the 100th object
system done in Tcl; how many languages can say that? So as soon as
Donal finishes, we'll be ready to release.
Donal (from a small cellar in the basement, where he's been locked):
Help! Let me out of here!
Joe English is sitting in another corner, chipping away and polishing a
gigantic pile of ceramic tiles.
Joe: You know, this is all great and such, but if anyone else wanted to
help out, that'd be okay!
Jeff: So yeah, the next release should be any day now.
Larry McVoy pops down the chute where the front door should be, carrying
a long pointy stick.
Newbie: Hey, what's with the stick?
Larry M.: I need it to go around poking all those free software weenies
in the eye. Suckers. You should have seen Stallman after I got him
last week. It was hilarious! He hasn't been around here again lately
has he?
Everyone: No, thank god.
Larry M.: By the way, I hate to keep mentioning it, but if you guys
would just put a front door on this shop like people are used to instead
of the stupid laundry chute that people have to use to get in, you might
get a few more people coming through.
Gerald Lester offers Larry a bottle of hot sauce, and turns on the neon
sign he wears on his ballcap saying "ask me about the oil platform...
please!"
Gerald: You know Larry, I think laundry chutes are kinda nice.
A large box comes flying down the laundry chute and lands with a thud.
Newbie: Wow, that's a pretty big box? What's in that?
Jeff: Just today's batch of "thank you" cards, from all the people who
are happily using Tcl to get their job done, and not worrying about
whether it's dying or not, or caring how it compares with Ruby or Python
or Java or whatever. They seem to think that it's nice having a choice
of tools out there, and if Tcl works for them, they're happy.
Newbie: I think I get it now. You know, I've learned something today.
Sure, there are lots of different tools out there, and their popularity
goes up and down. Some get a lot of attention for particular things.
Others may not be as flashy but get the job done, and may be better for
a different set of problems. If we spent less time worrying about who
was better and who sucked, and actually learned from each other, we'd
make life better for a lot of people. It's not so important to prove
you're right and the other guy is wrong. Maybe we could all work
together and make it easier for everyone to do their jobs, rather than
wasting time arguing with each other.
Larry M.: Yeah, like that's going to happen.
Fade out.
Scene: a nice office, far far away. John Ousterhout is sitting in front
of a row of video screens showing images from hidden cameras all around
the shop. A group of TV executives is watching closely.
John: See, I knew all along the only way we'd make money from Tcl is by
getting all these technical guys in one spot and making a reality TV
series out of it!
si...@whiteowl.co.uk
</snip>
> And so on..., look at the drafts at the TIP site.
>
> If _you_ want any of this to happen in Tcl 8.5 / Tk 8.5 get something
> done, adopt a TIP write a ref implementation and push the TCT to vote on
> the subject.
>
> Michael
I wasn't aware that TIPs got approved if they didn't have some sort of
reference implementation. Surely we aren't now in the situation that
8.5 is being held up because a TIP that was approved for 8.5 doesn't
have an implementor. Or are you saying that all TIPs approved for 8.5
have to be implemented before it is released. If that is the case (I'll
be suprised if it is) it would be nice if someone in the TCT could
summarize with a list of those TIPs and perhaps a statement that no
more TIPs will be accepted for 8.5.
As it happend I did want something done and so I produced a TIP which,
after discussion was approved. I did the implementation work and the
result has been sitting in the 8.5 tree for more than a year. If 8.5
isn't defined then no amount of people working on it is going to
produce a release. There will always be new nice-to-have TIPs being
added. Without the TCT saying what the requirement for 8.5 is and
giving a definitive list of TIPs and bug-fixes for 8.5 there is no
process in place to release 8.5 on any timescale.
Another point that IMHO is worth making is that tcl is a community
effort. Most people give up some of their free time in order to
contribute to a language they like and believe in (whatever that
means!). I know that my own contribution is very small, but personally
I find that it can be very demotivating if having spent your free time
implemeting a TIP you then see your contribution sitting in an
unreleased branch of the code for years without any real prospect of
release.
Simon Geard
Michael Schlenker
> Neil Madden <n...@cs.nott.ac.uk> writes:
>
>> Peter Dalgaard wrote:
>> [...]
>>> ActiveTcl, for all its virtues, is a single-platform proprietary item.
>> What do you mean by this? ActiveTcl is available on 6 different
>> platforms, as far as I can see (AIX, HP-UX, Linux, Mac OS X, Solaris,
>> and Windows according to
>> http://www.activestate.com/Products/ActiveTcl/?mp=1). I use it on 3 of
>> those myself.
>
> Yes, should have checked that. However, the point was never that it is
> not available, but that it is not what e.g. a standard Fedora or SuSE
> user will have in hand.
Standard Fedora or SUSE user..., if you add Debian in it gets absurd.
The main thing you have with a standard user is inconsistency.
Ok, if someone packaged up an app or deb as an rpm for a specific
distribution i may be lucky that it works. This is usually the case for
most apps included with the distribution, but not always.
(example: Eclipse fails miserably on SUSE 10.1 x86_64 because the
java-gtk binding is only provided as a 32-bit version...).
Unless you run exactly the distro your building packages for, your
doomed for failure, due to the non-stable glibc and kernel apis on
Linux. Try building anything that works on a redhat 5.x to Fedora Core 4
System without recompile.
Or try to get a decent Firefox for a Pentium I System on Linux, fun
stuff, need to recompile everything.
Tcl has the benefit that it is easier to ship your custom Tcl install
without the need for system wide installation files and things, then
with other langs.
>>> What it provides is not usable under e.g. Linux, or even on Windows if
>>> you want to bundle Tcl/Tk with other software.
>
>> Again, what do you mean by "not usable under ... Linux"? I use
>> ActiveTcl under Linux almost daily. ActiveTcl is an effective
>> "batteries included" distribution for end-users.
>
> I meant that you cannot assume that it is there.
Right. But thats a similar situation for many other packages. I'myself
find me currently cursing distributors that they missed package x or y,
which is absolutley critical, or that they bundled only the static lib
or only the dynamic lib or an old version or whatever.
>> Bundling/redistribution is a separate issue.
>
> No. It's _the_ _reason_ you cannot assume the presence of ActiveTcl.
> ActiveTcl is something that you need to tell the end-user to go
> download (and install and maintain by nonstandard methods, as far as I
> can tell). On Windows, this is just "business as usual" - you also
> need to tell people where to get a C compiler, perl, emacs, younameit,
> but on the modern Unix-alikes things are usually done differently.
>
As i said above, the shrink wrap approach on modern unix-alikes does not
work (apart from OS X, where it might work). Take a look at distrowatch,
it list more than a thousand Linux distributions, each with its own
little differences in packaging guidelines, package locations and so on.
Add the BSD's and other OSs to the picture and things don't get
brighter. Not even the widely used rpm is maintained, SUSE and Redhat
are working from private, diverging forks of the code base.
So if you want complete Tcl package covering in many more distros just
start packaging things up:
For SUSE start with the Build Service:
http://en.opensuse.org/Build_Service
For Debian enlist you self to the new tcltk-pkg team:
http://lists.alioth.debian.org/mailman/listinfo/pkg-tcltk-devel
I'm sure others could add the appropriate places for the distro of your
choice.
Its not an impossible task for the extensions following the TEA build
system, as Daniel Steffen demonstrated with his Apple OS X bundling of
Tcl/Tk and comments from Jeff Hobbs indicate similar things for
ActiveTcl, but its work to be done. And work that has to be done again
for each new distro release, each new extension release. Most Tcl
extensions are actually quite easy to build (there are exceptions of
cause, lots of em, as always).
Maybe I'm ranting a bit too much, but blaming ActiveTcl for faults of
Linux distributors is a bit of mark.
Michael
P.S. I personally think Reinhard Max does a great job for SUSE,
packaging Tcl, although i would like to have mysqltcl and xotcl and dict
added to the list of available packages.
Bryan Oakley
> Scene: A run down shop at the end of a long, mostly deserted street. A
> cracked and weather-beaten sign, obviously from the mid-90's, hangs over
> a large boarded up window. It reads "Tcl and Tk Programming House and
> Support Group". The word "Tk" has been recently updated on the sign,
> and now is made up of a set of small shiny tiles of different colors, at
> stark contrast to the rest of the sign.
Priceless.
Uwe Klein
just sprayed my Draft of Tcl-URL with Coffee.
This is going to be a long night.
uwe
Michael Schlenker
> Scene: A run down shop at the end of a long, mostly deserted street. A
> cracked and weather-beaten sign, obviously from the mid-90's, hangs over
> a large boarded up window. It reads "Tcl and Tk Programming House and
> Support Group". The word "Tk" has been recently updated on the sign,
> and now is made up of a set of small shiny tiles of different colors, at
> stark contrast to the rest of the sign.
Lol!
Ever tried to get hired in Hollywood?
Michael
Peter Dalgaard
> Peter Dalgaard wrote:
> > Neil Madden <n...@cs.nott.ac.uk> writes:
> >
> >> Peter Dalgaard wrote:
> >> [...]
> >>> ActiveTcl, for all its virtues, is a single-platform proprietary item.
> >> What do you mean by this? ActiveTcl is available on 6 different
> >> platforms, as far as I can see (AIX, HP-UX, Linux, Mac OS X, Solaris,
> >> and Windows according to
> >> http://www.activestate.com/Products/ActiveTcl/?mp=1). I use it on 3 of
> >> those myself.
> > Yes, should have checked that. However, the point was never that it
> > is
> > not available, but that it is not what e.g. a standard Fedora or SuSE
> > user will have in hand.
>
> I think SuSE do actually ship many/most of the extensions that
> ActiveTcl contains as part of their standard distro. No idea about
> Fedora. But, in what way is the fact that ActiveTcl is not available
> everywhere a valid criticism of ActiveTcl itself?
Ah, read more closely (possibly between the lines): I am not
criticizing ActiveTcl, but the fact that it was being used as an
argument for not making something an "action item". I was pointing out
that ActiveTcl is not for everyone, and it is not reasonable to rely
on their services.
> Red Hat and SuSE
> *could* adopt ActiveTcl as a standard set of extensions and bundle
> their own versions.
Yes, but see below.
> I think it's a bit much to criticise ActiveState -- who are doing the
> Tcl community a great favour in distributing a *free* QA'ed batteries
> included distro on many popular platforms -- on the grounds that they
> can't guarantee that ActiveTcl or equivalent will be installed on
> every machine you need to run on.
(It is "free" as in beer, not as in software. For free software
applications, the no-redistribution requirement becomes a real
problem.)
> Nobody could possibly guarantee
> that. Even if the TCT blessed a standard set of extensions for distros
> to include, you would still have to wait many years before any kind of
> guarantee could be made (and even that is not very likely).
I think you're being overly pessimistic there. Actively encouraging
distribution of particular extensions could go quite a long way.
Prepackaged BI-style sources help too. Even better if there is some
activity checking whether extensions break upon new iterations of the
Tcl core.
> >
> >>> What it provides is not usable under e.g. Linux, or even on Windows if
> >>> you want to bundle Tcl/Tk with other software.
> >
> >> Again, what do you mean by "not usable under ... Linux"? I use
> >> ActiveTcl under Linux almost daily. ActiveTcl is an effective
> >> "batteries included" distribution for end-users.
> > I meant that you cannot assume that it is there.
>
> Again, this is hardly the same as "not usable".
For me, it is, actually. But please, don't take it in the derogatory
sense; of course it is perfectly usable for many people.
>
> >
> >> Bundling/redistribution is a separate issue.
> > No. It's _the_ _reason_ you cannot assume the presence of ActiveTcl.
> > ActiveTcl is something that you need to tell the end-user to go
> > download (and install and maintain by nonstandard methods, as far as I
> > can tell). On Windows, this is just "business as usual" - you also
> > need to tell people where to get a C compiler, perl, emacs, younameit,
> > but on the modern Unix-alikes things are usually done differently.
>
> What exactly is the problem, again? Most modern Unix-alikes (Mac OS X,
> SuSE etc) seem to come with Tcl/Tk and many/most of the extensions
> that are in ActiveTcl.
The mainstream linuxen seem to be getting there (it used to be a
bigger problem). I'm less sure about the older Unixen: Solaris, HP-UX,
IRIX et al.. Finding out which extensions are available on which
platforms that is still messy.
> As you say, on Windows it is fair enough to
> just ask users to download ActiveTcl.
(Actually, we have chosen not to do so and ship with a self-compiled
version of Tcl/Tk core on Windows.)
> So what is the problem, and what
> is your proposed solution to it?
I just don't want the development to be impeded by the redistribution
policy of a private company.
Michael Schlenker
> reference implementation.
TIPs are good ideas that should be implemented. But it is an illusion to
think: Oh, there is a TIP, so someone else will do the work, and i don't
have to do anything myself to get all those goodies.
> Surely we aren't now in the situation that
> 8.5 is being held up because a TIP that was approved for 8.5 doesn't
> have an implementor. Or are you saying that all TIPs approved for 8.5
> have to be implemented before it is released.
No. Its just there are lots of 'would be nice to have' TIPs, but no one
moves them really forward.
Michael
Darren New
>> multithreading (for me) is even more
>> important,
>
> Dito, mt is there since 8.4 at least.
And with real threads, yet - something most of the other scripting
languages fail at, surprisingly enough.
--
Darren New / San Diego, CA, USA (PST)
Just because you find out you are
telepathic, don't let it go to your head.
Tom Poindexter
Mark Roseman <ma...@markroseman.com> wrote:
>Scene: A run down shop at the end of a long, mostly deserted street. A
Hehehehehehehe....
>John: See, I knew all along the only way we'd make money from Tcl is by
>getting all these technical guys in one spot and making a reality TV
>series out of it!
^
|
----------------------------------------------------------
|
V
Shouldn't that be a "Reali-Tk" TV series.
--
Tom Poindexter
tpoi...@nyx.net
Helmut Giese
I bet you're an avid reader of Dr. Dobb's and enjoy Swaine's Falmes.
Very nicely done, thank you.
Helmut Giese
Bruce Hartweg
> Some funny stuff
Nice!
Bruce
Ralf Fassel
Larry W. Virden
Mark Roseman wrote:
> Scene: A run down shop at the end of a long, mostly deserted street.
This deserves to be immortalized... but not, obviously, as a QOTW since
it would triple the normal size :-D
Mark, as always, you have touched so many of the items. About the only
things I see missing are Cameron Laird and the annual workshops...
Darren New
> This deserves to be immortalized...
It's already on Reddit with a link to google groups.
Bruce Stephens
> I used to be very active in Tcl/Tk programming back in 2001. I was just
> trying to get back into it and I started looking around but couldn't
> find much recent development (other than work at ActiveState). I found
> the roadmap for tcltk 9.0 on www.tcl.tk being promised for 2003
> specially disturbing! How worried should I be about tcl/tk's future?
Not very, I think. There's no particular reason to believe that it's
any less useful than it was before.
I think there's good reason to believe that it has less impact than
before, simply because the various niches ("scripting language",
"easily extensible language", "cross platform scripting language",
"easily learned language", etc.) have a lot more competition nowadays.
And many people find another language works better for what they want
to do, whereas not so long ago they'd have chosen Tcl (because nothing
else qualified).
David N. Welton
>> What it provides is not usable under e.g. Linux, or even on Windows if
>> you want to bundle Tcl/Tk with other software.
>
> Again, what do you mean by "not usable under ... Linux"? I use ActiveTcl
> under Linux almost daily. ActiveTcl is an effective "batteries included"
> distribution for end-users. Bundling/redistribution is a separate issue.
I would bet good money that the relation of Tcl installations to
ActiveTcl installations on Linux is around the order of 1000/1. There's
something terribly short-sighted in that, along the lines of "we'll only
give you a good Tcl installation if you ask for it". Ruby, PHP and
Python have the sense to give you something much more useful than Tcl in
terms of libraries, out of the box.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
David N. Welton
>> Tcl/Tk needs better marketing. And good articles are a part of this.
> You're absolutely right here, but I'm terrible at doing this sort of
> thing (and I've been up to my eyeballs in pay-work for most of the past
> year too).
This is the real problem with waning popularity. It's difficult to get
hired to work exclusively on what you want (I don't think the Python or
Ruby guys work on their languages full time), but when most (some/a
significant portion) of the core team doesn't even get to use Tcl in
their day jobs, that's a warning sign.
David N. Welton
> 2. One of the reasons for the bad marketing is, IMHO, the lack of a real
> roadmap. Tcl 8.5 and some fantasies about 9.0 are around since... when was
> Methusalem born? But although we can read here about whats going on and why
> things need so long (and please, I do not blame anyone of the core team,
> because I love Tcl and so I love, what they have done with and for Tcl in
> the past), the implicit message to the outside world is, that Tcl has
> simply stopped evolving somewhen in the late 90's.
At the risk of stepping on toes, I think in some ways that the core team
hasn't really filled Dr. Ousterhout's shoes. I don't know if the
problem is that having a 'benevolent dictator' is necessary, or if the
TCT simply hasn't been up to the task of not only hacking on the code,
but representing it as well.
JO got invited to conferences. The TCT is completely absent from the
open source scene. I mean, they might as well be herding yaks in
Mongolia for all the visibility they give the language in the "buzzy"
circles that matter for marketing things to future generations of geeks.
> convince, that Tcl is worth a look... Where is the image manipulation
> framework for Tcl? TclMagick was a good start, but...
Ok, this one involves me. But what?
> Tcl's community also needs refreshment from new and young programmers who
> brings life to the community.
Yep. But it is invisible to them....argh!
> For example in the Python (again...)
> newsgroup there are many postings starting with "I'm a newbie, please
> help..." - You might think, that those people are not a big help in
> developing a language anyway, so there is no reason to miss them. But they
> are: because they will be good programmers in the future, they learn Python
> instead of Tcl and they will later contribute to the development of the
> language and they will write cool scripts and apps. And everybody who sees
> those cool extensions or apps will ask: wow, what's it made with? And the
> answer then is not Tcl, which again is one step toward oblivion.
Precisely.
Donal K. Fellows
> I wasn't aware that TIPs got approved if they didn't have some sort of
> reference implementation.
We don't usually do it. We've learned to not do that.
> Surely we aren't now in the situation that
> 8.5 is being held up because a TIP that was approved for 8.5 doesn't
> have an implementor. Or are you saying that all TIPs approved for 8.5
> have to be implemented before it is released. If that is the case (I'll
> be suprised if it is) it would be nice if someone in the TCT could
> summarize with a list of those TIPs and perhaps a statement that no
> more TIPs will be accepted for 8.5.
There's a bit of a hold-up for a couple of TIPs that we want for
strategic reasons (Tile and OO) but we won't hold up for anything else.
Heck, we won't wait very long for even the current blockers.
There will (probably) be an announcement of the date of the 8.5 feature
freeze at (or, if we're unlucky, shortly after) the Tcl Conference.
Consider things to be slushy now. :-) I will not preempt that
announcement.
Once we've frozen, the Tcl maintainers will focus on trying to get the
bug count down and the execution speed up. Since 8.5 is in a much
better state than 8.4 was at an equivalent stage, I'd hope that this
period would be shorter. (8.4 had an excruciatingly long beta.)
Donal.
Donal K. Fellows
> I just don't want the development to be impeded by the redistribution
> policy of a private company.
I understand the specific issue to be fixed from the next release of
ActiveTcl; we (the good citizens of c.l.t) persuaded Jeff that the
license wasn't serving ActiveState's best interest as it stood.
Donal.
Peter Dalgaard
Cool...
Uwe Klein
> Stephan Kuhagen wrote:
>
>> 2. One of the reasons for the bad marketing is, IMHO, the lack of a real
>> roadmap. Tcl 8.5 and some fantasies about 9.0 are around since... when
>> was
>> Methusalem born? But although we can read here about whats going on
>> and why
>> things need so long (and please, I do not blame anyone of the core team,
>> because I love Tcl and so I love, what they have done with and for Tcl in
>> the past), the implicit message to the outside world is, that Tcl has
>> simply stopped evolving somewhen in the late 90's.
>
>
> At the risk of stepping on toes, I think in some ways that the core team
> hasn't really filled Dr. Ousterhout's shoes. I don't know if the
> problem is that having a 'benevolent dictator' is necessary, or if the
> TCT simply hasn't been up to the task of not only hacking on the code,
> but representing it as well.
we ARE a bunch of old friendly uncles as has just been narrated elsewhere.
Tcl does not even have a single parent in contrast to perl and python,
ruby:I don't know my way around ruby.
This has to some extent (drawn as a different picture) the taste of
starwars, jedi knights and young padavans.
To make the comparison: the star wars universe still has three episodes
open ( and in the future of the existent episodes at that)
Nothing says that the clone armies must win.
uwe
Donal K. Fellows
> This is the real problem with waning popularity. It's difficult to get
> hired to work exclusively on what you want (I don't think the Python or
> Ruby guys work on their languages full time), but when most (some/a
> significant portion) of the core team doesn't even get to use Tcl in
> their day jobs, that's a warning sign.
Hah. It was just a horrible project crunch caused by being more than a
little bit over ambitious elsewhere (and the horrendous state of some
Java tooling for web-services). Even if I'd been able to do it all in
Tcl, I'd still have had near zero time for Tcl core hacking for 9
months. It was just that sort of year. Over now. :-)
Donal.
Gerald W. Lester
> ...
> There should be much faster development to catch up with recent developments
> in other parts of the world. I know, there are things going on, but they
> are going on in half darkness, effectively hidden to the outside world. OO
> should be part of the language,
This is what 8.5 has been held up for.
> multithreading (for me) is even more important
That has been there for a long time.
> a modern GUI binding (Tk is cool in its simplicity, but it's so
> much outdated...) or toolkit
Have you looked at Tile, which is also part of 8.5
> a complete and comprehensive standard library
> is needed (as integral part of the core language and not as an add on) to
> give the programmer the tools she needs to get the every day things quick
> and concentrate on the real problems.
So you don't want it to be like JAVA, Perl, Python, Fortran, Pascal, ...
> I do not agree, that performance is
> such a problem as it is stated often when Tcl is compared to other
> languages. But more and better support for programming environments and
> debugging are needed desperately. I know, there are good tools from
> ActiveState, but where is the standard Tcl-Plugin for Eclipse
There are two under development that I'm aware of (have been posted here in
c.l.t in the last six months)
> or KDevelop (the IDE I like best).
Write it.
> For example in the Python (again...)
> newsgroup there are many postings starting with "I'm a newbie, please
> help..."
I saw at least six (or maybe more) of those here on c.l.t last week -- plus
a lot more on the TkChat channel(s).
> ... And everybody who sees
> those cool extensions or apps will ask: wow, what's it made with? And the
> answer then is not Tcl, which again is one step toward oblivion.
Most people can care less what an application is written in, as long as it
does what they want in a way that they want it to do it.
> ...
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Donal K. Fellows
> Jeff: Well, we've got some pretty cool stuff - an improved, modern user
> interface and a brand new object system. I think it's the 100th object
> system done in Tcl; how many languages can say that? So as soon as
> Donal finishes, we'll be ready to release.
>
> Donal (from a small cellar in the basement, where he's been locked):
> Help! Let me out of here!
Actually, the correct cry from the crypt there is: "Bwahahahahaaa! It
lives! My creation is alive, Igor!"
Donal.
Michael A. Cleverly
> > multithreading (for me) is even more
> > important,
>
> Dito, mt is there since 8.4 at least.
From everything I've ever read Tcl is ahead of Ruby, Perl, & Python, etc.
in this area. Still.
Michael
Michael A. Cleverly
SOTY? (Script of the year)
Jeff Hobbs
Let's not misunderstand the changes in the EULA for ActiveTcl. They
allow limited redistribution within other single-file wrapping
applications (specifically to date, starkits, freewrap and tobe). The
changes will not allow outright redistribution of ActiveTcl or random
parts (that still requires an OEM license). The EULA changes are not
necessarily in ActiveState's best interest, but in ActiveState's
interest in helping the community (which is a key part of the whole
circle of life thing).
--
Jeff Hobbs, The Tcl Guy, http://www.activestate.com/
Stephan Kuhagen
>> multithreading (for me) is even more important
>
> That has been there for a long time.
Sorry, that was not precise enough. I meant was multithreading on the
scripting level. I know, we all do and love the event based programming in
Tcl, and it solves the problem most of the time. But sometimes you really
want a real thread or a bunch of them, that does things in parallel without
managing the events that schedules you different threads yourself. Script
level multithreading is hard to implement in Tcl, I think, but I think, it
would make the language very attractive and more powerful is many ways.
> > a modern GUI binding (Tk is cool in its simplicity, but it's so
>> much outdated...) or toolkit
>
> Have you looked at Tile, which is also part of 8.5
No yet. And the reason is, that it simply does not exist in the real world.
8.5 is, until now, vaporware and so I do not spend any time learning all
the fine things, it offers. 8.4 is what you get (at best), when you need a
Tcl, that runs everywhere. And compared with other scripting languages and
other toolkits 8.4 is simply outdated for some years now. And that is a
pity, because the concept and integration of Tk in Tcl is really good.
>> a complete and comprehensive standard library
>> is needed (as integral part of the core language and not as an add on) to
>> give the programmer the tools she needs to get the every day things quick
>> and concentrate on the real problems.
>
> So you don't want it to be like JAVA, Perl, Python, Fortran, Pascal, ...
I want it to learn from the success of others. There is no way surviving,
when everything you see are the advantages of Tcl compared to the others.
It has many of them, that's why I like it so much. The pure language and
it's design ans concept fits my kind of thinking better than anything else
I have ever found. But Tcl also has a huge amount of disadvantages compared
to the others. And one reason is, that it stopped evolving and the bad
"marketing". No, I don't want Tcl to be like Java, although I think it is a
good designed language. But Java has extensive support libraries for all
kinds of stuff. Python is even better as an example. Sometimes I get really
knots in my brain, when programming Python (but I got used to it, and in
some way, it is a good designed language - but designed by a mathematician,
not by a software engineer. I think, one can feel the difference...), but
the standard library, that comes with Python is overwhelming. You have
simply everything! (And it has _good_ Scripting level threading, just to
say that to the people who state, that Tcl has better threading that most
others. Sorry, it has not...) - The standard library that comes with Python
is an integral part of Python. I mean the thing you download as a tarball
and do a "configure && make & make install" with. - What do you have, when
you do this with Tcl? Nothing. ActiveStates distribution may be a big step
in the right direction but ActiveStateTcl is not Tcl, it is just a good
distribution package. But you do not always have it at hand, and one should
not confuse one prepackaged distro with the thing itself. You don't think,
gcc or VisualStudio _is_ C++, right? It is just one possibility to get it
on your system. What is needed is a definitive Tcl base. Others then can
build their distros with it (as it already happens). And this base must
have the stuff, that other competing languages have in their base package.
> > or KDevelop (the IDE I like best).
>
> Write it.
This is the kind of answer that has been perfectly described in Mark
Rosemans posting (LOL again!): "Yes, I can write that in no time". But the
problem is, that it is not there already. Maybe I could write that (but I
won't, because Emacs does it for me and it is more easy to switch from
KDevelop to emacs when programming as to extend KDevelop), but the question
for me really is, why is Tcl not attractive enough for the KDE people, to
have it already integrated into KDevelop? Look, they have Ada and Haskell
integrated (and a bunch of scripting languages), but no Tcl!
>> For example in the Python (again...)
>> newsgroup there are many postings starting with "I'm a newbie, please
>> help..."
>
> I saw at least six (or maybe more) of those here on c.l.t last week --
> plus a lot more on the TkChat channel(s).
Yes, six... Ever read comp.lang.python for some days? It can be a fulltime
job...
>> ... And everybody who sees
>> those cool extensions or apps will ask: wow, what's it made with? And the
>> answer then is not Tcl, which again is one step toward oblivion.
>
> Most people can care less what an application is written in, as long as it
> does what they want in a way that they want it to do it.
I do not agree. Yes, the user does not care. But other developers do,
because they always search for good tools, and managers do because they
want to say "hey look, we have done this neat app, and it is written in the
same language as the famous app XYZ from the big Company Z - so it must be
cool and powerful" From an engineers point of view, you may dislike such
arguments, but in the real world they count.
When one goal is to get new people to Tcl, there has to be some killer apps
written in it. But there are none currently. AOLServer and all the stuff
mentioned do not count, because if you try to advertise with an unknown
product (compared to other products in that category) from a dead company
(not dead yet, okay, but look at their decline in the last time...), this
seems not to be a very good argument for Tcl.
If I watch the answers in this thread so far, I remember a scene from a
Monty Python movie, where some guy collects all the dead people in a
village on a wheelbarrow. One old man is thrown on that wheelbarrow whining
"I'm not dead! I feel fine! I want to take a walk!" Bang! Hit on the head
and carried away. The OPs question was, if Tcl is dying out. But the
answers are mostly to the question, if Tcl is dead already. No, it is not,
but even if you really love Tcl and have nearly no contact to the outside
world, you can see, that Tcl is on a long decline since years. "Not dead
yet" is no argument, if you want to know, if Tcl has a future and how Tcl
can get a better position compared to other languages again.
I think, what is needed is not the introspection of the Tcl community which
I observe here as long as I read this group and other places about Tcl.
What is needed is to learn from the success of the other languages. Maybe
you do not need all the fancy things, that some others have, but obviously
there is some use of it, because otherwise nobody had written it and used
it. So, why did Python come into existence? Tcl was there for many year
before Python and people here always state, that Tcl is the better
language, but there have to be many drawbacks in Tcl, that lead other
people to search for alternatives and do the really big step to develop
another language, instead of extending Tcl. Guido van Rossum knew Tcl
before starting Python. Why was it necessary to start Python, Ruby or
others? And then what were the reasons for their success in many fields,
what are the advantages over Tcl? For Tcl to have a future, some of these
questions must be answered and the Tcl comunity must learn from the others.
But with the answers here, I can not see that. All I can see here is: "I'm
not dead! I feel fine! I want to take a walk!" Bang...
Regards
Stephan
Stephan Kuhagen
> At the risk of stepping on toes, I think in some ways that the core team
> hasn't really filled Dr. Ousterhout's shoes. I don't know if the
> problem is that having a 'benevolent dictator' is necessary, or if the
> TCT simply hasn't been up to the task of not only hacking on the code,
> but representing it as well.
Yes, I think I wrote something similar. Whats missing (besides many other
things) is a charismatic Mr(s) Tcl. I think this may be the most
problematic part of giving Tcl a future. The people here are mostly very
good software engineers, but to be charismatic, a face and name to the
world too, can not be learned easily. Learning Tcl is simple, but being a
star in the OpenSource community...
>> convince, that Tcl is worth a look... Where is the image manipulation
>> framework for Tcl? TclMagick was a good start, but...
>
> Ok, this one involves me. But what?
Oops... ;-) If I look on the website (sourceforge), I find no last update
line, but only the date 2004. That make me think, that there is not much
development in the last two years. To get it, you either have to check it
out from the repository and compile it (which is no choice for many people)
or go to the download section and find one binary version for Windows and
some older binaries for Linux, but no installers and no recent versions.
This simply leaves the impression, that it is not a really living and
maintained project.
Another thing, but that is a design decision, is that the API of TclMagick
reflects the API of ImageMagick very closely. This makes it very powerful
on the one hand, but OTOH very complex. I miss a simple interface, some
kind of scripting equivalent of a very simple drawing program.
But what is the biggest problem is something, that has not to do with
TclMagick. As I said, TclMagick was a good start, but it is not part of Tcl
as Tk is. If you install simply Tcl, you do not have anything to do simple
image manipulation. - I wrote a NightlyBuild system with graphical reports
here at our company. I wanted smileys to indicate with their mood the state
of the last build... ;-) Because it must run on different kinds of Windows
(XP, 2k at least), Linux (different distributions) and MacOSX, I can not
depend on too many extensions that are not part of the core. Another thing
is, that I do not have display access on all host everytime when I need to
draw something, so what I really wanted was a simple graphics extension in
the Tcl core which allows me to draw a yellow circle and some lines... I
did it as a completely dasy hack, but I did it in my spare time when I was
completely gone mad for some time... ;-)
>> Tcl's community also needs refreshment from new and young programmers who
>> brings life to the community.
>
> Yep. But it is invisible to them....argh!
Yes, argh! When I talk to younger people about how cool Tcl as a language
is, they really think it must be cool in the same way JavaScript or
VisualBasic is cool. I falling down, lying shrugging on the floor, if I
hear that...
Regards
Stephan
Stephan Kuhagen
>
>
>> But to make it
>> happen and to keep Tcl alive (and make fresh and attractive for others)
>> there is much too less active and coordinated development of the language
>> core and its peripherals _and_ of the social or marketing component of
>> it.
>
> Or, from another perspective, there are too few killer apps being
> written in it.
Exactly.
> Something interesting though, is that I do see a lot of questions, over
> the months, from eggdrop users. That seems to be one place where new
> programmers are aware of Tcl's possibilities.
We need more of those... If I had the time... ;-)
Stephan
Stephan Kuhagen
>> 2. One of the reasons for the bad marketing is, IMHO, the lack of a real
>> roadmap. Tcl 8.5 and some fantasies about 9.0 are around since... when
>> was Methusalem born? But although we can read here about whats going on
>> and why things need so long (and please, I do not blame anyone of the
>> core team,
>
> There is a valid reason for that - and this is quality. Tcl stands for
> API consistency and backwards compatibility, features that other
> languages are not so aware of. And this justifies that things need
> longer, IMO.
I agree, but not fully. Quality is a good reason for doing some things
carefully and without haste. But this does not explain a missing definitive
roadmap and the missing progress. You are right with the API consistency.
In Python you sometimes have the problem, that things simply stop working
from version to another, but somehow this seems not to be a problem since
the new version then has so much improvement and the porting from one
version to another is so simple, that it does no harm.
And I do not vote for making things just faster and sacrifice quality. But
that is not what happens. I know, the TCT works hard to get it right and
good, but to the outside world, there is no development to see in the
language and in it's supporting standard library. Just a few days ago the
new version of Python came out. It is something Tcl can learn from. There
was a clear timeline, when which alpha, beta and RC# come out, which
features are in which version, feature freeze, bugfix and done. Maybe the
steps, Tcl takes are too big to make them happen in a reasonable time.
Maybe there should be defined a small set of features that can be done in
six month each and then really be finished. This shows the people that
something happens and the language lives. Important features are faster in
the community and in the standard version.
>> The Tcl-lib has become a
>> good replacement for many missing features and standard library things in
>> Tcl, and there are many other good packages to add missing core
>> functionality, too. But this is not a good replacement for a real
>> standard library as it comes with other current hype languages such as
>> python. If
>
> The usual way for the average Tcl newbie is to install ActiveTcl, and
> this comes with everything included. I don't see an action item here.
This depends on the platform. On Linux/Unix this is not the default. The
distribution has Tcl already in it, and it is not ActiveState normally. For
Windows there is no alternative, I agree. But since Tcl is meant to be
platform independent, it must include a good base of functionality and a
good standard library in the core distribution (and that is, what you get
when taking the tarball and compile Tcl - compare what you get there, with
what you get in Python!) because when you really write cross platform
scripts and apps, you are often near the lowest common denominator of
features and extras available.
>> 3. Tcl has no good central repository for extensions and external
>> packages.
>
> True, really. We had this discussion recently here. My offer is still
> valid: if someone likes to put up a website based on AOLserver and
> maybe OpenACS for the central repository, I will host in on my virtual
> server. I just don't have the time to put the site together, otherwise
> I'd do it myself.
I know, I read that thread. I would really appreciate such thing. I'm a
little afraid that a virtual server and the constraints you give are too
tight for the job, but maybe it would be a good stating point.
>> 4. Compared to other languages there is very little good literature about
>> Tcl, I means books, paper...
>
> There are a few good books: "Practical Programming in Tcl and Tk",
> "Effective Tcl/Tk programming".. the latter is a little outdated,
> right.
They are all outdated in the same way the language is... Learning the basics
of Tcl is no problem with the books. But getting people enthusiastic about
Tcl and make them wanting to learn and use it is no way with the current
books.
> It would be good to have more books (for newbies) but someone
> has to write and publish them.
For newbies? I do that... ;-) Tcl is so simple to learn... Who publishes it?
I'm afraid, you only get raised eyebrows when going to a publisher with
such a book.
>> There should be much faster development to catch up with recent
>> developments in other parts of the world. I know, there are things going
>> on, but they are going on in half darkness, effectively hidden to the
>> outside world.
>
> There are good reasons for that sometimes. One is, that you find lots
> of crappy, half finished free software everywhere (especially in the
> Python and Java domain for some reason). Personally, I am always
> deterred of the language when I try to use a program written in that
> language and it just brings up lots of errors: "Hey, there are no
> memory leaks in this language... so there is no need for bugfixing,
> just throw the error - fine!".
That's right. But because they develop faster, they get over it faster. It
is an illusion to get it perfect with the first try, so evolution is
necessary. Today there are many development tools to assure high quality.
The situation is much better as when Tcl was invented. So I think, the
development of Tcl should use this and speed up a little.
> I wouldn't release anything to the public when it is not finished, at
> least to an extend where others will find it useful as well.
This is one possible philosophy of software development. I like another,
which I read in one of the older article from Eric S Raymond as one of the
main rules for good (successful) and fast open source software development:
"Releasy early, release often!" - Not every release should be marked as
production release then, but more and shorter release cycles (even with the
small danger of sometimes having a bug) seems better to me than giving
potential users the feeling, that the project had died and it would be
better to switch to something alive, even if it has some flaws left.
>> OO should be part of the language,
>
> Tcl 8.5. Many OO extensions available out of the box. It's just a
> marketing problem again.
No, its a problem that 8.5 isn't there!
>> multithreading (for me) is even more
>> important,
>
> Dito, mt is there since 8.4 at least.
I meant on the scripting level.
>> a modern GUI binding (Tk is cool in its simplicity, but it's so
>> much outdated...) or toolkit
>
> Tile is there, again a marketing problem. Tk is still fine.
Again not in the currently available basic version of 8.4, which is the
current version of Tcl.
>> and concentrate on the real problems. I do not agree, that performance is
>> such a problem as it is stated often when Tcl is compared to other
>> languages.
>
> Has improved continuously and will have a quantum jump in 8.5.
I know, and I'm amazed when I compare it to some execution times I had, when
I was starting with Tcl.
>> But more and better support for programming environments and
>> debugging are needed desperately.
>
> Work in progress (Check out my website). Just a question of time,
> currently delayed...
Which website? Sorry, don't know that.
> There is a binding to libgd, google for "tcl gd". Also, there is the
> Img extension (part of ActiveTcl)
Again, ActiveTcl is not Tcl, it is just one distribution of it, and you can
not be sure to have it. The Tcl core and a standard library is what counts.
>> But I really think, that there is much too less effort in bringing Tcl to
>> the people
>
> That is true. People always complain about it... I am a little sad of
> complainings, really. We need more people being active (still
> complaining is important...)
Well, I'm really bad in public relations, but I doing my best with my
colleagues... But seriously: We must distinguish between a programmer and
user of a language who sees (or thinks he sees) a decline and bad marketing
and the people who can and should do something about it. I'm using Tcl and
I love it, but I'm not Tcl's marketing guy. As I said in another posting,
we need a Mr(s) Tcl. But thats not me.
Regards
Stephan
Stephan Kuhagen
>> > multithreading (for me) is even more
>> > important,
>>
>> Dito, mt is there since 8.4 at least.
>
> From everything I've ever read Tcl is ahead of Ruby, Perl, & Python, etc.
> in this area. Still.
Well, I'm doing Multithreading with Python on the Scripting level and it is
quite good and effective. Knowing event based programming, you may say, mt
is not really needed. But it is. More and more people start thinking in
threads for solving computational problems and with multicore architectures
it will get mainstream pretty fast. It is a must have for the future - and
I mean at scripting level.
Regards
Stephan
David N. Welton
Very nice post, I think you 'hit the nail on the head' with your
observations in a lot of ways.
> Gerald W. Lester wrote:
>
>>> multithreading (for me) is even more important
>> That has been there for a long time.
>
> Sorry, that was not precise enough. I meant was multithreading on the
> scripting level. I know, we all do and love the event based programming in
> Tcl, and it solves the problem most of the time. But sometimes you really
> want a real thread or a bunch of them, that does things in parallel without
> managing the events that schedules you different threads yourself. Script
> level multithreading is hard to implement in Tcl, I think, but I think, it
> would make the language very attractive and more powerful is many ways.
Once again, here we have a brilliant example of Tcl being technically
great, and falling flat on its face in the 'marketing' department.
Tcl *has* a nice, easy to use, and well thought out 'Thread' extension.
Another one of those things that probably ought to be shipped with a
binaries included standard Tcl distribution so that more people would
see it and use it.
> I think, what is needed is not the introspection of the Tcl community which
> I observe here as long as I read this group and other places about Tcl.
> What is needed is to learn from the success of the other languages.
Yes!
> it. So, why did Python come into existence? Tcl was there for many year
> before Python and people here always state, that Tcl is the better
> language, but there have to be many drawbacks in Tcl, that lead other
> people to search for alternatives and do the really big step to develop
> another language, instead of extending Tcl. Guido van Rossum knew Tcl
> before starting Python. Why was it necessary to start Python, Ruby or
> others? And then what were the reasons for their success in many fields,
> what are the advantages over Tcl?
Well to be honest people will always want to do their own thing. It's a
good thing that those guys wrote their languages. What's a little more
dubious from 'our' point of view is why people are flocking to them and
abandoning Tcl.
Stephan Kuhagen
>> The usual way for the average Tcl newbie is to install ActiveTcl, and
>> this comes with everything included. I don't see an action item here.
>
> Whoops! I can't leave that one alone.
>
> ActiveTcl, for all its virtues, is a single-platform proprietary item.
I think you have been beaten enough for this, but I agree. The problem is,
that ActiveStates Tcl is not Tcl, it is just one distribution. And one
should not confuse one distribution with the thing itself. It has to be the
core Tcl and its standard library that has to fulfill all the things a
modern language can be expected to have. As I wrote before: compare what
you get, when you download Tcls tarball and install it with Pythons tarball
and installing it. This is, what counts, because this is, what the language
defines.
I think, there may be many extensions on C level and scripting level that
may be worth a look for future releases (not 8.5, please!!!) to go into the
Tcl core tarball and as a start of a standard library (tcllib as a starting
point).
Regards
Stephan
Stephan Kuhagen
> To me, Tcl is a bit like the Apple Macintosh of programming languages.
Did you notice, that Apple switched to intel some time ago, because Motorola
and IBM with PPC and 68k before did not evolve fast enough for Apple...?
Regards
Stephan
Eckhard Lehmann
Stephan Kuhagen wrote:
> Well, I'm doing Multithreading with Python on the Scripting level and it is
> quite good and effective. Knowing event based programming, you may say, mt
> is not really needed. But it is. More and more people start thinking in
> threads for solving computational problems and with multicore architectures
> it will get mainstream pretty fast. It is a must have for the future - and
> I mean at scripting level.
It *is* there at scripting level. Check out the Threads extension
(tcl.sf.net) and my patch to Itcl to have it for classes & objects.
Eckhard
David N. Welton
>>> convince, that Tcl is worth a look... Where is the image manipulation
>>> framework for Tcl? TclMagick was a good start, but...
>> Ok, this one involves me. But what?
>
> Oops... ;-) If I look on the website (sourceforge), I find no last update
> line, but only the date 2004. That make me think, that there is not much
> development in the last two years. To get it, you either have to check it
> out from the repository and compile it (which is no choice for many people)
> or go to the download section and find one binary version for Windows and
> some older binaries for Linux, but no installers and no recent versions.
> This simply leaves the impression, that it is not a really living and
> maintained project.
Let's put it this way, like many things, it's alive, it works, but it's
dormant.
> Another thing, but that is a design decision, is that the API of TclMagick
> reflects the API of ImageMagick very closely. This makes it very powerful
> on the one hand, but OTOH very complex. I miss a simple interface, some
> kind of scripting equivalent of a very simple drawing program.
Rolf's the guy who actually did the lion's share of the work and wrote
all that code, so it was his decision. I think it's the right one,
though, because it was already a huge task to get all that API
translated into Tcl via C. If people want something on top of it, the
effort will have to come from someone else, unfortunately. I think it
would be sensible and not too hard, though.
> But what is the biggest problem is something, that has not to do with
> TclMagick. As I said, TclMagick was a good start, but it is not part of Tcl
> as Tk is. If you install simply Tcl, you do not have anything to do simple
> image manipulation.
To be honest, I don't think TclMagick is the best candidate for a
batteries included distribution, as it's not really that small once you
include IM or GraphicsMagick along with it (probably around 4 megs total).
David N. Welton
IMO the *future* from this point of view is Erlang:-) Its concurrent
programming model is much nicer than nasty threads. The language itself
... isn't particularly the greatest thing out there, but a lot of their
ideas are very nice.
Stephan Kuhagen
>> architectures it will get mainstream pretty fast. It is a must have for
>> the future - and I mean at scripting level.
>
> It *is* there at scripting level. Check out the Threads extension
> (tcl.sf.net) and my patch to Itcl to have it for classes & objects.
Yes, and I really appreciate, that there is such an extension - I will have
a closer look at it. But it is an extension, not the core language, as it
should be. When I write cross platform scripts for hosts where I can not
simply compile and install some extensions but have to stay with standard
Tcl, this is no choice. I do not know, if your extension fits the quality
requirements of the TCT, but if it does, it should get into Tcl core in a
not so far release after 8.5.
Everything I always say about missing features is meant to be missing in the
core language and standard library. This is all what counts for me and
other people. OTOH there must be some care, not to bloat the language and
make it too fat to work with it. But for many missing features in Tcl this
is not a problem (at least for the other languages - and don't come and
make a memory footprint comparison between Tcl and Python, even a small
coffee machine has enough RAM for running it...)
Regards
Stephan
Stephan Kuhagen
>> recent versions. This simply leaves the impression, that it is not a
>> really living and maintained project.
>
> Let's put it this way, like many things, it's alive, it works, but it's
> dormant.
I did not mean to say, that it is dead. As I stated before, I think, it is a
good starting point. To be honest, I was amazed when I found it.
> To be honest, I don't think TclMagick is the best candidate for a
> batteries included distribution, as it's not really that small once you
> include IM or GraphicsMagick along with it (probably around 4 megs total).
I agree. For what I mean what should be part of Tcl is a very small basic
image manipulation and drawing part in the core. This can then easily
extended at scripting level in the standard library.
But nevertheless, TclMagick is a cool extension. So do not think, that I do
not like it!
Regards
Stephan
Jeff Hobbs
While I agree that the Thread module should be standard with any
threaded Tcl build, you are massively overestimating Python's threading
capability compared to Tcl. Tcl uses native threads and relative
fine-grained locks. Python has a fat global lock that kills any true
scalability you might otherwise achieve. Read the first line at:
http://docs.python.org/api/threads.html
Tcl is not encumbered in this way, which is why projects like AOLServer
(formerly and newly reemerging as NaviServer) have succeeded with Tcl as
the driving dynamic language.
Eckhard Lehmann
Stephan Kuhagen wrote:
> > The usual way for the average Tcl newbie is to install ActiveTcl, and
> > this comes with everything included. I don't see an action item here.
>
> This depends on the platform. On Linux/Unix this is not the default. The
> distribution has Tcl already in it, and it is not ActiveState normally. For
> Windows there is no alternative, I agree. But since Tcl is meant to be
> platform independent, it must include a good base of functionality and a
> good standard library in the core distribution (and that is, what you get
> when taking the tarball and compile Tcl - compare what you get there, with
> what you get in Python!) because when you really write cross platform
> scripts and apps, you are often near the lowest common denominator of
> features and extras available.
The more functionality you pack in the core, the worse. We see it with
Linux distros which try to bring you everything: the quality is worse
than windows because they can not manage the dependency trees and
configuration correctly. Even debian with its most powerful package
management struggles with that issue and the result is that stable
releases are delayed. Woody was the actual release for - uhm - how
many years?
Actually, doing it the windows way is much better in my opinion - why
should an operating system contain every bit and byte of the latest
software? People should know what they want to do with their computer
and be able to install things by themselves and using the mechanisms
their OS provides. Period.
And this involves that, if they want to develop in whatever programming
language they want, they have to look it up and install it. It's
business as usual with Java and others for all the time now. And for
Tcl, ActiveTcl is *the* batteries included distro. If you want to have
everything to get started, go to activestate.com, download it and
finished.
>
> I know, I read that thread. I would really appreciate such thing. I'm a
> little afraid that a virtual server and the constraints you give are too
> tight for the job, but maybe it would be a good stating point.
There is also PHP running - and sadly I have to run MySQL as well for
wordpress... But as soon as I have an alternative, I will remove that
one.
It's just that if we talk about a Tcl repository, it should be done in
Tcl as well. As for the virtual server, I am surprised how well it does
- and if the load gets to high, it can be upgraded at any time.
> > It would be good to have more books (for newbies) but someone
> > has to write and publish them.
>
> For newbies? I do that... ;-) Tcl is so simple to learn... Who publishes it?
> I'm afraid, you only get raised eyebrows when going to a publisher with
> such a book.
Yes for newbies. To be honest, I don't by any computer books for any
language I use any more. Most of them are crap and copied tutorials
from the net. Why spend money and space in my book shelf for something
that you can get for free when you need it?
There are other channels to learn a programming language which I use
primarily. This situation has changed... when I was a newbie I bought
computer books en mass as well.
> > language and it just brings up lots of errors: "Hey, there are no
> > memory leaks in this language... so there is no need for bugfixing,
> > just throw the error - fine!".
>
> That's right. But because they develop faster, they get over it faster. It
Really?
> is an illusion to get it perfect with the first try, so evolution is
> necessary.
[...]
> > I wouldn't release anything to the public when it is not finished, at
> > least to an extend where others will find it useful as well.
[...]
> "Releasy early, release often!" - Not every release should be marked as
It's the right balance that matters. Imagine, IBM had released Eclipse
before you were even able to edit Java files with it... You for sure
had switched to Netbeans and never looked at Eclipse again, because
once you are used to Netbeans, the switch is hard. Many other examples
here.
> >> OO should be part of the language,
> >
> > Tcl 8.5. Many OO extensions available out of the box. It's just a
> > marketing problem again.
>
> No, its a problem that 8.5 isn't there!
No, a marketing problem. Because you *can* use OO with any of the
extensions right now. You just have to be aware of them being there.
> > Tile is there, again a marketing problem. Tk is still fine.
>
> Again not in the currently available basic version of 8.4, which is the
> current version of Tcl.
But in ActiveTcl, which you will install anyway if you plan to start
with Tcl ;-).
> >> But more and better support for programming environments and
> >> debugging are needed desperately.
> >
> > Work in progress (Check out my website). Just a question of time,
> > currently delayed...
>
> Which website? Sorry, don't know that.
Google for my name or: http://e-lehmann.de. It's rather inofficial at
the moment. I just need some time to get important things done before I
make it public.
> > There is a binding to libgd, google for "tcl gd". Also, there is the
> > Img extension (part of ActiveTcl)
>
> Again, ActiveTcl is not Tcl, it is just one distribution of it, and you can
> not be sure to have it. The Tcl core and a standard library is what counts.
Again, ActiveTcl is the most useful and complete distribution of Tcl.
It is also the distribution that you can get most easily and it gives
you a quick start.
What are you doing if you want to develop Java? Do you complain that
the standard JDK does not have image manipulation, native platform look
& feel GUI toolkit, ant, etc..? Or do you simply go to www.eclipse.org,
download the SDK and start to use it? The discussion about this is not
worth the trouble, really.
> I love it, but I'm not Tcl's marketing guy. As I said in another posting,
> we need a Mr(s) Tcl. But thats not me.
I think that the TCT should do the marketing, because they can
represent Tcl. If no member of the TCT is good in those kind of things,
maybe they should elect a non-hackish member to do these kind of things
Eckhard
David N. Welton
> The more functionality you pack in the core, the worse. We see it with
> Linux distros which try to bring you everything: the quality is worse
> than windows because they can not manage the dependency trees and
> configuration correctly. Even debian with its most powerful package
> management struggles with that issue and the result is that stable
> releases are delayed. Woody was the actual release for - uhm - how
> many years?
I disagree:
*) Python and Ruby have been successful with fairly big standard
distributions.
*) Linux has been successful too. Debian has problems that go beyond
just including a lot of stuff - Ubuntu has been quite successful for
instance.
*) Windows higher quality than Linux?
*) ... no, seriously?
*) Ok, you had me going there for a second.
> Actually, doing it the windows way is much better in my opinion - why
> should an operating system contain every bit and byte of the latest
> software? People should know what they want to do with their computer
> and be able to install things by themselves and using the mechanisms
> their OS provides. Period.
A middle ground is a sensible way of doing things. Debian does not
install *everything*, but gives you fantastic tools to help you install,
maintain and remove many software packages.
>>>> OO should be part of the language,
>>> Tcl 8.5. Many OO extensions available out of the box. It's just a
>>> marketing problem again.
>> No, its a problem that 8.5 isn't there!
>
> No, a marketing problem. Because you *can* use OO with any of the
> extensions right now. You just have to be aware of them being there.
This has been discussed before, and I've explained why a number of OO
extensions is worse than one good, standard one. For a book about this
sort of phenomenon, see "The Paradox of Choice".
>>> There is a binding to libgd, google for "tcl gd". Also, there is the
>>> Img extension (part of ActiveTcl)
>> Again, ActiveTcl is not Tcl, it is just one distribution of it, and you can
>> not be sure to have it. The Tcl core and a standard library is what counts.
>
> Again, ActiveTcl is the most useful and complete distribution of Tcl.
And it's only available if you download it. So what most Linux people
see is just the bare bones, which is obviously far less useful than what
they get with Python on their system.
>> I love it, but I'm not Tcl's marketing guy. As I said in another posting,
>> we need a Mr(s) Tcl. But thats not me.
>
> I think that the TCT should do the marketing, because they can
> represent Tcl. If no member of the TCT is good in those kind of things,
> maybe they should elect a non-hackish member to do these kind of things
I don't know if that would really work. If you were organizing a tech
conference, would you want a 'marketing guy'? The really successful
people are guys like Linus Torvalds who are 100% technical, but also
have some skills in terms of being fun to listen to.
Gerald W. Lester
And Tcl switch to byte code from pure interpretive...
Eckhard Lehmann
Stephan Kuhagen wrote:
> Eckhard Lehmann wrote:
> Tcl, this is no choice. I do not know, if your extension fits the quality
> requirements of the TCT, but if it does, it should get into Tcl core in a
> not so far release after 8.5.
I doubt that my Itcl patch will go in the core, as long as Itcl itself
won't go in the core ;-). And this is definitely not going to happen,
the core's object system will be a different one, according to TIP
#217.
The Threads extension is not from me.
> is not a problem (at least for the other languages - and don't come and
> make a memory footprint comparison between Tcl and Python, even a small
> coffee machine has enough RAM for running it...)
No I won't make memory footprints. But another one: Tcl's focus has
always been to be an integration language, meant to be included in
other programs as an extension script language. For that it is good to
be a small language package without much overhead, yet to be extensible
with whatever functionality you want. For threads this means that you
may want to run a Tcl interpreter inside your target application in
just one thread - and then you don't need script access to threads -
you even might not want to have it at all. That's the reason for the
Threads extension to be an extension.
But still it should be part of a standard library (which in turn should
be an extension, IMO).
Eckhard
Michael Schlenker
the threading capabilities of some popular languages.
Michael
Gerald W. Lester
> Gerald W. Lester wrote:
>
>>> multithreading (for me) is even more important
>> That has been there for a long time.
>
> Sorry, that was not precise enough. I meant was multithreading on the
> scripting level. I know, we all do and love the event based programming in
> Tcl, and it solves the problem most of the time. But sometimes you really
> want a real thread or a bunch of them, that does things in parallel without
> managing the events that schedules you different threads yourself. Script
> level multithreading is hard to implement in Tcl, I think, but I think, it
> would make the language very attractive and more powerful is many ways.
I knew what you meant, we've had threading at the script level almost since
the core has been thread safe -- you really need to know what is available
before going off.
>
>> > a modern GUI binding (Tk is cool in its simplicity, but it's so
>>> much outdated...) or toolkit
>> Have you looked at Tile, which is also part of 8.5
>
> No yet. And the reason is, that it simply does not exist in the real world.
> 8.5 is, until now, vaporware and so I do not spend any time learning all
> the fine things, it offers. 8.4 is what you get (at best), when you need a
> Tcl, that runs everywhere. And compared with other scripting languages and
> other toolkits 8.4 is simply outdated for some years now. And that is a
> pity, because the concept and integration of Tk in Tcl is really good.
Funny, I can do a package require tile just fine in 8.4. Again, an example
of going off without knowing what is available.
You obviously do not get sarcasm ... all those other languages have stuff
you outside of their "core" that you need to pull in/down for any real
programming.
>
>> > or KDevelop (the IDE I like best).
>>
>> Write it.
>
> This is the kind of answer that has been perfectly described in Mark
> Rosemans posting (LOL again!): "Yes, I can write that in no time". But the
> problem is, that it is not there already. Maybe I could write that (but I
> won't, because Emacs does it for me and it is more easy to switch from
> KDevelop to emacs when programming as to extend KDevelop), but the question
> for me really is, why is Tcl not attractive enough for the KDE people, to
> have it already integrated into KDevelop? Look, they have Ada and Haskell
> integrated (and a bunch of scripting languages), but no Tcl!
Again, you do not get sarcasm -- which is what Mark's post was!
>>> For example in the Python (again...)
>>> newsgroup there are many postings starting with "I'm a newbie, please
>>> help..."
>> I saw at least six (or maybe more) of those here on c.l.t last week --
>> plus a lot more on the TkChat channel(s).
>
> Yes, six... Ever read comp.lang.python for some days? It can be a fulltime
> job...
>
>>> ... And everybody who sees
>>> those cool extensions or apps will ask: wow, what's it made with? And the
>>> answer then is not Tcl, which again is one step toward oblivion.
>> Most people can care less what an application is written in, as long as it
>> does what they want in a way that they want it to do it.
>
> I do not agree. Yes, the user does not care. But other developers do,
> because they always search for good tools, and managers do because they
> want to say "hey look, we have done this neat app, and it is written in the
> same language as the famous app XYZ from the big Company Z - so it must be
> cool and powerful" From an engineers point of view, you may dislike such
> arguments, but in the real world they count.
Actually managers pay more attention to buzz words they read in the trade
rags than what things are developed in.
> When one goal is to get new people to Tcl, there has to be some killer apps
> written in it. But there are none currently. AOLServer and all the stuff
> mentioned do not count, because if you try to advertise with an unknown
> product (compared to other products in that category) from a dead company
> (not dead yet, okay, but look at their decline in the last time...), this
> seems not to be a very good argument for Tcl.
Ok, products done using Tcl (again a little research would show this):
NBC's North American Broadcast
Hubble Space Telescope Control
Space Shuttle Control
European Southern Observatory Control
Nasa's Deep Impact
Parts of Nasa's Mars Lander
Cisco Routers control interface
Oracle Test Framework
InstallJammer
BitMover
Again, people don't care what something is written in because they can't see
it -- they only see the results.
Most things are done in Cobol/Java/C/C++/Ruby to a large extent because
either they are contractually dictated or someone (a professor or a manager)
has read this is **the language** to use.
Eckhard Lehmann
David N. Welton wrote:
> *) Linux has been successful too. Debian has problems that go beyond
> just including a lot of stuff - Ubuntu has been quite successful for
> instance.
Right, but Ubuntu focusses on a relatively small core, which is
actively supported. Everything in "universe" is up to the user. They do
it right, compared to (original) debian.
> *) Windows higher quality than Linux?
>
> *) ... no, seriously?
Not really*g*. But if Linux distros would focus more on a *core*
operating system and less on any software package that is available out
there, it could do even better. That means, if Linux distros would go
more on the Windows path, they could easier overtake ;-). But that's
not the point here...
> A middle ground is a sensible way of doing things. Debian does not
> install *everything*, but gives you fantastic tools to help you install,
> maintain and remove many software packages.
And all those packages have to be maintained in the debian repository.
That's the problem. If they would be elsewhere and not in debian
itself, this would be better for the debian release cycle.
> > I think that the TCT should do the marketing, because they can
> > represent Tcl. If no member of the TCT is good in those kind of things,
> > maybe they should elect a non-hackish member to do these kind of things
>
> I don't know if that would really work. If you were organizing a tech
> conference, would you want a 'marketing guy'? The really successful
> people are guys like Linus Torvalds who are 100% technical, but also
> have some skills in terms of being fun to listen to.
You're right, absolutely. Also that is what I mean... I think they
would elect a member who is techie to 100%, but also has
marketing/publishing skills.
On the other hand site: Cannonical hired a "community manager" for
Ubuntu not long ago. This could be an option as well... Someone who is
reasonable techie but not so deeply as TCT members and has mainly
marketing/publishing skills in the open source community.
Eckhard
Michael Schlenker
http://article.gmane.org/gmane.comp.web.aolserver/13391
Michael
Stephan Kuhagen
> No I won't make memory footprints. But another one: Tcl's focus has
> always been to be an integration language, meant to be included in
> other programs as an extension script language. For that it is good to
> be a small language package without much overhead, yet to be extensible
> with whatever functionality you want.
Right. But this is not a discrepancy I think. Linking against a core
library, that only includes the language interpreter to extend your app
should not be a problem.
> For threads this means that you
> may want to run a Tcl interpreter inside your target application in
> just one thread - and then you don't need script access to threads -
> you even might not want to have it at all. That's the reason for the
> Threads extension to be an extension.
> But still it should be part of a standard library (which in turn should
> be an extension, IMO).
I think, the standard library should be part of the languages core
distribution as it is in Python. Again I say, we should learn from the
success of other languages. It is no problem to link the Python interpreter
into your app as an extension language (we do this - I wish it were Tcl,
but it's Python and JavaScript, because they are more shiny. Tcl was used
years ago and dropped because in the point of view of the people in charge
Tcl is a dying language...) and deliver only the parts which are needed for
your app. This doesn't make your app too huge, and as an extension language
bound to a specific app it is normal not to have a full blown programming
environment. But when Python is used as a scripting language standalone, it
has everything needed in the core distribution. The same should be possible
with Tcl, I think.
Regards
Stephan
Stephan Kuhagen
>> architectures it will get mainstream pretty fast. It is a must have for
>> the future - and I mean at scripting level.
>
> While I agree that the Thread module should be standard with any
> threaded Tcl build, you are massively overestimating Python's threading
> capability compared to Tcl.
I don't think so. You are right, that they are not as good as they should be
and for many real things they are nearly unusable. But they are there...
People can start out of the box using them, currently with some (more or
less serious) limitations, but considered the speed with which Python
evolves this is just a matter of (little) time...
Okay, maybe I underestimate Tcls threading the same amount I overestimate
Pythons. But Pythons is integrated and alway available, Tcls is not. For
me, a not so perfect solution works better that a perfect one, that is not
available... I'm afraid, when outsiders have to decide, which language they
should start to learn or which one does a good job for something specific,
this is a reason for many to skip Tcl.
Offtopic: I hope, you all do not think, all I want to and can do is to make
Tcl look bad compared to Python or others. The opposite is the case!
Regards
Stephan
Michael Schlenker
> Jeff Hobbs wrote:
>
>>> architectures it will get mainstream pretty fast. It is a must have for
>>> the future - and I mean at scripting level.
>> While I agree that the Thread module should be standard with any
>> threaded Tcl build, you are massively overestimating Python's threading
>> capability compared to Tcl.
>
> I don't think so. You are right, that they are not as good as they should be
> and for many real things they are nearly unusable. But they are there...
> People can start out of the box using them, currently with some (more or
> less serious) limitations, but considered the speed with which Python
> evolves this is just a matter of (little) time...
>
> Okay, maybe I underestimate Tcls threading the same amount I overestimate
> Pythons. But Pythons is integrated and alway available, Tcls is not. For
> me, a not so perfect solution works better that a perfect one, that is not
> available... I'm afraid, when outsiders have to decide, which language they
> should start to learn or which one does a good job for something specific,
> this is a reason for many to skip Tcl.
There are two points in enabling threads:
1. You gain the possibility to write concurrent code based on the Thread
paradigma
2. You gain an nearly infinite amount of ways to shoot yourself in the
foot and deadlock or crash your code, especially when using external
libs that are not thread safe.
There are lots of nice blog posts and articles out there why threading
is a dangerous beast, just watch reddit for a week or two. Nontheless
lots of people want threads..., but few know what their really asking
for. So its 'checklist' or buzzword compliance your after in this case.
With the new multi-core cpus getting more common i see the market and
usecase for threads, so going in the direction of a thread enabled
default including the thread extension is a good thing. (and is done by
debian for the Tcl 8.4 version for quite a while now).
Michael
Stephan Kuhagen
>> yourself. Script level multithreading is hard to implement in Tcl, I
>> think, but I think, it would make the language very attractive and more
>> powerful is many ways.
>
> I knew what you meant, we've had threading at the script level almost
> since the core has been thread safe -- you really need to know what is
> available before going off.
But it's not activated in the default core package that is available
everywhere... I know it's there. As well as I know that about Tile which
can be used in 8.4, but again, not there in pure 8.4 core package.
ActiveStates version is advertised as the batteries included package which
comes with all what you need. But my point is, that Tcl itself should be a
batteries included scripting language the way Python is. I really think,
Tcl could learn from that.
> You obviously do not get sarcasm ... all those other languages have stuff
> you outside of their "core" that you need to pull in/down for any real
> programming.
For Python, which was in the list, this is not the case. Not everything is
in the C interpreter but in the standard library, that is integral part of
the language. For the other languages I can't say, so I may have missed the
point... But AFAIK some of the others are compiled languages or at least
live in a totally different scope as common scripting languages do.
>> people, to have it already integrated into KDevelop? Look, they have Ada
>> and Haskell integrated (and a bunch of scripting languages), but no Tcl!
>
> Again, you do not get sarcasm -- which is what Mark's post was!
Maybe, sorry then. I'm not a native speaker, so I may miss some humor. But
isn't it irony instead of sarcasm, what you mean? Anyway: the reply was
serious. You often get the answer: just do it yourself. But this is not an
adequate answer if you try to make something a success.
>> must be cool and powerful" From an engineers point of view, you may
>> dislike such arguments, but in the real world they count.
>
> Actually managers pay more attention to buzz words they read in the trade
> rags than what things are developed in.
Sadly... But I was speaking of Managers who also have fundamental
programming background, as those we have here. They are all able to program
very well but they also decide which way to go.
And for the other managers: Maybe Tcl needs more Buzzwords known to the
masses. Buzzwords alone do not make a product a success and the people who
really work with it, prefer functionality over shiny advertising. But
before they can prefer and appreciate the functionality, you have to bring
it into their minds...
> Ok, products done using Tcl (again a little research would show this):
>
> NBC's North American Broadcast
> Hubble Space Telescope Control
> Space Shuttle Control
> European Southern Observatory Control
> Nasa's Deep Impact
> Parts of Nasa's Mars Lander
> Cisco Routers control interface
> Oracle Test Framework
> InstallJammer
> BitMover
Agreed and I know it. You don't have to convince _me_ of Tcl. I use and love
it anyway. And I will also use it, if it evolves as slow in the future as
it does currently because I simply write myself what I'm missing. But with
that, you do not convince beginners.
> Again, people don't care what something is written in because they can't
> see
> it -- they only see the results.
Again also: Users don't care. New programmers (which are needed to keep a
language alive) do.
Tcl: your list and possibly many really cool things more.
Python: Google
Tcl loses, Python wins...
Regards
Stephan
Stephan Kuhagen
>> A middle ground is a sensible way of doing things. Debian does not
>> install *everything*, but gives you fantastic tools to help you install,
>> maintain and remove many software packages.
>
> And all those packages have to be maintained in the debian repository.
> That's the problem. If they would be elsewhere and not in debian
> itself, this would be better for the debian release cycle.
It is not easy to find the right balance... But currently the real core is
far away from having this balance. I agree, that not every possible
extension should be part of the core. But only having the minimum included
with which some of us can live, is not enough either.
> On the other hand site: Cannonical hired a "community manager" for
> Ubuntu not long ago. This could be an option as well... Someone who is
> reasonable techie but not so deeply as TCT members and has mainly
> marketing/publishing skills in the open source community.
Google has hired Vint Cerf as "Chief Internet Evangelist". _That_ was a cool
move... ;-)
Regards
Stephan
Michael Schlenker
Michael
Michael Schlenker
> Again also: Users don't care. New programmers (which are needed to keep a
> language alive) do.
>
> Tcl: your list and possibly many really cool things more.
> Python: Google
>
> Tcl loses, Python wins...
>
Basically your telling us: oh, Tcl has already lost, because its not
used by Google (repeat the argument with Microsoft and C# or Sun and Java).
If your really believing this, nothing but a full scale multi-million
dollar marketing campaign can rescue any of the languages not used by
those three. All the others will die real soon now, or be just academic
exercises.
Michael
Stephan Kuhagen
>> Tcl loses, Python wins...
>>
> Basically your telling us: oh, Tcl has already lost, because its not
> used by Google (repeat the argument with Microsoft and C# or Sun and
> Java).
>
> If your really believing this, nothing but a full scale multi-million
> dollar marketing campaign can rescue any of the languages not used by
> those three. All the others will die real soon now, or be just academic
> exercises.
No, I do not believe that and that was not, what I meant. It was meant as a
counter argument against the other list. The problem with NASA software and
such is, that it does not usually run on a newbies home PC, so it may have
not such an impact on making him enthusiastic about a language as Google
does. Nevertheless, the list Tcl can bring is impressive to me... But I'm
conviced of Tcl already. The question should always be, how to bring new
people to Tcl.
Regards
Stephan
Kaitzschu
>>> For example in the Python (again...) newsgroup there are many postings
>>> starting with "I'm a newbie, please help..."
>>
>> I saw at least six (or maybe more) of those here on c.l.t last week --
>> plus a lot more on the TkChat channel(s).
>
> Yes, six... Ever read comp.lang.python for some days? It can be a
> fulltime job...
Maybe c.l.python just has more reputation as a place to get your homework
assignment done for you? :)
It is true that Python beats Tcl fairly when you look at numbers of places
where those languages are being taught. For example I should do 3D in
Python, listen about Perl in lectures, and get blank stares when I tell
people "Tcl can do that."
--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done
Uwe Klein
> 2. You gain an nearly infinite amount of ways to shoot yourself in the
> foot and deadlock or crash your code, especially when using external
> libs that are not thread safe.
This is required. Who wants a docile beast for the presentation before
the races?
You wrestling with the code to make it behave is what gains apreciation
from your boss.
uwe
Stephan Kuhagen
>> Google has hired Vint Cerf as "Chief Internet Evangelist". _That_ was a
>> cool move... ;-)
>>
> You can do flashy moves, when you get some millions to burn for hot smoke.
Of course. I did not wanted to suggest that TCT should hire Gandhi to make
people think different about Tcl. But Vint Cerf is not only hot smoke for
Google, he is also an external sign for some internal decisions and
philosophies behind Google (even if not all of them are really trustworthy)
that make people having faith in Google. Tcl can not and should not try to
play at the same level. But there is no doubt, that Tcl needs some smoke
signs to get remembered and considered by people.
Regards
Stephan
Michael Schlenker
Googles software doesn't work that well on the newbies home PC too,
unless you got 10.000 of them...
Depending on what kind of newbies your talking about, you have different
vectors of infection. Few are interested in technical brilliance, some
want to scratch an itch, some have a program on windows and look for
something similar on Linux or Mac OS X, some are just following
buzzwords, some are self styled cool hackers that can't read a manual
and hack at things like bit torrent or IRC bots, and so on...
Not all are probably worth the trouble.
So how about this (short list):
aMSN, Eggdrop, PortAuthority, InstallJammer, aol.com, greenpeace.org,
OpenACS...
Michael
Stephan Kuhagen
> Maybe c.l.python just has more reputation as a place to get your homework
> assignment done for you? :)
No doubt, the quality in c.l.tcl is much higher. But c.l.python is more
alive... Having a place, where you get your homework done also means, that
there _are_ homework to be done in Python and that young programmers and
beginners do learn Python instead of Tcl. They grow up and always remember
Python as the one cool and real language of their good days and so they
keep it alive. Young people that start at a lower quality and then get
better are the future of every project. So it is necessary to get them and
not say, that we do not need them.
> It is true that Python beats Tcl fairly when you look at numbers of places
> where those languages are being taught. For example I should do 3D in
> Python, listen about Perl in lectures, and get blank stares when I tell
> people "Tcl can do that."
Right, same to me. I only know some old veterans that really know Tcl
besides me here. Okay, they all have heard about Tcl (because I talk all
the day about it... ;-), but because I seem to be the only one who talks to
them about Tcl in the world, they probably just think, I'm a little bit
mad.
Regards
Stephan
Uwe Klein
<from http://article.gmane.org/gmane.comp.web.aolserver/13391, mentioned here elsewhere>
The irony here is so few people have even heard of Tcl that if it was
evangelized and marketed correctly, it could be brought to the
marketplace as a "new" language to replace Ruby and Python and PHP.
Write a slew of books, release a mound of free Tcl code and add simple
enhancements to Tcl like closures/lambdas and other language features
that'll make the language geeks go "ooh!" and the unwashed masses will
download all the free code they need ...
... and then the cycle starts all over again.
<end>
Now who would meet your fancy as PosterDad for Tcl?
uwe
Kevin Walzer
>
>
> Let's not misunderstand the changes in the EULA for ActiveTcl. They
> allow limited redistribution within other single-file wrapping
> applications (specifically to date, starkits, freewrap and tobe).
Will this also apply to an standalone "embedded" build of Wish.app on
Mac OS X, i.e. where the Tcl/Tk frameworks are included in the
application bundle? One can just as easily use a starpack on the Mac and
stick the executable inside the app bundle, but using the standalone app
bundle without the starkit structure has some advantages for deployment.
Just curious.
--
Kevin Walzer
Poetic Code
http://www.kevin-walzer.com
Eckhard Lehmann
Uwe Klein wrote:
> <from http://article.gmane.org/gmane.comp.web.aolserver/13391, mentioned here elsewhere>
> The irony here is so few people have even heard of Tcl that if it was
> evangelized and marketed correctly, it could be brought to the
> marketplace as a "new" language to replace Ruby and Python and PHP.
Nice idea.. thats it! :-))
Eckhard
Robert Hicks
Stephan Kuhagen wrote:
> Gerald W. Lester wrote:
>
> > > a modern GUI binding (Tk is cool in its simplicity, but it's so
> >> much outdated...) or toolkit
> >
> > Have you looked at Tile, which is also part of 8.5
>
> No yet. And the reason is, that it simply does not exist in the real world.
> 8.5 is, until now, vaporware and so I do not spend any time learning all
> the fine things, it offers. 8.4 is what you get (at best), when you need a
> Tcl, that runs everywhere. And compared with other scripting languages and
> other toolkits 8.4 is simply outdated for some years now. And that is a
> pity, because the concept and integration of Tk in Tcl is really good.
>
I use it with 8.4 myself. It ships with ActiveTcl 8.4.13.
Robert
Neil Madden
> si...@whiteowl.co.uk wrote:
>> I wasn't aware that TIPs got approved if they didn't have some sort of
>> reference implementation.
>
> We don't usually do it. We've learned to not do that.
TIP 2 could probably do with a bit of an update. It still contains
phrases like "The TIP should be reviewed and accepted before a reference
implementation is begun..."
-- Neil
Neil Madden
[...]
> With the new multi-core cpus getting more common i see the market and
> usecase for threads, so going in the direction of a thread enabled
> default including the thread extension is a good thing. (and is done by
> debian for the Tcl 8.4 version for quite a while now).
Well, we already have [exec] which is quite capable of utilising as many
cpus/cores as you require...
There are other options that could also be explored before unleashing
explicit threading in the default Tcl configuration. For instance, could
we make a super-clever event loop that uses multiple threads
behind-the-scenes for executing callbacks? (Like a much better version
of Java's executor framework). Can we design a message-passing component
abstraction that can transparently scale from single-threaded
event-based, up through shared-state multi-threaded, all the way to
distributed processes communicating over sockets? David already
mentioned Erlang, which is well worth plundering for ideas (a
thread-safe metakit/starkit/sqlite equivalent of mnesia mightn't be a
bad idea either). I'd much rather that kind of solution than just making
threads available by default in Tcl. Tcl's threading model is pretty
good, but it's still fairly low level. Ideally, I'd like to never have
to see the word "thread" or "lock" (or "mutex"!) anywhere in a Tcl script.
-- Neil
Larry W. Virden
Gerald W. Lester wrote:
>
> >>> ... And everybody who sees
> >>> those cool extensions or apps will ask: wow, what's it made with? And the
> >>> answer then is not Tcl, which again is one step toward oblivion.
> >> Most people can care less what an application is written in, as long as it
> >> does what they want in a way that they want it to do it.
> >
> > I do not agree. Yes, the user does not care. But other developers do,
> > When one goal is to get new people to Tcl, there has to be some killer apps
> > written in it. But there are none currently.
> Ok, products done using Tcl (again a little research would show this):
>
> NBC's North American Broadcast
> Hubble Space Telescope Control
> Space Shuttle Control
> European Southern Observatory Control
> Nasa's Deep Impact
> Parts of Nasa's Mars Lander
> Cisco Routers control interface
> Oracle Test Framework
> InstallJammer
> BitMover
>
> Again, people don't care what something is written in because they can't see
> it -- they only see the results.
At least a couple posters have made a brief reference to killer apps
and developers.
I know what I had in mind is this - when I'm familar with an extremely
useful application
I sometimes think "man, if I could build a ABC widget like
such-and-such uses,
that would be so neat right here in this program", or, for me more
commonly, I'll say "if I could only hook into such and such
application, and get at the data, or add my own little tweak". Some
apps make that possible. Others don't. Having some killer apps that
make use of Tcl and make it possible to either see how things are done,
or hook into the process, is what appeals to me as a developer.
Bryan Oakley
> Stephan Kuhagen schrieb:
>> Okay, maybe I underestimate Tcls threading the same amount I overestimate
>> Pythons. But Pythons is integrated and alway available, Tcls is not. For
>> me, a not so perfect solution works better that a perfect one, that is not
>> available... I'm afraid, when outsiders have to decide, which language they
>> should start to learn or which one does a good job for something specific,
>> this is a reason for many to skip Tcl.
>
> There are two points in enabling threads:
> 1. You gain the possibility to write concurrent code based on the Thread
> paradigma
> 2. You gain an nearly infinite amount of ways to shoot yourself in the
> foot and deadlock or crash your code, especially when using external
> libs that are not thread safe.
>
> There are lots of nice blog posts and articles out there why threading
> is a dangerous beast, just watch reddit for a week or two. Nontheless
> lots of people want threads..., but few know what their really asking
> for. So its 'checklist' or buzzword compliance your after in this case.
I suspect the point Michael is trying to make is, regardless of the
merits of the various threading implementations, developers _want_ the
ability to easily shoot themselves in the foot and we make that harder
than other languages.
Python hands 'em an ugly, loaded gun in a paper sack. Tcl hides a
beautiful chrome revolver with pearl handles in a hand carved walnut box
you have to first find and load before using.
I can see the point. I think if adding threads out of the box were all
it would take to make Tcl popular I'd vote for it, but it's all so much
more complicated than that. Part of the beauty of Tcl is the rather
generous amount of care and thought that has gone into it over the years.
Frankly, in many respects I think Tcl's lack of market share is a Good
Thing. Not in all respects, but many. If all of a sudden the world was
knocking on our doorstep, I fear the overall quality would go down as
features are tacked on to feed the insatiable demands of buzzword hungry
programmers.
Ralf Fassel
| There are two points in enabling threads:
| 2. You gain an nearly infinite amount of ways to shoot yourself in the
| foot and deadlock or crash your code, especially when using external
| libs that are not thread safe.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
<quote>
My point is that even this very simple and commonly used design
pattern has required some rather intricate thinking about possible
interleavings. I speculate that most multithreaded programs have
such bugs. I speculate further that the bugs have not proved to be
major handicaps only because today’s architectures and operating
systems deliver modest parallelism. The cost of context switching
is high, so only a tiny percentage of the possible interleavings
of thread instructions ever occur in practice. I conjecture that
most multi-threaded general-purpose applications are, in fact, so
full of concurrency bugs that as multi-core architectures become
commonplace, these bugs will begin to show up as system failures.
This scenario is bleak for computer vendors: their next generation of
machines will become widely known as the ones on which many programs
crash. These same computer vendors are advocating more multi-threaded
programming, so that there is concurrency that can exploit the
parallelism they would like to sell us. Intel, for example, has
embarked on an active campaign to get leading computer science
academic programs to put more emphasis on multi-threaded
programming. If they are successful, and the next generation of
programmers makes more intensive use of multithreading, then the next
generation of computers will become nearly unusable.
</quote>
R'
Donal K. Fellows
> TIP 2 could probably do with a bit of an update. It still contains
> phrases like "The TIP should be reviewed and accepted before a reference
> implementation is begun..."
Good catch. Let me know if you think the updated version is still out of
date, please. TIA!
Donal.
Larry W. Virden
Stephan Kuhagen wrote:
> >> a complete and comprehensive standard library
> >> is needed (as integral part of the core language and not as an add on)
This keeps being tossed out, over and over. How about defining
specifically what features you envision in the complete and
comprehensive standard library? Because in my experience, what I want
in such a library and what someone else wants are quite different.
If there is ever to be a hope to move in a positive direction during
these sorts of rambling discussions, people need to start the ball
rolling. And the first step would be to pick a set of features,
explicitly flesh out the details, then convince people to either start
coding, or at least to find something that has already been coded and
someone to work out the details.
> to the others. And one reason is, that it stopped evolving and the bad
> "marketing".
I myself don't see a stop to the evolving. But what I do see is a
different between your expectations and the expectations of those
writing Tcl core code. And the choices for response at this point seem
to be:
1. write code and work on getting it into the core,
2. write specifications and work with someone willing to write code and
work on getting it into the core,
3. continue the regular discussions with people spending quality time
writing responses rather than code,
4. modify personal expectations to be satisfied, or
5. move to another language.
And frankly, I'd love to options 1 and 2 continue.
> What is needed is a definitive Tcl base.
I think what you probably mean here is "What is needed is a more
comprehensive Tcl base". The source code of the Tcl core is the
definitive Tcl base, at any point in time.
But your proposal, to date, is that more functionality should be in the
core. And frankly, I agree. I look at the http://tip.tcl.tk/ and I see
a lot more functionality that has gone into Tcl in the past few years.
I see a lot of attractive new functionality that could appear once
proposers get back to working on it. And I see a process whereby people
who need more functionality can work with interested others to propose
an implementation be added to the core.
The issue, in my opinion, is NOT that Tcl is not evolving. It is. It is
not that Tcl is dead - it's not. The issue with which you are
struggling is that algorithms and language bindings that exist in other
languages "out of the box" are not present in Tcl "out of the box".
>From the early days, languages have come with libraries of
algorithms/solutions to common problems. Some languages download with
more of these than others. For instance, some C compilers come with
libc. I seem to remember, the last time I build gcc, that I needed to
download a separate tar file to get gcc's libc. Java comes with a set
of classes of solved problems. Beyond that, there are a large number of
additional items that can be downloaded. Python, Perl, Ruby - these
all come with a large toolset in the default download, and then their
respective communities have developed additional invaluable libraries.
In the case of Tcl, the initial core is relatively light in terms of
functionality. Some people are okay with that - they prefer to write
everything from scratch - in some cases, every time.
I know that _I_ prefer to have a set of pre-written, pre-debugged
libraries from which to work. So, with Tcl, I end up with a dozen or
two downloads to get what, to me, is a base working environment. Or, if
I am working on personal stuff, I use ActiveTcl, which is a good
starting point.
> And this base must
> have the stuff, that other competing languages have in their base package.
It might be an interesting exercise to take the major languages, list
the functionality present in each one, and see how many of the features
overlap. Because that overlap is surely the subset of functionality to
which you refer. I suspect that Java functionality is not identical to
Perl or Python or Ruby (and all the iterations of the 4 are surely not
equal either).
Shoot - Perl probably has the most functionality out of the box of all
5 languages.
>
> but the question
> for me really is, why is Tcl not attractive enough for the KDE people, to
> have it already integrated into KDevelop? Look, they have Ada and Haskell
> integrated (and a bunch of scripting languages), but no Tcl!
Because most developer communities think of Tk when they think of Tcl.
And a desktop environment community is going to want as much
compatibility with their GUI standard as they can get. Right now, Tk
bridges platforms, bringing to it inconsistencies in look and feel.
>
> >> For example in the Python (again...)
> >> newsgroup there are many postings starting with "I'm a newbie, please
> >> help..."
> >
> > I saw at least six (or maybe more) of those here on c.l.t last week --
> > plus a lot more on the TkChat channel(s).
>
> Yes, six... Ever read comp.lang.python for some days? It can be a fulltime
> job...
What I generally find is that the number of questions a newbie to Tcl
brings to the table are significantly less than other languages. If my
experience is not unique, then the ease of entry to Tcl would be the
explanation of the "missing" overload of repeated questions by
newbies...
> Guido van Rossum knew Tcl
> before starting Python. Why was it necessary to start Python, Ruby or
> others?
Because his requirements were different - he wanted an OO based
programming language. Tcl is never going to be an OO based programming
language. It will likely include an OO module/OO features, but the
essence of Tcl isn't going to be an OO language.
A better question, to be asked in some other group than this one, is
why create Python when other languages did have the OO basics.
Smalltalk's been around for longer than either Tcl or Python. As have
other OO languages.
> And then what were the reasons for their success in many fields,
> what are the advantages over Tcl?
To answer this question, one must define what "success" means. Once
that word is clearly and unambiguously defined, then one can answer it
for various languages, and then draw from that analysis recommendations
to the Tcl community.