- Would you say that Tcl/Tk is popular in your country?
- Does Tcl have to be popular? Is it good, bad or we shouldn't really care?
- Why isn't Tcl popular and how could that be changed?
Salvatore Sanfilippo: In Italy TCL popularity seems not so bad. I write for a Linux magazine here (called Linux&C http://www.oltrelinux.com
, no english) and we are planning to do a number of articles about TCL. BTW the fact that TCL is not very popular does not means it's a TCL's problem: the mass likes to code with algol-like not-so-flexible languages like PHP, a big part of programmers just don't understand TCL: because it is much more simple to say it is slow then to make an effort to understand how it works, it is how it goes. With Lisp it is pretty much the same, for the average programmer it is hard to understand Lisp, while to say there are too brackets and that isn't good of real programming tasks is much more simple. Not to mention stack-based languages like FORTH or Joy: this programming languages are IMHO very great, it's fantastic how they are able to build great abstractions using few semantics: if you ask the average programmer, he will tell you that's just crazy to program with an RPN language.RR: I think Tcl/Tk's usefulness and appropriateness depends on what you're trying to do with it. Most of the time, I use it for engineering analysis and test data generation. Mostly that relies on Tcl with Tk thrown in to make it easier to give direction. In that case I don't really care how "modern" the windows look. I have used it in part of a delivered application but in that case it was sort of a dispatcher for submitting a batch job; again, modernity wasn't important. That Tcl isn't as popular as Perl, for example, has more to do with cgi scripts than anything else. If you're going for a wide distribution, maybe Tcl/Tk isn't the "right" language (the right language, however, is always the one you speak!).One thing that would enhance Tcl's utility would be a decent translator into some more standard industrial language (C or Java come to mind). I can think of no faster way to test out an algorithm than in Tcl. Then, I could, presto/changeo, turn it into C and stick it in a project in progress.FW: What about ICE?
See also Tcl advocacy.
Anyone see this URL and have comments about it?http://www.kudla.org/raindog/tcl/
DKF: Someone ought to show starkits to that guy!rjk: I am "that guy." I don't think Starkit was around when I wrote that page a couple years ago.... I never did finish that emulator front end interface, mostly because I don't really use Windows anymore and haven't had as much of a need for crossplatform stuff. My crossplatform goals of late are to get VB forms more or less translatable to Gambas (http://gambas.sf.net/) (sorry, don't know this wiki's markup well enough to link those...) I noticed a number of hits to my tcl page from around here, and so I've browsed through the site a little. I mean no disrespect, but I don't think any of the X-based screenshots on the Good Looking Tk page are especially good-looking, or rather, they would have looked great in 1994 but now it's 2003. Performance-wise, I put a program called "Hack-O-Matic" out there on my site around the time I wrote the above article, only to have it reimplemented by someone else recently in a Windows-based BASIC clone called "RapidQ", ten times faster, seemingly easier to develop, and more stable. Tcl/Tk seems more and more stuck in the past to me, and I feel less positively about it these days than I did when I wrote the above article.KPV: See Hack-O-Matic for a fast version of this utility.rjk: Yep, it seems H-O-M's slowness was due to my own poor practices and not to tcl itself. That takes care of the performance issue, at least. At any rate, the portability thing was (as noted on that page linked above) my only reason for muddling through Tcl/Tk in the first place, and since that's not an issue for me anymore I don't have much motivation to try to like (or improve) the language or toolkit.FW: I think Tcl is inevitably going to be not-highly-popular and thought of as weak, because even more than other unpopular-ish languages like Lisp, it irks people on a syntactic level. People think of "programming" as typed, with a separate syntax and semantics. Even Lisp is closer to this idea than Tcl. Even people who do code in Tcl routinely make mistakes by thinking in that paradigm. A weird analogy is that if programming is like hauling scrap metal and the language is a crane or whatnot, Tcl admits that the crane itself is made of the same materials, which is interpreted as "weakness" when it's really enlightenment. Ah, we'll never be understood. ... In simple terms, all this means is again, people like Algolish languages <g>On another note, Tcl is a terrible first language IMO because it exposes you to the opposite paradigm to "real" languages syntax-wise.RS Sad, but true... if someone starts with Tcl, and really gets the spirit, and then takes up Java, C++ or whatever, lessons learned will be: "you can't do this here... you can't do that there..."AMG: I read "Algolish" as "ghoulish." :^)Well, I think your analogy is correct: in Tcl, precious little is sacred (enshrined in the Dodekalogue), and everything else is implemented either in terms of that or as an extension. (Here I consider the "core" commands to be extensions.) Also note that we seem to be moving towards implementing our core commands in Tcl. Witness [clock] in 8.5.Hmm, what would happen if child [interp]s could be configured to have different language rules? Chaos? Beauty? Both? Or are those all the same thing? :^) This would let us use the Tcl eval engine to process a wider variety of configuration file formats, network protocols, and other things we haven't considered yet. Now try to imagine doing anything of the sort in any other language. That sort of power is frightening.All the warty infelicities in Tcl come from commands not language. For instance, the way we delete procs is utterly bogus. I wonder. Is this fractured namespace problem (is that the problem??) an inescapable consequence of the Tcl language refusing to set laws about storage of objects? Maybe we can make some recommendations and provide standard commands for object management so that every extension doesn't have to make its own create/destroy commands. Or will this hurt Tcl? I don't know.Lars H: Hmm... that idea about different types of interpreters feel familiar. [Searches Wiki.] Oh yes, I wrote something along those lines on Getting rid of the value/command dichotomy for Tcl 9. Maybe you'd like the interp define sketched there too.
"People think of "programming" as typed, with a separate syntax and semantics. Even LISP is closer to this idea than Tcl. Even people who do code in Tcl routinely make mistakes by thinking in that paradigm." Would you please elaborate more on what you mean ... what is exactly THIS IDEA?FW: Well, for example, the fact that unlike other languages data isn't considered abstracted from the language, it's all directly accessible as a string.RS: Yes - sometimes when Tcl'ing (for eight years or so) I have to free my mind from limitations learned 30 years ago...
Typed Tcl
proc int {varName equalSign value} {
if { ![string is integer $value] } {
error "Non-integer value cannot be assigned to type int."
}
eval {
global $varName
set $varName $value
}
}
int a = 5
int b = 7mailto:xtended@ameritech.net
I will repost what I posted at the CIT website just a little while ago. TCL has its strengths and weaknesses. But its strengths far out weigh its weaknesses. As far some of the other scripting languages I feel that TCL/TK has its competitors beat hands down. Please read the followingI have been a programmer for 15 Years now. The languages I use are: C++, C and Java. Out of the scripting languages I have used Perl. I really was not very happy with its mix of grammar, nomenclature and vagueness. Out of curiosity I picked up a book written for TCL/TK. I was amazed how organized TCL's syntax is. I am also taken back on how solid the programming structure is from package to package throughout. And last but not least how easy it is read TCL code. What's even more amazing is that in one week I was able to develop a tool that has upgraded over 2000 devices in about two hours. And what's funny about that is, the enterprise commercial equivalent could not even come close to the features built into the tool I wrote in "TCL/TK". The TCL project started on a Monday morning and was complete in one week. Please understand I am not bashing Perl. Thanks to PERL the competition is tight. But I have to admit I have been able to turn more people on to TCL and get them up and running in less time than in PERL. Others like me in experience and some with much less programming experience. And as far as the graphics is concerned, no one new it was a TCL script. They thought it was bonafide Windows program. Oh well that's it for me, for now.Xtended 31 May 2004, 03:20 GMTFrom: xtended@ameritech.net on June 09 10:03:00 amI would welcome the opportunity, to get involved in writing a series of books that demonstrates the strengths that live with in TCL/TK. The series should start with a gentle approach and end up with a hard core use of TCL/TK, including the use of contributed packages. This would give the public, the chance to see the growth and development that TCL/TK supports. I would also say this would change the outlook perceived at the book stores. In addition I know that just with the individuals that have shown their concerns for the future of TCL/TK have the art and sophistication of creating such a series of books. For example this website alone is a wealth of information that if put in a book perspective could create a series of books that would make script-ers from other languages jealous.I would welcome and love to hear from any and all of the individuals involved with WIKI.TCL.TK. Please forward this posting on to friends/colleagues of interest.
My email address is xtended@ameritech.netThanks and I hope this results in a positive outcomeCL, who has helped with a half-dozen Tcl books, and occasionally feels great enthusiasm for a book from the Wiki, the second book of Expect, a book on testing with Tcl, good style with exceptions, models of deployment, light-weight databasing, and so on, mostly has discouraging things to say about publication. I'll try to make it back later to be more explicit.LV experience to date indicates that the amount of time and effort to write a book on Tcl typically does not recover the costs of creation. This tends to dampen the spirits of most publishers... Perhaps a better approach would be to write the book online, publishing it as a PDF or whatever. I notice several other communities have done something approaching this - bash has a great manual that is published electronically, as does awk, Eckel's Thinking in C++/Java/ , etc. If the electronic version reaches the point of being good enough, then one might approach O'reilly or someone else to discuss the dead tree route for additional coverage.
From xtended@ameritech.netWell if the electronic way is the way to go, then let us make it happen. I do feel that the hardest part would be the chapter assignment, and in addition making sure the text flows evenly from one chapter to the next . Besides the chapter assignment, making sure the overall look and feel is consistent. One of the nicest features of an e-book is its access to the public and the ability to edit it as new enhancements come up.Let me know
xtended@ameritech.net
LV If I might make a suggestion, for the gentle start book, arjen has begun an electronic book of sorts, oriented toward helping someone with no programming experience learn Tcl. Perhaps a joining of forces might be a useful place to contribute?That sounds great. Is this page a good place to keep on meeting? The interesting part about this web page, is that it shows other individuals the enthusiasm that is developing.From xtended@ameritech.net
EKB 24 April 2005One thing I've noticed is that many bookstores shelve Tcl/Tk books under "Unix" rather than "Programming Languages". This might account for some of the poor response to books about Tcl. (For a while I thought none of my local bookstores carried any Tcl books.) It also prevents people from serendipitously finding books on Tcl when looking for books on other programming languages.
SYStems I have to admit, when I was (and still am) in the phase of picking a programming language that puts me on the road to become a programmer, the language comparison chart here [1] really had an impact on me, maybe a new updated chart that can be use in Tcl propaganda will be nice.Also slashdot and few other site, are heavily read, and can be used to learn whats hip and whats not, I believe the announcement of new versions of important packages, or platforms that uses Tcl will help. I know I am kind of eagerly waiting to see how readers will reply to the release of Tcl 8.5 I am sure it will make it to slashdot.I expect the {*} syntax to be butchered, the new dict thingie, will be bashed to, people will say things like perl and python had dictionaries since version -1, and things like thatTile if it is part of 8.5 and is good enough, can get some nice replies.Point is, we need to discuss the good things in Tcl on popular sites like slashdot. And the Tcl core team should take the replies and criticism as seriously as possible. I really think word of mouth in the hacker community is what opened the road for python. Ruby is heading in the same direction, I now even see ruby talked about on the serverside site [2] which is another key site on the net
[Expect the unexpected] I have problems using TCL. I program in many languages, C, C++, Various assemblers, VHDL, Verilog etc. I think a significant part of my problem with TCL has two causes: 1/ I have not been able to find a good TCL book. I think many writers of TCL books start at the deep end. They could learn a LOT from the original K&R C book: Start simple and ALWAYS start telling the user how to get text on his/her terminal. (note: Practical Programming... [3] has the canonical "Hello, World" on page 4, where page 3 is the first page of Chapter 1...)2/ Many things which you take for granted are not applicable to TCL. Because things are done in the same way in 'all' languages you tend to think that is the way it SHOULD be. The best example is the 'after a double quote almost everything is literal and syntax hardly applies anymore'. Yes, MOST languages do this but TCL does NOT. Is TCL wrong? I don't think so, but it immediately makes that I also don't LIKE it! So I have to keep an open mind and distinguish what I am `used to have' from 'like to have'. [Gert August 2006]AM Well, the treatment of strings inside quotes is not different in essence from UNIX shells or such dynamic languages as Perl. Have you tried Clif Flynt's book, BOOK: Tcl/Tk: A Developer's Guide?Todd Coram Syntax-wise, lots of languages use double-quotes to mean quite different things (strings, comments, auto-docs). Functionality-wise, what you described is (mostly) accomplished in Tcl with curly braces. So, you still get your 'like to have' if you use curly braces. Unless you find Tcl truly lacking in functionality that other general purpose languages have (which I doubt you will), what you have to decide is: Can you live with Tcl's syntax (or lack of ;-) and approach ?LV What languages treat text inside double quotes as literal? In my 30 years of experience programming, most languages treat strings in double quotes exactly as Tcl - if anything, it is text in single quotes which is surprising to the novice programmer. They try something like:
% set a 'abc' % puts 'a = $a' bad argument "'abc'": should be "nonewline"and are surprised. However, like any language, there are weird things to learn - do lines end in a newline, semicolon, do lines have to be indented or continued in a particular fashion, etc.RLH I doesn't matter to me in a real sense whether Tcl is "popular". I use it when I can. It does what I want. The community is great. The answers to my questions are swift and given in a helpful manner. If it was more popular that would be okay too but not mandatory for me.LV Popularity for popularity's sake isn't something of interest to me. Popularity that leads to more people learning that Tcl has a solution for their problems would be nice. The really useful thing that popularity might bring is more interest in letting people write in Tcl (and perhaps even some demand for a few books, etc. about Tcl).
