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: Bruce Hartweg on 15 Dec 2009 09:51 Rodericus wrote: > On 14 Dez., 23:31, "Gerald W. Lester" <Gerald.Les...(a)cox.net> wrote: > >> 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. > > No, syntax is not all. You have objects, like numbers and strings, and > you must be able to write all recursive functions on them without > having to program a turing machine. You must be able to communicate > with the system and the outer world. You must be able to efficiently > write efficient programs with a minimal tool command language. I think > for example that the addition of expansion syntax, if this was done > efficiently, is a very good improvement, perhaps based more on > programming experience than on reflection of what is the ideal > language. > And yet you still haven't given concrete reasons/questions/problems with the new Tcl other than "I don't like change", or it isn't exactly what JO thought is was many decades ago, It has things I don't want or need or like. But none of those generalities preclude you from continuing to use Tcl in the same way as you always have. Bruce
From: drscrypt on 15 Dec 2009 10:00 Gerald W. Lester wrote: > 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. And they are? DrS
From: Will Duquette on 15 Dec 2009 10:09 On Dec 15, 2:56 am, Arndt Roger Schneider <arndt.ro...(a)web.de> wrote: > Donal K. Fellows schrieb: > > > [snip] > >For Tk, the > >really big thing is the new themed widgets, both conceptually (the new > >state model) and in implementation terms (Tk no longer has to look > >utterly outmoded). > > >Donal. > > 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. > In order to reducing the memory footprint of Tcl/Tk: > Separate Tile into a shared library, create an alternative > wish loading tile, importing the ttk windows > into the global namespace as default. > > The other wish(Tk) is then still able to load tile as > a package. > > Requires under X11 to implement all Tcl-dialogs independent > from either Tk or tile aka separate the file dialog into its own > namespace, put styles and visual configuration inside the option database.. > > Second Tk: > Remove all embedded bitmaps and replace them with font-glyphs, > very much as you did with the warning symbols inside the message box, > but with anti-aliased glyphs, instead! > > Do progressingly the same with all controls: corners, shadows, > highlightthickness, indicators... start with radiobutton and checkbutton > indicators. > > Make the glyph-font user customizable: > Gives a full vectorized themed engine, anti-aliasd, fast as hell, > low memory footprint. > > Third Panedwindow: > Reduce platform dependencies: > The panedwidow is a simple geometry manager > and should not be implemented as a window, make > it the fourth general purpose geometry in Tk and > leave the stash configuration to the developer using it. > Remove the redundant version in tile. > > -roger The ttk::panedwindow is far from redundant; in my experience it works *much* better (in both behavior and appearance) than the non-ttk panedwindow. On top of this, moving the ttk widgets into a separate package would be a major step backward for Tk.
From: Arndt Roger Schneider on 15 Dec 2009 10:29 Will Duquette schrieb: >On Dec 15, 2:56 am, Arndt Roger Schneider <arndt.ro...(a)web.de> wrote: > > >>Donal K. Fellows schrieb: >> >> >> >>>[snip] >>>For Tk, the >>>really big thing is the new themed widgets, both conceptually (the new >>>state model) and in implementation terms (Tk no longer has to look >>>utterly outmoded). >>> >>> >>>Donal. >>> >>> >>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. >>In order to reducing the memory footprint of Tcl/Tk: >>Separate Tile into a shared library, create an alternative >>wish loading tile, importing the ttk windows >>into the global namespace as default. >> >>The other wish(Tk) is then still able to load tile as >>a package. >> >>Requires under X11 to implement all Tcl-dialogs independent >>from either Tk or tile aka separate the file dialog into its own >>namespace, put styles and visual configuration inside the option database. >> >>Second Tk: >>Remove all embedded bitmaps and replace them with font-glyphs, >>very much as you did with the warning symbols inside the message box, >>but with anti-aliased glyphs, instead! >> >>Do progressingly the same with all controls: corners, shadows, >>highlightthickness, indicators... start with radiobutton and checkbutton >>indicators. >> >>Make the glyph-font user customizable: >>Gives a full vectorized themed engine, anti-aliasd, fast as hell, >>low memory footprint. >> >>Third Panedwindow: >>Reduce platform dependencies: >>The panedwidow is a simple geometry manager >>and should not be implemented as a window, make >>it the fourth general purpose geometry in Tk and >>leave the stash configuration to the developer using it. >>Remove the redundant version in tile. >> >>-roger >> >> > >The ttk::panedwindow is far from redundant; in my experience it works >*much* better (in both behavior and appearance) than the non-ttk >panedwindow. > > > Fine, use the ttk:panedwindow code for the stand-alone geometry manager. >On top of this, moving the ttk widgets into a separate package would >be a major step backward for Tk. > > Why? You have two applications, one linked against tile, and another one only with tk, where is the step backward? It provides the same environment as is current in 8.5, plus the option to use a smaller set on such platforms which don't have themes or were the extra memory requirements are to big a burden. -roger
From: Óscar Fuentes on 15 Dec 2009 10:59
"slebetman(a)yahoo.com" <slebetman(a)gmail.com> writes: > On Dec 15, 3:19 am, Óscar Fuentes <o...(a)wanadoo.es> wrote: >> "Donal K. Fellows" <donal.k.fell...(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? >> > > The word "easily" "easily" here is subjective. It is "easy" to introduce new commands for interfacing with C code, in the sense of requiring less boilerplate than other languages. But Tcl requires more work than others (notably, some languages or implementations requires one line of code per C/C++ reflected function/method, some languages requires none.) It is not so easy to reflect complex external data on the Tcl data model, though. The above is for interfacing with external libraries. Certainly, a programmer who can't get the grips on Tcl's weirdness will say that is not easy to add functionaility to Tcl writting Tcl code. And EIAS is not all that great for some tasks. Being interpreted forces you to write C from time to time. So, Donal's is reflecting its own personal likes and dislikes. What he says makes no sense otherwise. -- Óscar |