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: tom.rmadilo on 15 Dec 2009 01:09 On Dec 14, 4:20 pm, Kevin Kenny <kenn...(a)acm.org> wrote: > 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.) I agree this sounds like the correct choice in this case. So if there is any question, my so called indignation is with the characterization of Tcl as "merely" a glue language. Or even a language which has "gaps" in functionality. Or that any programming language should be deemed "insufficient" just because nobody got around to writing and distributing your favorite application using the language. Tcl takes advantage of well written applications in any programming language. By well written, I mean that they export their functionality via some useful interface. Maybe it is just a shell command, or a C or Tcl library, or a mail program which deposits message files in a particular directory. Or an external tcp server or local ipc server (including stdin/stdout/stderr i/o). Note that Tcl itself does many of these things: exported C and Tcl libraries, great tcp/ipc support, many language features for packaging code into reusable components. What is generally lacking is any enforcement of well structured code. In a sense, that means the learning curve is not very steep. You might write ugly code for a few years, but your code still works. And it works on windows, mac and unix. And it is very possible to write large, even very large programs in Tcl. And you can do what I usually do: write programs which write programs (not always Tcl programs either) so you can enforce code to be well structured, and automatically improve the structure of all generated code. Most of these tasks are made easy because Tcl imposes no particular "world view" on really anything. The only thing that is really enforced is the basic syntax of the language.
From: slebetman on 15 Dec 2009 01:26 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"
From: Donal K. Fellows on 15 Dec 2009 01:34 On 14 Dec, 22:31, "Gerald W. Lester" <Gerald.Les...(a)cox.net> wrote: > 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. Thinking about it, one of the genuine themes of the whole Tcl 8.* series has been increasing support for writing large programs. Which isn't to say that it couldn't be done in previous versions (I've done it) but it took a lot of discipline. Making things easier in this regard is a good thing; it makes Tcl easier for newcomers to use, and it's helpful for old hands too. [Digression Alert!] The other thing that I really like is the starkit distribution model. It's an area where the closest I've heard of elsewhere is Java Web Start, and that's not easy to deploy at all. (Well, going by the comments of my colleagues at work on JWS; I've not used it myself.) Let me be crystal clear; what Tcl has there is ahead of the opposition. We don't know how far ahead though, because they're not yet up to the level where we were at in 2002... If we look at Tcl the language, the big changes have been the adoption of UNICODE, the addition of the expansion syntax, and the introduction of a new datatype (the dict, though it really just captures ideas in Tcl that already existed), and 8.6 adds an object system and a much more powerful execution model (coroutines). In terms of the implementation, 8.0's upgrading of Tcl's value model and the introduction of compilation are the massive features. 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.
From: Uwe Klein on 15 Dec 2009 03:27 tom.rmadilo wrote: > What is generally lacking is any enforcement of well structured code. > In a sense, that means the learning curve is not very steep. You might > write ugly code for a few years, but your code still works. And it > works on windows, mac and unix. 1. If it works you won't improve on it anymore ;-? 2. The Peter Prinziple of Software Creation: Any Code is beautyfied towards the death of it's usefullness ? uwe
From: Donal K. Fellows on 15 Dec 2009 04:19
On 15 Dec, 05:20, Rob <dislexic_wob...(a)NOSPAMyahoo.com> wrote: > The code you refer to is presumably in a demo rather than the actual > core code. It's supposed to say "Hebrew Language" or equivalent. But I don't read any Hebrew script at all (or Arabic) so it's quite possibly wrong. Fixes welcome. (Well, it's actually changed now so fixes are not needed now.) > Requesting that the Arabic version say 'Palestine' would be fine, In a demonstration that is supposed to be totally non-controversial? Not at all. There has never been any intent for Tcl/Tk to display *any* political point of view on topics like this, even an even-handed basis. Donal. |