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: jr4412 on 14 Dec 2009 06:38 On Dec 14, 10:50 am, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > I think you slightly failed in the targeting of your post, you know. > It feels like a provocation. It feels like an insult. It also feels > like a railing rant against the changing of the world. no man. the original post makes an excellent point -- Tcl is undergoing change for change's sake, it is getting feature heavy, trying to supply all programming paradigms to all men, nothing like Ousterhout's original aim. "Tcl was born of frustration. In the early 1980s my students and I developed a number of interactive tools at the University of California ... the command language for one tool was never quite right for the next tool ... fall of 1987 it occurred to me that the solution was to build a reusable command language." (from the Preface to JK Ousterhout 'Tcl and the TK Toolkit'). rather than feeling "provoked" tell me why modern Tcl is becoming more and more indistinguishable from the Python's, Ruby's, Perl's of this world. you say: "Tcl has features because someone wanted them and persuaded others that adding the feature was a good idea." I say, that how Windows (TM) came about ;( anyway, FWIW, I share Rodericus concern that Tcl/Tk has lost its way.
From: Rodericus on 14 Dec 2009 07:17 First of all, I thank everybody answering. About the recommendation of Etcl, lua, jim: I will see them , but I do not think they are the alternative, for example due to licence, due to object orientation that I do not like. Using an older version (7.6) is not the solution, due to mantainace: C compiler and OS developes/mutates. I also do not condemn every developement, I like for example the idea of stackles bytecode engine. I do not like the inflation that goes against the original idea of Tcl/ Tk. This inflation is specially patent in 8.5 and 8.6, so that a split would be a good idea. Why are there now widgets that do escentially the same? Only because the new ones are prettier? I do use old computers, with few RAM. Tcl is a language for binding it to other programs, Tcl may be used also for embeded systems: Small image is a very important feature, it is part of the concept of tcl. Cool features is not what I expect from Tcl/Tk, and much less if they make it unnecessarily fatter, even if it makes it only a little fatter. 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. Tcl/Tk ist an extensible language. Cool Extensions, cool features, cool object orientation can be added as extension, but the core of the language is the false place. As long as extensions are written and hence the language used, the language is not death. Those writing extensions could perfectionate the core language: in its original spirit. This is not a death strategy. I continously use Tcl with databases, but never expected that an API be added. I dont need png as native image format, I use for example the API of graphics magic in a small application I am writing. I used many times the extension for processing SGML (Cost). That object orientation was added, says a lot. I would be much happier seing a goto statement in the language. Object orientation is good for making big programs readable, although it hides algorithms and hence adds inefficiency. Programming with "goto" is much easier and makes programs more efficient, but programs are less readable, big programs perhaps unreadable. 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. 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. Rodrigo Readi.
From: Rodericus on 14 Dec 2009 07:18 First of all, I thank everybody answering. About the recommendation of Etcl, lua, jim: I will see them , but I do not think they are the alternative, for example due to licence, due to object orientation that I do not like. Using an older version (7.6) is not the solution, due to mantainace: C compiler and OS developes/mutates. I also do not condemn every developement, I like for example the idea of stackles bytecode engine. I do not like the inflation that goes against the original idea of Tcl/ Tk. This inflation is specially patent in 8.5 and 8.6, so that a split would be a good idea. Why are there now widgets that do escentially the same? Only because the new ones are prettier? I do use old computers, with few RAM. Tcl is a language for binding it to other programs, Tcl may be used also for embeded systems: Small image is a very important feature, it is part of the concept of tcl. Cool features is not what I expect from Tcl/Tk, and much less if they make it unnecessarily fatter, even if it makes it only a little fatter. 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. Tcl/Tk ist an extensible language. Cool Extensions, cool features, cool object orientation can be added as extension, but the core of the language is the false place. As long as extensions are written and hence the language used, the language is not death. Those writing extensions could perfectionate the core language: in its original spirit. This is not a death strategy. I continously use Tcl with databases, but never expected that an API be added. I dont need png as native image format, I use for example the API of graphics magic in a small application I am writing. I used many times the extension for processing SGML (Cost). That object orientation was added, says a lot. I would be much happier seing a goto statement in the language. Object orientation is good for making big programs readable, although it hides algorithms and hence adds inefficiency. Programming with "goto" is much easier and makes programs more efficient, but programs are less readable, big programs perhaps unreadable. 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. 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. Rodrigo Readi.
From: Kevin Walzer on 14 Dec 2009 07:58 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. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com
From: Bruce Hartweg on 14 Dec 2009 10:12
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" ? > He got a point there. > seemed more like an opinion, rather than a point. Bruce |