Tcl/TK is indeed dying
in [TCL]
|
Prev: www.prevayler.org anyone do an in ram data base with transactionlog in tcl?
Next: accessing GUI with TWAPI (was: Accessing GUI of CAD through Tcl/Tk)
From: David Gravereaux on 14 Dec 2009 16:54 Ãscar Fuentes wrote: > "Donal K. Fellows" <donal.k.fellows(a)manchester.ac.uk> writes: > > [snip] > >> That's one of the *great* things about Tcl, that you can easily extend >> it with extra functionality through packages, your own code, or >> through calling external programs. > > And how is this different from every other existent programming > language? > Ever written a Perl extension? How about one that involves I/O? Some nice OS level hacking you have to do to get under libc on windows, eh? What a joy. Not so with Tcl as the channel API is wonderful. About the only thing it lacks is the inverse of channel stacking where it operates as a container... But only kooks like me ever get into stuff like that. Python extensions aren't so bad, though. I got up to speed pretty quick. Although with Python, the concept of a command returning a value (an eval) is a bit odd as there are two types of execution: statements and expressions. So first you need to source the code block with PyRun_String(Py_file_input), then execute it with PyRun_String(Py_single_input). I find that just odd. --
From: Gerald W. Lester on 14 Dec 2009 17:31 Rodericus wrote: > First of all, I thank everybody answering. ... > > ... > > Indeed I can ignore the new cool features and use Tcl/Tk as usual. The > usual things remains easy to learn. The problem begins, when many > people are involved in the developement and everyone must read what > other write. It was part of the concept of Tcl that it is easy to > learn and minimalistic. Which brings us to the question of what is Tcl -- and no I'm not being funny. To me Tcl is the Endekalogue -- *everything* else is just an extension and can be overwritten (including the "built in" commands). All one has to really learn is the Endekalogue, everything else can be looked up. > .. The question is now, if Tcl/Tk is a language for > big programs or small ones. That Tcl/Tk works with big programs proves > that the language is stable and realiable, but writing big programs > with Tcl/Tk remains an abuse. There are a lot of languages for big > programms. ... I disagree that writing big programs with Tcl/Tk is an abuse -- and have for years. In fact J.O. was shocked at the first Tcl/Tk workshop when a paper was presented about a system that was ~300,000 lines of Tcl/Tk. The system was deployed over time at several sites and grow to ~500,000 line of Tcl/Tk. Very few bugs and easy to maintain. Of course it has been overshadowed by at least an order of magnitude by two other systems written in Tcl/Tk by two other vendors. -- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+
From: Kevin Walzer on 14 Dec 2009 17:50 On 12/14/09 12:36 PM, tom.rmadilo wrote: > > "Probably technically possible"? > > Basically you are blaming Tcl because it is missing an application you > want to use. I have python on my machine, but it doesn't have an Atom/ > RSS parser. > > Problem is, if I was interested in Atom or RSS feeds, I might want to > maintain some kind of database of the feeds. But neither Python or Tcl > have real database capabilities. For that I would need to install > another application and communicate with it. This is where Tcl ends up > being ahead of the game. It could use any available RSS parser and > store the results in a database. Tcl would also be very good at the > server side of Atom or RSS. I'm not quite sure what in my reply has made you so indignant. I'm not blaming Tcl for anything. I'm saying, among other things, that it lacks a well-supported library for parsing RSS/Atom feeds. I'm well acquainted with Tcl's abilities to cooperate with and to drive external applications. Most of my Tcl/Tk applications make use of this feature. That's not especially relevant in this instance because I'm not aware of any good command-line RSS parser. > > As far as parsing this stuff, one problem is the poor quality of the > XML which is generated. But if it is valid XML, the Tcl community has > developed two different parsers. As someone who has developed an XML > application in Tcl (tWSDL/TWiST, which requires parsing, processing > and generating XML documents), I can tell you Tcl works very well. Yes, I realize that Tcl can parse XML. But if I wrote my RSS application in Tcl, I would still have to figure out how to parse the different kinds of RSS and Atom feeds in Tcl, which would be a lot of work. By contrast, Python has Mark Pilgrim's feedparser library, which is a comprehensive parser for RSS and Atom feeds. By choosing Python for my specific application to parse RSS/Atom feeds, I can take advantage of this library: I don't have to figure out how to parse all the different RSS and Atom formats. By avoiding the work of writing my own feed parsing library, I can develop my application faster and with fewer bugs. > > Hopefully Tcl (the language) will remain insufficient for everyone's > needs, I mean, the list of built-in Tcl commands is only one browser > sized page. It is also very hard to argue that the number of new > commands add bloat. For all the additional bloat, certain things have > simplified code development: namespaces, auto-initializing incr > variables and lists, portable arrays (dict). Also things have been > sped up by compiling some scripts into bytecodes. I agree that Tcl is not a bloated language and I would number all of the things you are listing as advantages of the language. > > And yet Tcl remains insufficient for my needs. Thankfully I know how > to write library and application code to build up to something which > is sufficient. > I think in many cases this is the correct approach. I've extended Tcl and, especially, Tk many times myself to add functionality that was missing. I also leverage system/command-line tools to fill in gaps in Tcl's functionality. However, this isn't always the best or fastest approach. By choosing Python and its robust, widely-praised, widely used feedparser extension library, I can complete my application much sooner than I could if I were developing it in Tcl. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com
From: Kevin Kenny on 14 Dec 2009 19:20 Kevin Walzer wrote: > I think in many cases this is the correct approach. I've extended Tcl > and, especially, Tk many times myself to add functionality that was > missing. I also leverage system/command-line tools to fill in gaps in > Tcl's functionality. However, this isn't always the best or fastest > approach. By choosing Python and its robust, widely-praised, widely used > feedparser extension library, I can complete my application much sooner > than I could if I were developing it in Tcl. And, until and unless you or someone else develops the library you need, I think you've made a wise choice. If your problem is solved, that's good. (If Tcl solves it, that's even better, but solving the problem is paramount.) -- 73 de ke9tv/2, Kevin
From: Rob on 15 Dec 2009 00:20
Rodericus wrote: > Somewhere in the TK source, where it is shown that TK can work with > unicode, it appears in many languages the greating "hallo world" or > something similar. Only in hebrew its stays something different: > "Jerusalem, Israel" in hebrew letters. (In arabic in should stay > "Jerusalem, Palestine"). This issue shows, that arbitrarity is > imposing itself: giving Jerusalem to the european jewish colonists is > becomming more important than the concept of Tcl. <rant> That is your opinion. There is, at this time, no official country of Palestine. I also object strongly to your choice of words. </rant> The code you refer to is presumably in a demo rather than the actual core code. If you find it offensive, please feel free to create a "fix" and ask to maintainers to apply it. Also, while discussion of language issues is most welcome here, I believe your injection of a political statement is definitely NOT appropriate. Requesting that the Arabic version say 'Palestine' would be fine, but the comment on "giving Jerusalem to the european jewish colonists" is, IMO, absolutely off-topic in this newsgroup... Rob. |