> > From: klm@nist.gov (Kenneth Manheimer)
> >
> > 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.
>
> > 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.
>
> 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.
Well, that's kinda demeaning. Morever, you might could be implying
that i was disingenously dismissing syntax and speed because they are
weaknesses of python - which you further imply to be the case. In
case anyone got that impression, i had no such agenda, and in fact i
do not think the case is there.
The syntax issue is a fairly religious one, but let it be known that i
consider that one of python's major strengths. The language takes
much from a rigorously designed language named 'abc', which aimed for
a very straightforward, clean, and versatile syntax. I think python
reflects that, with one of the cleanest and most cogent syntaxes
around, in marked contrast to tcl and perl.
Re speed, if i recall correctly, a few of the reports at the last VHLL
conference did not attribute that as a relative failing of python.
Python was rated, re speed, about comparable with perl, with scheme
coming out significantly, but not extremely, faster, and tcl coming
out significantly *and* extremely slower.
All that said, i still would not dismiss tcl due to speed or syntax
issues, despite my reservations about the language in both those
regards. I do have a beef with it re versatility.
> 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
Perhaps i made a poor choice of wording. By payoff i meant "critical
benefit". The benefit be universality, or whatever other factors are
crucial to you.
> 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.
I'm not quite sure i understand what you're saying here. I agree that
the languages need not all be unified, and people are free to choose
which ones they will use, for which purposes. However, i think it's
important to be able to choose one that will suit as many of ones
needs as possible. It's *quite* costly to have to switch between
languages that are not integrated with eachother, both in terms of
integration efforts and in terms of diluted expertise. Given the
choice of one language that does just about everything well, or a few
that do some things better and some things less well, i'd choose (i
choose) the former, of course.
> This said, its amusing to pretend its important....
Aargh. How condescending!
> 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
It may simply be an artifact of my own submersion in python, but i am
stunned to hear that the use of indentation to convey block
structuring could confuse *any* programmer. When you read C code (or
lisp!), do you actually count braces, and ignore the indentation with
which **most** people format their code?
I have always assumed that most program code (including lisp) is
formatted using indentation because people depended on the indentation
cues for navigating around the program structure. The braces (eg, in
c and c-heritage languages) are left as rigorous cues for the
compiler.
What python does, quite successfully i think, is require rigorous
indentation, which both the human and the compiler use it as the
structuring cue. This disposes of the loose, sometimes betrayed,
coupling between the braces and the indentation.
> > 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.
Very readable, ok! Not safe or good? Why??? If there is some flaw
in the scheme, we need to hear about it - i'd hate to think that i
will find myself, down the road, trying to write a program, and
discovering that i can not do so because of the indentation scheme...
(And i doubt that such a situation exists, any more so than it does
for brace-delimited blocks.)
> Simple & straightforward? From the guy who dismissed 'simplicity of
> trivial programs' as criteria? Yes, Im sure python makes a fine
> calculator.
Dismissed it as a primary criterion. And i did not dismiss
simplicity, i said that simplicity for writing trivial programs is a
more superficial issue - i said that because it can be misleading when
considering the language's general effectiveness and versatility.
(In fact, simplicity is very important to me, when it means clean,
clear, and concise, as opposed to over-simplification/simplistic.)
> > (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...?
Lisp. I much prefer a lexically scoped lisp, like scheme. But i have
had little opportunity to do development with scheme, and only had
opportunities lately to use emacs lisp, sigh. (I did own a pair of TI
Explorers for a while, though - big fun. Too cumbersome, though, for
hobbying. But talk about programmable, even the prom microcode was
written in a kind of lisp!)
I've used and liked praxis, a block-structured communications language
out of lawrence livermore labs, which i would guess (despite my being
only minimally acquainted with ada) to be somewhere between pascal and
ada. I also have done a lot of programming using sh and (n)awk and
ancillaries, which can be fun, but frustrating when you run up against
the boundaries.
Of them all, python seems to be by far the best compromise. Though i
do miss the ease of parsing lisp code using lisp, i find python more
easily readable and easy to use.
> > 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'm not sure i would call natural-language programming a "stupid"
goal, but i don't think it promises the easy benefits that marketers
like to imply.
ken