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: Rodericus on 15 Dec 2009 16:27 Bruce Hartweg wrote: > And yet you still haven't given concrete reasons/questions/problems > with the new Tcl other than [...] I think, you do not get the point, or do not want to get it, so that the whole discussion sound ideological. I am not a programmer, programming is not my work, I do not like to learn continously a new programming/scripting language. I am very glad to find Tcl everywhere, I used it for example among others with MySQL at client side, with Postgresql at server side, as Cost for processing SGML (a beautiful extension with a clear concept), as websh apache module, with GraphicsMagick, now with sqlite. The main advantage using Tcl lies less in the language self, more in the fact that it is beeing bound to other software. A growing image, new features that may add new bugs, mutations for the sake of mutation, the fact that it is becoming a scripting language like any other goes against this original goal of Tcl. The problem lies that you see Tcl at the center, as a tool command language it is at the margin of the application. My only critic was against inflating the core with new features that belog to extensions, and your answer is that I should ignore the inflation. Shin remarks with right, that I will never find a pure doctrine, but every programming language has a concept and some deviations of it for practical reasons, and I think the inflation is because the original concept was forgotten. Object orientation in the core is too much! The alternative is C, in each good piece of software you have a good C API. Indeed is programming in C not always so easy as in Tcl, and for gluing software I like the scripting language. I never programmed a GUI with C, and I suspect here is one of the biggest advantages of Tk. Rodrigo.
From: Pat Thoyts on 15 Dec 2009 18:01 Arndt Roger Schneider <arndt.roger(a)web.de> writes: >Tk and Tile are memory wise the largest parts in Tcl/Tk. >Tile is dependent on Tk, but Tk should not be dependent on Tile. ....blah blah blah ... [big pile of suggestions snipped] Its an open source project. You can fork it anytime you want. It will be interesting to review your forked version. You can announce it here when you have something ready. -- Pat Thoyts http://www.patthoyts.tk/ To reply, rot13 the return address or read the X-Address header. PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
From: Bruce Hartweg on 15 Dec 2009 18:50 Rodericus wrote: > Bruce Hartweg wrote: > >> And yet you still haven't given concrete reasons/questions/problems >> with the new Tcl other than [...] > > I think, you do not get the point, or do not want to get it, so that > the whole discussion sound ideological. you are the one that seems to not get (or have) a point, and keep throwing out the "ideological" discussion of what tcl "should" be, based on the past. You still havent't shown an actual problem that the "new" Tcl has caused in your usage. > > I am not a programmer, programming is not my work, I do not like to > learn continously a new programming/scripting language. I am very glad > to find Tcl everywhere, I used it for example among others with MySQL > at client side, with Postgresql at server side, as Cost for processing > SGML (a beautiful extension with a clear concept), as websh apache > module, with GraphicsMagick, now with sqlite. The main advantage using > Tcl lies less in the language self, more in the fact that it is beeing > bound to other software. A growing image, new features that may add > new bugs, mutations for the sake of mutation, the fact that it is > becoming a scripting language like any other goes against this > original goal of Tcl. The problem lies that you see Tcl at the center, > as a tool command language it is at the margin of the application. My > only critic was against inflating the core with new features that > belog to extensions, and your answer is that I should ignore the > inflation. Shin remarks with right, that I will never find a pure > doctrine, but every programming language has a concept and some > deviations of it for practical reasons, and I think the inflation is > because the original concept was forgotten. Object orientation in the > core is too much! object orientation in the core has zero impact to anything you want to do with tcl. just ignore it. it is NOT changing the language itself - it is adding new capabilities for those who want/need it so all those things you mentioned above that you like, what no longer works? what can you no longer do? Bruce
From: Arndt Roger Schneider on 16 Dec 2009 04:08 Pat Thoyts schrieb: >Arndt Roger Schneider <arndt.roger(a)web.de> writes: > > > >>Tk and Tile are memory wise the largest parts in Tcl/Tk. >>Tile is dependent on Tk, but Tk should not be dependent on Tile. >> >> >...blah blah blah ... >[big pile of suggestions snipped] > >Its an open source project. You can fork it anytime you want. >It will be interesting to review your forked version. You can announce >it here when you have something ready. > > > Thanks for the suggestion! I am not interested in forking it.
From: Rodericus on 16 Dec 2009 04:25
On 16 Dez., 00:50, Bruce Hartweg <doNOTmai...(a)example.com> wrote: > object orientation in the core has zero impact to anything you > want to do with tcl. A fat Tcl interpreter has impact to all wanting to see Tcl linked to other software and embedded in hardware, because fatness make it less attractive to those that do not like fatness and do not like to link a fat interpreter as tool command language to their meager software they write. Those liking fatness will not have a problem linking a meager interpreter. The solution is to clear distinguish what is the core of Tcl (and also Tk) and what is an extension that may be make fat to satisfy those that like fatness. Is it realy so difficult to understand? The proposal of Pat Thoyts to Arndt Roger Schneider also confirm that the first do not get the point: Forking Tcl/Tk would only make it unattractive to potential linkers. Tile as a separated package, as a complement to a meager Tk, should not be a problem. Rodrigo. |