[Python] Why learn Python ??

As for AI, I would choose Prolog any time over Lisp. ;) I know either one
really but I had more fun with Prolog than with Lisp when playing with them.
You know the AI people are divided into two groups: 'the fuzzy' and 'the
tidy'. (Dunno these are the orginal phrases in English..)
The former ones are people of practice and little theory, the latter ones
are people of theory and more theory which works in practice. ;)
The former ones like Lisp and the latter ones use Prolog.
Lisp is prefered in the USA, Prolog is preferred in Europe and Japan.

Anyway, my point is that Python is very neat for doing AI:
http://www.cs.berkeley.edu/~russell/aima.html

This is the best AI textbook I've seen so far and their textbook code is
being put into Python...
Help them out.. ;)

Best,
Mikl?s


Bicho Verde <bichoverde at sapo.pt> wrote in message
news:40029dad$0$28706$a729d347 at news.telepac.pt...

I agree in large part with Paul's comments.

C# is Microsoft's baby though it's technically an open standard --
don't go there unless you have a reason.

Perl is pretty cool but I definitely found it harder to use and less
intuitive than Python.

I would not dismiss C++ (or even vanilla C) outright. I strongly
suggest starting in Python and looking to C and C++ when you have good
reason -- that is, when those languages will let you do something that
Python is less than than stellar at: large applications, system
software, performance-critical applications, embedded programming,
etc.

I would also add that while Lisp has been a favorite in the AI
community, you will find that most AI techniques generalize to most
any programming language. I spent a good deal of time in grad school
and on my first job doing AI programming in C++. The only time I used
Lisp was in introductory classes, mostly to write elegant -- but
toy -- programs.

I guess I didn't really answer the main question: Why learn Python
over Perl, C/C++, C#, etc.

In short, because it's easier to program, isn't tied to a platform,
and has lots of high-level functionality right out of the box.

Lest Derek give the impression that Lisp is in any way a "toy"
language, or that it somehow sacrifices practicality for elegance, I
feel honour bound to point out that it is actually the most powerful
and expressive programming language known to man, and excells in
solving problems which are often considered too hard to be solved in
other languages.

If you want to perform miracles, then learn Lisp. If you
merely want to write programs that rock, then learn Python.

:-)

If, however, masochism is more you bent, then I thoroughly recommend C++.

Jacek> Lest Derek give the impression that Lisp is in any way a
Jacek> "toy" language, or that it somehow sacrifices practicality
Jacek> for elegance, I feel honour bound to point out that it is
Jacek> actually the most powerful and expressive programming
Jacek> language known to man, and excells in solving problems
Jacek> which are often considered too hard to be solved in other
Jacek> languages.

Python will catch up Real Soon Now - there are so many Python+Lisp
projects in the works, soon we can implement all the impossible tasks
in the world by combining development speed of Python with macro magic
of Lisp for that final, "impossible" leap :-).

Jacek> -- Greenspun's Tenth Rule of Programming:

Jacek> Greenspun's Tenth Rule of Programming: "Any sufficiently
Jacek> complicated C or Fortran program contains an ad-hoc,
Jacek> informally-specified, bug-ridden, slow implementation of
Jacek> half of Common Lisp."

At least they should have implemented scheme instead.

I meant no disrespect to Lisp. My intention was only to point out
that it's quite possible to carry out AI programming in other
languages, albeit less miraculously. :)

Jacek Generowicz <jacek.generowicz at cern.ch> writes:
[...]
[...]

...and then somebody argues that macros aren't a programming language
feature, but a harmful means of inventing new languages, and then we
get into that endless macro thread again...


John

Well they're all Nazis.

Godwin's Law !

You lose !

Nah na-na naaa nah !

Game over.

(And I'll predend I've never heard of Quirk's Exception, so I'm outa
here.)

I believe Godwin's Law was meant to be descriptive, not prescriptive.
HAND.

Cheers,
mwh

In article <btubno$bd8k6$1 at ID-46268.news.uni-berlin.de>,
Derek wrote:
.
.
.
.
.
.
I contest the proposition that "Python is less than stellar at
large applications ...", and, in particular, that C++ is super-
ior there. I recognize you're not alone in that; for me, though,
large-scale programming is one of Python's *strengths*.

I don't have a good decision mechanism to propose. Trial by
ordeal (and most large-team projects fit in that category) seems
as apt as any.
--

Cameron Laird <claird at phaseit.net>
Business: http://www.Phaseit.net


From http Mon Jan 12 22:46:38 2004
From: http (Paul Rubin)
Date: 12 Jan 2004 13:46:38 -0800
Subject: C++ bad-mouthing (was: Why learn Python ??)
References: <40029dad$0$28706$a729d347@news.telepac.pt>
<7xisjh1e3i.fsf@ruckus.brouhaha.com>
<10064loqc7sd7e3@corp.supernews.com>
Message-ID: <7xeku496wx.fsf@ruckus.brouhaha.com>

claird at lairds.com (Cameron Laird) writes:
C++ was motivated by the problems faced by big projects written in C.
I'm talking about stuff like telephone switches with hundreds of
programmers and millions of lines of code. Even with very competent
designers and managers, those projects usually ran amuck. C++ gives
some real help in keeping projects like that functioning, if the
programmers and managers know what they're doing. If they don't know
what they're doing (as is the case in most projects), C++ isn't that
likely to help and may make the problems worse.

But if you've lived through the multitudinous nightmares of projects
like that, and you then read Stroustrup's book about C++, on just
about every page you'll see some feature described and you'll
recognize the specific nightmare that inspired it. If you haven't
experienced those nightmares yourself, I can't be sure but I think the
feature descriptions will just seem like feature descriptions and
you won't understand the real reasons why they're there.

I think the OP's list should also have included Java, which is sort of
a modernized, "discount" version of C++.

All I know is that there are thousands of extremely large projects
written in C++, some consisting of millions of lines of code written
by hundreds of developers. C++, while far from perfect, has proven
its worth on a huge scale. Python, at the very least, has yet to do
so.

"Derek" <none at none.com> writes:
[...]
See a recent thread here listing some fairly large Python projects.

Of course, taking lines of code at face value is rather like talking
about waiting lists instead of waiting times...


John

Point taken. I once worked on a project where we implemented a
production system in C++ and then implemented it again in Python for
QA purposes. It took about 150k lines of C++ code and 10k lines of
Python. Python took less code because so many modules are bundled
with the language, but the C++ system ran many times faster. It's all
about picking the right tool for the job.

"Derek" <none at none.com> writes:
[...]
Well, that's a banal truism obscuring the fact that, for the great
majority of projects, optimisation does not require implementation of
the *entire* system in a language like C++. The sum of C++ and Python
is greater than the parts.


John

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

Look at how many modules in the stdlib are not implemented in Python.
Look at all the builtin types. It *can* and *does* work, and with very
little mess, if you know what you're doing.

Jp

They're also not implemented in C++. They're implemented in C, a very
different language. And they *are* a mess compared to C code that doesn't
have to interface with Python.

[...]
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

Is it true that the original Google spider was written in Python?

I came across a paper on the web some time back that I saved and read just
last night:


The Anatomy of a Large-Scale Hypertextual Web Search Engine

Sergey Brin and Lawrence Page
{sergey, page}@cs.stanford.edu
Computer Science Department, Stanford University, Stanford, CA 94305

A neat read, but I'm not sure of the authenticity of the paper: I could be
gullible. It would appear to be a paper written some years back on the
genesis of the Google search engine.

[excerpt]
Running a web crawler is a challenging task. There are tricky performance
and reliability issues and even more importantly, there are social issues.
Crawling is the most fragile application since it involves interacting with
hundreds of thousands of web servers and various name servers which are all
beyond the control of the system.
In order to scale to hundreds of millions of web pages, Google has a fast
distributed crawling system. A single URLserver serves lists of URLs to a
number of crawlers (we typically ran about 3). Both the URLserver and the
crawlers are implemented in Python. Each crawler keeps roughly 300
connections open at once. This is necessary to retrieve web pages at a fast
enough pace. At peak speeds, the system can crawl over 100 web pages per
second using four crawlers. This amounts to roughly 600K per second of
data. A major performance stress is DNS lookup. Each crawler maintains a
its own DNS cache so it does not need to do a DNS lookup before crawling
each document. Each of the hundreds of connections can be in a number of
different states: looking up DNS, connecting to host, sending request, and
receiving response. These factors make the crawler a complex component of
the system. It uses asynchronous IO to manage events, and a number of
queues to move page fetches from state to state.
[/excerpt]

It would seem like the poster boy example for using Python in some
respects, if true.


Eric, Intrigued

"but at least I didn't top post"

EP wrote in message ...
Um, nothing new about this:

http://python.org

Read the top center of the front page....

"Francis Avila" <francisgavila at yahoo.com> wrote in message news:<1009fum3evnc96a at corp.supernews.com>...
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.

In article <1009fum3evnc96a at corp.supernews.com>,
Francis Avila wrote:
How about http://www.python.org/Jobs.html

Bicho> I have now free time and money to do what I want :-) I have
Bicho> some basic skills in programming (C, Pascal, Macromedia
Bicho> Actionscript) but don't know exactly what to do in the
Bicho> world of programming. And also I don't know exactly why
Bicho> would I learn Python rather than C#, C++ or Perl. Basicaly

Well, I assume you want to have fun programming, and that kinda rules
out C# and (especially) C++. They don't really have the favourable
effort/gratification ratio of Python. If you want to get something
done, choose Python. If covering your ass if/when your project fails
is more important than actually succeeding, choose more
conservatively, which means Java/C++/C#. Since you are on your own in
this, Python is an excellent choice.

If you choose Perl, you will at some regret your choice and consider
porting the app to Python. You save a lot of time/frustration by not
going there in the first place.

Bicho> I don't know where to start, if there is much to do or if
Bicho> it is has it seems and there is software to everything
Bicho> nowadays and so doesn't make sense to spend time in
Bicho> learning a programming language. I just have this idea

There really isn't software to do all those little script-level tasks
you need to do every now and then, so learning Python is still not a
lost cause even if you never get anything bigger done. Also, writing a
Python script is often faster than searching for a program to do the
thing and then learning how to use that program. It's also more fun.

Bicho> that I would like to contribute to the curve of accelarated
Bicho> exponential progress (technological singularity),
Bicho> artificial intelligence and so on. From that point of view
Bicho> there is much to do... But can I stand for it and where to
Bicho> start? Anyone would help me and give me some hints?

Learn Python first, the ease of programming can quite possibly inspire
you to create something interesting.

This is true. Learn Python and *then* learn other languages. Learn as
many languages as you like. Python will teach you how to think when
writing programs. This thought process will be the same for C, C++,
Perl, etc. As a bonus, Python can be applied to solving real-world
problems as well. So, you get the best of both worlds:

1. A theorhetical language that easily teaches the concepts of modern
computer programming.

2. A practical language that is actually useful for doing things.

Python is also easy to read compared to other languages. It's much
easier to learn. Its syntax doesn't get in the way of learning like C
++, or other language's syntax can. It's fun too.

Best of luck,

Bart

This is only true if you actually know Python. If you carefully avoid
acquiring any knowledge of or ability in Python, you will rarely regret
the decision not to use Python for your project. <wink>

-Peter

Group : comp.lang.python
If I would have enough money and free time to do what I want, I would
*stop* programming....
But if you insist on wanting to write software, Python is a **very**
good choice.


--
Rony

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
/ bucodi_no_spam at yahoo.fr (delete _no_spam)
/
\ www.ifrance/karamusic -- My hobby
\_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

- C# is like a MS-specific Java.
- C++ is for system programming where performance is important. I love
C++ but I think it was Herb Sutter (a C++ guru) who described C++ as a
"last resort language" and I must agree.
- Perl is also a very nice language, but I would suggest to basically
see it as a parsing language and Perl 6 will make perl even better in
that domain with built-in support for grammars. And knowing a parsing
language is a very good thing. However, for other than that, even if
Perl has all the functionality, Python is cleaner, simpler and more
structured and elegant.

If you're interested in AI, I strongly suggest to look at functional
languages like Lisp dialects.

Don't be afraid to learn many languages, that's the way you will learn
what is strong about each of them, and that we basically need them all;)

Regards,

Nicolas

Go to the Bahamas. You'll enjoy it more.

[chop]
Here's my two cents on which languages to learn, why and in what order.

Python:
Python is probably the best language from which to branch out to other
languages. If you learn it well, you will have all the major concepts of
programming as part of your mental toolkit. Luckily, Python's learning
curve is not at all steep, there's a great and wonderful community that
gladly answers questions and helps you through the confusing parts. As a
bonus, you'll find that it's terribly, dastardly useful.

C:
In my opinion, this is where a student should move next. At some point or
another, every serious programmer has to dig into some C code. It's
important to learn C before C++ because many of the conveniences of C++
make one lazy about learning C. Because of it's vast popularity, you can
often find resources that give algorithms and outlines of processes in C,
and those ideas can then be applied to your language of choice. Be sure
to investigate linked lists, trees, hashing and memory allocation methods
and other such "not quite basic" constructs in C. From those, you will
understand a lot more of what goes on behind the scenes in other
languages.

C++:
If you've learned C, It's good to move onto C++ if only for the sake of
completeness. When I first learned C++, I was completely enamored of it,
but that crush has since died. It's important in GUI based applications
and gives you a fair grounding in Object Oriented programming. I strongly
recommend Bruce Eckel's "Thinking in C++" as a guide to the language
*after* you've gotten the basics down. It is available for free online,
but I'm glad I bought the dead tree version of it. There is some debate
as to how useful C++ is, but I think it's at least useful enough to take
some time learning well.

Lisp/Scheme:
Lisp and Scheme are two languages that people claim will give you
Jedi-like powers as a programmer. I'm learning them right now, so I can't
give you advice on why one would learn them. I'm learning Scheme first,
because there seem to be many more introductory tutorials and a lot of
advice that one should learn Scheme, then move to Common Lisp. YMMV. If
you like AI, at some point you will run across Lisp code, so it should be
of particular interest to you. In short, the consensus is that Lisp, like
milk, does a body good.

It is my philosophy that one should at least learn enough of a lot of
languages that you can at least browse some code without feeling lost.
Each new language gives you some new ideas that make you better at other
languages.

What follows is the minimum I would suggest you familiarize yourself with.

Sed/Awk/Bash shell Scripting:
Sed, Awk and bash shell scripting get tossed around enough that you should
be able to read them. Sed and Awk are confusing at first, and take some
measure of work to develop even a minimum competency in. Don't give up
easily here. It pays off in the long run.

Perl:
I don't like perl, but you shouldn't judge a language on my opinion of it.
Perl is very popular and is worthy understanding the basics of. Even if
you don't like it, learn enough of it to read programs written in it. It
is a very important language. Perl is easier to learn once you have
mastered Sed and Awk. (and vice versa) In many ways Perl is a souped up
combination of the two languages that's been imbued with mutant
super-powers.

Java:
Once you have learned C++, it's almost trivial to learn Java. The hardest
part is keeping separate in your head what applies to C++ and what applies
to Java. Besides, it's not a bad thing to be able to put on your resume.

C# and .Net:
I fear that C# is just another Microsoft misadventure, but for now it's
worth gaining a cursory knowledge of. If nothing else, it's a buzzword
compliant way to build your resume. Though, Microsoft can be a tricky
devil, so think carefully before you bank a career on something they
control.

PHP:
PHP has it's fair share of warts, but reading a couple of books on it
gives you a strong grounding in the issues a dynamic web-based application
faces.

Assembly:
Research carefully, and find a good book on assembly language programming.
Spend some time wrestling with it. It's hard and confusing. You may
never again touch a lick of assembly in your life, but you will always be
glad for the knowledge it gave you. Assembly is more of a long term
project than any of the other languages I've mentioned, so go slow here.

And always remember:

Programming is not a spectator sport.

Close the book often and try to write code from memory.

HTH

Good Luck!

Sam Walters.

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, the words which will be used
to point this out will probably be less colourful.

:-)

Heeeeeeeeee's back!

Cheers,
mwh

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

Samuel Walters <swalters_usenet at yahoo.com> wrote in message news:<pan.2004.01.12.20.18.36.606924 at yahoo.com>...
I can think of two situations:

1. You want to learn more about programming.
2: You want to implement your own programming language.

About 1: Lisp/Scheme are traditionally at the frontier of the research
in programming languages, so they have everything (Common Lisp) or
you can easily implement everything (Scheme). So, when you have learned
Lisp/Scheme, you have learned nearly every concepts in programming.
This is the reason why (IMHO opinion) you should not try to learn them
as first languages, especially Common Lisp. It is too difficult.
Learn Python first!

About 2: if you want to implement a programming language, it is much
easier to write it on top of Lisp/Scheme (thanks to the macro facility)
than to write it from scratch. Of, course, if you want performance,
you would implement it in C, but still Lisp/Scheme can be useful to
prototype it.

Apart for these two situations, I would stay with Python. Just my 2 eurocents,

Michele

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

Bruno

On Tue, 13 Jan 2004 12:21:00 +0100, rumours say that Bruno Desthuilliers
<bdesth.tagada at tsoin-tsoin.free.fr> might have written:
I think you mean Perl is a WORN language (Write Once, Read Never).

WORA (Write Once, Run Away)?

Cheers,
mwh

As usual, someone else already said it better than I can:

"Why Python?" by Eric S. Raymond
http://www.linuxjournal.com/article.php?sid882

--IAN

In article <7xisjh1e3i.fsf at ruckus.brouhaha.com>,
Paul Rubin wrote:
.
.
.
.
.
.
And if you *are* working on a big multi-person project, and you
choose C++, you're likely to end up with ... a big mess.

I get to say so. I'm fond of C++, and have seen plenty of pro-
jects which rely on it. I've also seen the teams assigned to
such projects ...

Paul Rubin <http://phr.cx at NOSPAM.invalid> writes:
[...]
[...]

If you're doing a comparative study of C and C++, that's true.

But many, many other languages that don't suffer from C++'s absurd
baggage also provide that kind of scalability (in terms of function
points -- nobody cares about lines of code). The consensus seems to
be that the root causes of C++'s baggage are C-compatibility and
efficiency, not primarily the demands of large projects.


John

In article <7xeku496wx.fsf at ruckus.brouhaha.com>,
Paul Rubin wrote:
Hm, to me this proposition seems too self-reliant. If the
designers and managers fail to thrive on C++, then Q.E.D. -
must not have known what they were doing.

At any rate, as you note, there are other languages such as
Java that may or may not (can't say from experience) offer
some or all of the benefits without the worst problems. Your
telephone switch example reminds me to mention Erlang, which
is by no means an attempt to offer any of C++'s features but
seems to work in that space.

I don't know if we're on very solid ground from which to laugh
at C++, though. Python has the advantage of a clean start, but
from a software engineering standpoint it really seems like a
hacker language. Full of neat tricks that work like magic, but
does it really even attempt to offer anything in the area you're
talking about?

If so, that might be a good direction for yet another book about
Python.

Donn Cave, donn at u.washington.edu

In article <donn-9D2291.16343412012004 at nntp6.u.washington.edu>,
Donn Cave wrote:
.
.
.
I sure think so; if only I were a man of leisure, writing *Programming
in the Large with Python* would be verrrrrry tempting.
--

Cameron Laird <claird at phaseit.net>
Business: http://www.Phaseit.net


From http Tue Jan 13 02:10:37 2004
From: http (Paul Rubin)
Date: 12 Jan 2004 17:10:37 -0800
Subject: C++ bad-mouthing (was: Why learn Python ??)
References: <40029dad$0$28706$a729d347@news.telepac.pt>
<7xisjh1e3i.fsf@ruckus.brouhaha.com>
<10064loqc7sd7e3@corp.supernews.com>
<7xeku496wx.fsf@ruckus.brouhaha.com>
<donn-9D2291.16343412012004@nntp6.u.washington.edu>
Message-ID: <7xhdz08xgy.fsf@ruckus.brouhaha.com>

Donn Cave <donn at u.washington.edu> writes:
It makes some feeble ones but is somewhat hobbled by its origins as a
scripting or "glue" language. Also, Python is really still in its
infancy. Maybe after PyPy is completed, someone can try writing a
serious compiler for it, and the issues brought out by writing the
compiler can drive the design of a successor language, Python II or
whatever.

The one attempt I know of to write a substantial Python application
competitive with similar applications written in C was the Grail web
browser, and AFAIK that was a complete failure. However, for small to
medium sized projects which don't have to run fast, Python is great.

Quoth Paul Rubin <http://phr.cx at NOSPAM.invalid>:
...
Well, egads. Grail is a Python/Tcl/Tk hybrid, and I think one
of the problems with that it complicates the optimization phase.
Plus the official objective never did seem to be to compete with
similar applications, rather they would say they were primarily
writing a document viewing tool for CRNI and it was just a coincidence
that it happened to be a nice web browser. Was a bit slow, but did
have some nice touches.

But at any rate, I thought we were talking about huge projects
involving many programmers, and I don't think Grail was of that
sort at all. I don't know what kind of programmer resources were
allocated to it, but I bet it was actually a smashing success in
those terms. As for its size, I'd have to look, I have the code
around somewhere, but I'd guess it was smaller than Mailman or Zope.
Small enough that one programmer could become pretty thoroughly
acquainted with the whole thing.

Donn Cave, donn at drizzle.com

[...]
Right. Wasn't it a research project? In any case, hardly a
large-scale programming effort along the lines of Mozilla!

No obvious attribution other than "CNRI" in the tarball, but I think
mostly Guido. :-)

john[0]$ find /usr/local/src/python/grail-0.6 -name '*.py' | xargs /home/john/bin/pycount.py
lines code doc comment blank file
[...]
34808 25255 2801 2356 4396 total

pycount reports 108756 code lines for Zope 2.6.3 (watch out: for some
reason pycount spits out more than one total line with Zope, which you
then have to add up -- maybe I'm doing something wrong there...).
Given typical reported ratios of Python to C++ lines of code, that's a
lot of code (not to mention all the Zope Python code outside of that
package -- plone, for example; there's a fair amount of C code there,
too, of course). Alex Martelli claimed a C++/Python lines of code per
function point ratio of 5 or 6 in a post in this group -- if you
believe that's a fair rule of thumb, then on that basis you'd expect
550-650 kLoC for a mythical Zope-in-C++ . In reality, since Zope
takes advantage of Python's features, you'd expect to have to write
many more lines of C++ than that, following Greenspun's tenth law.

Who can be sure what the biggest Python code is, though? See Paul
Graham's article on his web store-builder (implemented in Lisp) for
one motivation for keeping it a secret (a motivation of the order of
several tens of millions of dollars, IIRC ;-).

http://www.paulgraham.com/avg.html


(pycount reports 21730 code lines for mailman 2.1.4, BTW)


John

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

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.

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

In article <878yka2sze.fsf at pobox.com>, John J. Lee wrote:
.
.
.
.
.
.
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."

In article <Xns94711F202CED8JanC at 213.119.4.35>,
JanC wrote:
.
.
.
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.

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. ;-)

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
dalke at dalkescientific.com

"Andrew Dalke" <adalke at mindspring.com> wrote in message news:<ALMNb.11700$1e.231 at newsread2.news.pas.earthlink.net>...
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