Why learn Python ??
Paul Rubin
> And also I don't know exactly why would I learn Python rather than C#,
> C++ or Perl. Basicaly I don't know where to start, if there is much to do or
> if it is has it seems and there is software to everything nowadays and so
> doesn't make sense to spend time in learning a programming language.
I'd say don't bother with C++ unless you're working on a big
multi-person project. Its design will make no sense to you unless
you've faced the problems that come up in those projects. Otherwise
it's a big mess.
Perl has its fans and I can't promise you won't be one. It's built
like a natural (spoken) language, that is, it wasn't designed, it just
sort of evolved, and has all kinds of specialized rules and exceptions
and multiple ways of doing the same thing. Some people think that's
great. Others (most Python fans) think Perl is a big mess. The book
"Learning Perl" by Schwartz and Christiensen is definitely very good,
so you might look at it to decide if you like Perl. But note that the
book only scratches the surface, and Perl gets messier the deeper you go.
C# is mostly Microsoft-specific and not much serious is done with it, IMO.
> I just have this idea that I would like to contribute to the curve of
> accelarated exponential progress (technological singularity), artificial
> intelligence and so on. From that point of view there is much to do... But
> can I stand for it and where to start?
> Anyone would help me and give me some hints?
Traditionally that kind of research has been done in Lisp. You could
look at Winston and Horn's book on Lisp, which is also a reasonably
good introduction to AI methods.
Derek
> I have now free time and money to do what I want :-)
>
> I have some basic skills in programming (C, Pascal,
> Macromedia Actionscript) but don't know exactly what to do
> in the world of programming.
>
> And also I don't know exactly why would I learn Python
> rather than C#, C++ or Perl. Basicaly I don't know where
> to start, if there is much to do or if it is has it seems
> and there is software to everything nowadays and so
> doesn't make sense to spend time in learning a programming
> language.
>
> to the curve of accelarated exponential progress
> (technological singularity), artificial intelligence and so
> on. From that point of view there is much to do... But can
> I stand for it and where to start?
>
> Anyone would help me and give me some hints?
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.
Derek
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.
Jacek Generowicz
> 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.
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++.
--
Greenspun's Tenth Rule of Programming:
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated
C or Fortran program contains an ad-hoc, informally-specified,
bug-ridden, slow implementation of half of Common Lisp."
Ville Vainio
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.
--
Ville Vainio http://www.students.tut.fi/~vainio24
Ville Vainio
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.
Bart Nessux
> 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
Peter Hansen
>
> 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.
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
Rony
> I have now free time and money to do what I want :-)
> .....
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_...@yahoo.fr (delete _no_spam)
/
| www.bucodi.com - My work
\ www.ifrance/karamusic -- My hobby
\_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Derek
>
> > 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.
>
> 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.
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. :)
Nicolas Fleury
> Anyone would help me and give me some hints?
- 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
Samuel Walters
13:05:19 +0000|
> I have now free time and money to do what I want :-)
Go to the Bahamas. You'll enjoy it more.
[chop]
> Anyone would help me and give me some hints?
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.
--
Never forget the halloween documents.
http://www.opensource.org/halloween/
""" Where will Microsoft try to drag you today?
Do you really want to go there?"""
ian
> And also I don't know exactly why would I learn Python rather than C#,
> C++ or Perl.
As usual, someone else already said it better than I can:
"Why Python?" by Eric S. Raymond
http://www.linuxjournal.com/article.php?sid=3882
--IAN
Cameron Laird
Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
.
.
.
>I'd say don't bother with C++ unless you're working on a big
>multi-person project. Its design will make no sense to you unless
>you've faced the problems that come up in those projects. Otherwise
>it's a big mess.
.
.
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 ...
--
Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net
Cameron Laird
Derek <no...@none.com> wrote:
.
.
.
>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 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.
Paul Rubin
> >I'd say don't bother with C++ unless you're working on a big
> >multi-person project. Its design will make no sense to you unless
> >you've faced the problems that come up in those projects. Otherwise
> >it's a big mess.
>
> choose C++, you're likely to end up with ... a big mess.
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++.
Derek
> 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.
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.
John J. Lee
[...]
> 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
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
John J. Lee
[...]
> If you want to perform miracles, then learn Lisp. If you
> merely want to write programs that rock, then learn Python.
...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
John J. Lee
[...]
> 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.
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
John J. Lee
[...]
> I have some basic skills in programming (C, Pascal, Macromedia
> Actionscript) but don't know exactly what to do in the world of programming.
If you just want to motivate yourself for some semi-arbitrary project,
my advice is to start using some open-source software. All software
sucks, so you'll eventually find something that pisses you off enough
to make you want to fix it or do it from scratch, properly :-)
> And also I don't know exactly why would I learn Python rather than C#,
> C++ or Perl.
They are all very different languages. Trawl through google groups --
comp.lang.python is a great place to look for comments on all three
(but I would say that). Try some of Alex Martelli's posts. I used to
default to the widely-held position that "language wars" are mostly
content-free "religious" arguments, but experience has taught me
otherwise. There are big, important, differences in programmer
efficiency, in computer-resource efficiency, and in community support.
And, to some extent, in the ways they make you think about problems.
The issues are subtle and complicated, and understanding them requires
writing programs in a set of languages diverse enough to come
somewhere vaguely close to spanning the big space of language-design
possibilities.
I'm feeling particularly self-indulgent, so here are a bunch that seem
notable current players to me:
Python: All-round pragmatic winner, and elegant to boot. One
disadvantage: you'll struggle to motivate yourself to learn any other
language once you've used it ;-)
Perl: CPAN is great; the language is merely an insane version of Python
(yes, Perl does predate Python).
C++: No compromises on execution speed; plays well with C (and with
Python: check out Boost Python); horrendously complicated; no garbage
collector (unless you add one yourself, but then you'd be better off
mixing C++ with a saner language). Notable for "templates".
C: Needs no introduction!
Java: Solid security model; piles of code; shockingly mediocre language,
to the extent that there would be precious few sane uses of the thing
were it not for Jython and all those libraries (but watch out for over-
engineering).
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...)
O'Caml: Excellent execution speed without C/C++'s unpleasant bugs.
Functional (in the technical sense), with elegant static type
inference, but multi-paradigm: you can write procedural code too.
Requires a different way of thinking to procedural languages for best
use. Nasty syntax. O'Reilly book in English and French.
Haskell: Another functional language (like O'Caml); good for forcing you
to think functionally; lazy evaluation. Lots of good books.
Fortran: Still rules for some numerical analysis work.
Lisp: Powerful, elegant and well-established, but it has been argued
(see recent threads here) that Lisp macros are not best described as a
language feature, but rather as a harmful, Babel-inducing, tool for
making new languages.
Scheme: Cleaned-up version of Lisp. Beautifully simple. Suffers from a
splintering of the user community thanks to a multitude of subtly
different implementations. Worth learning just to read Abelsson &
Sussman's (sp?) freely-downloadable book "Structure and Interpretation
of Computer Programs".
Eiffel: Design by contract. The book to read is Meyer's "Object-
Oriented Software Construction". Full of interesting stuff, if you can
stand his self-importance ;-).
Lua: Pint-sized Python.
Erlang: Concurrent programming.
Ruby: Python with a smaller user community (unless you're Japanese),
some minor wins and losses, and a very questionable design decision or
two thrown in (see numerous threads on this group).
Smalltalk: Never tried it, but sounds interesting, and similar to Python
in some ways.
Oz: Prolog for the 21st century (OK, I admit I haven't a clue what it's
like really, but I have to try it some day...).
Mathematica and Maple: Heaven, if you're into maths.
Alex Martelli has pointed out the brain-stretching value of learning
languages of a different nature (some of which aren't Turing
complete): including query languages (eg. SQL) and markup languages
(eg. XML).
Everybody here will tell you this, but I'm going to say it yet again:
don't be so foolish as to think you have to write *all* your code in a
language like C++ (or C, or Fortran, depending on the use) just
because you want the program as a whole to run fast.
And take the current myopic view of static typing (in the eyes of the
great unwashed programming public) with a bucket of salt.
> Basicaly I don't know where to start, if there is much to do or
> if it is has it seems and there is software to everything nowadays and so
> doesn't make sense to spend time in learning a programming language.
>
> I just have this idea that I would like to contribute to the curve of
> accelarated exponential progress (technological singularity), artificial
> intelligence and so on. From that point of view there is much to do... But
You should be able to get that lot done in a weekend, no? <wink>
Really, if you buy the notion of a technological singularity, you've
got me well-and-truly puzzled as to how you fit that into your brain
at the same time as believing that "there is software to everything
[sic] nowadays"!
> can I stand for it and where to start?
Small?... and, of course, keep your eyes peeled for something you
think really matters.
John
Rick Muller
> And also I don't know exactly why would I learn Python rather than C#,
> C++ or Perl.
I'd like to take a slightly different perspective on why you should
learn Python: it's simply more fun that the other languages. I know
lots of programming languages, and many are useful, but python is the
only language that I actually look forward to programming in. There is
a real elegance to the syntax, and, once you get used to the whole
indenting thing, you can use python as a pseudocode or an outlining
language. The more you enjoy a language, the more you will use it, and
the better you will be at it.
Donn Cave
Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> cla...@lairds.com (Cameron Laird) writes:
> > >I'd say don't bother with C++ unless you're working on a big
> > >multi-person project. Its design will make no sense to you unless
> > >you've faced the problems that come up in those projects. Otherwise
> > >it's a big mess.
> >
> > 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.
>
> 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.
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, do...@u.washington.edu
Miklós
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 <bicho...@sapo.pt> wrote in message
news:40029dad$0$28706$a729...@news.telepac.pt...
> I have now free time and money to do what I want :-)
> I have some basic skills in programming (C, Pascal, Macromedia
> Anyone would help me and give me some hints?
>
> -BichoVerde
Cameron Laird
.
[pages of marvelously
precise analysis]
.
.
>Eiffel: Design by contract. The book to read is Meyer's "Object-
> Oriented Software Construction". Full of interesting stuff, if you can
> stand his self-importance ;-).
.
.
Mostly I'm writing just to applaud--this post had a lot
of value to it. The largest quibble I could find in its
scores of lines was the failure to mention that *OOSC*
is valuable reading for OO programmers working in *any*
language, not just Eiffel. *OOSC* is like *SICP* in
that regards; it towers not just over the competition,
but also any apparent limit imposed by its language of
expression.
Anton Vredegoor
> I just have this idea that I would like to contribute to the curve of
>accelarated exponential progress (technological singularity), artificial
>intelligence and so on. From that point of view there is much to do... But
>can I stand for it and where to start?
> Anyone would help me and give me some hints?
Anton
Cameron Laird
Donn Cave <do...@u.washington.edu> wrote:
.
.
.
>If so, that might be a good direction for yet another book about
>Python.
>
> Donn Cave, do...@u.washington.edu
I sure think so; if only I were a man of leisure, writing *Programming
in the Large with Python* would be verrrrrry tempting.
Paul Rubin
> 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?
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.
Donn Cave
...
| 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.
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, do...@drizzle.com
Michele Simionato
> 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 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
Jacek Generowicz
Well they're all Nazis.
Jacek Generowicz's alter ego
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.)
Jacek Generowicz
> because there seem to be many more introductory tutorials and a lot of
> advice that one should learn Scheme, then move to Common Lisp.
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.
:-)
Graham Dumpleton
> In article <7xisjh1...@ruckus.brouhaha.com>,
> Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> .
> .
> .
> >I'd say don't bother with C++ unless you're working on a big
> >multi-person project. Its design will make no sense to you unless
> >you've faced the problems that come up in those projects. Otherwise
> >it's a big mess.
> .
> .
> .
> 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 ...
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. Part of the utility of Python is thus not so much
the language itself, but the availability of useful modules to go with
it. I wouldn't say all the Python modules are perfect, some could
certainly have done with a bit more thought, but it certainly gives
a Python programmer a head start over a C++ programmer.
Bruno Desthuilliers
> |Thus Spake Bicho Verde On the now historical date of Mon, 12 Jan 2004
> 13:05:19 +0000|
>
>
>>I have now free time and money to do what I want :-)
>
> Go to the Bahamas. You'll enjoy it more.
>
> [chop]
>
>
>> Anyone would help me and give me some hints?
>
>
> Here's my two cents on which languages to learn, why and in what order.
>
>
> 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.
<troll>
Woops ! The problem with Perl is actually that it's more or less a
write-only language !-)
</troll>
Bruno
Michael Hudson
I would also say that OOSC is one of those books that's at least as
interesting when it's *wrong* than when it's right.
Cheers,
mwh
--
You sound surprised. We're talking about a government department
here - they have procedures, not intelligence.
-- Ben Hutchings, cam.misc
Michael Hudson
> Jacek Generowicz <jacek.ge...@cern.ch> writes:
>
> > j...@pobox.com (John J. Lee) writes:
> >
> > > Jacek Generowicz <jacek.ge...@cern.ch> writes:
> > > [...]
> > > > If you want to perform miracles, then learn Lisp. If you
> > > > merely want to write programs that rock, then learn Python.
> > > [...]
> > >
> > > ...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...
> >
> > Well they're all Nazis.
>
> Godwin's Law !
I believe Godwin's Law was meant to be descriptive, not prescriptive.
HAND.
Cheers,
mwh
--
LINTILLA: You could take some evening classes.
ARTHUR: What, here?
LINTILLA: Yes, I've got a bottle of them. Little pink ones.
-- The Hitch-Hikers Guide to the Galaxy, Episode 12
David M. Cook
> I have now free time and money to do what I want :-)
> I have some basic skills in programming (C, Pascal, Macromedia
> Actionscript) but don't know exactly what to do in the world of programming.
> And also I don't know exactly why would I learn Python rather than C#,
> C++ or Perl. Basicaly I don't know where to start, if there is much to do or
You could casually pick up enough Python to be useful in a week or so of
evenings.
Perl is not much harder, but has a lot of "gotchas". I think Perl is more
natural as a system administration language, though, as that is what it was
designed for.
The others require much more up-front study before one can start writing
useful programs. C#/Java are much easier than C++, but have huge, complex
APIs (my experience here is with Java, not C#) and require a lot of
boilerplate to get things done.
http://www.ferg.org/projects/python_java_side-by-side.html
> if it is has it seems and there is software to everything nowadays and so
> doesn't make sense to spend time in learning a programming language.
This is where the ease of writing "one off" Python programs comes in. When
you do find yourself needing to write some custom code, you'll find it very
easy to cobble together something useful quickly.
Dave Cook
Derek
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.
Michele Simionato
> Eiffel: Design by contract. The book to read is Meyer's "Object-
> Oriented Software Construction". Full of interesting stuff, if you can
> stand his self-importance ;-)
I couldn't!
Peter Hansen
>
> Python has the advantage of a clean start, but
> from a software engineering standpoint it really seems like a
> hacker language.
Ohh.... nice controversial statement. :-)
I would strongly disagree with the above statement for a number
of reasons, including (random thoughts):
- packages
- interactive interpreter
- no static typing
- high productivity
- ease of testing
- flexibility
- extremely broad library support
- low learning curve
and probably a dozen others. I think this has all been discussed before,
though, so I won't belabour the point. Basically, as a software engineer
(nominally a "Systems Design Engineer") I find Python to be hands down
*the* best language I've encountered for use in serious work. I can't
actually think of another which excels on so many fronts.
-Peter
John J. Lee
> Quoth Paul Rubin <http://phr...@NOSPAM.invalid>:
> ...
> | 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.
[...]
> 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.
Right. Wasn't it a research project? In any case, hardly a
large-scale programming effort along the lines of Mozilla!
> I don't know what kind of programmer resources were
> allocated to it,
No obvious attribution other than "CNRI" in the tarball, but I think
mostly Guido. :-)
> 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.
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
Cameron Laird
.
.
From a Python standpoint, "software engineering" has made a
nice start, but it needs to catch up with hacker insights.
John J. Lee
> Donn Cave <do...@u.washington.edu> writes:
[...re Python...]
> > 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?
>
> It makes some feeble ones but is somewhat hobbled by its origins as a
> scripting or "glue" language.
Are you referring to *anything* other than the lack of static type
checking and execution speed?
> 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.
[...]
I'm sure you're right that things will advance. Not sure it would be
best to make a "Python II", though -- Python seems close to a local
maximum.
John
Donn Cave
But your list describes the perfect hacker language, at
least on some counts. I'm nominally a Software Engineer
myself, but I have no formal CS education and have never
worked on a large project, so I feel right at home with
the hacker culture here. But help me out here, suppose
we're going to go in and develop one of those massive
projects - I don't know, say the IRS needs a new computer
system - what on that list would we care about?
Maybe vague promises like high productivity and ease of
testing would be attractive, but anyone can say that for
some ideal context. Library support is probably not even
on the charts. I would think a major consideration at
the outset of a project like this would be whether the
code that all these teams is writing will eventually come
together and work like it's supposed to, and from that
point of view it's tempting to look for some support for
architectural consistency, like "interfaces" and that sort
of thing.
Donn Cave, do...@u.washington.edu
John J. Lee
[...]
> 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.
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
John J. Lee
:-))
I admit I have nowhere near finished it either, but more due to my
slowness and the book's vastness than the manner of discourse.
The irritation he inspires *is* productive, as Michael Hudson says.
John
John J. Lee
> In article <40029dad$0$28706$a729...@news.telepac.pt>, Bicho Verde wrote:
[...]
> You could casually pick up enough Python to be useful in a week or so of
> evenings.
>
> Perl is not much harder,
It *seems* so when you first learn it...
> but has a lot of "gotchas".
... and they never end! Ilya Zakharevich (a "Perl God"):
http://www.google.com/groups?threadm=8h8scu%245h2%241%40charm.magnus.acs.ohio-state.edu
In article <8f498v$751$1...@charm.magnus.acs.ohio-state.edu>,
il...@math.ohio-state.edu (Ilya Zakharevich) wrote:
[...]
> Let me reiterate my current opinion on the topic: the reason for my
> puzzlement (and your trouble) is the difference between Perl as a
> scripting language and Perl as a programming language. Perl is
> absolutely fine as a scripting language. Perl is pretty unusable as a
> programming language.
[...]
I'm not sure I'd go quite as far as that, but it's not a million miles
from the truth. Why saddle yourself with the costs of Perl when
Python demonstrates there are no significant associated benefits?
(I'm talking about "programming" not "scripting" here, using Ilya's
language, though I'd argue Python is just as good for scripting as
Perl)
John
John J. Lee
[...]
> code that all these teams is writing will eventually come
> together and work like it's supposed to, and from that
> point of view it's tempting to look for some support for
> architectural consistency, like "interfaces" and that sort
> of thing.
Not sure about "that sort of thing" <wink>, but more explicit
interfaces do seem like a real issue here. It's interesting to note
that Zope, a notable large Python project, has moved (and is moving)
in this direction.
John
John J. Lee
At least one was PEPed, wasn't it?
I suppose it's waiting for Guido-bandwidth.
John
Paul Rubin
> > involving many programmers, and I don't think Grail was of that
> > sort at all.
>
> Right. Wasn't it a research project? In any case, hardly a
> large-scale programming effort along the lines of Mozilla!
Grail wasn't huge but I think any serious browser qualifies as
substantial. If you're saying it didn't really fail but actually
wasn't even seriously attempted, ok, that's even fewer substantial
programs that have even been tried in Python.
Derek
Python and C++ can also be a bigger mess than sum of either part.
Take your pick.
Peter Hansen
> > *the* best language I've encountered for use in serious work. I can't
> > actually think of another which excels on so many fronts.
>
> But your list describes the perfect hacker language, at
> least on some counts. I'm nominally a Software Engineer
> myself, but I have no formal CS education and have never
> worked on a large project, so I feel right at home with
> the hacker culture here. But help me out here, suppose
> we're going to go in and develop one of those massive
> projects - I don't know, say the IRS needs a new computer
> system - what on that list would we care about?
Never having done a new system for the IRS (yet? ;-) I can't
really say, but I do some pretty hard core stuff and Python
fits the bill for me better than past attempts...
> Maybe vague promises like high productivity and ease of
> testing would be attractive, but anyone can say that for
> some ideal context.
Perhaps, but it's also pretty easy to quantify, at least in the
non-scientific fashion which I've attempted to use for that.
> Library support is probably not even on the charts.
Very few systems cannot benefit from good library support.
Presumably the IRS requires networking, some user interface
capabilities, probably a bunch of database interfaces, really
sophisticated testing, and these days maybe even some standardization
in the area of, say, XML or something like that.
> I would think a major consideration at
> the outset of a project like this would be whether the
> code that all these teams is writing will eventually come
> together and work like it's supposed to, and from that
> point of view it's tempting to look for some support for
> architectural consistency, like "interfaces" and that sort
> of thing.
I agree, though I personally find it much more effective to use
good tests for this kind of thing. Interfaces don't cut it when
there's not a simple caller-callee relationship between things. I
have lots of components which are separated by various other kinds of
interfaces, such as a particular file format, or XML, or some custom
network protocol. Need tests to check both sides of those equations.
-Peter
Paul Rubin
> Presumably the IRS requires networking, some user interface
> capabilities, probably a bunch of database interfaces, really
> sophisticated testing, and these days maybe even some standardization
> in the area of, say, XML or something like that.
I think if there's one application that needs decimal arithmetic...
Jp Calderone
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
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Rainer Deyke
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.
--
Rainer Deyke - rai...@eldwood.com - http://eldwood.com
Francis Avila
John J. Lee wrote in message <87oet7i...@pobox.com>...
>Forgot to add: what happened to all those Python interface proposals?
>
>At least one was PEPed, wasn't it?
>
>I suppose it's waiting for Guido-bandwidth.
I think the general opinion of Guido was, yes, we need something like this,
but it's important enough to require his full and undivided attention, and
this must be given later, when a major revision comes up. I also think he
wasn't fully satisfied with all the options.
I forget where I read this. Maybe the pep-parade, or maybe one of the peps
themselves?
--
Francis Avila
EP
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.
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"
Francis Avila
>Is it true that the original Google spider was written in Python?
I don't know *what* Google uses Python for, but it uses Python.
>It would seem like the poster boy example for using Python in some
>respects, if true.
Um, nothing new about this:
Read the top center of the front page....
--
Francis Avila
Michael Hudson
> Samuel Walters <swalter...@yahoo.com> writes:
>
> > because there seem to be many more introductory tutorials and a lot of
> > advice that one should learn Scheme, then move to Common Lisp.
>
> 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
--
MAN: How can I tell that the past isn't a fiction designed to
account for the discrepancy between my immediate physical
sensations and my state of mind?
Jacek Generowicz
> > 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!
Yes, kinda ironic that I happened to post this on the eve of his
return.
Lothar Scholz
> EP wrote in message ...
> >Is it true that the original Google spider was written in Python?
>
> 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
Francis Avila <franci...@yahoo.com> wrote:
>EP wrote in message ...
>>
>>Is it true that the original Google spider was written in Python?
>
>I don't know *what* Google uses Python for, but it uses Python.
How about http://www.python.org/Jobs.html
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
A: No.
Q: Is top-posting okay?
John J. Lee
> j...@pobox.com (John J. Lee) writes:
> > > 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.
> >
> > Right. Wasn't it a research project? In any case, hardly a
> > large-scale programming effort along the lines of Mozilla!
>
> 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
> "John J. Lee" wrote:
[...]
> > 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.
>
> 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.
>>> os.system("/bin/true " + "x" * 129000)
0
>>> os.system("/bin/true " + "x" * 130000)
32512
Jeff
John J. Lee
> "David M. Cook" <dave...@nowhere.net> writes:
>
> > In article <40029dad$0$28706$a729...@news.telepac.pt>, Bicho Verde wrote:
> [...]
> > You could casually pick up enough Python to be useful in a week or so of
> > evenings.
> >
> > Perl is not much harder,
>
> It *seems* so when you first learn it...
>
> > but has a lot of "gotchas".
>
> ... 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
>>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.
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."
--
JanC
"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Christos TZOTZIOY
<bdesth...@tsoin-tsoin.free.fr> might have written:
><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).
--
TZOTZIOY, I speak England very best,
Ils sont fous ces Redmontains! --Harddix
Michael Hudson
> On Tue, 13 Jan 2004 12:21:00 +0100, rumours say that Bruno Desthuilliers
> <bdesth...@tsoin-tsoin.free.fr> might have written:
>
> ><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).
WORA (Write Once, Run Away)?
Cheers,
mwh
--
Worryingly, DEFUN appears to be a function that removes all the
fun from something: after using it all your code is converted
to C++. -- Tim Bradshaw, comp.lang.lisp
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
--
Our Constitution never promised us a good or efficient government,
just a representative one. And that's what we got.
-- http://www.advogato.org/person/mrorganic/diary.html?start=109
Cameron Laird
JanC <use...@janc.cjb.net> wrote:
>cla...@lairds.com (Cameron Laird) schreef:
>
>>>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.
>
>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
> In article <Xns94711F2...@213.119.4.35>,
> JanC <use...@janc.cjb.net> wrote:
>>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?
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
> 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
da...@dalkescientific.com
Paul Boddie
> 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.
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
beli...@aol.com
> 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
> "Bicho Verde" <bicho...@sapo.pt> writes:
> 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!
Mirko Zeibig
> beli...@aol.com wrote:
>
>>What is so dangerous about the STL in C++?
>
>
> One thing is that iterators can get invalidated when the container is
> modified.
Hm, I think there are similar problems in Python:
--- snip ---
adict = {'foo': 'bar', 'spam': 'ham'}
for key in adict: # has to be adict.keys()
del adict[key]
--- snap ---
This snippet leads to a RuntimeError but the first item will be gone.
Of course, you may use the "older" syntax in this case. ".keys()" will
generate the list of keys once in advance, while the upper example will
call next() each time AFAIK.
Regards
Mirko
--