Newbie. Why Python?
bryce
Ok, I realize this is a *broad* statement but let me try to clarify.
I have been reading the Python newsgroup for a couple months now and
find it to be interesting. Yes, I've downloaded it and have fiddled
with it but I still do not see a blazing feature that has knocked me
in the forehead as to why I would want to use it.
This is in *no way a flame*. I think that the existence of a free
and seemingly capable language like this exists. I do feel that the
documentation does leave a lot to be desired. (maybe i'm looking in
the wrong place ?? )
But please, post away and let me know your loves & hates (if any)
about Python !
I look forward to reading them !
Konrad Hinsen
al...@erinet.com (bryce) writes:
> I have been reading the Python newsgroup for a couple months now and
> find it to be interesting. Yes, I've downloaded it and have fiddled
> with it but I still do not see a blazing feature that has knocked me
> in the forehead as to why I would want to use it.
There's probably no single feature that is revolutionary, but the mix
of features just happens to be right. Try Python for a real-life project
and you will see...
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hin...@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
Gerco Ballintijn
al...@erinet.com (bryce) writes:
> I have been reading the Python newsgroup for a couple months now and
> find it to be interesting. Yes, I've downloaded it and have fiddled
> with it but I still do not see a blazing feature that has knocked me
> in the forehead as to why I would want to use it.
> This is in *no way a flame*. I think that the existence of a free
> and seemingly capable language like this exists. I do feel that the
> documentation does leave a lot to be desired. (maybe i'm looking in
> the wrong place ?? )
Actually, my intro was the set of standard docs. They gave me right-
away a firm grasp as to what Python program is supposed to look like.
Now I've also bought the Programming Python book to fill the gaps.
> But please, post away and let me know your loves & hates (if any)
> about Python !
What won me over was when I had to write 2 programs for a demonstration
at our university. We wanted to let some (potential) students do some
practical work concerning Public Key Encryption and Network Protocols.
It was important that the user interface of the programs were simple,
since their knowledge of computers was unknown and probably not very
big.
The programs consisted of a GUI part, a network part and (for the PK
encryption) the 'RSA engine'. Without any design (yes, this is a mortal
sin :-) I was able to first create the GUI to show my collegues what
my idea was; then create the RSA engine and test it, Which was easy
with the builtin long integers; and then I could add the networking
as an afterthought. In less than a week I wrote both programs (together
approx. 2000 lines of code), outside my normal work. Both served fine
at the demo.
That is what I like about Python, its fast prototyping capabilities.
And that is why I'm not too sure that adding extra (static) type
checking or other such things is a good idea.
Just my 0.02 golden florins...
Gerco.
--
----------------------------------v------------------------------------
G.C. Ballintijn | Oh, Fortuna
mailto:ge...@cs.vu.nl | Velut luna
http://www.cs.vu.nl/~gerco/ | Statu variabilis.....
Chris Hoffmann
>>>>> "bryce" == bryce <al...@erinet.com> writes:
bryce> Ok, I realize this is a *broad* statement but let me try to
bryce> clarify. I have been reading the Python newsgroup for a
bryce> couple months now and find it to be interesting. Yes, I've
bryce> downloaded it and have fiddled with it but I still do not see
bryce> a blazing feature that has knocked me in the forehead as to
bryce> why I would want to use it.
I agree with Konrad's posting that the appeal is not so much *a*
blazing feature, but the way *lots* of *good* features all fit
together to make a pleasant whole.
But to better direct the discussion, could you mention what languages
and their features you already use and like? It could well be that
Python does indeed have some feature that will knock you over the head
once you really understand what it lets you do!
Chris
--
Chris Hoffmann DataViews Corporation
chof...@dvcorp.com 47 Pleasant St. Northampton MA 01060
GCS d H s+: g+ ?p a w v+ C+$ US+ P++(++++) L E+(+++) N++ K W--->-- M+
V- po- Y+ t+ 5+(+++) Jx R G tv b+++ D+ B-() e+++ u++ h---- f r+++ n--- y++++
Tero Pulkkinen
> > I have been reading the Python newsgroup for a couple months now and
> > find it to be interesting. Yes, I've downloaded it and have fiddled
> > with it but I still do not see a blazing feature that has knocked me
> > in the forehead as to why I would want to use it.
Python has several advantages:
1) Availability (works about any platform because its based on standard
language(C) and standard interfaces (POSIX etc)
=> means its safe to use it - it wont get broken in near future
2) Very easy extensibility and prototyping features
=> quick development
3) Great documentation - a very important part
=> very easy to learn and use
4) Simplicity
(we used python as extension language inside our C++ code and it worked
better than we could have guessed, about all problems were with the C++
code)
> That is what I like about Python, its fast prototyping capabilities.
> And that is why I'm not too sure that adding extra (static) type
> checking or other such things is a good idea.
Static type checking is a good thing, and thats one thing I've been
missing in python. But it should be made so that the prototyping
features wouldnt get affected. Maybe freeze/melt thingys copied from
eiffel or transframe would do it? (But if static typing is made, it
must be made so that its possible to turn it off for certain modules
while having it for other modules)
--
-- Tero Pulkkinen -- te...@modeemi.cs.tut.fi --
Aaron Watters
From: al...@erinet.com (bryce)
> I have been reading the Python newsgroup for a couple months now and
>find it to be interesting. Yes, I've downloaded it and have fiddled
>with it but I still do not see a blazing feature that has knocked me
>in the forehead as to why I would want to use it.
Python's lack of blazing features is an advantage.
It's rock solid software engineering that has been
torture tested for several years now. It contains a
select set of the very best features from the very
best programming languages invented in the last 40
years. Nothing experimental or visionary -- just
a beautifully crafted package that is at once clear,
easy to learn, and extremely practical. If you want
a fruit salad of syntax and experimental novel features,
look elsewhere. Also, look to Python's excellent
C API for more examples of excellent design.
>... I do feel that the
>documentation does leave a lot to be desired...
The documentation is excellent, but past the tutorial
it's aimed at a fairly high powered audience. For more
introductory material look to the Python books. One
or the other (or all three, if you read German) might
appeal to you. http://www.python.org/doc/#books
-- Aaron Watters.
===
JIT happens. --CodeWarrior tee shirt from JavaOne.
Bill Janssen
Excerpts from ext.python: 8-Apr-97 Re: Newbie. Why Python? Gerco
Balli...@cs.vu.n (2165)
> That is what I like about Python, its fast prototyping capabilities.
> And that is why I'm not too sure that adding extra (static) type
> checking or other such things is a good idea.
Right. That's why I liked the optional, add it as needed, kind of type
declarations I sketched out last week. I think this could be a really
exciting addition to Python, and would vastly improve the ability to
remove certain kinds of misunderstanding-based errors from large systems.
For example, you could declare a type constraint on just one parameter
of a function, or on just one of the three local variables you'd be
using, so that the compiler could give you whatever help it can with
that information, but would never hinder you.
Bill
Terry Reedy
Bryce raises an interesting question. Many of the things I like
about Python can be summarized by calling it executable psuedocode.
To explain: computer algorithm/programming book writers must decide
whether to write in a particular programming language or in a more
English-like and hopefully clearer and more succinct 'psuedocode'.
Those who decide on the latter do things like leave out variable
declarations. Since they indicate structure with indentation, they may
leave out block structure delimiters as redundant. They leave off
statement terminators (by using \n). They may collapse and clarify
multiple assignment lines into one multi-assignment statement (as with
condensing t=x;x=y;y=t as x,y=y,x). IE, in an effort to communicate
clearly, they may write something much like Python!
Not knowing about Python, they may say things like "To run this code,
the reader will have to add all the things I left out". However, in at
least one book, I found that 'psuedo-C' translated pretty much
line-for-line, with only minor modifications, into executable Python.
If I were writing such a book, I would seriously consider using Python
as a simple 'psuedocode' which just happens to be directly executable
with the proper interpreter.
Terry
John Stevens
In article <5icf3j$i...@server1.erinet.com>, you wrote:
>
> But please, post away and let me know your loves & hates (if any)
>about Python !
Loves:
1) Dynamic.
2) OO Scripting language.
3) Meta-class protocol.
4) Indirect activation of methods upon message reception.
5) Meta-programming support.
6) Reasonably portable.
7) Embed Python in C, or Embed C in Python.
8) Source code availability (and, better yet, relatively readable
source, at that).
Hates:
1) Not dynamic enough.
2) Slooooow regular expressions.
3) No generalized protocol support.
4) No direct (language based) support for distributed objects.
5) Not released under GPL.
6) No clean separation between interface and implementation.
7) No support for attribute access control.
All of the above will be argued back and forth, but the three things
I *REALLY* miss are support for distributed objects built into the language
(Objective C is really nice that way), *fast* regular expressions, and
a clean way of adding object instance specific methods dynamically.
On the other hand, there are systems that support distributed Python
objects, there is a group that is supposedly working on moving Perl's
regular expressions into Python, and I am personally wading through
the Python source trying to figure out just how difficult point #3
would be to implement.
In closing, I cannot get people here to take Python seriously, but it
does make an excellent training language for OOP classes since it is so
interactive, and easily supports basic meta-programming and dynamic
OOP exercises.
John S.
Fredrik Lundh
> 1) Not dynamic enough.
Compared to what?
> 5) Not released under GPL.
Sorry, but this doesn't make sense. Why would it be an advantage to
ship Python under a more restrictive license?
/F
Aaron Watters
(Terry Reedy)
>Bryce raises an interesting question. Many of the things I like
>about Python can be summarized by calling it executable psuedocode.
"I hate the Mac -- it just doesn't feel like I'm using a *real*
*computer*!"
This is what one of my friends said when the first Mac came out, and
many "professionals" had the same reaction -- this obviously wasn't
for them. Now, of course, all the professionals are using *something*
that looks a lot like the original Mac.
Oddly, Python's elegantly practical design and ease of use is
actually a disadvantage for many guru types (you know the type
-- the guy who shows up dressed as Merlin at the Halloween party).
Real programmers want to see something with a lot more crypticisms,
or "purity" or whatever, not always, but too often. You can't
convince them that it's a practical and powerful *real* programming
language, because they can't get past how easy it is.
My brother-in-law, for example, who teaches jr-high students
just couldn't stop saying: "yeah, but it's too easy -- it's
a toy programming language, right?"
I suspect that Python's true audience may be larger among
"non-programmers" and "amateurs" who just want to get the
computer to do interesting things without having to clutter up
their brains too much with mystic gunk and weird philosophy.
Python is the shortest path from A to B, whether you think
imperative, object oriented, functional, algebraic, you name it.
And in about 10 years the "professionals" will follow. (Of
course, a select few could wise up and catch the wave now.)
As in the Mac metaphor, of course, I don't think the ultimate
"winner" need be Python per se, although I don't see why not,
but I'll bet anything it (or they) will look a lot like Python.
And you are right, books that discuss a computational topic
might do well to choose Python to illustrate the concepts with
actual working pseudocode. Hmmm, this sounds a bit like
/F's upcoming book, or maybe even "Internet Programming
with Python" or "Programming Python".
-- Aaron Watters
===
Once you've gone through Zebra, Zither, and Zoo
You're flat out of Z-words
I got the Z-word Blues. -- Muppets with long beards.
Jeffrey C. Ollie
-----BEGIN PGP SIGNED MESSAGE-----
On 9 Apr 1997 17:26:40 GMT, John Stevens <jste...@samoyed.ftc.nrcs.usda.gov>
wrote:
>
>Hates:
>
>2) Slooooow regular expressions.
>
> [...]
>
>All of the above will be argued back and forth, but the three things
>I *REALLY* miss are [...] *fast* regular expressions, and [...]
>
> [...]
>
>there is a group that is supposedly working on moving Perl's
>regular expressions into Python,
More than just supposedly. Although there isn't a lot to show yet, we
are making progress. I've got a drop-in replacement for the core
regular expression implementation. I don't know if it's any faster but
it does fix most, if not all, of the long-standing bugs.
>In closing, I cannot get people here to take Python seriously, but it
>does make an excellent training language for OOP classes since it is so
>interactive, and easily supports basic meta-programming and dynamic
>OOP exercises.
I think that Python isn't taken seriously mostly because it isn't as
well established as other languages (e.g. Perl) and there isn't a huge
marketing department forcing it into the consciousness of
managers (e.g. Java or Visual Basic).
[A copy of the headers and the PGP signature follow.]
Date: Wed, 09 Apr 1997 14:49:55 -0500
Newsgroups: comp.lang.python
Organization: netINS, Des Moines, IA, USA
References: <5icf3j$i...@server1.erinet.com>
<slrn5knglq....@samoyed.ftc.nrcs.usda.gov>
Subject: Re: Newbie. Why Python?
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news.
iQCVAwUBM0v1upwkOQz8sbZFAQE/1QQAwsINjBku0B4OFJwM5Qmod69L8PtjjXEr
HbtccbQR8r+kLdXMuNclUMC4HRc4Rl/aY8qTTQ2/f6RBGDrW4qMxApX3J/gb9EyS
gCtqNuRL7IL14vZ+2yPwcjoDFyopddrras9JzjeysMPdMhIwRrd00qdOec48xpqN
ddOrl955jvY=
=/eCE
-----END PGP SIGNATURE-----
--
Jeffrey C. Ollie | Should Work Now (TM)
Python Hacker, Mac Lover |
Samuel L. Bayer
In article <1997040819...@dante.mh.lucent.com>, "Aaron Watters" <a...@dante.mh.lucent.com> writes:
|> >... I do feel that the
|> >documentation does leave a lot to be desired...
|>
|> The documentation is excellent, but past the tutorial
|> it's aimed at a fairly high powered audience. For more
|> introductory material look to the Python books. One
|> or the other (or all three, if you read German) might
|> appeal to you. http://www.python.org/doc/#books
While I certainly agree with your characterization of the documentation, I think
it should be clear after the numerous newbie complaints that "aimed at a fairly
high-powered audience" != "excellent" for documentation...
Cheers,
Sam Bayer
WILSHER THOMAS
jste...@samoyed.ftc.nrcs.usda.gov (John Stevens) writes:
>Hates:
>1) Not dynamic enough.
>2) Slooooow regular expressions.
>3) No generalized protocol support.
>4) No direct (language based) support for distributed objects.
>5) Not released under GPL.
>6) No clean separation between interface and implementation.
>7) No support for attribute access control.
>All of the above will be argued back and forth, but the three things
>I *REALLY* miss are support for distributed objects built into the language
>(Objective C is really nice that way)
Hmmm, unless they have made some radical changes to Objective-C recently, that is
incorrect -- there is no support for distributed objects in the _language_ per se.
However, NeXT has their (very nice) distributed objects. From the Objective-C FAQ:
Distributed Objects
The Distributed Objects system provides a relatively simple way for
applications to communicate with one another by allowing them to
share Objective-C objects, even amongst applications running on
different machines across a network. They are useful for
implementing client-server and cooperative applications. The
Distributed Objects system subsumes the network aspects of typical
remote procedure call (RPC) programming, and allow an application to
send messages to remote objects using ordinary Objective-C syntax.
The Distributed Objects system takes the form of two classes,
NXConnection and NXProxy. NXConnection objects are primarily
bookkeepers that manage resources passed between applications.
NXProxy objects are local objects that represent remote objects.
When a remote object is passed to your application, it is passed in
the form of a proxy that stands in for the remote object; messages
to the proxy are forwarded to the remote object, so for most intents
and purposes the proxy can be treated as though it were the object
itself. Note that direct access to instance variables of the remote
object isn't available through the proxy.
(Introduction from the NeXTSTEP General Reference, "Distributed Objects"
reprinted with permission. Copyright (c) 1993 NeXT Computer, Inc.
All rights reserved.)
Something similar exists in the GNU Objective-C Class library; again, not in the
language proper. However, this system was made _possible_ by the dynamic nature
of Objective-C, which means that something similar should be pretty easy to implement
in Python. (Possibly by having a Proxy object that uses its __getattr__ and
__setattr__ to do remote method invocation -- haven't really thought that one out yet)
My guess is that for this task, python is "dynamic enough", as I usually the case in
my experience. ;-)
--thomas
Jack Jansen
"Aaron Watters" <a...@dante.mh.lucent.com> writes:
>Oddly, Python's elegantly practical design and ease of use is
>actually a disadvantage for many guru types (you know the type
>-- the guy who shows up dressed as Merlin at the Halloween party).
>Real programmers want to see something with a lot more crypticisms,
>or "purity" or whatever, not always, but too often. You can't
>convince them that it's a practical and powerful *real* programming
>language, because they can't get past how easy it is.
Aren't you being too hard on the Real Programmer's here? I think that
one of the main factors in choice of language (or *any* tool, really:
lots of my collegues still use "vi", and I myself still used "ex" just
7 years or so ago) is conservatism: if you have a tool that does the
job for you you stick with it.
Hence, if you've invested years of work in learning, say, Perl, it's
easy to point out that many of the things you can do in Python you can
as easily do in Perl (the "you" here being the experienced Perl user).
My guess is that it's more the newbies (who've just spent months
huddled over the manual) who tend to flame anything but their own One
True Language...
--
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack....@cwi.nl | ++++ if you agree copy these lines to your sig ++++
http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
Fredrik Lundh
Jack writes:
> Hence, if you've invested years of work in learning, say, Perl, it's
> easy to point out that many of the things you can do in Python you can
> as easily do in Perl (the "you" here being the experienced Perl user).
Not to mention when you've invested years of work in teaching, say, Perl
<wink>
> My guess is that it's more the newbies (who've just spent months
> huddled over the manual) who tend to flame anything but their own One
> True Language...
Don't forget those parts of the CS crowd that prefer to hang around
on Usenet discussing "How Telescopes Should Be Built" rather than
gazing at the Hale-Bopp or thinking about what's out there...
...
I don't really care much about what language I use, but I care a lot
about what I'm able to produce with it; to quote Grady Booch:
Would I like to go back to the days of just EMACS and a compiler?
Not really. In the hands of a master, you can go a long way with just
these basics. However, I rather like the direction the industry is
taking, the move toward components: Pounding out code can be enter-
taining, but what's more interesting to me is delivering full systems
that work. Components give me greater leverage, making it possible to
build complex systems that people could only dream of just a few years
ago.
Python allows me to create and integrate more and better components in
less time and with less effort than I've ever seen anyone do with any
other language. And where I have to, I can wrap or interface to vir-
tually anything else. I think that's a really good thing. YMMV ;-)
Cheers /F (http://hem1.passagen.se/eff)
PS Custom Computer Applications, Inc.
Thanks for your input so far everyone. Could someone give me a piece
of 'skeleton code' for a stand-alone app ( i assume using CApp and
MainFrame objects) under Windows 95. I can't seem to grasp it.
Thanks for any help.
PS: I must be missing the point on the documentation. I'm just not
grasping much of it.
Paul Svensson
>> 5) Not released under GPL.
>
>ship Python under a more restrictive license?
I believe this is a religious issue for some people.
/Paul
--
Paul Svensson _ /| Every absurdity needs a champion to defend it
SM5SJS \'o.0' http://www.lysator.liu.se/~paul/home.html
+46 13 121021 =(___)= _ _
pa...@svensson.org U Luftvarnsgatan 62, 587 34 Linkoping, Sweden
Fredrik Lundh
> Possibly by having a Proxy object that uses its __getattr__ and
> __setattr__ to do remote method invocation -- haven't really thought
> that one out yet) My guess is that for this task, python is "dynamic
> enough", as I usually the case in my experience. ;-)
Creating a "generic" proxy class is trivial, as is designing a corre-
sponding server module. For a pretty complete implementation, see
Daniel Larsson's RemoteCall module.
> Something similar exists in the GNU Objective-C Class library;
> again, not in the language proper.
But obviously, people mix up Python the language, Python the inter-
preter (including the standard C libraries), and Python the environ-
ment. Just imagine arguing that C++ sucks because the regexp library
one happens to use is slow...
Cheers /F (http://hem1.passagen.se/eff)
Samuel L. Bayer
In article <5icf3j$i...@server1.erinet.com>, al...@erinet.com (bryce) writes:
|> Ok, I realize this is a *broad* statement but let me try to clarify.
|>
|> I have been reading the Python newsgroup for a couple months now and
|> find it to be interesting. Yes, I've downloaded it and have fiddled
|> with it but I still do not see a blazing feature that has knocked me
|> in the forehead as to why I would want to use it.
OK, I'll chime in. I've programmed in Pascal, C, C++, APL, Tcl, Zetalisp, Common
Lisp and Scheme, at least. I'll agree with there being no single blazing feature.
But it continues to surprise me how *right* Python has gotten most things; it has
most of the advantages, and almost none of the flaws, of almost all the languages
I've used (and seen). Not only that, it's free; it runs on almost every platform;
it's a true object-oriented, block-structured language; it has a stable
connection to a well-established GUI toolkit; it has bindings for a vast array of
UNIX libraries, which in every case are much easier to use in Python than in C
(my favorite is the socket module); and it's trivial to write more. None of these
properties is unique to Python, but the SUM of them is.
For instance, Common Lisp has a much richer object system, and much richer lambda
functionality, but Python chose the "right" pieces, and improved considerably on
Common Lisp by adopting the "everything is an attribute" strategy for namespace
management. I used to program in CL all the time, and now I use Python. I've got
it running on my 68030 Powerbook at home, and it's the first time I've ever been
able to program usefully on that machine. Etc.
You've probably seen the vigorous discussions on the newsgroup about language
changes and extensions. These discussions, for me, reflect the greatest resource
that Python has: a firm, guiding hand in Guido, and a commitment on the part of
the entire community that the language needs to be designed rather than cobbled
together.
BTW, while we're talking about comparing programming languages, those of you who
haven't yet should visit the "99 bottles of beer on the wall" Web site, which
features code for generating lyrics for this delightful song in no less than 180
programming languages and counting, including ABC, TeX, the FileMaker Pro
scripting language, and (of course) Python:
http://www.ionet.net/~timtroyr/funhouse/beer.html
Bottoms up,
Sam Bayer
Konrad Hinsen
s...@linus.mitre.org (Samuel L. Bayer) writes:
> While I certainly agree with your characterization of the documentation, I think
> it should be clear after the numerous newbie complaints that "aimed at a fairly
> high-powered audience" != "excellent" for documentation...
I don't agree at all. For someone with programming experience, nothing
is more inefficient than a documentation that starts by explaining
what a variable is. So there is a need for documentation at various
levels, and the "high-level" documentation can very well be excellent.
Graham Matthews
Jack writes:
>My guess is that it's more the newbies (who've just spent months
> huddled over the manual) who tend to flame anything but their own One
> True Language...
Fredrik Lundh wrote:
> Don't forget those parts of the CS crowd that prefer to hang around
> on Usenet discussing "How Telescopes Should Be Built" rather than
> gazing at the Hale-Bopp or thinking about what's out there...
Have you ever stopped to think that the "CS crowd" might have a valid
point? Moreover have you ever considered that the issues the "CS crowd"
are crowing on about have a direct impact on practical programming
issues like productivity, reliability, efficiency, etc. I'll give you a
few examples. Take parallel programming. A lot of that is done in
Fortran. The "CS crowd" do it in Sisal. Studies have shown Sisal
programmers to be something like 7 times more productive than their
Fortran counterparst. Sisal is a pure applicative language -- one of
those one the "CS Crowd" always talk about. Note also how Fortran-90
includes a lot of pure functional features like pure functions, map,
etc. Another example is static typing. It produces more reliable code
since you don't ship code with type errors in it. This is critical for
things like GUIs where its very difficult to test all your code. Another
example is garbage collection. That was one of those things the "CS
crowd" used to go on about, and now all of a sudden its appearing all
over the place, like in Java for example.
I think you both under-estimate and mis-understand what the "CS crowd"
are really doing.
graham
--
And love love love is a dangerous drug,
You have to receive it and you still can't get enough of the stuff
Graham Matthews
Aaron Watters wrote:
> Python is the shortest path from A to B, whether you think
> imperative, object oriented, functional, algebraic, you name it.
How do you figure this Aaron? Python is easy to use but how do you know
its the "shortest path". This sounds like evangalising to me.
graham
> Once you've gone through Zebra, Zither, and Zoo
> You're flat out of Z-words
> I got the Z-word Blues. -- Muppets with long beards.
What about Zloty!
Aaron Watters
Aaron Watters wrote:
> Python is the shortest path from A to B, whether you think
> imperative, object oriented, functional, algebraic, you name it.
Graham:
>How do you figure this Aaron? Python is easy to use but how do you know
>its the "shortest path". This sounds like evangalising to me.
Me? Evangelize Python? Never!
Deeply hurt and shocked that anyone would ever think such a thing.
Evangelizing and hyperbole vanished in the programming language
world sometime around the invention of Algol 66. It just isn't done
anymore. To think!
-- Aaron Watters
===
With my New York brim and my gold tooth displayed
Nobody give me trouble 'cause they know I got it made
I'm bad. I'm nationwide. -- ZZ-top
Aaron Watters
Graham:
>Take parallel programming. A lot of that is done in
>Fortran. The "CS crowd" do it in Sisal. Studies have shown Sisal
>programmers to be something like 7 times more productive than their
>Fortran counterparst.
I'm sure Sisal is fantastic, but...
Did you ever think that maybe getting excited about using a
brand new experimental language can improve your productivity
by itself? Programming language studies tend to suffer from
the Hawthorne effect (I think it's called) so named after a management
study that showed that factory workers worked more productively
if the lights were brighter, or if the lights were dimmer, or if they
were made to stand on their heads, provided there were a lot
of folks in white coats around taking notes... Unfortunately, once
the folks in white coats left the effect tended to wear off.
Python does get a fair number of testimonials like, "I tried it,
not expecting much, but now I'm amazed at how much I'm
producing, and at how much fun I'm having. I'm hooked."
Happened to me, 2 years ago or so. I honestly intended to
remove it after a few experiments, but I never got around to
it :).
-- Aaron Watters
===
...but what really irritates me is when the programming
language inventors themselves talk about how much more
productive they are...
Fredrik Lundh
> Have you ever stopped to think that the "CS crowd" might have a
> valid point?
But of course. I did't write "CS crowd", I wrote "parts of the CS
crowd". And as the Tcl thread shows, some parts of the CS crowd do
believe that the language is pretty much everything. There's probably
some astronomers around that think that once you create the perfect
telescope, it will only be a matter of time before you have all the
answers. But that doesn't mean that they all do it. Some focus on
tripods...
> I think you both under-estimate and mis-understand what the "CS
> crowd" are really doing.
I think this works both ways, really. But that discussion was
recently held over at comp.graphics.algorithms, no need to repeat it
here...
...
You see, when I talk about "computers", I usually mean virtually
everything that the computer *industry* has to deal with. In that
context, the language (or operating system, hardware, etc.) is just a
very small part of the problem domain. If you can code 7 times faster
in SISAL than in FORTRAN, does that mean that you can deliver your
product in 14.3% of the time? That if your project would have taken
10 weeks, you can ship it after 10 days? Or that you can get rid of 6
programmers? And are you sure the factor 7 _only_ illustrates the
qualities of SISAL, and not problems with FORTRAN? What results would
parallel systems based on C(++) or Java give?
Personally, I'm searching for development tools and strategies that
let me cut the overall project time with (at least) 7 times. Today,
this includes OO (for which there exist field-proven and widely known
design methods that maps cleanly onto things like C++, Java, Python);
tools that are either widespread (C++, Java) or easy to grasp for
mortal programmers (Java, Python), continous integration and test
strategies, cyclic project models, Scott Adams, etc. Tomorrow, it
might include functional/intentional/aspect oriented (you know more
such words than I do ;-) stuff, but that's another day. I need to
ship my stuff before I can figure out whether monomorphism
restrictions are part of the Hindley-Milner type system...
...
This also reminds me of the good old myth that scientists are
constantly searching for the really true answers hidden out there,
engineers use whatever the scientists discovers and wraps it up for
the masses, and the masses live happily ever after. Personally, I'm
not sure its that simple. But what do I know?
Cheers /F (http://hem1.passagen.se/eff)
"I still think that many people who refer to Simula only grasp
parts of it. In fact, those who understand Simula best are not
the people in programming research, but rather Simula's
simulation users. The computer scientists like Simula as a
vehicle for implementing abstract data types." -- Nygaard, 1981
Gordon McMillan
In article <334DC9...@maths.anu.edu.au>, graham....@maths.anu.edu.au
says...
>... Moreover have you ever considered that the issues the "CS crowd"
>are crowing on about have a direct impact on practical programming
>issues like productivity, reliability, efficiency, etc.
Not to deny or belittle the great practical advantages that have come
from CS research, but if practicality were a large
concern in CS, all modern languages would support dates with valid ranges
in the thousands of years, and numeric types that support
arithmetic the way accountants do it.
--
Gordon McMillan
___ ________
/_ \ / ______\
/ /\ \ / /\ \____
/ / \ \/ / \ ___\
McMillan Enterprises, Inc.
/__/ \________\
Graham Matthews
Graham:
> >Take parallel programming. A lot of that is done in
> >Fortran. The "CS crowd" do it in Sisal. Studies have shown Sisal
> >programmers to be something like 7 times more productive than their
> >Fortran counterparst.
Aaron Watters wrote:
> I'm sure Sisal is fantastic, but...
>
> Did you ever think that maybe getting excited about using a
> brand new experimental language can improve your productivity
> by itself? Programming language studies tend to suffer from
> the Hawthorne effect (I think it's called) so named after a management
> study that showed that factory workers worked more productively
> if the lights were brighter, or if the lights were dimmer, or if they
> were made to stand on their heads, provided there were a lot
> of folks in white coats around taking notes... Unfortunately, once
> the folks in white coats left the effect tended to wear off.
This is pretty feeble Aaron. While the Hawthorne effect may/may not have
been involved, one could also argue that mitigated against this is the
fact that we are measuring the productivity of programmers unfamiliar
with Sisal ...
> Python does get a fair number of testimonials like, "I tried it,
> not expecting much, but now I'm amazed at how much I'm
> producing
Why do you "pythonise" everything? I made a comment about Sisal's
productivity in relation to Fortran. And suddenly you are talking
Python's productivity. What relevance is that?
graham
--
On the streets tonight
The innocent are dying
And the world's not right
So many millions dying
Fredrik Lundh
> Why do you "pythonise" everything? I made a comment about Sisal's
> productivity in relation to Fortran. And suddenly you are talking
> Python's productivity. What relevance is that?
Well, we're on comp.lang.python, aren't we?
(okay, I have to admit that it has looked a lot like comp.lang.scheme
and/or comp.lang.tcl lately, but it says "python" in the subject and
"python" in the newsgroups field ;-)
Cheers /F (http://hem1.passagen.se/eff)
Jason Orendorff
> But please, post away and let me know your loves & hates (if any)
> about Python !
maybe six months now. Here's what I like about python vs. other
languages, besides what you already mentioned.
. It byte-compiles.
. It uses normal C-style notation for math, not some weird
reverse-reverse polish notation like Lisp.
. It uses normal C-style notation for accessing variables: there's no
weird lookup operator that litters your code with $'s.
. It has lambdas. I had never seen a lambda function before I used Python.
. It's generally faster than a shell for scripting-- in both coding time
and run time.
. The real kicker for me is that I have a much better hit/miss ratio with
Python than with C. You know what I mean-- for most "quick little tasks"
you can knock off a C program in 5 minutes (this is a "hit"), but about
20% of the time the thing just utterly refuses to work, dumps core,
you crawl through the code, you bang your head against the wall, and
before you know it you've been debugging this program (and drumming your
fingers waiting for it to recompile) for two hours. This
is a "miss". In python I never "miss", and the "hits" are much quicker.
. Since I'm on an .edu domain, I have a quota. I can only take up so
much disk space. When I'm running low on storage, I can just convert
a handful of programs from C to python, usually with a great gain in
functionality (and an unnoticeable decrease in speed). Then delete
the C binary to free up 48 to 500 K of quota. Archive the C code
somewhere.
. It's insanely versatile. I have a bot that checks and divides my mail
and a whole series of cgi scripts written in python. I sometimes do
homework in python. It's the quickest way to do any number of things.
What do I miss in python?
. I am not entirely comfortable with the fact that lookups aren't checked at
(forgive me if I don't know the lingo) "compile time". Not everything
can be, I guess, but it'd be nice if after defining a function you could
f.__dynamic__ and get a list of the names that aren't internal
to the function... The reason this can be a problem is that if I don't
test *every* if/else branch there might be a name in there that's
misspelled, and I'd never know. A c++ compiler catches typos at compile
time; python throws 'em at runtime, which is a little yucky.
. The occasional static type-check. So sue me.
. Emacs won't help me format my code "electrically". :o( If there is
an emacs python-mode out there, someone please let me know.
--
jason
Fredrik Lundh
> Emacs won't help me format my code "electrically". :o( If there is
> an emacs python-mode out there, someone please let me know.
But of course:
http://www.python.org/ftp/emacs
(or grab it directly from ftp://ftp.python.org/pub/emacs/python-mode.el)
Cheers /F (http://hem1.passagen.se/eff)
Fredrik Lundh
> > Emacs won't help me format my code "electrically". :o( If there is
> > an emacs python-mode out there, someone please let me know.
>
> But of course:
And yes, if you have the source distribution, it's in the Misc
subdirectory, as mentioned in the README:
Emacs mode
----------
There's an excellent Emacs editing mode for Python code; see the file
Misc/python-mode.el. Originally written by Tim Peters, it is now
maintained by Barry Warsaw <bwa...@cnri.reston.va.us>.
(a case of RTFRM, obviously ;-)
Cheers /F (http://hem1.passagen.se/eff)
Dennis Lee Bieber
On Sat, 12 Apr 1997 19:16:03 -0500 in comp.lang.python,
Jason Orendorff (jore...@odin.cbu.edu) declaimed:
> . It uses normal C-style notation for math, not some weird
> reverse-reverse polish notation like Lisp.
<chuckle> RPN is also known as Polish-postfix... Lisp, in
contrast, would then be Polish-prefix...
{No, I have never seen a Polish-infix format <G>}
--
> ============================================================ <
> wulf...@netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> Finger for PGP key | Bestiaria Support Staff <
> ============================================================ <
> Bestiaria Home Page: http://beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <
-=-=-=-=-=-
Usenet KILL-FILED for excessive off-topic SPAM:
earthlink.net istar.net hotmail.com
Is your site going to be next?
John Stevens
On Wed, 09 Apr 1997 14:49:55 -0500, Jeffrey C. Ollie <je...@ollie.clive.ia.us> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>On 9 Apr 1997 17:26:40 GMT, John Stevens <jste...@samoyed.ftc.nrcs.usda.gov>
>wrote:
>
>well established as other languages (e.g. Perl) and there isn't a huge
>marketing department forcing it into the consciousness of
>managers (e.g. Java or Visual Basic).
Not taken seriously due to lack of support.
We have commercial support for Perl, none for Python, so we use Perl for
all our little scripting tasks.
Besides, it is hard to get people to learn a new paradigm (OOP).
John S.
John Stevens
On 10 Apr 1997 07:29:49 GMT, Paul Svensson <pa...@lysator.liu.se> wrote:
>>> 5) Not released under GPL.
>>
>>Sorry, but this doesn't make sense. Why would it be an advantage to
>>ship Python under a more restrictive license?
>
>I believe this is a religious issue for some people.
Bingo. After all, wasn't this a reply to a request for opinions?
Don't like my opinions? Fine. . .
John S.
Guido van Rossum
> >I think that Python isn't taken seriously mostly because it isn't as
> >well established as other languages (e.g. Perl) and there isn't a huge
> >marketing department forcing it into the consciousness of
> >managers (e.g. Java or Visual Basic).
>
> Not taken seriously due to lack of support.
>
> We have commercial support for Perl, none for Python, so we use Perl for
> all our little scripting tasks.
Point well taken. I expect that CNRI will start providing some form
of commercial support for Python later this year. In the mean time,
there are a number of companies (e.g. Automatrix, Digital Creations)
that I believe would gladly take care of your Perl programming needs.
--Guido van Rossum (home page: http://www.python.org/~guido/)
John Stevens
On 9 Apr 97 20:58:00 GMT, WILSHER THOMAS <wil...@ucsu.Colorado.EDU> wrote:
>jste...@samoyed.ftc.nrcs.usda.gov (John Stevens) writes:
>
>Hmmm, unless they have made some radical changes to Objective-C recently, that is
>incorrect -- there is no support for distributed objects in the _language_ per se.
Yah. But going into a discussion of Objective-C-as-a-NeXT-langauge wasn't
my intent.
You are perfectly correct, of course, but using Objective C without using
either the NeXT system, or some other OPENStep clone (I, of course, advocate
the use of GNUStep) is probably more work than it is worth. Since the
GNUStep base is quite far advanced, it makes sense to use it if you can.
>(Possibly by having a Proxy object that uses its __getattr__ and
>__setattr__ to do remote method invocation -- haven't really thought that one out yet)
>My guess is that for this task, python is "dynamic enough", as I usually the case in
>my experience. ;-)
Oh, sure. But the context at that point wasn't how dynamic the language was,
but how well it supported distributed objects.
I find that once I got through the rather extreme requirements for head
bashing (this package was the most difficult to compile and install of
any I have ever tried; I gave up on it twice, but kept coming back to
it because it was the best in terms of features available), ILU give
sufficiently good support for distribution (if a trifle slower than
absolutely necesary).
John S.
Guido van Rossum
I quoted:
> > >I think that Python isn't taken seriously mostly because it isn't as
> > >well established as other languages (e.g. Perl) and there isn't a huge
> > >marketing department forcing it into the consciousness of
> > >managers (e.g. Java or Visual Basic).
> >
> > Not taken seriously due to lack of support.
> >
> > We have commercial support for Perl, none for Python, so we use Perl for
> > all our little scripting tasks.
and replied:
> Point well taken. I expect that CNRI will start providing some form
> of commercial support for Python later this year. In the mean time,
> there are a number of companies (e.g. Automatrix, Digital Creations)
> that I believe would gladly take care of your Perl programming needs.
^^^^
Of course, I meant Java. Eh, Tcl. Eh, Scheme. Eh, Lisp. Eh, ML.
Eh, what was my favorite language's name again? Ah, got it. Python!
Red-facedly yours,
Thomas Wilsher
jste...@samoyed.ftc.nrcs.usda.gov (John Stevens) writes:
>On 9 Apr 97 20:58:00 GMT, WILSHER THOMAS <wil...@ucsu.Colorado.EDU> wrote:
>>jste...@samoyed.ftc.nrcs.usda.gov (John Stevens) writes:
>>
>>Hmmm, unless they have made some radical changes to Objective-C recently, that is
>>incorrect -- there is no support for distributed objects in the _language_ per se.
>Yah. But going into a discussion of Objective-C-as-a-NeXT-langauge wasn't
>my intent.
Nor was it mine. Let's back up a little: the discussion was about
Python likes and dislikes. You mentioned that one thing you would like
to see in Python was better support for distributed programming,
specifically mentioning Objective-C as an example. My point, which I
evidently could have stated clearer, is that the Objective-C _language_
has _no_ support for distributed programming -- no keywords, no primitives,
nada -- nor does it _need_ any such things. Due to the dynamic method dispatch of
Objective-C, NeXT was able to build their distributed objects seamlessly on top
of that language, without making any changes to the language itself. Since
Python is quite similar to Objective-C in this respect, I speculated that likewise
there should be no need to make any changes to Python itself in order
to build NeXTStep/GnuStep-style distributed objects. Fredrik L. pointed
out that this has indeed been done, which seems to verify my claim ;-)
>Oh, sure. But the context at that point wasn't how dynamic the language was,
>but how well it supported distributed objects.
As I mentioned above, sometimes those characteristics are related.
--thomas
Paul Everitt
GB wrote:
>
> > In the mean time,
> > there are a number of companies (e.g. Automatrix, Digital Creations)
> > that I believe would gladly take care of your Perl programming needs.
>
While my mother doesn't work here, even if she did, I don't think I
could teach her Perl. :^)
--
Paul Everitt Digital Creations
pa...@digicool.com 540.371.6909
## Python is my favorite language ##
## http://www.python.org/ ##
Dan Wilder
ra...@gco.apana.org.au writes:
[ ... ]
>Python is impressive and comes with excellent documentation ( Guido's
>tutorial is especially impressive as an introduction ). Most
>importantly, it seems to be supported by an active community of users
>like Linux is.
>I just deleted my Visual Eiffel installation today.
>For me, Python seems to be a better fit...
It would seem the two languages have rather different missions.
I don't think I'd want to write an operating system kernel in
Python. In Eiffel, it might be possible.
Eiffel is perhaps unwieldy for the quick one-off sysadmin
program to do some simple manipulation on a password file
or a runlevel table; Python might not make a very good choice
for large mission critical real-time software; say, a flight
computer.
Someplace in between expect to see a crossover where the
relative advantage shifts from one language to the other.
Some contrasts.
The absence of static typing in Python, while
contributing to quick development over some range of program
sizes, perhaps up to and including something like "grail,"
the Python browser, is bound to have adverse impact on
both development time and on reliablility, with increasing
scale, and as more programmers become involved in a project.
Grail provides another contrast. Compare its speed with
that of other browsers written in compiled languages. While
this may not matter in some contexts, the difference in
execution speed certainly will matter in others.
Python does have multiple inheritance, a step in the right
direction, with renaming of sorts to avoid name collisions.
Inheritance is liquidated (more or less) at each stage, also.
There is no implicit join of inherited methods; instead,
name collisions not otherwise handled, are resolved by
taking the first feature found in the built-in search order,
and ignoring any other features of the same name in the
inheritance tree. This beats declaring an error and requiring
that the ancestors be revised, but it may have some unexpected
results. And it fails to provide the type safety that comes
with the join rules.
The syntax of references within classes becomes tedious, as
one types self.this, self.that, self.the_other over and over
and over again.
Rumor has it Python may incorporate some form of design by
contract. How this might be done in a dynamic typed language is
an interesting question.
The amount of interest Python is generating on the internet is
heartening. As is the completely unencumbered licensing
(compare with Java), and the large class library containing many
more wrappers for C library functions than we are used to seeing
in Eiffel libraries.
I believe I would see Python as a more adequate alternative to
Java, however, than as a substite for Eiffel. The somewhat
surprising claims of the Java camp aside, the missions of the
various languages simply are not the same.
---
Dan Wilder
Brendan J. Rankin - vmGeek
Jason Orendorff <jore...@odin.cbu.edu> writes:
> > But please, post away and let me know your loves & hates (if any)
> > about Python !
> Hi, I'm a newbie to this newsgroup. I've been using python for
> maybe six months now. Here's what I like about python vs. other
> languages, besides what you already mentioned.
>
> . It byte-compiles.
> . It uses normal C-style notation for math, not some weird
> reverse-reverse polish notation like Lisp.
> . Emacs won't help me format my code "electrically". :o( If there is
> an emacs python-mode out there, someone please let me know.
>
> --
> jason
Jason,
There's an emacs mode at http://www.python.org/ftp/emacs/pmdetails.html. I believe it's also included with the latest version of xemacs (a program I highly recommend) at www.xemacs.org.
Enjoy,
Brendan