Why learn Python ??

[Michael Hudson]

Careful. If you were to make such a suggestion on comp.lang.lisp, then
you'd be likely to be told that learning Scheme first will cause you
irreversible brain damage. Of course, now that He Whose Name Must Not
Be Mentioned is no longer posting there,

Heeeeeeeeee's back!

Cheers,
mwh

 

[Jacek Generowicz]

Heeeeeeeeee's back!

Yes, kinda ironic that I happened to post this on the eve of his
return.

 

[Lothar Scholz]

EP wrote in message ...

I don't know *what* Google uses Python for, but it uses Python.

The old version of the google toolbar showed a special hint when
hovering over the page rank icon. At least the first spider was
written in python - there is nothing like a urban legend about this
fact. And it seems that python was used enthusiastic by the google
team.

I remember an article about google's spider in a pre 1998 issue of
germans 'CT' or 'IX' magazine, can't remember which one.

 

[Aahz]

EP wrote in message ...

I don't know *what* Google uses Python for, but it uses Python.

How about http://www.python.org/Jobs.html

 

[John J. Lee]

Grail wasn't huge but I think any serious browser qualifies as
substantial.

True, though not on the same scale as Zope, for example (or the others
I list below).

If you're saying it didn't really fail but actually
wasn't even seriously attempted,

Not sure what the goals were, but I'm not sure they were to compete
with Netscape and IE. CNRI funding -- "R" for research -- seems to
imply I do remember correctly (one of us should really check the facts
here... oh well, it's USENET ;-).

Do correct me if I'm wrong, but you seem to imply, in saying "wasn't
even seriously attempted", that if Grail wasn't intended to be a
Netscape-replacement, it must have had no purpose at all. That's
certainly not obvious to me.

ok, that's even fewer substantial
programs that have even been tried in Python.

The project stopped, according to the tarball, because CNRI didn't
want to allocate more money to it because of low usage compared to,
the big two of the day. Given that, what do we learn from Grail?

Well, what does the *existence* of Grail tell us (along with
similar-size projects like Mailman)? It tells us that projects at
least that large are feasible. What does the *ending* of Grail
development tell us about Python's suitability for development of
large projects? Not a lot: all we know is that it *didn't* run into
the problems that afflict large-scale projects (if you believe the
tarball README, anyway).

Others provided (in a different bit of the thread) at least one
example of a much larger system, solving a problem that would take a
best-estimate of on the order of a million lines of C++ code if solved
in C++. Other people posted examples in an thread last year:
eg. Peter Hansen with another project the same size as Zope (there
have been lots of other threads too, by the look of it -- but I
haven't scoured those for examples). Twisted is at least that big,
too (according to pycount.py run on the old version of Twisted that's
sitting on my hard drive -- again, it seems to spit out multiple total
lines, so I hope it's working right...!).

Of course, the above two paragraphs (implicitly) points out the big
joke here: it seems hard to dispute that reducing the number of lines
of code needed by an order of magnitude is a good way of reducing risk
on big projects. Now, what sort of language would you pick to achieve
that? C++ or Java? Or Lisp or Python?

not-holding-my-breath-for-your-answer-<wink>-ly y'rs,


John

 

[John J. Lee]

Python and C++ can also be a bigger mess than sum of either part.
Take your pick.

Not entirely sure what you mean, so I'll try and restate it:

You're saying that the C++ code for a Python extension is uglier than
the equivalent C++ code you'd write for a pure-C++ solution, where the
C++ code in question is that used to solve the *small part* of the
*whole* problem that you've farmed out to C++. Right?

Actually, I think that's only true if you're writing wrappers in C on
the C API level. Leaving that important point aside, though, the
choice we're discussing here is between:

1. Most code in Python, plus small amount (say 10 percent) of C/C++
code plus ugly code to wrap it (or the latter two mixed up
together, if you prefer).

2. All code in C++.


For cases where it meets the performance requirements, 1 is preferable
to 2 because, even given an overhead of ugliness (which I dispute,
thanks to SWIG and Boost Python) in that 10 percent of the problem
recoded in C++, you make a saving on the other 90 percent that (far!)
more than compensates. A ratio of 5-10 in terms of lines of code is
often quoted, and that ratio applies to 90% of the project.


John

 

[Cameron Laird]

.
.
.

Not sure what the goals were, but I'm not sure they were to compete
with Netscape and IE. CNRI funding -- "R" for research -- seems to

.
.
.
Certainly not the *original* goal, because Grail antedated those latecomers.

 

[Jeff Epler]

according to pycount.py run on the old version of Twisted that's
sitting on my hard drive -- again, it seems to spit out multiple total
lines, so I hope it's working right...!

"find | xargs foo" can invoke foo multiple times. linux has a
surprisingly small upper bound on commandline length, on the order of
a 128k, and xargs is probably more conserative than that.
32512

Jeff

 

[John J. Lee]

It *seems* so when you first learn it...


... and they never end! Ilya Zakharevich (a "Perl God"):

[...]

Can't resist another bit of Perl-bashing: I just noticed this bit of
the FSF's license page. There's an amusing (and not accidental, I
think) parallel between the language and its license:

http://www.fsf.org/licenses/license-list.html

The (Original) Artistic License.
We cannot say that this is a free software license because it is
too vague; some passages are too clever for their own good, and
their meaning is not clear. We urge you to avoid using
it,[snip...]


John

 

[JanC]

(e-mail address removed) (Cameron Laird) schreef:

Certainly not the *original* goal, because Grail antedated those
latecomers.

My copy of Netscape 0.94beta for Windows has a file date of 1994-11-22.

And from the Grail docs:
"Grail was started in August 1995 as a quick and dirty demo. It quickly
became a serious project, as witnessed by the release of version 0.2 in
November 1995, and again by the planned release of version 0.3 (currently
in beta) in June 1996."

 

[Christos TZOTZIOY Georgiou]

<troll>
Woops ! The problem with Perl is actually that it's more or less a
write-only language !-)
</troll>

I think you mean Perl is a WORN language (Write Once, Read Never).

 

[Michael Hudson]

I think you mean Perl is a WORN language (Write Once, Read Never).

WORA (Write Once, Run Away)?

Cheers,
mwh

 

[Michael Hudson]

Not sure what the goals were, but I'm not sure they were to compete
with Netscape and IE. CNRI funding -- "R" for research -- seems to
imply I do remember correctly (one of us should really check the
facts here... oh well, it's USENET ;-).

I thought the purpose of grail was a test bed for research into mobile
agents, that being what most of the PythonLabs flok were working on at
CNRI. I'm probably no better informed than the rest of this thread,
though

Cheers,
mwh

 

[Cameron Laird]

(e-mail address removed) (Cameron Laird) schreef:



My copy of Netscape 0.94beta for Windows has a file date of 1994-11-22.

And from the Grail docs:
"Grail was started in August 1995 as a quick and dirty demo. It quickly
became a serious project, as witnessed by the release of version 0.2 in
November 1995, and again by the planned release of version 0.3 (currently
in beta) in June 1996."

.
.
.
Yikes! Good research--and I'm always in favor of that.
I apologize for my error. It's certainly disquieting;
I had such a strong memory that Grail was around in
mid-'94 that I didn't verify the facts. What *was* I
thinking about?

Thanks for correcting the mistake.

 

[JanC]

(e-mail address removed) (Cameron Laird) schreef:

Yikes! Good research--and I'm always in favor of that.
I apologize for my error. It's certainly disquieting;
I had such a strong memory that Grail was around in
mid-'94 that I didn't verify the facts. What *was* I
thinking about?

Well, I didn't know Grail was that old, so I went searching.

But Netscape was largely based on Mosaic anyway; being developed by the
same developers. The beta I was talking about above still has a Mosaic
logo. ;-)

 

[Andrew Dalke]

JanC:

But Netscape was largely based on Mosaic anyway; being developed by the
same developers. The beta I was talking about above still has a Mosaic
logo. ;-)

While it had many of the same developers, as I recall, none of the code was
shared. They were planning to call it Netscape Mosaic but that was
changed before the final release. Also, and again pulling out some old
memory here, Netscape paid UIUC a chunk of money just in case there
was some accidental copyright transfer because of not doing a pure
clean-room reimplementation. I think that was mentioned in the IPO
prospectus... but I'm not going to try and dig it up now.

Andrew
(e-mail address removed)

 

[Paul Boddie]

JanC:

While it had many of the same developers, as I recall, none of the code was
shared. They were planning to call it Netscape Mosaic but that was
changed before the final release.

It was actually called Mosaic Netscape for a time since the company
was originally called Mosaic Communications Corporation. Visit
http://www.mcom.com and see where it takes you! (Completely work safe,
I might add.) Now that's what I call long term domain name asset
management!

There seemed to be some fairly major differences between later
releases of Mosaic before NCSA pulled it (after licensing it to
various corporations) and Netscape Navigator - Navigator was threaded
even on Windows 3.1, and was clearly better supported on UNIX, Windows
and Mac. Still, it's amusing to consider Netscape 4.x and earlier as
having some common heritage with Internet Explorer.

As for Grail, it was certainly a "hot product" in the Python community
in 1995 because of the restricted execution environment which I
evaluated for a project involving mobile software agents. How
priorities and trends have changed since then! Who would have thought
that Microsoft Outlook would be the premier platform for mobile code?
;-)

Paul

 

[beliavsky]

(e-mail address removed) (Graham Dumpleton) wrote in message

Would agree that more often than not it is the programmers working
on the project. I have met very very few programmers who I thought
had what it takes to develop decent C++ code which is understandable
and maintainable. Part of the problem though is not the programmers
but the C++ libraries they have to work with. Even though the
STL may be the "standard template library", it is pretty dangerous stuff.
Your average programmer however will tell you it is wonderful stuff
and never understand its danger and how one can so easily create
huge disasters with it.

<SNIP>

What is so dangerous about the STL in C++?

 

[Rainer Deyke]

What is so dangerous about the STL in C++?

One thing is that iterators can get invalidated when the container is
modified.

 

[Aaron Watters]

C#: Java for MS .NET users (to first order, anyway). .NET has broader
goals than Java for language interoperation, so even though Jim Hugunin
and others have done some initial work on a .NET implementation of
Python, dynamic languages like Python will likely never be full .NET
citizens (thanks to the design of the .NET CLR). If that full
citizenship is important to you, C# has that advantage, but I'm
reliably informed it's fairly well-described as "a Java clone"
(implying programmer-inefficiency), so I'd be inclined to look for a
better language with a good .NET implementation. Lisp? Smalltalk?
(there was talk of an excellent .NET smalltalk implementation, but I'm
not sure whether that was vapourware or not...)

C# also fixes a lot of stupidities in java: for example a method can
"return" more than one new value and there is a syntax for first class-ish
callback methods (delegates) among the more prominent improvements.
Also C# is far friendlier to "legacy" code (than java was originally
intended to be).

From a pure code beauty point of view (or point of me/us ) Python
is still easier to read thanks to things like slicing,
list/dictionary displays, and keyword arguments
but type safety is a really big win for larger projects, and of course
C# is much faster.

And once you get some feeling for the namespace
hierarchy and the development environment I think it is a fairly
productive work environment. Maybe more productive than python?
There are some easily fixable problems/irritations --
like the way IO uses preallocated buffers in C++ style, which is
irritating but easy to wrap away. To my taste I'd definitely prefer
C# over lisp or smalltalk.

There is the portability thing, of course. And python is free...

OTOH *stackless* python has some *really* compelling advantages over C#
-- like the ability to feasibly manage thousands of microthreads,
which I wouldn't advise in C#, java, or "normal" python....

-- Aaron Watters
===
WIND THE FROG!