| Larry W. Virden 2006-09-26, 8:40 am |
|
Stephan Kuhagen wrote:
This keeps being tossed out, over and over. How about defining
specifically what features you envision in the complete and
comprehensive standard library? Because in my experience, what I want
in such a library and what someone else wants are quite different.
If there is ever to be a hope to move in a positive direction during
these sorts of rambling discussions, people need to start the ball
rolling. And the first step would be to pick a set of features,
explicitly flesh out the details, then convince people to either start
coding, or at least to find something that has already been coded and
someone to work out the details.
[color=darkred]
> to the others. And one reason is, that it stopped evolving and the bad
> "marketing".
I myself don't see a stop to the evolving. But what I do see is a
different between your expectations and the expectations of those
writing Tcl core code. And the choices for response at this point seem
to be:
1. write code and work on getting it into the core,
2. write specifications and work with someone willing to write code and
work on getting it into the core,
3. continue the regular discussions with people spending quality time
writing responses rather than code,
4. modify personal expectations to be satisfied, or
5. move to another language.
And frankly, I'd love to options 1 and 2 continue.
> What is needed is a definitive Tcl base.
I think what you probably mean here is "What is needed is a more
comprehensive Tcl base". The source code of the Tcl core is the
definitive Tcl base, at any point in time.
But your proposal, to date, is that more functionality should be in the
core. And frankly, I agree. I look at the http://tip.tcl.tk/ and I see
a lot more functionality that has gone into Tcl in the past few years.
I see a lot of attractive new functionality that could appear once
proposers get back to working on it. And I see a process whereby people
who need more functionality can work with interested others to propose
an implementation be added to the core.
The issue, in my opinion, is NOT that Tcl is not evolving. It is. It is
not that Tcl is dead - it's not. The issue with which you are
struggling is that algorithms and language bindings that exist in other
languages "out of the box" are not present in Tcl "out of the box".
>From the early days, languages have come with libraries of
algorithms/solutions to common problems. Some languages download with
more of these than others. For instance, some C compilers come with
libc. I seem to remember, the last time I build gcc, that I needed to
download a separate tar file to get gcc's libc. Java comes with a set
of classes of solved problems. Beyond that, there are a large number of
additional items that can be downloaded. Python, Perl, Ruby - these
all come with a large toolset in the default download, and then their
respective communities have developed additional invaluable libraries.
In the case of Tcl, the initial core is relatively light in terms of
functionality. Some people are okay with that - they prefer to write
everything from scratch - in some cases, every time.
I know that _I_ prefer to have a set of pre-written, pre-debugged
libraries from which to work. So, with Tcl, I end up with a dozen or
two downloads to get what, to me, is a base working environment. Or, if
I am working on personal stuff, I use ActiveTcl, which is a good
starting point.
> And this base must
> have the stuff, that other competing languages have in their base package.
It might be an interesting exercise to take the major languages, list
the functionality present in each one, and see how many of the features
overlap. Because that overlap is surely the subset of functionality to
which you refer. I suspect that Java functionality is not identical to
Perl or Python or Ruby (and all the iterations of the 4 are surely not
equal either).
Shoot - Perl probably has the most functionality out of the box of all
5 languages.
>
> but the question
> for me really is, why is Tcl not attractive enough for the KDE people, to
> have it already integrated into KDevelop? Look, they have Ada and Haskell
> integrated (and a bunch of scripting languages), but no Tcl!
Because most developer communities think of Tk when they think of Tcl.
And a desktop environment community is going to want as much
compatibility with their GUI standard as they can get. Right now, Tk
bridges platforms, bringing to it inconsistencies in look and feel.
>
>
> Yes, six... Ever read comp.lang.python for some days? It can be a fulltime
> job...
What I generally find is that the number of questions a newbie to Tcl
brings to the table are significantly less than other languages. If my
experience is not unique, then the ease of entry to Tcl would be the
explanation of the "missing" overload of repeated questions by
newbies...
> Guido van Rossum knew Tcl
> before starting Python. Why was it necessary to start Python, Ruby or
> others?
Because his requirements were different - he wanted an OO based
programming language. Tcl is never going to be an OO based programming
language. It will likely include an OO module/OO features, but the
essence of Tcl isn't going to be an OO language.
A better question, to be asked in some other group than this one, is
why create Python when other languages did have the OO basics.
Smalltalk's been around for longer than either Tcl or Python. As have
other OO languages.
> And then what were the reasons for their success in many fields,
> what are the advantages over Tcl?
To answer this question, one must define what "success" means. Once
that word is clearly and unambiguously defined, then one can answer it
for various languages, and then draw from that analysis recommendations
to the Tcl community.
|