Python advocacy
Paul Prescod
Python.
I'm somewhat nervous about the flamage I'll get, but c'est la vie.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"The calculus and the rich body of mathematical analysis to which it
gave rise made modern science possible, but it was the algorithm that
made possible the modern world."
- from "Advent of the Algorithm" David Berlinski
http://www.opengroup.com/mabooks/015/0151003386.shtml
Don Tuttle
news:38BEE429...@prescod.net...
> O'Reilly asked to publish something I had written for my homepage about
> Python.
>
> http://www.oreilly.com/
>
> I'm somewhat nervous about the flamage I'll get, but c'est la vie.
I bow before man with big, big gonads! You very brave man, Paulsan. End
article with "You can respond to Paul at py...@prescod.net " You write
wonderful article.
Now about the flamage...where would you like us to scatter your ashes? ;-)
Don
Andrew M. Kuchling
> O'Reilly asked to publish something I had written for my homepage about
> Python.
Interesting article, and carefully written to avoid *too* much
flamage. (Which doesn't imply that readers will pick up on it and
avoid flaming you, but at least you tried.)
The observation that "C++ and Perl only make sense if you have a
particular programming background" is a pretty good one. Doesn't Tcl,
like Perl, bear traces of being Unix shell-inspired. Even the Python
tutorial bears traces of this, with the very first paragraph giving a
motivating use for Python: translate a really complicated shell script
into Python for more maintainability. I can't remember the last time
I started out by writing a shell script for some task, and I think few
people reach for the shell unless the task involves only moving files
around. I have replaced Makefiles with a Python script in the last
year, though.
--
A.M. Kuchling http://starship.python.net/crew/amk/
I think it would be totally inappropriate for me to even contemplate what I am
thinking about.
-- Don Mazankowski, (Mazankowski was the Canadian Finance Minister for
most of the 1980s.)
Paul Prescod
>
> ...
> I bow before man with big, big gonads! You very brave man, Paulsan.
Well, thus far all response has been positive! Obviously I stacked the
deck by alerting comp.lang.py'ers about the article but Perl-mongering
flamers have been conspicuously absent. Obviously some large majority
are going to be mature about it and some other percentage indifferent.
I'm just surprised not to hear from the lunatic fringe. I'll hasten to
add that every community has a lunatic fringe -- Perlers are probably no
worse than anyone else.
Of course the most vicious flamers probably hang out together somewhere
other than the O'Reilly web site...
> End
> article with "You can respond to Paul at py...@prescod.net " You write
> wonderful article.
pyguy is an alias set up specifically for that article so that I can
redirect flamage to my "read this on a rainy day" folder.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"We still do not know why mathematics is true and whether it is
certain. But we know what we do not know in an immeasurably richer way
than we did. And learning this has been a remarkable achievement,
among the greatest and least known of the modern era."
Ran
Paul Prescod wrote:
> Well, thus far all response has been positive!
It's early yet. Even by net standards ;-)
There's a fundamental problem with your argument that makes any
comparison among languages moot, anyway: your "scalability" criterion
is a myth that just doesn't fit the real world.
There's no single continuum of "easy to difficult problems". Nor is
there one from "beginners" to "experts". There are significant
*qualitative* differences among problem domains, and significantly
different programming styles and methodologies (with differing degrees
of usability/appropriateness to the different domains). A single person
can be an "expert" hacker, a "mediocre" engineer, and a "rank
beginner" systems analyst.
Each applications area has characteristics that make some languages
"ideal", others "problematic", and sometimes even some of them
"dangerous" to use.
And the same applies to developers: different people have different
approaches to solving problems. Some languages will fit a particular
person's temperament and abilities, and some won't.
A "Perl-vs-C-vs-Python-vs-APL-vs..." argument is equivalent one about
"hacksaw-vs-screwdriver-vs-scalpel-vs-tweezers": it may have some
amusement value, but any real-world benefits are an accidental
by-product.
Ran
Brett g Porter
"Ran" <r...@netgate.net> wrote in message
news:38BF6169...@netgate.net...
> Each applications area has characteristics that make some languages
> "ideal", others "problematic", and sometimes even some of them
> "dangerous" to use.
>
> And the same applies to developers: different people have different
> approaches to solving problems. Some languages will fit a particular
> person's temperament and abilities, and some won't.
Bonnie Nardi's book "A Small Matter of Programming" deals with both these
points in pretty great detail.
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0262140535 sez:
A Small Matter of Programming : Perspectives on End User Computing
By Nardi, Bonnie A.
162 Pages
Published by MIT Press
Date Published: 09/1993
ISBN: 0262140535
Summary
A Small Matter of Programming asks why it has been so difficult for end
users to command programming power and explores the problems of end
user-driven application development. Drawing on empirical research on
existing end user systems, A Small Matter of Programming analyzes cognitive,
social, and technical issues of end user programming. In particular, it
examines the importance of task-specific programming languages, visual
application frameworks, and collaborative work practices for end user
computing, with the goal of helping designers and programmers better satisfy
the needs of end users who want the capability to create, customize, and
extend their applications software.
----
I'm glad, as a C++ programmer, to be adding Python to my toolbox -- I don't
see any reason to disparage C++ as Paul did. I agree that C++ is not the
language for everyone or for every project, but I feel a lot better as a C++
and Python programmer than I would knowing only one of those languages.
A-uniter-not-a-divider-ly y'rs
-- BgP
Donn Cave
...
| I'm glad, as a C++ programmer, to be adding Python to my toolbox -- I don't
| see any reason to disparage C++ as Paul did. I agree that C++ is not the
| language for everyone or for every project, but I feel a lot better as a C++
| and Python programmer than I would knowing only one of those languages.
That's a good perspective, and I don't think it's really so different
from what I read in the article. It's kind of hard to take an advocacy
position with an ``I'm OK, you're OK'' style, because we have to talk
about struggling against inertia and paths of least resistance to get
to a better place. If we're all in a fine place now, what's the point?
These popular technologies need to be knocked hard! But it doesn't
mean that as individuals or institutions we're morally flawed if we
learn to use them effectively, or worse yet enjoy it. I can profit
from it, but just I can't say therefore it's good enough to be the
core technology for computing for the indefinite future. That's where
advocacy kicks in, and it's great to see it stated in such an articulate
way in such a prominent place.
Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu
Brett g Porter
"Donn Cave" <do...@u.washington.edu> wrote in message
news:89p2kd$1arc$1...@nntp6.u.washington.edu...
> Quoth "Brett g Porter" <BgPo...@NOacmSPAM.org>:
> ...
> from what I read in the article. It's kind of hard to take an advocacy
> position with an ``I'm OK, you're OK'' style, because we have to talk
> about struggling against inertia and paths of least resistance to get
> to a better place. If we're all in a fine place now, what's the point?
". C++ and Perl have no such excuse. They are cryptic and complex because of
an overemphasis on backwards compatibility and plain, old-fashioned poor
design. "
"Where languages like Basic, TCL, and Logo were artificially limiting, C++
and Perl are, in my opinion, artificially complex. Obviously there are many
smart people out there preparing to send me an email claiming that the
complexity "buys" them something valuable. I think that the cost is high. "
"Personally, I cannot stand this design aesthetic, because it divides the
world into "programmers" and "non-programmers"."
You'll have to forgive me, my academic training was as a composer, so that's
the pool I always dip into for analogies -- this argument strikes me as:
"Tape recorders are better than pianos because it's too darn hard to become
a good piano player. It divides the world into 'musicians' and
'non-musicians'. The piano suffers from an overemphasis on being backwardly
compatible with the clavichord."
Obviously, Paul is entitled to his view that the cost of proficiency in C++
is too high. As a proficient C++ programmer, I have to disagree. I can't
imagine writing industrial-strength apps solely in Python (and I do mean
industrial -- I've got applications running in steel mills).
I agree with all the slams against Perl, though. KILL!! KILL!!
Paul Prescod
>
> ...
>
> Each applications area has characteristics that make some languages
> "ideal", others "problematic", and sometimes even some of them
> "dangerous" to use.
It is my observation that over time these differences have moved more
and more from programming languages into their libraries. So it used to
be said that TCL was "good for user interfaces" and Perl is "good for
text processing" and COBOL was "good for business problems" but nowadays
every language is pretty good at GUIs thanks to stealing TK and every
language is good at text processing (not necessarily equally good, but
good nevertheless) since Perl regexps are ubiquitous and many business
programmers seem to use Java to good effect.
But here's my problem. It is very, very, very rare that I right a real
"computer program" that does not span "domains."
> And the same applies to developers: different people have different
> approaches to solving problems. Some languages will fit a particular
> person's temperament and abilities, and some won't.
The interesting thing is that I haven't yet met a person who gave Python
a solid try and then said it didn't fit their temperament or abilities.
If many of these people come out of the woodwork in the next few years
then I will have to admit I am wrong that Python is the embodiment of
CP4E.
Anyhow, let's say that there are people who naturally gravitate toward
Perl, others that naturally gravitate towards C++ and so forth. What
does that mean for maintainability of large software systems? Every
programmer chooses the language that they gravitate towards and then the
customer worries about the maintenance problem later? "We need a
C++/Java/Lisp programmer to fix up this system we've bought."
Let's say that you increase the LOC of a project by 20% using 2
languages instead of 6. Doesn't the reduced maintenance burden offset
the additional coding time (if any)?
> A "Perl-vs-C-vs-Python-vs-APL-vs..." argument is equivalent one about
> "hacksaw-vs-screwdriver-vs-scalpel-vs-tweezers": it may have some
> amusement value, but any real-world benefits are an accidental
> by-product.
In my opinion that is not true. My life is measurably better now that
potential employers as me about my skill with Java instead of my skill
with C++. My job is clearly more enjoyable when I can think about my
business problems instead of the interaction of C++ pure virtual
functions and base class constructor execution.
So while I may not know anything about the world outside my head, I know
that C++ and Perl programming gives me a headache and I have been forced
to do both in the last year (even together...on Windows). Therefore from
a purely selfish point of view, pro-Python evangelism is enlightened
self-interest!
To some extent, though, you are right. My meagre efforts at evangelism
are not that important beside the evolutionary processes that drive
technology adoption. My personal opinion is that simplicity drives out
complexity naturally so it is only a matter of time before the ugly
programming languages go away. :)
Ivan Van Laningham
Brett g Porter wrote:
>
[bobbit]
> Obviously, Paul is entitled to his view that the cost of proficiency in C++
> is too high. As a proficient C++ programmer, I have to disagree. I can't
> imagine writing industrial-strength apps solely in Python (and I do mean
> industrial -- I've got applications running in steel mills).
>
> I agree with all the slams against Perl, though. KILL!! KILL!!
>
"Worst case of testosterone poisoning I've ever seen."
--Commander Ivanova, Babylon 5
<yeah-but-the-good-guys-still-won>-ly y'rs,
Ivan;-)
----------------------------------------------
Ivan Van Laningham
Callware Technologies, Inc.
http://www.pauahtun.org
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours
Fredrik Lundh
> Obviously, Paul is entitled to his view that the cost of proficiency in
C++
> is too high. As a proficient C++ programmer, I have to disagree. I can't
what if Python would grow a type system?
and an industrial-strength compiler, on top of that?
is there *anything* you can do in C++ that you
couldn't express in a typed version of Python?
</F>
Brett g Porter
"Fredrik Lundh" <eff...@telia.com> wrote in message
news:VNVv4.40$y3.187...@newsb.telia.net...
At this point I'm still biased by 10 years of C / 5 years of C++ as opposed
to ~1 year of Python. I'd certainly like to give it a try. I'd be happier
right now if I had a tighter/more transparent Python->C++->Python connection
If I could generate the same quality of code in Python, and had the same
caliber of development/debugging tools, maybe.
Emile van Sebille
Emile van Sebille
em...@fenx.com
-------------------
----- Original Message -----
From: Fredrik Lundh <eff...@telia.com>
Newsgroups: comp.lang.python
To: <pytho...@python.org>
Sent: Friday, March 03, 2000 1:04 PM
Subject: Re: Python advocacy
> Brett g Porter wrote:
> > Obviously, Paul is entitled to his view that the cost of proficiency
in
> C++
> > is too high. As a proficient C++ programmer, I have to disagree. I
can't
> > imagine writing industrial-strength apps solely in Python.
>
> what if Python would grow a type system?
>
> and an industrial-strength compiler, on top of that?
>
> is there *anything* you can do in C++ that you
> couldn't express in a typed version of Python?
>
> </F>
>
>
> --
> http://www.python.org/mailman/listinfo/python-list
>
>
Tim Peters
> Obviously, Paul is entitled to his view that the cost of proficiency in
> C++ is too high. As a proficient C++ programmer, I have to disagree. I
> can't imagine writing industrial-strength apps solely in Python.
[Fredrik Lundh]
> what if Python would grow a type system?
>
> and an industrial-strength compiler, on top of that?
>
> is there *anything* you can do in C++ that you
> couldn't express in a typed version of Python?
Hmm. At work this week, I defined a C++ class whose instances occupy
exactly one byte (& would be useless if they occupied more), and had some
methods whose bodies consisted of inline assembler #ifdef'ed for various
platforms. C++ was perfect for this low-level grunge, while Python is about
as far from being suitable as I can imagine. Ask me whether I care <wink>.
just-hoping-to-*invoke*-this-class-web-via-python-ly y'rs - tim
John Nielsen
You'll find lots of comments there. (You'll probably have to go back a
day to when it was posted).
I am a reasonably long time perl programmer, whose found lots of fun
w/python.
I've written virtually identical code in both systems (using some
complicated data structures) and I was impressed that (being less
experienced w/python), I could pretty much write it w/out reviewing the
python documentation.
It helped that I had already written it in perl first, but I was still
impressed, that as a newcomer to python, I could just spit out the code.
I don't think the other way around would have been true (writing it in
python first, then just spit out the perl code).
Tom Christiansen posted an excellent comparison of perl and python back
in august. And, he has some criticisms that are worth looking at.
john
In article <38BF1990...@prescod.net>,
Paul Prescod <pa...@prescod.net> wrote:
> Don Tuttle wrote:
> >
> > ...
> > I bow before man with big, big gonads! You very brave man, Paulsan.
>
> Well, thus far all response has been positive! Obviously I stacked the
> deck by alerting comp.lang.py'ers about the article but Perl-mongering
> flamers have been conspicuously absent. Obviously some large majority
> are going to be mature about it and some other percentage indifferent.
> I'm just surprised not to hear from the lunatic fringe. I'll hasten to
> add that every community has a lunatic fringe -- Perlers are probably
no
> worse than anyone else.
>
> Of course the most vicious flamers probably hang out together
somewhere
> other than the O'Reilly web site...
>
> > End
> > article with "You can respond to Paul at py...@prescod.net " You
write
> > wonderful article.
>
> pyguy is an alias set up specifically for that article so that I can
> redirect flamage to my "read this on a rainy day" folder.
>
> --
> Paul Prescod - ISOGEN Consulting Engineer speaking for himself
> "We still do not know why mathematics is true and whether it is
> certain. But we know what we do not know in an immeasurably richer way
> than we did. And learning this has been a remarkable achievement,
> among the greatest and least known of the modern era."
> - from "Advent of the Algorithm" David Berlinski
> http://www.opengroup.com/mabooks/015/0151003386.shtml
>
>
--
niel...@my-Deja.com
Sent via Deja.com http://www.deja.com/
Before you buy.
Bijan Parsia
> Paul Prescod <pa...@prescod.net> wrote in message
> news:38BEE429...@prescod.net...
> > O'Reilly asked to publish something I had written for my homepage about
> > Python.
> >
> >
> > I'm somewhat nervous about the flamage I'll get, but c'est la vie.
>
> I bow before man with big, big gonads!
[snip]
I'm afraid you're mistaken, since only last month I ran Paul through a
gonad reduction program...
They-don't-call-it-*Small*talk-for-nothing-ly y'rs,
Bijan Parsia
P.S. With apologies to Paul. And his gonands, of course, but I do
presume that they're, er, "man enough" to take a joke ;)
P.P.S. Please notice my manfully refraining from commenting on Paul's
comments on Smaltalk in that article. Especially since they were, to a
quibbler like myself, not *exactly* correct. But hey, it's an advocacy
piece. And he certainly did try to be nice :)
P.P.P.S. I notice that my newsreader (the very fine MacSoup) will
complain if my sig's too large or I have to much quoted material, but
cares not a whit if most of my article is in the P.S.s!
P.P.P.P.S It was certainly a much better article than that wretched Ruby
one, though I do detect a slight tension between these quotes:
"C++ and Perl only make sense if you have a particular
programming background"
and
"Python merges many of Smalltalk's ideas with a syntax that is
more likely to appeal to C, C++ and Java programmers".
I rather suspect it appeals more to Pascal and Modula-2 programmers :)
And poor Dylan, which sold it's soul to mixfix only to be doomed to
obscurity, in the general world, and scorn from its progeniters.
Quinn Dunkan
>And poor Dylan, which sold it's soul to mixfix only to be doomed to
>obscurity, in the general world, and scorn from its progeniters.
I don't quite understand... gwydion dylan seems to be moving along, and
ex-harlequin dylan enjoys a company (functional objects) focused around its
improvement. Guess it would help if I knew what mixfix was...
Martijn Faassen
[snip]
> "Python merges many of Smalltalk's ideas with a syntax that is
> more likely to appeal to C, C++ and Java programmers".
> I rather suspect it appeals more to Pascal and Modula-2 programmers :)
> obscurity, in the general world, and scorn from its progeniters.
I don't know -- I always preferred C and C++ to Pascal (and Object Pascal
in Delphi). I don't know Modula-2 or Dylan and only have passing familiarity
with Java (the syntax's like C++ anyway). And I like Python's syntax a lot.
That's just a single case in point, I may be just weird. :)
No-I-*am*-just-weird-ly yours,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Neel Krishnaswami
> On Sat, 4 Mar 2000 00:37:06 -0500, Bijan Parsia <bpa...@email.unc.edu>
> wrote:
> >obscurity, in the general world, and scorn from its progeniters.
>
> and ex-harlequin dylan enjoys a company (functional objects) focused
> around its improvement.
I'm having fun with Dylan, at any rate, and expect to continue using
it for a long time to come.
> Guess it would help if I knew what mixfix was...
Not really; he just means Algolish (Algolic? Algolaceous?) syntax,
like so:
define method fact(n :: <integer>) => (result :: <integer>)
if (n = 0)
1
else
n * fact(n - 1)
end if;
end method fact;
rather than Lispy fully-parenthesized syntax.
Neel
Patrick Phalen
:: Quinn Dunkan <qu...@mono.ugcs.caltech.edu> wrote:
:: > On Sat, 4 Mar 2000 00:37:06 -0500, Bijan Parsia <bpa...@email.unc.edu>
:: > wrote:
:: > >And poor Dylan, which sold it's soul to mixfix only to be doomed to
:: > >obscurity, in the general world, and scorn from its progeniters.
:: > Guess it would help if I knew what mixfix was...
::
:: Not really; he just means Algolish (Algolic? Algolaceous?) syntax,
I think he's referring to Dylan Thomas, who was a hopeless Algolholic
and cooC addict, who was known to mix his fixes.
Andrew Dalke
> I think he's referring to Dylan Thomas, who was a
> hopeless Algolholic and cooC addict, who was known
> to mix his fixes.
When you say "Dylan".
Thinks you're talking 'bout
Dylan Thomas, whoever he was.
Tha man ain't got no culture.
- Simon & Garfunkel
Andrew
da...@acm.org
Andrew Dalke
>is there *anything* you can do in C++ that you
>couldn't express in a typed version of Python?
My usual example - object allocation into a specific
shared memory arena. C++ lets me create objects in
a given space on a per-object basis. This is handy
when you want to share the data amoung different
processors. It was little more than derive a new
class with the new allocator, and put a few mutexes
so the client tasks wait for updates.
That's something I've need, oh, once every five years,
so I mostly stick with Python :)
Andrew Dalke
da...@acm.org
Ran
> It is my observation that over time these differences have moved more
> and more from programming languages into their libraries.
But your observation is based on the applications areas you work in. My
observations are very different, because I work primarily on embedded
systems for 8-bit (and occasionally 16-bit) processors. So I see *huge*
differences among problem domains on a daily basis, as I split my time
among firmware, production-level support apps on the desktop, and
development tools. And many of those differences are not the sort that
can be reduced by hanging a new library on the run-time.
> The interesting thing is that I haven't yet met a person who gave Python
> a solid try and then said it didn't fit their temperament or abilities.
You're asking the wrong people: you need to talk to the ones who have
to use/maintain their code ;-) I've known several programmers who
would have to be shot for the protection of their customers if we didn't
have tools like lint and compilers with strict type-checking.
> Anyhow, let's say that there are people who naturally gravitate toward
> Perl, others that naturally gravitate towards C++ and so forth. What
> does that mean for maintainability of large software systems?
About as much as the fact that some people gravitate toward tweezers,
and some toward welding torches, does about the maintainability of
bulldozers and Swiss watches. You staff the project with people with
the talents and experience appropriate to the job, and let the others
find a different niche, where they can work well.
> Every
> programmer chooses the language that they gravitate towards and then the
> customer worries about the maintenance problem later?
No, the project manager chooses the language(s) according to the needs
of the project and the availability of programmers and other resources.
> Let's say that you increase the LOC of a project by 20% using 2
> languages instead of 6. Doesn't the reduced maintenance burden offset
> the additional coding time (if any)?
Much of the time? Yes. In most cases? Probably. In all cases? No.
Sometimes, it won't even reduce the maintenance burden. Which is not
the only life-cycle cost that starts accumulating after shipment:
execution efficiency is likely to be a significant factor for most
systems other than single-user workstations.
> To some extent, though, you are right.
Of course I am ;-) But not because I said that "[Your] meagre efforts
at evangelism
are not that important". Because they are: the ongoing arguments about
what makes tools "decent" (to use your term) are the biggest forces
driving those "evolutionary processes".
The reason I'm right is that I said there won't be any *single*
"survivor" of the evolutionary struggle, and that the efforts to crown
one's favorite as such are just so much noise. The software ecosystem
of the foreseeable future will always have its own form of "diversity":
there will be lions *and* elephants *and* fish *and* seals *and* birds,
because there will be many diverse "habitats" where the particular
adaptations of each will be needed/advantageous.
The reasoned debates (as opposed to religious wars) may lead to lions
with opposable thumbs, or elephants that can see in the infrared, but
there will never be a 2000-pound fish with a mane and wings. Well, not
outside the lab, anyway.
> My personal opinion is that simplicity drives out
> complexity naturally
Ah, but *whose* "simplicity"? The end user's? The programmer's? The
compiler writer's? The executing CPU's? Each has his/her/its own idea
of what's "simple", and you can't maximize all of them at once.
"Complexity" seems to be a lot like "energy": you can *transfer* it
from the end user to one/some of the other players, but the total
amount seems to remain pretty much constant for a given task.
> so it is only a matter of time before the ugly
> programming languages go away. :)
Does the name "COBOL" ring a bell? Don't hold your breath ;-)
Ran
Don Tuttle
> No, the project manager chooses the language(s) according to the needs
> of the project and the availability of programmers and other resources.
I have never programmed for a living. (I enjoy it way too much to ever do
that! <wink 0.5>) So let me ask all you folks that do. What percentage of
your paid, professional time do you get to use Python?
Don
Don Tuttle
Bijan Parsia
> [Neel Krishnaswami, on Sat, 04 Mar 2000]
> :: Quinn Dunkan <qu...@mono.ugcs.caltech.edu> wrote:
> :: > On Sat, 4 Mar 2000 00:37:06 -0500, Bijan Parsia <bpa...@email.unc.edu>
> :: > wrote:
> :: > >And poor Dylan, which sold it's soul to mixfix only to be doomed to
> :: > >obscurity, in the general world, and scorn from its progeniters.
> ::
> :: > Guess it would help if I knew what mixfix was...
> ::
> :: Not really; he just means Algolish (Algolic? Algolaceous?) syntax,
>
> I think he's referring to Dylan Thomas, who was a hopeless Algolholic
> and cooC addict, who was known to mix his fixes.
This is about the funniest, cleverest thing I've read in at least a
week. I was dying!
(To add some content: My Dylan "slam" was a joke. Dylan started out with
a Lispy syntax (and if you want a Lispy Dylanish thing, try RScheme) but
then converted to a Pascalish one as a marketing move akin to how Paul
described Python in relation to Smalltalk (and if you can parse *that*,
you'll have no trouble with mere Dylan syntax ;)). Thereupon, a slew of
Lispy Dylan folks cried "Herasy herasy" and went back to mucking with
Common Lisp :) Dylan seems to have survived Harliquin's sale, although
it's still a bit too soon to tell. Apple's dumping of it, however, did
kill it's best shot at a building a substantial constituacy it's had,
and, as far as I can see, will have for quite a while. However, it's a
pretty darn nifty langauge, and I rather suspect that most Pythoners
might find it a bit more congenial than Common Lisp.)
Cheers,
Bijan Parsia.
Bijan Parsia
> Bijan Parsia <bpa...@email.unc.edu> wrote:
> [snip]
> > "Python merges many of Smalltalk's ideas with a syntax that is
> > more likely to appeal to C, C++ and Java programmers".
> > I rather suspect it appeals more to Pascal and Modula-2 programmers :)
> > And poor Dylan, which sold it's soul to mixfix only to be doomed to
> > obscurity, in the general world, and scorn from its progeniters.
>
> I don't know -- I always preferred C and C++ to Pascal (and Object Pascal
> in Delphi). I don't know Modula-2 or Dylan and only have passing familiarity
> with Java (the syntax's like C++ anyway). And I like Python's syntax a lot.
Ah! But would you have liked it more if you had always prefered Pascal
*et al* to C and C++? *That* is the question! ;)
I love counterfactuals!
> That's just a single case in point, I may be just weird. :)
You sound quite sensible to me. But, some might think, that *is* rather
wierd ;)
> No-I-*am*-just-weird-ly yours,
But-perhaps-not-weird-enough-ly y'rs,
Bijan Parsia.
Paul Prescod
>
> ...
>
> "Tape recorders are better than pianos because it's too darn hard to become
> a good piano player. It divides the world into 'musicians' and
> 'non-musicians'. The piano suffers from an overemphasis on being backwardly
> compatible with the clavichord."
The argument is totally different because a piano *does something
different* from a tape recorder. Here goes my rant:
Ten years ago many argued that C++ was too damn complex. The industry
was told that this was necessary for large, complex systems. So we put
in the effort and became proficient in all of that pure virtual array
destructor crap. Garbage collection? That could never fly in a language
for mission critical applications! Then along comes Java. It has 30% of
the weirdo complexity and yet the same people are now building the same
big, complex systems in Java. Billion dollar valuations are being built
on top of Java code.
One of the exciting (and frightening) things about Java is that Sun says
it can be used for everything. Embedded systems and million dollar
payroll systems alike. Telecoms and multimedia. The Full Monty. That's
frightening because it isn't my favorite language.
It is exciting because it breaks the historic pattern where language
designers excuse flaws in their language by saying "go use some other
language that's more suited to that." That kind of thinking gave us
"shell scripting" languages, TCL and other monstrosities. No language
can ever be perfect but language communities can address the limitations
of their language as limitations instead of labelling them as
"features".
I've actually been told that it is a feature of TCL that it is
inefficient because that helps you to know when to switch to C. TCL is
hard to scale because it is poorly designed, not because TCL people,
given an honest choice, would choose it be that way. Unfortunately we
are seldom presented with an honest choice. Things are the way they are
and we presume that there are fundamental reasons for that.
Then a language like Python comes along which subsumes the abilities of
(at least) TCL, Perl, Visual Basic and ten thousand macro languages. It
is my assertion that there are no large, complex problems that can be
solved more easily in any of those languages than in Python with a
suitable library and (in the case of VB) development environment.
Obviously the smaller the problem, the more likely it is to be solved in
one line by one language or another. But our software engineering
backlog is not made up of one-line problems so they should not be
choosing our programming languages for us. Yes, you can use sh and VBA
for tiny little programs but isn't it just one damn more thing to learn?
Is it worth learning another language to reduce a 10 line program into
1?
Given that Python offers us an opportunity to avoid the code
fragmentation caused by all of these little fragmented language
communities (Perl for text processing, TCL for Unix GUIs, VB for Windows
GUIs, other Basic variants for macros), it is only natural to ask if it
can also swallow the huge category of tasks being done with Java (we'll
leave C and FORTRAN alone for now...). If Sun succeeds in making Java
popular for everything from embedded computing to supercomputing then
there will be only one language for Python to replace. Bring it on!
Well, a Java evangelist would tell us two things, which may both turn
out to be myths:
1. that the one complex feature we still cannot profitably strip out is
type safety -- if we strip that out we won't be able to build big,
complex systems (sound familiar?) or at least efficient systems
2. that there is no good way to introduce this feature into an
erstwhile dynamically typed language
I am told by those in the know that Common Lisp disproves both of these
assertions. You can get fast code and complex systems from a language
with an optional "add-later" type declaration system. In fact, people
write large, complex systems in competely dynamic Lisps, Smalltalks and
low and behold, Python. The people writing the largest systems seem the
least inclined to argue that the lack of a static type system is
limiting them.
It is debatably the case that static type checking systems help people
to write code that scales to large systems. It is indisputably clear
that it can help the readability of the code. It is relatively clear
that it also helps the performance without massively complicating the
implementation. That's why Python is likely to eventually grow a static
type system. Then we can shove another sock in mouth of the apologists
for languages that are not good at one thing or another.
Can there be one language that does everything? Everything? Possibly
not, but it is better to presume so and fight to get there than to
presume not and live with languages that force us to shift from one to
the next because of designed-in limitations.
A cure for cancer in our lifetimes? Certainly not if we start with the
presumption that it cannot be done.
> Obviously, Paul is entitled to his view that the cost of proficiency in C++
> is too high. As a proficient C++ programmer, I have to disagree. I can't
> imagine writing industrial-strength apps solely in Python (and I do mean
> industrial -- I've got applications running in steel mills).
To be honest with you, if I was required to write an application that
was going to run in a steel mill, and I was not constrained by memory or
CPU (which you often would be) then I would choose a dynamically typed
language with automatic memory management and pointer safety over a
statically typed language without, any day. Tbe safe I would probably
use a language like Java or Eiffel with both, just to be safe.
Seriously, where reliability is an issue, C++ would be at the bottom of
my list. Dr. Watson's frequent appearance on Windows NT desktops is a
testament to C++'s reliability.
> I agree with all the slams against Perl, though. KILL!! KILL!!
The-enemy-of-my-enemy-ly 'yrs Paul
Paul Prescod
>
> Hmm. At work this week, I defined a C++ class whose instances occupy
> exactly one byte (& would be useless if they occupied more), and had some
> methods whose bodies consisted of inline assembler #ifdef'ed for various
> platforms. C++ was perfect for this low-level grunge, while Python is about
> as far from being suitable as I can imagine. Ask me whether I care <wink>.
Well, in a C++-less world, you would just make a C struct whose
instances occupy exactly one byte and have some functions (perhaps
referred to by function pointers) with inline assembler. Note that I am
not insane enough (yet <0.25 wink>) to suggest that Python replace C.
I think that there is a place in the universe for C with objects and for
a while it sounded like ANSI C 200x was tending in that direction but I
haven't followed closely. It is just C with objects and exceptions and
overloading and Turing-complete templates and multiple inheritance and
weird interactions between every feature that I object to.
I feel with C++ as I do with Perl, that there is a nice little language
screaming to get out, but if it were possible to get agreement on what
the nice little language was, the gross hairball would never have come
about.
Paul Prescod
>
> P.P.S. Please notice my manfully refraining from commenting on Paul's
> comments on Smaltalk in that article.
No, go ahead. I might as well get it right for subsequent discussions.
> Especially since they were, to a
> quibbler like myself, not *exactly* correct. But hey, it's an advocacy
> piece. And he certainly did try to be nice :)
That's right. I didn't advance any theories about reasons for Lisp and
Smalltalk's status.
> P.P.P.P.S It was certainly a much better article than that wretched Ruby
> one, though I do detect a slight tension between these quotes:
> "C++ and Perl only make sense if you have a particular
> programming background"
> and
> "Python merges many of Smalltalk's ideas with a syntax that is
> more likely to appeal to C, C++ and Java programmers".
Very slight. :) Python is close enough to be recognizable and far enough
to dump all of the weird stuff. C++ and Perl didn't have the good sense
to dump junk. Java went a little farther into the C camp than Python
which explains why I have flame mail telling me that Java is "basically
the same as C++". The Java motto: Confuse 'em with familiar syntax!
> I rather suspect it appeals more to Pascal and Modula-2 programmers :)
Well that's the point. Everyone likes Python.
> And poor Dylan, which sold it's soul to mixfix only to be doomed to
> obscurity, in the general world, and scorn from its progeniters.
Syntax only counts once you get sufficiently far across the chasm that
mainstream programmers get a chance to evaluate it!
Paul Prescod
>
> But your observation is based on the applications areas you work in. My
> observations are very different, because I work primarily on embedded
> systems for 8-bit (and occasionally 16-bit) processors.
Well this is the most common example of a wildly divergent problem
domain. I've got a few comments from embedded programmers in my mailbox
(even though I excluded ANSI C from the languages I would like to
replace...).
But I think that a constraint imposed by hardware is different in kind,
not just degree, from logically different problem domains like:
"financial computing", "telecommunications", "web interfaces", "GUIs",
etc.
> You're asking the wrong people: you need to talk to the ones who have
> to use/maintain their code ;-) I've known several programmers who
> would have to be shot for the protection of their customers if we didn't
> have tools like lint and compilers with strict type-checking.
Do they make decent code just by turning on static type-checking? I find
it incredible to believe that these coders are so bad that they can't
survive without a type checker but they have no problem with pointer
safety.
> > Every
> > programmer chooses the language that they gravitate towards and then the
> > customer worries about the maintenance problem later?
>
> No, the project manager chooses the language(s) according to the needs
> of the project and the availability of programmers and other resources.
Agreed. But that is not the way it works. Programmers tell the project
manager what language they should use. Programmers gravitate towards
complexity until they get overwhelmed at which point they revert to
simplicitly (like art movements). It has almost nothing to do with which
language will get the job done.
> The reasoned debates (as opposed to religious wars) may lead to lions
> with opposable thumbs, or elephants that can see in the infrared, but
> there will never be a 2000-pound fish with a mane and wings. Well, not
> outside the lab, anyway.
No, there will never be a single language that everyone uses. There is
likely to be a "shakeout" in the next five years that will reduce the
number of languages greatly. I think that after the shakeout there will
be a single language in the VB/TCL/Perl/Python space. It would be better
for everyone (other than the winner's) pride if it was a language that
didn't exist today but only a large shift in the computing environment
could allow a new language to arise and become popular.
> Ah, but *whose* "simplicity"? The end user's? The programmer's? The
> compiler writer's? The executing CPU's?
The programmer's. But, really, the languages I disparaged in the article
do not simplify any of the above. When I worked at a C++ compiler
vendor, we had a special "airline sickness bag" on the wall for when we
recognized another hoop that C++ forced us to jump through.
> Each has his/her/its own idea
> of what's "simple", and you can't maximize all of them at once.
> "Complexity" seems to be a lot like "energy": you can *transfer* it
> from the end user to one/some of the other players, but the total
> amount seems to remain pretty much constant for a given task.
No, Perl and C++ are harder to implement and also to use. The CPU
doesn't find them particularly "simple" and the end user doesn't care.
If we were comparing C and Python then your argument would be more
interesting.
Bijan Parsia
[snip]
> I am told by those in the know that Common Lisp disproves both of these
> assertions. You can get fast code and complex systems from a language
> with an optional "add-later" type declaration system.
This is very true. CMUCL and other systems have outperformed optimized C
code for certain numerical programs. Stalin, a highly optimizing, "whole
world" (a la Vyper) scheme compiler regular produced faster than C code
(for not crappy C, mind!).
There was an interesting discussion (I think on comp.lang.lisp) on
compiling to C. A Common Lisp implementer pointed out that on...Sparc
chips?...at the time, there were some powerful instructions and
instruction sequences that simply weren't usuable by C compilers. This
was an argument for generating native code directly.
One other general point is that systems like Smalltalk heavily optimize
message sends. So they permit/encourage a style where small methods,
forwarding messages, wrapping methods, etc. Similarly with classes,
which are easy and cheap to generate. Big systems tend to do better when
you can avail yourself of these sorts of abstraction techniques, and
langauges like C++ make it, in general, hard to use these with
reasonable performance (witness the problems lots of compilers had/have
with templates).
> In fact, people
> write large, complex systems in competely dynamic Lisps, Smalltalks and
> low and behold, Python. The people writing the largest systems seem the
> least inclined to argue that the lack of a static type system is
> limiting them.
Yep and this has *always* been true, afaict. Or perhaps, true more in
the past :)
> It is debatably the case that static type checking systems help people
> to write code that scales to large systems. It is indisputably clear
> that it can help the readability of the code.
Actually, we just recently disputed this quite vigorously in
comp.lang.smalltalk :) We had quite the war with some static functional
types from comp.lang.functional.
I'll make the point that those folks (well, and that I make when wearing
my functional hat): The most commonly used static typing systems are
brutally horrendous and almost completely broken. The ones in modern
functional langauges especially with good type inferencing systems are
*much* nicer.
(Actually, I think the langauge to watch is Mercury, which let's you
declare *all sorts* of stuff including mode, determinism, and so on.
Rather efficient too. And strictly declarative.)
> It is relatively clear
> that it also helps the performance without massively complicating the
> implementation.
This is the biggest, IMHO, but there typically *loads* of room for
optimization before you get there. The difference between Squeak and
VisualWorks (perhaps the fastest current Smalltalk) is perhaps an order
of magnitude, or close to it, but VisualWorks has *no* type declarations
(built in) and none of the add-on type inferencers were used for
performance. Granted, the VisualWorks compiler/VM are *somewhat*
complex, but not insanely so. The Squeak JIT in the works looks to
increase Squeaks performance by 2-3x, and it's *very* straightforward.
(And Squeak's current vm beats CPython 1.5 by, from what I've read, 2x
or so.) None of this requires heroic efforts or compromizing simplicity
of implementation (indeed, that's one of the design constraints on the
Squeak VM, along with portability).
Folks interested in these issues should really take a peek at the 1999
OOPSLA workshop on VMs:
http://www.squeak.org/oopsla99_vmworkshop/
I'll also point out that Self/Hotspot dynamic optimization based on
runtime profiling can get a lot of the speed with *no* actual type
declarations. Oberon has the basis of something like this in it's "slim
binaries", but, AFAIK, it's never been fully implemented.
Of course, some declarations + inferencing is probably easier to
implement. Especially if you want to e.g., compile to C.
[snip]
> Can there be one language that does everything? Everything? Possibly
> not, but it is better to presume so and fight to get there than to
> presume not and live with languages that force us to shift from one to
> the next because of designed-in limitations.
Of course, there are social issues, too. Tastes vary! But certainly I
think the default,
I'm-probably-going-to-be-stuck-programming-with-this-at-some-point,
all-the-jobs-require-this language could be *much* better than the
current ones. An XML of programming langauges (better than HTML with
it's goofy idiosyncracies and severe limitations, but more regualar than
SGML, though sharing in a lot of the benefits, including toolsets and
design strategies). Hmm. I like that analogy. I freely donate the title,
"An XML of programming lagnauges". ;)
Cheers,
Bijan Parsia.
Vetle Roeim
[ Paul rants about Java and C++ ;) ]
* Paul Prescod
> I've actually been told that it is a feature of TCL that it is
> inefficient because that helps you to know when to switch to C. TCL is
> hard to scale because it is poorly designed, not because TCL people,
> given an honest choice, would choose it be that way. Unfortunately we
> are seldom presented with an honest choice. Things are the way they are
> and we presume that there are fundamental reasons for that.
Although I dislike Tcl, I believe it was not designed to scale. Try
reading ``The Tcl War'' <url:http://www.vanderburg.org/Tcl/war/>.
Basically, RMS complained about the limitations of Tcl, and various
people flame him and each other. But Osterhout explains the design
principles of Tcl.
vr
Fredrik Lundh
> Although I dislike Tcl, I believe it was not designed to scale. Try
> reading ``The Tcl War'' <url:http://www.vanderburg.org/Tcl/war/>.
> Basically, RMS complained about the limitations of Tcl, and various
> people flame him and each other. But Osterhout explains the design
> principles of Tcl.
according to his company, Tcl is the *only* scripting language
"suitable for large server applications and other mission-critical
enterprise uses".
guess Python's not really a scripting language ;-)
</F>
Vetle Roeim
> Vetle Roeim <vet...@ifi.uio.no> wrote:
> > Although I dislike Tcl, I believe it was not designed to scale. Try
> > reading ``The Tcl War'' <url:http://www.vanderburg.org/Tcl/war/>.
> > Basically, RMS complained about the limitations of Tcl, and various
> > people flame him and each other. But Osterhout explains the design
> > principles of Tcl.
>
> according to his company, Tcl is the *only* scripting language
> "suitable for large server applications and other mission-critical
> enterprise uses".
yes.. well.. that's another story. I guess Tcl is used for things it
initially was not ment to be used for.
> guess Python's not really a scripting language ;-)
well.. what else should they say? perhaps something like this :
"Tcl is the only scripting language suitable for large server
applications and other mission-critical enterprise uses, if you
only count the languages that were not initially designed for
these tasks."
that would not be very smart ;-)
python-is-the-only-scripting-language-suitable-for-large-server-applications
-and-other-mission-critical-enterprise-uses-<wink>-ly y'rs, vr
Andrew M. Kuchling
> No, there will never be a single language that everyone uses. There is
> likely to be a "shakeout" in the next five years that will reduce the
> number of languages greatly. I think that after the shakeout there will
> be a single language in the VB/TCL/Perl/Python space. It would be better
Really? I'm very doubtful of such claims, because the world of
computing is so large. Languages may be hyped, and they may
alternately become hot and cold, but it takes a terribly long time for
a language to die: so much code to rewrite, so many systems to replace.
(This is why I think the Ruby people are being too grandiose in their
claims. If Python and Perl haven't killed off Tcl, and Java hasn't
killed off Python and Perl, it's unlikely that Ruby is going to manage
any of those feats. Ruby certainly can form a healthy community of
its own and prosper alongside these other languages, of course.)
--
A.M. Kuchling http://starship.python.net/crew/amk/
The Internet uses a form of time-sharing. It may not be as fast as you would
like, but it's time sharing. Demons may work the same way.
-- From the Demon Possession Handbook
(http://www.gelservices.com/part1.html)
Brian
> reading ``The Tcl War'' <url:http://www.vanderburg.org/Tcl/war/>.
> Basically, RMS complained about the limitations of Tcl, and various
> people flame him and each other. But Osterhout explains the design
> principles of Tcl.
To be fair, the "Tcl War" thread is REALLY old and Tcl has advanced rapidly
since then and has addressed pretty much all of it's early shortcomings. It
is now up to version 8.3 and supports Unicode, advanced regular expressions,
OOP, bytecode compilation, complex GUI's etc. You can find more recent
information here: http://dev.scriptics.com/advocacy/
"Vetle Roeim" <vet...@ifi.uio.no> wrote in message
news:yay8zzv...@ganglot.ifi.uio.no...
>
> [ Paul rants about Java and C++ ;) ]
>
> * Paul Prescod
> > I've actually been told that it is a feature of TCL that it is
> > inefficient because that helps you to know when to switch to C. TCL is
> > hard to scale because it is poorly designed, not because TCL people,
> > given an honest choice, would choose it be that way. Unfortunately we
> > are seldom presented with an honest choice. Things are the way they are
> > and we presume that there are fundamental reasons for that.
>
> Although I dislike Tcl, I believe it was not designed to scale. Try
> reading ``The Tcl War'' <url:http://www.vanderburg.org/Tcl/war/>.
> Basically, RMS complained about the limitations of Tcl, and various
> people flame him and each other. But Osterhout explains the design
> principles of Tcl.
>
>
> vr
Donn Cave
|>> reading ``The Tcl War'' <url:http://www.vanderburg.org/Tcl/war/>.
|>> Basically, RMS complained about the limitations of Tcl, and various
|>> people flame him and each other. But Osterhout explains the design
|>> principles of Tcl.
|>
|> "suitable for large server applications and other mission-critical
|> enterprise uses".
| well.. what else should they say? perhaps something like this :
|
| "Tcl is the only scripting language suitable for large server
| applications and other mission-critical enterprise uses, if you
| only count the languages that were not initially designed for
| these tasks."
|
| that would not be very smart ;-)
Maybe a clarification of the term ``scripting language'' would be
in order. That's one way to get to a place where I'd agree with
the claim /F quotes above. I can think of a lot of languages I'd
rather use for large applications, but they're not what I think of
as scripting languages (e.g., Python), while Tcl sure is.
That has been my complaint about Osterhout's rhetoric on the subject,
he confuses the issue by touting the real utility of [real] scripting
and his really quite nice scripting language, and then claims a lot
of territory he hasn't conquered by equating interpreted with scripting.
The idea that Python can or should replace these scripting languages
is equally dubious in my opinion. Replace the UNIX shell with Python?
Ha, ha ha! Or Scheme, as RMS wanted. As stone-age primitive and
limited as it may be, the shell is a really natural interface to its
problem domain, where a higher but more general purpose language has
a lot of rarely necessary power to offer in return for vastly more
awkward notation in everyday use. The shell is the one I'm familiar
with, I'm sure there are plenty of other examples in other problem
domains. I think Python stands a much better chance of growing the
muscles to compete with C++ and Java, than the flexibility to compete
with scripting languages.
Donn Cave, do...@u.washington.edu
Cameron Laird
Paul Prescod <pa...@prescod.net> wrote:
.
[Maybe Java can be
used for everything;
in any case, Tcl is
crap]
.
.
>Then a language like Python comes along which subsumes the abilities of
>(at least) TCL, Perl, Visual Basic and ten thousand macro languages. It
>is my assertion that there are no large, complex problems that can be
>solved more easily in any of those languages than in Python with a
>suitable library and (in the case of VB) development environment.
.
.
>choosing our programming languages for us. Yes, you can use sh and VBA
>for tiny little programs but isn't it just one damn more thing to learn?
>Is it worth learning another language to reduce a 10 line program into
>1?
>
>Given that Python offers us an opportunity to avoid the code
>fragmentation caused by all of these little fragmented language
>communities (Perl for text processing, TCL for Unix GUIs, VB for Windows
>GUIs, other Basic variants for macros), it is only natural to ask if it
>can also swallow the huge category of tasks being done with Java (we'll
>leave C and FORTRAN alone for now...). If Sun succeeds in making Java
.
.
> 1. that the one complex feature we still cannot profitably strip out is
>type safety -- if we strip that out we won't be able to build big,
>complex systems (sound familiar?) or at least efficient systems
>
> 2. that there is no good way to introduce this feature into an
>erstwhile dynamically typed language
>
>I am told by those in the know that Common Lisp disproves both of these
>assertions. You can get fast code and complex systems from a language
>with an optional "add-later" type declaration system. In fact, people
>write large, complex systems in competely dynamic Lisps, Smalltalks and
>low and behold, Python. The people writing the largest systems seem the
>least inclined to argue that the lack of a static type system is
>limiting them.
>
>It is debatably the case that static type checking systems help people
>to write code that scales to large systems. It is indisputably clear
>that it can help the readability of the code. It is relatively clear
>that it also helps the performance without massively complicating the
>implementation. That's why Python is likely to eventually grow a static
>type system. Then we can shove another sock in mouth of the apologists
>for languages that are not good at one thing or another.
>
>Can there be one language that does everything? Everything? Possibly
.
.
>> Obviously, Paul is entitled to his view that the cost of proficiency in C++
>> is too high. As a proficient C++ programmer, I have to disagree. I can't
>> imagine writing industrial-strength apps solely in Python (and I do mean
>> industrial -- I've got applications running in steel mills).
>
>To be honest with you, if I was required to write an application that
>was going to run in a steel mill, and I was not constrained by memory or
>CPU (which you often would be) then I would choose a dynamically typed
>language with automatic memory management and pointer safety over a
>statically typed language without, any day. Tbe safe I would probably
>use a language like Java or Eiffel with both, just to be safe.
>Seriously, where reliability is an issue, C++ would be at the bottom of
>my list. Dr. Watson's frequent appearance on Windows NT desktops is a
>testament to C++'s reliability.
.
.
Paul and I could happily go off in a corner and split hairs
for--well, for a long time. I disagree with several claims
about Tcl, Java, ...; those who truly care about the details
are welcome, as usual, to ask.
I'll decorate a few of his more central points, though:
1. Sun's not going to make Java a success. I
think Sun still intends that, but hasn't
the capacity.
IBM probably *will* make Java a success.
2. I have no idea whether Java will make it in
the embedded world. My current expectation
is that the project of porting Java every-
where's going to collapse in a sorry heap.
Maybe it'll work. I'm unconvinced.
3. Type safety is a tiny and essentially ir-
relevant part of what it really takes to
build big, complex systems. I know you
know this. It needs to be repeated.
4. Do NOT buy into the nonsense, even for a
moment, that C and C++ are "better supported
by tools". They *require* tools to compensate
for their burdens of memory management, ...
That's the whole story.
5. We're not far away from a time when people
will say, "Controlling a steel mill/submarine/
power plant/refinery/... with C++ codings?
Are you serious? That would be like, well,
like, driving a car without having the children
buckled into seat belts." Yup. We did it for
a lot of years. There's a much better way.
6. Complex systems never work, anyway.
7. Complex systems have a shot of working when
they're constructed from reliable parts. The
winning languages of the '90s were those that
played well with other technologies.
8. Ada and Eiffel: they're safe.
9. As much as Paul wants to do everything with one
language, I'm probably as strong on the other
side in looking for a way to accomodate lots of
different languages.
10. If I had to choose only one language, it would
definitely be Python. It's not really ready,
though, without Unicode ...
11. It's the libraries. Syntax--piffle!
I'm probably still better at C than anything else. I can
process signals and respond to external ports and maintain
complex data structures and so on without leaking memory or
violating array bounds or confusing argument lists. I'm an
anachronism, though. I might as well be knapping flints.
Industrial customers are better off with any of several
other languages, although they don't yet realize it.
My most important point: yes, we lose some benefits when
moving away from C and C++. With very few exceptions, those
are costs we can afford, in comparison with the greater
benefits brought by other modern languages. Don't get stuck
waiting for alternatives which are "perfect".
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Vetle Roeim
> > Although I dislike Tcl, I believe it was not designed to scale. Try
> > reading ``The Tcl War'' <url:http://www.vanderburg.org/Tcl/war/>.
> > Basically, RMS complained about the limitations of Tcl, and various
> > people flame him and each other. But Osterhout explains the design
> > principles of Tcl.
>
> since then and has addressed pretty much all of it's early shortcomings. It
> is now up to version 8.3 and supports Unicode, advanced regular expressions,
> OOP, bytecode compilation, complex GUI's etc. You can find more recent
> information here: http://dev.scriptics.com/advocacy/
as I understand many features are a little bit hackish (f.ex. OO), but
this may just be FUD I've heard.
vr
Grant Edwards
>> Although I dislike Tcl, I believe it was not designed to scale.
Agreed, but I don't spend my time on a crusade against it like
some people seemed to. I remember the original RMS vs. Tcl
thread many years (5?) ago...
>> Try reading ``The Tcl War''
>> <url:http://www.vanderburg.org/Tcl/war/>. Basically, RMS
>> complained about the limitations of Tcl, and various people
>> flame him and each other. But Osterhout explains the design
>> principles of Tcl.
>To be fair, the "Tcl War" thread is REALLY old and Tcl has
>advanced rapidly since then and has addressed pretty much all
>of it's early shortcomings. It is now up to version 8.3 and
>supports Unicode, advanced regular expressions, OOP, bytecode
>compilation, complex GUI's etc. You can find more recent
>information here: http://dev.scriptics.com/advocacy/
I gave up on Tcl years ago and switched to Scheme (and now
Python). The first time I tried to write a decent sized Tcl
app the lack of data structures and the quoting semantics both
made me bleed from the ears. Other people seem to manage
better than I. To each his own.
--
Grant Edwards grante Yow! I feel... JUGULAR...
at
visi.com
Fredrik Lundh
> 10. If I had to choose only one language, it would
> definitely be Python. It's not really ready,
> though, without Unicode ...
...which will appear in your favourite CVS repository any
day soon.
(do you think Scriptics will remove the Tcl vs. the world
comparision chart when we've added this? ;-)
</F>
Paul Prescod
>
> ...
>
> The idea that Python can or should replace these scripting languages
> is equally dubious in my opinion. Replace the UNIX shell with Python?
Not the interactive shell -- just the shell programming language.
(actually, I rather wonder if there isn't some variation on the Python
repl that could make it as convenient as any other shell and yet keep
compatibility with the Python flow control feeatures....)
> I think Python stands a much better chance of growing the
> muscles to compete with C++ and Java, than the flexibility to compete
> with scripting languages.
I've never heard anyone as knowledgable about Python as you claim that
it is *not flexible enough* to compete with anything. In what way is
"sh" more flexible than Python.
Okay, yes, in some cases a small program may be smaller in sh than in
Python. I've never consider the benefit in reducing 10 line programs to
2 lines worth the extra cognitive load of learning another stunted
language.
On the other hand, I would gladly learn something that is *more
powerful* in some particular problem domain like constraint programming
languages or matrix languages. There's a big difference between stepping
up to something domain specific and stepping down to something
brain-dead. I wasted too many brain waves trying to make DOS batch files
useful to go that route again on Unix.
Cameron Laird
.
>(actually, I rather wonder if there isn't some variation on the Python
>repl that could make it as convenient as any other shell and yet keep
>compatibility with the Python flow control feeatures....)
.
.
I'll argue for that. 'Fact, I'll bet it's only a minor variation.
I offer the suggestion to the EDU SIG to be gnawed over: what if
beginners were launched straight into Python for *everything*? My
speculation: that would be a good thing.
Paul Prescod
>
> In article <38C411A1...@prescod.net>,
> Paul Prescod <pa...@prescod.net> wrote:
> .
> [Maybe Java can be
> used for everything;
> in any case, Tcl is
> crap]
Well, Java will never take off with "scripters" so whether it could be
used for scripting or not is irrelevant because it won't be. It also
isn't appropriate as a CP4E language.
> Paul and I could happily go off in a corner and split hairs
> for--well, for a long time. I disagree with several claims
> about Tcl, Java, ...; those who truly care about the details
> are welcome, as usual, to ask.
You know a lot more about Tcl than I do. I would like to know what you
would prescribe as a problem that would be better suited to Tcl than to
Python. I am much more interested in problems that would take over 100
lines of Python code than in tiny ones, BTW. I am similarly curious
about non-trivial problems that lend themselves naturally to VB (the
language, not the development environment) and Perl.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
Out of timber so crooked as that which man is made nothing entirely
straight can be built. - Immanuel Kant
Juergen A. Erhard
Hash: SHA1
>>>>> "Paul" == Paul Prescod <pa...@prescod.net> writes:
Paul> Ran wrote:
>> No, the project manager chooses the language(s) according to
>> the needs of the project and the availability of programmers
>> and other resources.
Paul> Agreed. But that is not the way it works. Programmers tell
Paul> the project manager what language they should
Paul> use. Programmers gravitate towards complexity until they get
Paul> overwhelmed at which point they revert to simplicitly (like
Paul> art movements). It has almost nothing to do with which
Paul> language will get the job done.
You're both wrong. Neither programmers nor project managers say which
language to use... the development system already in place does. ;-)
Bye, J
- --
Jürgen A. Erhard eMail: j...@ilk.de phone: (GERMANY) 0721 27326
MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html
Mesa - Free OpenGL API (http://www.ssec.wisc.edu/~brianp/Mesa.html)
"No matter how cynical I get, I can't keep up." -- Bruce Schneier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Use Mailcrypt and GnuPG <http://www.gnupg.org/>
iEYEARECAAYFAjjFg84ACgkQN0B+CS56qs34KwCgpVYkRiQIyIlQ5EmGyaZtECgJ
nn0AoJFFwmF5f/11dlse2QYBW71EwL8a
=Pj50
-----END PGP SIGNATURE-----
Paul Prescod
>
> | I've never heard anyone as knowledgable about Python as you claim that
> | it is *not flexible enough* to compete with anything. In what way is
> | "sh" more flexible than Python.
>
> The UNIX shell is what you get with a very domain specific language,
> the simplest functions in the problem domain (UNIX commands) can be
> written with no punctuation at all. More complex operations can be
> expressed with only a little punctuation, e.g., a pipeline.
Well I haven't said anything against pipes! I just don't think we need
"if", "foreach" and friends. That's the point at which you want to wrap
your commands and pipes in a language with data structures and text
processing features.
> For an example of Tcl's lexical flexibility, see the "expect" command
> from Don Libes' Expect package. I think the Lisp & Scheme dialects
> can probably do the same kind of thing, and in this way they're more
> flexible than Python.
I guess I don't see a big problem with:
expect( "*number :*" )
sleep( 1 )
send( "r\r" )
Where little languages are useful, they can usually be embedded as we
have done with SQL, XPath, and pipes.
> Yes, I think "expect" is more powerful than any Python idiom I can
> think of to translate it to. I think the shell is a more powerful
> way to operate UNIX commands. I think this is not just the power
> to do something with less typing, it's also the power to do something
> with less investment in learning the ropes.
If you are going to learn expect without learning the "rest of TCL" then
I agree. My presumption is that everyone will (or at least should be
encouraged to) migrate from one-line commands to five-line hacks to 100
line toys to 1000 line tools (and perhaps beyond). I think that the
phase changes at those boundaries are actually harmful.
Also, I've pushed Python's lexical flexibility to its extremes and I am
rather glad that there is a point where it stops me! With too much
flexibility, it becomes a matter of learning a whole new syntax with
every module you import. More phase changes.
In the particular case of running system commands, I would prefer Python
to have some built-in syntax or function considering how often the task
is performed. Importing os is admittedly somewhat annoying for a really
tiny program.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
Donn Cave
| Donn Cave wrote:
|> ...
|>
|> The idea that Python can or should replace these scripting languages
|> is equally dubious in my opinion. Replace the UNIX shell with Python?
|> I think Python stands a much better chance of growing the
|> muscles to compete with C++ and Java, than the flexibility to compete
|> with scripting languages.
|
| it is *not flexible enough* to compete with anything. In what way is
| "sh" more flexible than Python.
Lexically, I guess would be the word. I have in mind two things.
The UNIX shell is what you get with a very domain specific language,
the simplest functions in the problem domain (UNIX commands) can be
written with no punctuation at all. More complex operations can be
expressed with only a little punctuation, e.g., a pipeline. This isn't
just a matter of how much work it is to type, it's really simpler and
more likely to be done right. The language per se is quaint and very
limited, a terrible choice for complex programming tasks, but that's
not what scripting is about. Is sh more flexible than Python? No,
but to get where sh is, Python would have to be a lot more flexible
than it is, as generic scripting languages like Tcl or REXX already are.
For an example of Tcl's lexical flexibility, see the "expect" command
from Don Libes' Expect package. I think the Lisp & Scheme dialects
can probably do the same kind of thing, and in this way they're more
flexible than Python.
| Okay, yes, in some cases a small program may be smaller in sh than in
| Python. I've never consider the benefit in reducing 10 line programs to
| 2 lines worth the extra cognitive load of learning another stunted
| language.
The survival value of those stunted languages has a lot to do with
that cognitive load.
| On the other hand, I would gladly learn something that is *more
| powerful* in some particular problem domain like constraint programming
| languages or matrix languages. There's a big difference between stepping
| up to something domain specific and stepping down to something
| brain-dead. I wasted too many brain waves trying to make DOS batch files
| useful to go that route again on Unix.
Yes, I think "expect" is more powerful than any Python idiom I can
think of to translate it to. I think the shell is a more powerful
way to operate UNIX commands. I think this is not just the power
to do something with less typing, it's also the power to do something
with less investment in learning the ropes.
Donn Cave, do...@u.washington.edu
PS, if you want to see something really horrid, David Korn kept on
developing the Bourne shell after the UNIX guys left with Bell Labs,
and I understand that by now this language (ksh96) can do simple
socket client/server operations, for example, and there are a couple
of independent object-oriented shell projects out there too.
I haven't used it, but it must be far worse than either of the two
common examples of languages extended too far. There are some hard
core fans, though, who really do a lot of work in it and see it as
more powerful, period.
Neel Krishnaswami
> Donn Cave wrote:
> >
> > The idea that Python can or should replace these scripting languages
> > is equally dubious in my opinion. Replace the UNIX shell with Python?
>
>
> Python repl that could make it as convenient as any other shell and
> yet keep compatibility with the Python flow control feeatures....
IMO, you really need to start playing with some Smalltalk environments.
The idea of needing a separate shell language to access system libraries
is rather bizarre, especially when you consider how impoverished most
shell languages' data structures are. IMO, it's a design decision well
worth revisiting -- whenever I need to do anything much more complicated
than an 'ls', I turn to Emacs and Python. Buffers plus the richer data
structures Python offers are just too much of a win over the plain
command line.
Neel
Yukihiro Matsumoto
|(This is why I think the Ruby people are being too grandiose in their
|claims. If Python and Perl haven't killed off Tcl, and Java hasn't
|killed off Python and Perl, it's unlikely that Ruby is going to manage
|any of those feats. Ruby certainly can form a healthy community of
|its own and prosper alongside these other languages, of course.)
Are we?
I consider myself as a provider of alternative, not killer, nor
replacement. Of course I know people tend to be grandiose in
advocacy, even Pythoneers.
matz.
Donn Cave
| Donn Cave wrote:
|> Lexically, I guess would be the word. I have in mind two things.
|> The UNIX shell is what you get with a very domain specific language,
|> the simplest functions in the problem domain (UNIX commands) can be
|> written with no punctuation at all. More complex operations can be
|> expressed with only a little punctuation, e.g., a pipeline.
|
| "if", "foreach" and friends. That's the point at which you want to wrap
| your commands and pipes in a language with data structures and text
| processing features.
I'd draw the line at some point too, but not there. It sounds ("foreach"?)
like you have been fighting csh, which is a miserable misbegotten language
that most agree should never be used for programming. (Interesting that
it's credited to William Joy, who I believe also gets some credit for Java.)
You probably know that the classic approach to shell programming is
very multi-lingual, you pull what you need from an assortment of
``UNIX tools'' like sed, awk, basename, expr, tr, who knows. It may
be anathema to someone like yourself, if you're attracted to the idea
of a single language to do everything, but it works for some people.
The profit in it is that each tool's very limited set of features can
be expressed pretty simply. I guess in a way this is like a conceptual
modularity. I solve sed problems in my mental sed module, which is
really small and simple, and until I encounter a sed program in a script,
that sed module is out of the way. So when you need text processing
features, you have the choice -- import them into the language (bash,
ksh, P***) - or find an external solution (sh, rc). I guess this is
getting a bit far afield of the notion of scripting languages in general,
because rarely does a scripting language find itself in an environment
with these kinds of tool laying around, but my point is that the genius
of UNIX was in this kind simplicity, and the efflorescence of kitchen
sink all-purpose tools and other elephantine appliances is a more recent
phenomenon that doesn't add much. Not everyone shares my opinion on
this, I know.
|> For an example of Tcl's lexical flexibility, see the "expect" command
|> from Don Libes' Expect package. I think the Lisp & Scheme dialects
|> can probably do the same kind of thing, and in this way they're more
|> flexible than Python.
|
| I guess I don't see a big problem with:
|
| expect( "*number :*" )
| sleep( 1 )
| send( "r\r" )
It has been years since I used Expect, but I think the big problem is
the "expect" verb does a lot more than this. It's kind of a big switch
statement whose branches' conditions are evaluated iteratively as input
accumulates, until one of them matches and gets executed. Now there
would be no excuse for adding bloat like this to Python, when you can
just put in the loops and if/elif/else blocks re.matches and whatever
else it takes. But it would be ridiculous to put a scripting language
into Expect and require its users to do all that.
| If you are going to learn expect without learning the "rest of TCL" then
| I agree. My presumption is that everyone will (or at least should be
| encouraged to) migrate from one-line commands to five-line hacks to 100
| line toys to 1000 line tools (and perhaps beyond). I think that the
| phase changes at those boundaries are actually harmful.
|
| Also, I've pushed Python's lexical flexibility to its extremes and I am
| rather glad that there is a point where it stops me! With too much
| flexibility, it becomes a matter of learning a whole new syntax with
| every module you import. More phase changes.
No argument here, I think Python has the right approach for what it is.
| In the particular case of running system commands, I would prefer Python
| to have some built-in syntax or function considering how often the task
| is performed. Importing os is admittedly somewhat annoying for a really
| tiny program.
Well, other languages that start with P do provide friendlier, more
convenient access to these functions, but there people do seriously
argue that you could almost dispense with the shell. The Python way
seems to be more verbose and inconvenient, but that's better for large
programs and that's why we're here. Isn't it better to have all Python
programs, large and small, share this same philosophy?
Donn Cave, do...@u.washington.edu
Darrell
On a large cross platform Python project we had people who wanted to use sh
scripts for odds and ends. Thankfully we DIDN'T !
That's all I need, another tool/constraint/syntax/pain-in-a---
--Darrell
Cameron Laird
.
>Well, Java will never take off with "scripters" so whether it could be
>used for scripting or not is irrelevant because it won't be. It also
of people who claim Java's so wonderful they use
it for scripting sorts of stuff (keeping in mind,
of course, that "scripting" means almost anything,
that is, nothing).
.
.
.
>You know a lot more about Tcl than I do. I would like to know what you
>would prescribe as a problem that would be better suited to Tcl than to
>Python. I am much more interested in problems that would take over 100
>lines of Python code than in tiny ones, BTW. I am similarly curious
>about non-trivial problems that lend themselves naturally to VB (the
>language, not the development environment) and Perl.
It's also almost a trick question: what's the
one domain Paul cares about most? XML. What's
the one clearest advantage Tcl currently has over
Python, as a language? That it does full Unicode,
which is necessary for XML. Conclusion: Paul,
you're one of the people in the world who should
most prefer Tcl.
That's a transient, of course, and arguably a
superficial one. My sources say Python 1.6's
Unicode is done well, which'll take care of that
argument.
Tcl's a little more introspective than Python.
Its traces are part of that. I'm accustomed to
thinking that's a benefit, but as a software
engineer I'm swinging around to the belief that
introspection might be an unhygienic habit.
Also, I spent all morning tracking down what I
believe is a wart in Tcl's traces, so my atti-
tude might be a bit different than it is most
days.
Historically, Tcl has been more minimal and
easier to extend and embed than Python. I'm
not sure that's still true. I think they've
converged.
Tcl's [exec] (think popen()) is neater than
people realize; it does a *lot* for a developer.
That's just a library issue, of course.
Certain Tcl extensions are champs: Tk, Expect,
and Scotty are the most prominent. What that
says about the *language* is a complex story
(and a different one in each case--sometime I'll
tell the unabridged versions).
I think I still could make a weak but definite
argument that Tcl is better as an extension
language--that is, for facilitating the under-ten-
line scripts that are a matter of indifference
to you.
Python's a better language than Visual Basic.
It's not worth arguing about.
.
.
Cary O'Brien
Cameron Laird <cla...@starbase.neosoft.com> wrote:
>In article <38C57EB8...@prescod.net>,[snip java stuff]
>
>Tcl's [exec] (think popen()) is neater than
>people realize; it does a *lot* for a developer.
>That's just a library issue, of course.
>
>Certain Tcl extensions are champs: Tk, Expect,
>and Scotty are the most prominent. What that
>says about the *language* is a complex story
>(and a different one in each case--sometime I'll
>tell the unabridged versions).
>
One reason that these extensions are so great is
the event model. Well, the right way would be
to say that Tk forced Tcl to operate in an event-driven
manner, and this allows things like fileevent and
Scotty to be so slick.
I'm doing a little Python (via Zope) and the thing
I miss the most is the tcl event model.
>I think I still could make a weak but definite
>argument that Tcl is better as an extension
>language--that is, for facilitating the under-ten-
>line scripts that are a matter of indifference
>to you.
>
One reason that Tcl seems better as an extension
language, no two, reasons...
1) Documentation, including The Good Doctor Ousterhout's
book.
2) The *old* calling sequence looked kinda like
c main(), i.e. you get (after Client Data and interp)
an argc/argv list. So this is very familiar to C
programmers. Of course with the new object layer
this changes.
-- cary
>Python's a better language than Visual Basic.
>It's not worth arguing about.
> .
Never touched VB.
> .
Cameron Laird
Cary O'Brien <cob...@Radix.Net> wrote:
.
.
.
>One reason that these extensions are so great is
>the event model. Well, the right way would be
>to say that Tk forced Tcl to operate in an event-driven
>manner, and this allows things like fileevent and
>Scotty to be so slick.
>
>I'm doing a little Python (via Zope) and the thing
>I miss the most is the tcl event model.
.
.
I entirely agree. The two things most distinctive
about Tcl programming--once one accepts that every-
thing is a string--are events and traces.
Very crudely, if you're feeling lonely in Pythonia
for event processing, look for a way to use threads.
Some argue that thread programming is inherently
superior to event programming. While I don't buy it
<URL:http://www.sunworld.com/sunworldonline/swol-11-1999/swol-11-regex.html>
readers shouldn't be surprised to encounter it.
Paul Prescod
>
> ...
>
> One reason that these extensions are so great is
> the event model. Well, the right way would be
> to say that Tk forced Tcl to operate in an event-driven
> manner, and this allows things like fileevent and
> Scotty to be so slick.
>
> I'm doing a little Python (via Zope) and the thing
> I miss the most is the tcl event model.
Interesting. Do you feel competent to "compare and contrast" Python
callbacks versus TCL events? What's wrong with:
def foo(x):
DoSomething()
DoSomethingElse()
events.handleFoo=foo
events.handleBar=bar
...
In XML processing we do a lot of event handling and I've only ever felt
constrained by Python once...and generators would have solved that
"once"...WE NEED GENERATORS.
You may or may not be up to speed on what we've been talking about
w.r.t. generators but I would like to see if TCL events can be
reexpressed as either callbacks or generators without losing anything.
Is lexical scoping perhaps what Python is "missing" for TCL-style event
handling?
Blake Winton
>"Tape recorders are better than pianos because it's too darn hard to become
>a good piano player. It divides the world into 'musicians' and
>'non-musicians'. The piano suffers from an overemphasis on being backwardly
>compatible with the clavichord."
Change that from "Tape recorders" to "Synthesizers", and I would
agree with Paul. The advances in ease of use allow for one-man-bands,
a feat which was nigh impossible in the early days of music.
Heck, even I, with no training in drums, can twiddle around in
7/4 time on a friend's drum machine, and come out with some
neat sounding beats. It seems to me that advances in technology
erase (at least partially) the lines between professionals and
amateurs. Maybe that's a good thing. Maybe not. Maybe both.
Later,
Blake.
--
4:20pm up 23 days, 19:12, 1 user, load average: 1.00, 1.00, 1.00
Blake Winton
>low and behold, Python. The people writing the largest systems seem the
I think that's spelt "lo and behold"...
Hope things are going well with you and Gwenyth Paltrow.
Blake Winton
>Even the Python tutorial bears traces of this, with the very first paragraph
>giving a motivating use for Python: translate a really complicated shell
>script into Python for more maintainability. I can't remember the last time I
>started out by writing a shell script for some task,
I can. It was just the other day, and I wanted to rename a bunch
of files and directories from "FOO/BAR/BAZ.HTML" to "foo/bar/baz.html".
It turned out to be far harder than I would have hoped. Not a
one-liner, anyways. I would have used Python, but it's been a
while since I've used the os.path and listdir functions, and I
wasn't in a mood to look them up.
As it turns out, there were also some files which should have
been "foo/bar/QuUx.java", so I had some manual renaming to do
after all. If I had been using Python, I would have been sorely
tempted to scan the html files as I was processing them, and
change the case of the files to whatever the html expected. So
in this case, not using Python actually saved me time... ;)
Barry A. Warsaw
>>>>> "BW" == Blake Winton <bwi...@tor.dhs.org> writes:
BW> Change that from "Tape recorders" to "Synthesizers", and I
BW> would agree with Paul. The advances in ease of use allow for
BW> one-man-bands, a feat which was nigh impossible in the early
BW> days of music.
BW> Heck, even I, with no training in drums, can twiddle around in
BW> 7/4 time on a friend's drum machine, and come out with some
BW> neat sounding beats. It seems to me that advances in
BW> technology erase (at least partially) the lines between
BW> professionals and amateurs. Maybe that's a good thing. Maybe
BW> not. Maybe both.
Ah, but can you look cool doing it? Eh? Eh? :)
Besides, to paraphrase Mr. Protocol, a piano is much better than a
tape recorder because it does more damage when you drop it.
-Barry