Mark Roseman wrote: > 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!"
On Mon, 25 Sep 2006, Bryan Oakley wrote: > Mark Roseman wrote: > > 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. > > ...
Donal K. Fellows wrote: > Peter Dalgaard wrote: >> 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.
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).
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.
> > 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...
David N. Welton wrote: > 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...
>> 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.
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, 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.
Michael A. Cleverly wrote: >> > 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.
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.
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.
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).
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.
Stephan Kuhagen wrote: >>> 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).
Stephan Kuhagen wrote: > Michael A. Cleverly wrote:
>>>> 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.
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.
Eckhard Lehmann wrote: >> 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...)
David N. Welton wrote: >> 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!
Stephan Kuhagen wrote: > Michael A. Cleverly wrote:
>>>> 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.
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:
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.
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 Lehmann wrote: > 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.
>> 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
And Tcl switch to byte code from pure interpretive...
-- +--------------------------------+---------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+
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).
> Stephan Kuhagen wrote: >> Michael A. Cleverly wrote:
>>>>> 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.
> 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:
> 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.
See also this posting on the aolserver mailing list, taking a look at the threading capabilities of some popular languages.
>>> 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.
>>> 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.
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.
> ...
-- +--------------------------------+---------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+
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.
