From: tom.rmadilo on
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
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
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
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
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.