The same but healthy, and more than a few moments.
> 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?
Well, I have to point out that these paragraphs are fluffy & just
serve to desmonstrate the author's bias in relief. Why? Well.. Syntax
is just as valid as any other criteria, and is one of Python's seeming
weaknesses. Speed is certainly as valid as anything else, and is
another relative failing of Python.
Payoff is generally defined as the return on effort invested, btw.
Payoff is also not always an important factor. Certain problem domains
need certain features, and the incidental cost isnt a part of the
choice. For example, people who want to write truely universal tools
(still) have to write them in K&R C. Despite the many failings of this
dialect & langauge, it can deliver more total result than other
langauges with might have better learning curves or "bug
incidence":"lines of code" ratios.
Lastly.. the relative virtues of these langauges isnt even vaguely
important. There is no pressing need to unify these langauges, and so
there is little need to throw any out in favour of others. Every
individual is free to choose whcih one they think will be best, based
on the langauges AND their knowledge of them.
This said, its amusing to pretend its important....
> 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.)
Well.. any langauge that allows modular programming will do you here.
As any C++ programmer will tell you, it merley takes god-like
willpower and diety inspired designs to write reusable code.
> > 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.
Here the author gets into explaining why Tcl kinda sucks, and does a
good job of it.
[...]
> 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.
This is a tad glib. My current work is "complex" and "Tcl". Tcl does
just fine.
> > The non Tcl packages have Tk 'ports' but it somehow seems contrived.
I strongly agree. Tk isnt bad though, and I dont see any reason to not
treat it as a kind of vague informal standard for graphical
descriptions. Before the Tk-standard, everyone had their own thing,
and while it wasnt contrived, it was often dumb. At least now its
consistant & not too dumb.
> > 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.
Well, I have used perl a lot.... Certainly the lineage is there,
though usually I think of the lineage as being C, not the other things
mentioned. The regexps part of perl is very good, but I have written
many a perl program that dosent use any of them.
> 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...
Reknowned? Perhaps rumoured. I have not had this trouble with my own
perl code. Just this week I took a lexer written in perl (not by me) &
modified the internals by hand to perform differently. I found it
pretty easy to do, even though it involved huge ammounts of regexps &
crypticly named variables. No, there is nothing about the langauge
that causes the code to be unreadable, just poor coders, which plague
any langauge.
Anything 'odd' makes code unreadable. Python's funky indentation
confuses the heck out of me now that I dont see it often. M3's CAPITAL
LETTERS always takes a bit of time to adjust to. Perl's $fetish _for
$bonus non-/[a-zA-Z]/ characters takes time to adjust to as well.
After you adjust, it is very handy to have little $ & @ & % characters
there telling you what something is. This is just the argument between
short func names and foo_reallyLongFunctionNamesWithSpecialPrefixes.
> > 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.
I gave it a real try. I'm the person who originally hacked python-mode
to parse #END tokens. I think its very readable, once you get used to
it, but I dont think it is safe or good.
> > scheme for block definitions (while, for, if, etc). Both of them seem
> > to suffer from many 'implied' operations and results. From a coding
Very true. I personally never make use of $_ in perl code. @_ is
somewhat unavoidable, but one can quickly assign it to something with
a real name. Python does this a lot less, but it shares a prediliction
for having functions have side effects on arbitrary stack-frames with
Tcl.
> 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.
Simple & straightforward? From the guy who dismissed 'simplicity of
trivial programs' as criteria? Yes, Im sure python makes a fine
calculator.
Yes, having written several Python classes I can tell you its paid off
big-time for me. Oh yeah. Yawn.
> > 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.
I generally agree, as I despise operator AND FUNCTION overloading. But
this 'word' thing is just downright ugly. I can enjoy a good perl with
tons of weird characters around. It isnt the job of the langauge to be
readable to one's boss. The COBOL thing has been done.
> 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.
This wasnt what was refered to, but yes, the string-thing generally
sucks. Perl does this type of thing as well though, in the right
places for it to help w/o being too much of a pain.
> (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.)
Highly so, yes. You prefer...?
> > 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:).
Well, the former opinion is more right than the latter. There is a lot
to be said for a good compile, and having a product that can
'eventually' compile arbitrary parts of itself is a good thing. Python
is easilly the worst in this regard, with its split object model
between Python objects and Python C-API objects. Tcl is probably the
best, but at the cost of making it be In Your Face even when you dont
care.
> > 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.
Bah. Screw english. As for cleverness.. nothing wrong with letting
some people be clever. The more time you spend 'on the idea' the more
code you'll throw away when someone thinks of a clever way of doing
it. Depends on what your constraints are.
> 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.
This is very true. And over & above this, English is a stupid goal for
a computer langauge. Let's try to pretend we think programmers are
skilled professionals, not people with degrees in English and a lot of
free time.
> 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...
I've done substantial work with Python, Perl, & STk. I'm writing a
Scheme interpreter (with a difference) and using Tcl a great deal now.
Scheme is by far the best of the lot, followed by perl, followed by
nothing. Tcl and Python are not better than (Scheme|Perl) at anything
I have ever thought to do.
-- John Redford (AKA GArrow) | 3,600 hours of tape. jredford@lehman.com | 5 cans of Scotchguard.