Dan Janowski (danj@netcom.com, message id <danjD68p8F.36J@netcom.com>) wrote:
> I almost hate to pose this question because of the possible flaming
> thread that it may produce, but alas, I must.
Well, i have a sick day here, and the topic is a dear one to my heart,
so i'd like to take a few moments to address it.
The relative virtues of these languages is an important question. Also,
certainly, it is a complex one, difficult to address because it is so much
easier to get a focus on the more superficial issues - syntax, simplicity
of trivial programs, speed - than on the deeper, more stuctural issues -
semantic power, data abstraction, management of complexity - that the
dialogue can quickly become meaningless.
The real question, in my view, is, which languages provide the biggest
payoffs for effort invested? "Payoff" has different components for
different people. However, one component that is always important for
me, and one that i think transcends most application boundaries, is
integratibility. When you build a system or a tool, will you be able
to use it for more than just a single application?
Will you be able to use all your tools together, gaining more leverage
as you go, or are you always starting from scratch? Will you be able
to go back and directly use, or indirectly adapt, code you have
already developed for other purposes? I think python is the big
winner in this regard. (I happen to think it is the big winner, in
the scripting/extension domain, in most regards, but that's a whole
nother story.)
> Simply, it has been asserted that the fact that Tcl is 'typeless' is a
> 'problem', mostly for reasons of speed, and that it has some syntactic
Tcl's "typelessness" is a serious issue, and issues of speed are the
most extremely superficial ramifications of it. The real problem has
to do with data abstraction - tcl does not adequately provide it
unless you create your own special extension data types, and then you
sacrifice the integration benefits that come with native data types.
When i explored tcl, i tried some substantial programming in it - a
dns domain cataloguer - and i found myself needing a simple nested
data structure. The problem is, i could *not* directly construct it
in a manageable way. Ie, as best i recall, i had to use indirection
through variable names, because eg nesting an array within an array is
really just putting a string within a string, and the boundaries can
be lost depending on the data. This is NOT NOT NOT adequate.
Of course, you *can* create your own extension data types in tcl, to
accomplish this kind of thing. However, this sacrifices the
generality of powerful data types that are native to the language.
Either you build extensions to implement your own fundamental
structuring mechanisms, inventing extrinsic rudiments that ought to be
intrinsic. Or you make disparate extension structures for each system
you develop, and arrive at type-discrepancies that prevent good
integration of the systems with eachother. In either case you
sacrifice the ease and cleanliness of well-reconciled, native data
structuring mechanisms, something which python offers to a profound
degree.
In my opinion, the lack of simple but sophisticated native data
structures is one of the main impediments to building clean, large
systems with tcl. That, together with the excessively rudimentary
scoping mechanisms, convinced me that the effort necessary to do
substantial things with the language would not nearly pay off in the
integratibility i need from my tools.
People say it is a simple language, i suggest it is simplistic, the
distinction being that it is handy for doing very simple things, and
not handy for doing less than simple things.
> The non Tcl packages have Tk 'ports' but it somehow seems contrived.
That's about as vague a criticism as i could imagine. I mean, the
ports **are** contrived - contrived to implement the tk functions in
the other languages. Question is, were the contrivances successful?
I've only been fooled with, not done any substantial things, with tk
and tkinter. (I have done very little with perl, in general.) I have
the impression that they're both very effective, with tkinter having
the benefit, in my perspective, of being python...
> Perl shows its lineage of replacing /bin/sh, awk, sed, and so on. It
> looks like a language of regexps, seems messy, hard to read. Python,
As i said above, i have done very little with perl.
When i first looked at it (twice, really, once during perl 3 and once
during perl 4, i think), i was very daunted by the complexity of the
language, and the difficulties in nesting data structures. (I have a
feeble memory, in some ways, and the apparent burden on the programmer
of using different operations to accomplish the same thing, depending
on the object data types, was very daunting.) Evidently, perl 5
addresses the nesting problem, but still seems overly complex to me.
Even supposing the complexity to be a misperception on my part, the
reknowned difficulty in reading and adjusting established perl code,
even your own code, betrays my integratibility criterion...
> seemingly new in the fray, is interesting but has a wierd indention
> scheme for block definitions (while, for, if, etc). Both of them seem
Have you tried the language's indentation scheme, for any substantial
purposes? It certainly is different. You may find it to be an
improvement, as most people do who give it a real try.
> scheme for block definitions (while, for, if, etc). Both of them seem
> to suffer from many 'implied' operations and results. From a coding
Not certain what you mean here by "implied operations and results",
but i do know that you need to be well acquainted with python class
object's intrinsic special disciplines (__init__, __add__, __del__,
etc) before you can be confident using these objects. However,
there's a ton of stuff you can do with python without even touching
class objects, that i consider to be extremely simple and
straightforward. And when you're ready for the class objects, the
effort invested to understand the disciplines will pay off big time.
> standpoint, the word basis of Tcl operations, as opposed to %^@:
> characters, means that the code is actually readable. Having named
> commands that do operations is a GOOD thing, as opposed to relying on
> non-alpha characters.
The "word basis" of tcl operations breaks down pretty quick. What
about:
[expr {($hostsNoticed > 1) ? "s" : ""}]
The string-nature of the native types in tcl drives me *crazy*, when
it comes to distingushing structure from syntax. Granted, this
doesn't come up with simple structures holding simple data. But it is
a real world problem when it comes to real tasks and real world data.
(I also happen to be uncomfortable with a lot of C's syntax, which
shows up more or less in all these scripting languages, but i'm
probably in the minority on this in the Unix world. Sigh.)
> My opinion is that all of these interps are for prototyping and growth
> applications that may become partially or completely compiled at some
Actually, i think the relative prominence of compiled languages will
be decreasing as we continue into the network age, where passing code
across the wire increasingly makes the network the computation (to
warp a phrase:).
> point. Fast, easy to remeber, english coding means less time is spent
> on being clever and more on the idea. Tcl seems to fit this notion more
> than Perl or Python.
I see nothing "english" about tcl coding. It uses words, but so do
most natural languages. Tcl's phrase structure is almost non-
existent, in marked contrast to any modern spoken language. Most
importantly, the structure is simplistic, in ways that become unwieldy
when the ideas you are trying to express - the algorithms - are
anything more than extremely simple. This is not a virtue.
I realize that the simplicity of tcl *is* a real virtue for some
applications. Have you tried doing some substantial things with each
of the languages? If not, i would be interested to hear what your
opinion is once you have gotten a feel for their relative
versatility...
Thanks for your indulgence,
ken
ken.manheimer@nist.gov, 301 975-3539