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: Arndt Roger Schneider on 14 Dec 2009 11:33 Bruce Hartweg schrieb: > Arndt Roger Schneider wrote: > >> I think, you did miss the point of the original posting. >> To remind you: the author complained that the Tcl language resembles >> every other language out there and this goes against the fundamental >> design of said Tcl-language. >> > how so? - what is "The fundamental design of Tcl" ? Message-ID: <62f4746b-9a02-4720-96c2-0f3d47c66e2a(a)d21g2000yqn.googlegroups.com> .... did make a present out of my own copy of Ousterhout's book many years ago, so thanks for posting it for me :-) >> He got a point there. >> > seemed more like an opinion, rather than a point. > > Bruce His opinion is: that Tcl/Tk should follow its initial design, but I guess here. He made a point and has an opinion-- -roger
From: Shin on 14 Dec 2009 12:34 On 13 Dez., 13:24, Rodericus <sc...(a)web.de> wrote: > Tk/Tk was my predilect language for small programms, because it was > minimalistic and expresive, low weight and extensible, lisp and C > similar, ideal for embedding it in other programms. Now it is getting > fat and "object oriented" with a lot of unnecesary "features" that > would belong to extensions for special purpose applications. It is > getting a "Cool Programming Language (CPL)" for cool people, not any > more a "Tool Command Language". I think, a splitting and a renaming of > the cool language to something like Cpl/Tk#++ would have been a much > better approach. I think this is the result of having very good > developers not knowing what to do. Please, dont consider this posting > a flame war provocation: it is my oppinion. > > Rodrigo Readi Hi, you'll never find a "pure doctrin" named Tcl. Even in it's earliest versions Tcl had a lot of syntaxes like simple function call, object orientation and commands/subcommands constructs. Categorised such, Tcl has never been a minimalistic language. Actually, there is no language "Tcl", but a bunch of syntaxes for your comfort. - IMO Tcl is more like a meta-language for creating problem oriented scripting languages and so doesn't pull every new concept into a syntactically predictable form. It's pure freedom ;)
From: tom.rmadilo on 14 Dec 2009 12:36 On Dec 14, 4:58 am, Kevin Walzer <k...(a)codebykevin.com> wrote: > On 12/14/09 12:24 AM, Gerald W. Lester wrote: > > > Kevin Walzer wrote: > >> .... Sometimes, > >> in fact, Tcl is insufficient for my needs, and so for certain projects > >> I'm using Python instead. > > > Kevin, > > > Out of curiousity where are you finding Tcl insufficient? > > Python has better support for some things than Tcl in its standard > library or extensions: > > 1. A complete parser for Atom/RSS feeds, Mark Pilgrim's Feedparser. > 2. A complete implementation of SSH support, paramiko. > > I realize these things are probably technically possible in Tcl, but I > don't have time to code them myself, so Python is a better tool for > projects requiring these capabilities. "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. 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. Since the next fad is probably JSON, note that we have two pure Tcl packages for that data structure...although my version can only round- trip data from JSON to tcl list and back. It lacks a clean interface for creating a JSON structure. But you can validate a JSON structure via a web interface: http://junom.com/json/json.tcl 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. 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.
From: Donal K. Fellows on 14 Dec 2009 14:16 On 14 Dec, 17:36, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > But neither Python or Tcl > have real database capabilities. For that I would need to install > another application and communicate with it. Well, the sqlite3 package will do. There are other database interfaces too, some of which are to embedded DBs (i.e., the implementation is built in to the interface) and others are to remote database servers. You get to choose which you want to use. 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. Donal.
From: Óscar Fuentes on 14 Dec 2009 14:19
"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? -- Óscar |