Guido van Rossum Interviewed

Qa1 writes "Guido von Rossum, creator of Python, was recently interviewed by the folks at O'Reilly Network. In this interview he discusses his view of the future of Python and the Open Source community and programming languages in general. Some more personal stuff is also mentioned, like his recent job change (including the Slashdot story about it) and a little about how he manages to fit developing Python into his busy schedule."

Comments

Python

[Anonymous Coward]

I want to learn python, where should I start? I have looked at it breifly before, but now I actually have time to learn it. Any good pointers?

Re:Python

[dirtydiaper]

go to their website and look at their tutorials thats where is started

Re:Python

[Anonymous Coward]

RTFTutorial (www.python.org)

Re:Python

[bsharitt]

To just start learning, python's website is a good starting point. it has a lot of good beinner resources.

Re:Python

[maharg]

I learnt from the book "Python Essential Reference" - see Amazon's page. It has an excellent first chapter which will give you an excellent grasp of the fundamentals. Good luck, and have fun :o)

Re:Python

[holovaty]

I highly recommend Dive into Python, a free online book that's targeted at experienced programmers.

Re:Python

[Anonymous Coward]

www.perl.com

Re:Python

[e.colli]

Bruce Eckel, Thinking in Java's author has an inclomplete and unfinished, but interesting book. http://mindview.net/Books/TIPython

Re:Python

[rsax]

You might want to download this book as well as use the tutorials at python.org

The same book is available in downloadable versions here: http://greenteapress.com/thinkpython/

Re:Python

[Anonymous Coward]

Start by learning COBOL. That way, when you switch to Python, the moronic 'significant whitespace' won't drive you to distraction and make you long for a more sensible language.

Python on the Zaurus

[SHEENmaster]

For those with OpenZaurus, install the python packages and learn it between meetings/classes/etc.

Re:Python on the Zaurus

[uberslack]

Python is available for the regular Zuarus OS as well.

Interesting...

[dysprosia]

Interesting that smarts still counts for something, and that they're not just employing talented developers just for the producs they have created. Hope the trend continues.

Start here

[niom]

That's what says in the link to the Python tutorial. It's quite good to get you to know the language and does not require a lot of previous programming experience. Then, the library reference can come very handy too.

Can anyone

[Timesprout]

explain what the major advantages of using Python are. I have only ever looked at it very briefly and even more briefly at Jython. From this very limited experience I cant really think of a compelling reason to use Python over some of the more mainstream languages, other than perhaps as a scripting type glue.

Re:Can anyone

[pioneer]

explain what the major advantages of using Python are. I have only ever looked at it very briefly and even more briefly at Jython. From this very limited experience I cant really think of a compelling reason to use Python over some of the more mainstream languages, other than perhaps as a scripting type glue.

If you are using Java then python is a step up because it offers first class functions and some other incredibly power constructs.

Unfortunately, although Python's effort is applaudable, it really is only a first class imperative language that has added some features of Lisp.

If you are going to chose a new language to learn, then you should be learning Lisp. Most people avoid it because it looks complicated but, believe me, after using in for many years, Lisp is gorgeous.

I highly suggest you check out Paul Graham's website and read his articles about Lisp before you waste anytime learning any other language.

All languages nowadays are slowly adding individual pieces of Lisp functionality. Why not just use Lisp (no reason to wait a decade for all the "popular" languages to finally come fill circle and become Lisp dialects).

Re:Can anyone

[maharg]

I guess the advantages are really quite subjective i.e. it depends what languages you are coming from, and also depends on what you need to get done.

I came to Python from Perl, dealing mainly with text manipulation and glue-type applications, in which both Perl and Python are very adept languages. For me, Python was a breath of fresh air, - no more curly braces, indentation became an integral part of the code, rather than an annoyance (when it went wrong), and mainly, Python is OO by design, whereas in Perl I always felt that objects were bolted on as an afterthought.

YMMV.

Re:Can anyone

[David Eppstein]

Python has a large convenient featureful library, but so do many other languages. The biggest advantage it has for me is that Python looks almost exactly like pseudocode, without the overhead (braces, variable type declarations, etc) other languages make you go through. The effect is that coding is much easier and the results are much more readable when you come back to your code later and want to understand what you did.

Re:Can anyone

[Anonymous Coward]

its like perl, but coherent.

its fast for parsing, yes perl is faster. but for most people 75,000 lines of text in 3.01 seconds is just as good as 90,000 lines, considering the python code is easy to deal with.

Re:Can anyone

[Telex4]

Compared to the other "scripting" languages I know (Perl, Bash, PHP, so fairly limited), Python has a few major differences:

o Python uses indentation to denote code blocks, rather than curly brackets {} or other methods. This, along with a few other layout rules, makes Python code very strictly laid out. This makes it both easy to read and code, and you really don't miss being able to use your own crazy layouts (ahhh, perl ;)

o Python is totally object orientated, and very intelligently designed in this department. Whereas in Perl (5) you have to jump through hoops to create objects, especially OO modules, in Python it's as easy as assigning a variable a new value.

o Python has quite a few very useful built in object types, including strings, ints, floats, lists, tuples, dictionaries, functions, classes, and more. This makes things easy if you don't want to make complex matrices. It is also easy to make more complicated types by embedding C...

o It is really easy to embed C/C++ code in Python, and vice versa, so where Python suffers on performance you can boost it with C/C++, or use a Python tool appropriately called "boost"

Generally, Python is very handy for anything from one-time dirty scripts to full applications (there are some good GUI toolkit ports about.. PyGtk, PyQt, PyKDE, wxWindows, etc), and is also very handy when developing prototypes.

But what really makes me like Python (as I'm not a language nerd by any measure) is that it is just *easy* and *fast* to code in... it doesn't get in your way.

(Pimping out...)

Re:Can anyone

[fredrikj]

You might find Eric S. Raymond's take on the question quite informative.

Re:Can anyone

[merlin262]

Note: my knowledge of python is somewhat limited as I just started using it, so if there are errors here, I apologize.

1. Python as a scripting language has several features seen in Objective C(and other similar languages) not found in C++. Class members can be detected and bound at runtime, further it's possible to search a classes members for information.

2. Pydoc and documentation strings. Python has built in support for documentation strings, and a great utility for automatically generating documentation. Documentation is actually a part of the programming language, and not an after-market add-on.

3. Dictionary objects, tuples, lists - are all part of the basic language. Dictionary objects allow interesting hash tables to be created without much effort at all. This feature is seen in Perl.

4. Maybe a miss feature, but enforced indentation creates much easier to read code.

5a. The shelf object. This essentially allows any object to have it's runtime information stored in an easy and effecient matter. It can then be reloaded after a run.

5b. The pickle object again allows objects to easily be stored in files.

6. Python is _EXTREMELY_ easy to extend using the Python C API.

7. Python includes functional programming aspects such as mapping and lambda forms.

8. Python includes an extremely complete library that does just about everything one would desire to be able to do. Using the python runtime library allows your code to be easily portable without the headaches involved in C/C++ porting.

9. Using psyco, it's possible to have Python code JIT on i386 processors. This gives a significant performace boost.

10. A development community and support community second to none.

There are other aspects that I haven't touched on here, but these are the major things I've found helpful so far.

Re:Can anyone

[einstein]

Lisp programmers scare me. Someone mentions a feature that lisp has had for a few years, and invariable some lisp guy comments on how it's the future! switch now! Look at all the babes I attract with my Lisp skillz!

Re:Can anyone

[JanneM]

Depends on what you mean.

Python, Perl and Ruby are all very good interpreted, flexible, rapid-prototyping languages. They all have their relative strengths and weaknesses, but all are good enough that if you are choosing between them, it boils down pretty much to your own preferences and what coworkers and other people around you use (or on what animal you prefer on the cover of your reference literature:) ).

If you mean this class of languages as opposed to C, C++, Java and so on, well, it becomes a matter of what you want to accomplish. The great benefits of these interpreted languages are that they make development very fast, compared to the more traditional languages (yes, Java is interpreted, but it is still designed as a traditional language). You spend more time solving your task and less time managing the mechanics of development. Also, they really make use of the benefits of being interpreted with things like closures, dynamic code evaluation and so on. And they typically have very complete, transparent access to the surrounding system - why spend two days writing some hairy functionality when you can trivially filter your data through an external application that already does the whole job for you? Do not underestimate "scripting type glue".

They do make a pretty good fit running large systems - the Swedish pension management system is all written in Perl, for instance, and Zope is written in Python. They are also quite efficient; they are on the whole as fast as a Java implementation, and occasionally (when the task plays to the specific language's strengths), quite a bit faster.

I typically use C/C++ and Perl for development, and every time I've been using Perl for a while, I get bouts of frustration with traditional languages for the lack of such things as hash datatypes and inline regular expressions. But for some tasks, traditional languages are the way to go.

Re:Can anyone

[pioneer]

Lisp programmers scare me. Someone mentions a feature that lisp has had for a few years, and invariable some lisp guy comments on how it's the future! switch now! Look at all the babes I attract with my Lisp skillz!

its true. we do attract lots of women.

Re:Can anyone

[pioneer]

Concerning advantages of Phython

Python is totally object orientated, and very intelligently designed in this department. Whereas in Perl (5) you have to jump through hoops to create objects, especially OO modules, in Python it's as easy as assigning a variable a new value.

Alright, lets set something straight here. The world is on a huge object oriented high. As has been said about strict types, object oriented programming is a hammer and everything all of a sudden looks like a nail.

Any language that is *only* objected oriented is forcing you to look at everything as nails.

Try Lisp, you'll feel much better.

(Insert language here) is just a watered down Lisp.

Re:Can anyone

[Anonymous Coward]

Most zealous zealot?
A lisp zealot.

Re:Can anyone

[ultrabot]

I typically use C/C++ and Perl for development, and every time I've been using Perl for a while, I get bouts of frustration with traditional languages for the lack of such things as hash datatypes and inline regular expressions.

I'm a professional C++ programmer, and a devout pythonista. What I miss most in C++ are the easy-to-instantiate datatypes like tuples. It's so much easier to pass a relatively simple datatype as a tuple, as opposed to introducing a whole new class and even *gasp* a new file to do the trick.

For example I can trivially code a function that returns an array of (name, address) tuples, and I can easily manipulate such an array:

tuples = get_address_entries()
for name,address in tuples:
print name,"lives in",address

After doing Python for a while, one sees how much static typing gets in your way of doing things the "proper" way, and very often one tries to avoid doing the damn thing at all... resulting in a sub-optimal design. Python allows you to be all you can be :-)

Re:Can anyone

[HiThere]

...The great benefits of these interpreted languages are that they make development very fast, compared to the more...

No. That's a big advantage, but the really great advantage is that you can modify things on the fly. You can add methods to a class, or to objects of a class, during the execution of the program. You can create code that you then execute, etc. (I know that you *can* do that in C... but just try it!)

Lisp has most of the advantages that I mentioned in the preceeding paragraph, but it is much more difficult to read, because it's grammar is essentially without structure. This at one point lead to it being called Lots of Irritationg Single Parenthesis. I'm told that you can get used to this, but I never put in enough time at it that I actually did. And I don't see the advantages against either Ruby or Python. But Lisp is compileable. So if you need that, then Lisp is a good choice.

Re:Can anyone

[tordia]

Any language that is *only* objected oriented is forcing you to look at everything as nails.

From the Learning Python book (see sec. 1.1.1.1):

Of equal significance, OOP is an option in Python; you can go far without having to become an object guru all at once.

So, while Python supports object oriented programming, it doesn't force you to use it.

Re:Can anyone

[Waffle Iron]

Any language that is *only* objected oriented is forcing you to look at everything as nails.

You don't have to use Python's object oriented features. For example, you can find all of the 22-character long English words with only the tiniest sprinkling of OO:

>>>for w in filter(lambda x: len(x) == 22, file('/usr/share/dict/words').readlines()): print w

electroencephalograph
Mediterraneanizations

OTOH, people high on OO could write:

>>> print 22. __add__(3)

25

Python gives you both hammers and vice grips.

Re:Can anyone

[Anonymous Coward]

There really isn't any advantage to Python. It has a pretty decent library of modules, but PERL's CPAN beats it (and any other language's) in spades.

Python's syntax is somewhat cleaner than PERL's, but the whitespace indentation quickly becomes maddening. Besides, Pythons has all kinds of quirky function names and pseudo OOP stuff.

I really don't see any reason to use Python. Stick with PERL, PHP, etc. Or give Ruby a shot - it looks cleaner than Python.

Re:Can anyone

[Dan Ost]

OOP is a part of Python the way that OOP is part of C++.
It's available if you want to use it, but you're not forced to
use it when it's not appropriate.

Re:Can anyone

[Malcontent]

"Python uses indentation to denote code blocks, rather than curly brackets {} or other methods."

Personally I think this is a flaw and not a feature. One of my pet peeves is scrolling to the end of some function and seeing this.
}
}
}

With python you don't even have that.

I like the php alternative best.

endif;
endwhile;
endforeach;
}

Re:Can anyone

[Malcontent]

By the same token it does bother me that people are constantly re-inventing things that have been around for a long time.

I look around and it seems to me like most "new" things in CS have been around for 20 years. Why is everybody so intent on rewriting smalltalk and lisp? Does it seem strange to you that every language eventually starts looking like smalltalk and lisp?

Re:Can anyone

[GnuVince]

>>> print 2.__add__(3)
File "<stdin>", line 1
print 2.__add__(3)
^
SyntaxError: invalid syntax
>>>

Hum, seems you cannot do that. Of course, in Ruby you can do 10.+(29)

Re:Can anyone

[Waffle Iron]

It looks like I made a typo. You need a space between the 2 and the '.', otherwise Python thinks it's a float literal.

Try:
2 .__add__(3)

or even:
2. .__add__(3)

Re:Can anyone

[smallpaul]

Python, Perl and Ruby are all very good interpreted, flexible, rapid-prototyping languages. They all have their relative strengths and weaknesses, but all are good enough that if you are choosing between them, it boils down pretty much to your own preferences and what coworkers and other people around you use (or on what animal you prefer on the cover of your reference literature:) ).

I don't think that is really true. How cheap and easy is it to make a COM object or Java class in Perl? What if you want to work with Unicode. Would Ruby be up to it? The truth is that about half of my Python work is really not the sort of thing that even Perl evangelists tend to do in Perl.

Re:Can anyone

[Anonymous Coward]

I have a friend from Alabama who, despite being as much as a country boy as me, puts sugar on his grits (rather than butter, salt, and pepper, or red-eye gravy as god intended). I say to each his own. If you like curly braces or sugar on your grits, so be it.

Re:Can anyone

[Anonymous Coward]

And the automobile was just a re-invention of the horse-and-buggy. All the principles were already in place years before the automobile came along.

Re:Can anyone

[Anonymous Coward]

Does it seem strange to you that every language eventually starts looking like smalltalk and lisp?

I've heard this line of reasoning before. For me, the biggest thing against lisp is the absolutely awful syntax - that is, that many close parens begin to hurt the eyes.

I've often wondered how succesful a language would be that simply took all of the abilities of lisp and presented them in a way that's easier for C/C++ programmers to use and read.

Re:Can anyone

[be-fan]

While Lisp programmers can be scary* there is some element of truth to it. I was trying to extend SCONS (a build system) to make it easier to use while building my OS kernel. I needed to have lots of conditionals, to handle varying platforms and build situations. Now that I look back on it, there are a lot of Lisp ideas in there. Specifically, if code is data, then data should be code, right? So I ditched my original idea of using an XML file format, and decided to use regular python scripts as the config files. It worked like a charm, and the resulting build system was flexible enough that when I applied it to a later project for work, I only had to write a couple of dozen lines of build scripts for a complicated project that needed to build on Linux, Windows, be configurable to use various CORBA ORBs, and have switchable drivers at compile time.

More and more, I'm thinking corporate America is decades behind what the academic world takes for granted. XSLT, for example, is something that never should have happened. And its not just Lisp. Take, for example, DAML+OIL. Its an XML-based language that can make statements in first order logic that can be verified by a theorem prover. Its so complicated and verbose, that its nearly impossible to write by hand, and most people use GUI tools to work wih it. In the next version, they're adding support for limited execution capability (ala XSLT). Meanwhile, I'm thinking, "hello --- Haskell?"

*> My impression of this mainly comes from comp.lang.lisp. I find some of the people who hang out there to be among the rudest I've seen on the Internet. Some pricks, like Eric Naggum (search for "arrogant" on c.l.c in Google Groups and see who gets the first 20 hits...) are actually revered for their rudeness! It might just be there are more math/pure-science types on that board, and while they're definately smart, they can also be rather rude.

Re:Can anyone

[Mooncaller]

CPAN beats nothing. For anything important in CPAN, a Pyhton equivalent can be found. The Python equivalent will most likely be of superior quality and easier to understand. Because, Python syntax is signifigantly cleaner the PERLs, Python scales to large projects far better then PERL.

Anyone who can't get use to indentation based block delimiters within a few minuets, ought not be programming in PERL. It demonstrates a complete lack of the programming discipline that is crucial for creating maintainable PERL code. This is examplified by the fact that most PERL code looks like shit.

Python is REAL OOP from the ground up. In fact its implimentation of Objects is far superior to C++s let alone PERLs. The very small set of uncommon methods that might be described as quirky ( using the broadest possible definition of quirky) far outweighs a language whos very syntax is quirky by almost everyones definition.

Unless you are writing something small (under 100 lines) that has absolutly no chance of expanding into a larger system, does not involve anything other then a rudimentary GUI, and is concerned mostly with text manipulation, stay away from PERL. In all regards, except quick and dirty text manipulation, Python is far better then PERL. The only scripting langage that has anything over Python is Ruby.

Re:Can anyone

[berklee]

"Look at all the babes I attract with my Lisp skillz!"

Funny, I've always thought that with a lisp, I'd be attracting men instead...

Re:Can anyone

[Anonymous Coward]

All languages nowadays are slowly adding individual pieces of Lisp functionality. Why not just use Lisp (no reason to wait a decade for all the "popular" languages to finally come fill circle and become Lisp dialects).

There are reasons to use Python rather than Lisp:

• OO. Python is quite OO in the core and libraries. Lisp is not. I know, there is metaobject protocol and so on, I even have the book, but this is useless in practice. In practice Lisp OO is unusable compared to Python. Why type twice as much code?
• Ugly core functions and libraries. I mean Python Lists are nicer to work with Lisp lists. Yes, I know I can recurse with car/cdr, but this is uninteresting micro-managing.
• And in general, it all boils down to the fact that Python is less painful to type. Try hash tables, try lists, try arrays, try objects.
• Then there is the community: Python community exists too (leading to Zope, Python in Blender, etc...).

Re:Can anyone

[Meowing]

Python is totally object orientated

Not really. 2.2 and up get a little closer to that, but Python is really a procedural language with a very nice but very optional set of OO features. (Internally, the Python and Perl OO implementaions are very similar, even if Perl's hideous object syntax does a good job of hiding it.) This is a nice pragmatic approach, akin to what Objective C does.

If OO purity is one of those things that appeals to you, Ruby or Smalltalk might be fun toys.

Re:Can anyone

[Anonymous Coward]

Apple tried this with Dylan. It wasn't really a big hit with anyone except Lisp progammers.

Re:Can anyone

[Anonymous Coward]

Parenthesizing the number seems to work, also, ie (22).add(3)

Re:Can anyone

[Tablizer]

Look at all the babes I attract with my Lisp skillz!

Lisp is so good, you won't want a babe anymore :-P

Besides, if us geeks really wanted (real) babes, we would be at the mall instead of on slashdot haggling over Lisp versus Python.

But, I gotta admit, the name "Python" probably brings better pants-directed imagery to the babes than "Lispy".

Re:Can anyone

[commodoresloat]

Why is everybody so intent on rewriting smalltalk and lisp?

Because they get embarrassed trying to make smalltalk with a lisp.

Re:Can anyone

[Anonymous Coward]

Any language that is *only* objected oriented is forcing you to look at everything as nails.

The core library is OO, and this is very good. Because 99% of my code is OO, and thus I do want a 00 core library, not the thousand of not OO lisp functions. Try passing an objet instead of a list to a standard Lisp function - yes in Python you can implement the List protocol, or inherit from the standard List class.

Re:Can anyone

[Anonymous Coward]

Funny, but missing the point entirely.

Re:Can anyone

[Anonymous Coward]

Yes, let's make another language with that godawful C syntax. Good god, no.

Go play with K or something.

Re:Can anyone

[Anonymous Coward]

In practice Lisp OO is unusable compared to Python.

Huh?! Are you insane or something? Ever checked out CLOS?

Re:Can anyone

[Anonymous Coward]

Huh?! Are you insane or something? Ever checked out CLOS?

Yes. As I said I even have the book "The Art of the Metaobject Protocol". Actually what I truely hate is Lisp structs, lists, hash tables, strings and related functions. I just have a slight dislike and strong annoyance for/at CL objects.

Re:Can anyone

[alangmead]

And then the moved to an infix syntax and pissed all of them off.

Re:Can anyone

[angel'o'sphere]

All languages nowadays are slowly adding individual pieces of Lisp functionality. Why not just use Lisp (no reason to wait a decade for all the "popular" languages to finally come fill circle and become Lisp dialects).


At first:

Lisp alone is only Lisp, if at all, some should use a lisp with oo extensions.

Even the simplest pascal algorith is hard to be coded in "pure" lisp, as you have to do the trick of converting all "record" like data structures in list/lisp like equivalences.

Second:
Some people think and even more important "visualize" stuff different like others.
For me lisp is just a fence of paranthesis. I find it incredibel hard to read. And, no, the idea that this is only a matter of practicing, is a myth.
Braces like in Java/C++ are absolutely clear markers and do not confuse in any way with the mathematical idioms I learned for 13 years in school, and use since nearly 30 years in all day life.

Sorry, but for me the function name or class name has to be in front of the () nd not inside. Controll structures have to be easy spotted and not to be hidden inside of () signs.

Unfortunatly I know that this is not just me, you need to have a mind to be suited with lisp. About 50% of my lisp class failed ... I only had luck to pass it.

Nevertheless, alot of teh paradigms lisp exposes on you are very suitable, I mimic them all day in C++. Unfortunatly its to hard(to verbouse) to mimic them in Java. (No overloading of the () operator for classes, object creation only with new etc.)

Regards,
angel'o'sphere

Re:Can anyone

[ZvlvLord]

Ok I'll bite =)
ANYTHING that you can do in Lisp/Ocaml (and other functional languages), you can do in Python. Go read a bit. Python does not force you into any style. You're free to use whatver you want.

Re:Can anyone

[jjgm]

XSLT is quite an amusing example, because it's essentially a dumbed-down reformulation of DSSSL in XML.

They even have the same primary author, James Clark, producer of the ubiquitous expat XML parser.

DSSSL is Scheme-based, and Scheme is a rarefied dialect of LISP.

Thus turns the circle.

Re:Can anyone

[Anonymous Coward]

Specifically, if code is data, then data should be code, right?

Not at all. How did you come up with that stupid leap in logic? Because LISP does it, so it must be right?

Data as code violates the principle of least power and leaves you wide open to doing things in "data" that are very nasty. There is no good reason for it.

So I ditched my original idea of using an XML file format, and decided to use regular python scripts as the config files.

That's great. Now you've effectively tied your system to a single language. Pretty much any language can parse XML, a config file written in Python is only going to have crude workarounds available to it for other languages.

Re:Can anyone

[William Tanksley]

Lisp alone is only Lisp, if at all, some should use a lisp with oo extensions.

You mean perhaps CLOS (Common Lisp Object System), the first international standard for an object-oriented language?

Even the simplest pascal algorith is hard to be coded in "pure" lisp, as you have to do the trick of converting all "record" like data structures in list/lisp like equivalences.

Why would you do that? Why code in someone else's idea of "pure" Lisp, when you have the full language available, with structures, arrays, hash tables, multimethods, and so on all before you?

Lisp isn't Scheme. Scheme is a purist's language, with limited iteration and data but lots of clean, clever ways to recurse over lists. Lisp is a pragamtic, powerful language with TONS of datatypes and library functions. Oh, and the most powerful object system I've seen.

For me lisp is just a fence of paranthesis. I find it incredibel hard to read. And, no, the idea that this is only a matter of practicing, is a myth.

Why do you say it's a myth?

Braces like in Java/C++ are absolutely clear markers and do not confuse in any way with the mathematical idioms I learned for 13 years in school, and use since nearly 30 years in all day life.

It's interesting that so many people defend as "intuitive" something that they spent 13 years learning, and still often don't get right. You're not making that mistake, fortunately :-).

Sorry, but for me the function name or class name has to be in front of the () nd not inside.

This doesn't make any difference at all.

Controll structures have to be easy spotted and not to be hidden inside of () signs.

This does make a difference, definitely. It's why indentation is so important, and why Lisp programmers tend to STRONGLY recommend using a good editor, to make sure that you NEVER forget (and even to help you by syntax highlighting).

Unfortunatly I know that this is not just me, you need to have a mind to be suited with lisp. About 50% of my lisp class failed ... I only had luck to pass it.

Well, you've been confusing Lisp and Scheme; I'd say that your class probably wasn't a good one. I'm sorry.

-Billy

Re:Can anyone

[be-fan]

Because LISP does it, so it must be right?
>>>>>>>>>
I'm not even a Lisp programmer! I'm a C++ programmer. But its so obvious, once you are exposed to it, that its not even funny.

Data as code violates the principle of least power and leaves you wide open to doing things in "data" that are very nasty.
>>>>>>>>>
It's not appropriate in all cases, but is in most. If HTML was code, we wouldn't have all of this machinery (XSLT, CSS, DHTML, etc) to make it behave like code.

And while it may violate the principle of least powers, that's not a crime in and of itself. What matters is whether the end product is secure. Remember, more code = more bugs. Its far easier to build a totally secure sandbox for a VM with a few dozen instructions, than to make sure that dozens of different ad-hoc interpreters are free of buffer overflows and potential exploits.

There is no good reason for it.
>>>>>>>>>
Oh yes there is. Just take a look at the cross platform build scripts for the Linux kernel or KDE. QT had to make a tool (qmake) just to make the mess managable. Now, take a look at how f*cking easy SCONS makes building. Programmable data is the future. Just take a look at graphics cards. Static data (textures, geometry) was too limiting, so they needed to make the cards programmable (shaders). Static HTML was too limiting, so they needed to make the web programmable (Flash, XSLT, PHP, CGI, etc). Its far better to pick some programmable data representations and work on making them secure, than to keep writing and rewriting bug-ridden, exploitable processors for an ever growing set of static data representations.

Now you've effectively tied your system to a single language.
>>>>>>>
Now, there, what exactly do you think make is? If you answered "one-off, extremely limiting, non-standard programming language" you get a cookie! I knew I was heading down the wrong path when I found myself writing stuff like:

module-win32.cpp

Now I have to write an interpreter for my own god-damn one-off language!

As for interfacing to other languages, consider this: which is easier? Using Python's excellent's inter-language interfacing capabilities to have Python code directly interact with a program written in another language, or writing (and maintaining!) a (verbose!) set of XML data files and writing an interpreter for our very own XML-based programming language?

Re:Can anyone

[pioneer]

Try passing an objet instead of a list to a standard Lisp function - yes in Python you can implement the List protocol, or inherit from the standard List class.

You clearly have no idea what you are talking about. Every heard of CLOS (common lisp object system)? Full object oriented support.

Also, Lisp is dynamic typed so you can pass whatever you like into a function. Including other functions, lists, symbols, strings, continuations and, eventually with dialects like Arc, macros.

Re:Can anyone

[Dr. Smeegee]

Not too far off base for python. :-) Check out the new list comprehension features.

Forthtunately I have been footing myself in the shoot with Forth lately. Exciting.

Re:Can anyone

[Anonymous Coward]

why wait DECADES more, if ever, for Lisp to have libraries and interfaces to the applications you need to work with when the other languages will have most all the useful Lisp functionality long before then, and work with your apps NOW?

Re:Can anyone

[Peaker]

While I agree that Python is cool, and in many regards better-designed than all existing Lisp variants, there are still things Lisp can do any Python cannot. (Probably some things going for Ocaml too, but I don't really know it well).

Lisp's main powerful feature is macros, which allows the definition of new syntax. This allows programmers to create a language on top of Lisp to suit their more specific needs.

Python is more powerful than Lisp in many of its semantics, and thus requires less macros to achieve most of its goals. However, no language will ever be complete and ideal for all tasks at hand, and thus macros get you as close as possible to that.

Re:Can anyone

[Peaker]

Also, Lisp is dynamic typed so you can pass whatever you like into a function. Including other functions, lists, symbols, strings, continuations and, eventually with dialects like Arc, macros.

Yes, Lisp is like Python dynamically typed.

However, Lisp is not polymoprhic about its basic types. No Lisp object can be a first-class List in the sense a List can, because no Lisp object can implement the car/cdr protocol.

Give a Lisp function that expects a list some other object, and (car object) will fail.

In Python, "everything is an object", and what that really means is that all access to all program entities is indirected. Sure, this has a performence penalty (at least without smart optimizers), but its more flexible and powerful than Lisp's builtin functions such as car/cdr that do not go through such indirection.

As a side note, unlike many other languages, Python wasn't created out of ignorance of Lisp, but out of realization (that you may agree or disagree with) that Lisp's macros are also a bother because learning a language variant before reading the code can be a nuisance.

I know the claim that learning a new macro-defined syntax is just as hard as learning the semantics of the called functions, but this is not at all true - as there are many guarantees and many properties a Python programmer can easily expect of code - even if it calls unknown functions. There is nothing a Lisp programmer can say whatsoever about some Lisp code that contains use of unknown macros.

Re:Can anyone

[pioneer]

i think you some good points here. it is true that car and cdr can not be overloaded... however the way you are using them i think you mean the same as the lisp "get" command which can behave polymorphically.

and, in addition, if you CLOS (common lisp object system) to implement an object oriented system you can define an object 'car' of sorts that you can share between subtypes.

the fact of the matter is python, lisp and perl are all much better than java. python and lisp people should really be fighting to convert people from java... and C++

dan

Slowing down already - here's the article

[Anonymous Coward]

Guido van Rossum Speaks
by Steve Holden
08/14/2003

Guido van Rossum is the well-known creator of the Python programming language. During his address at OSCON 2003's States of the Unions event, he announced that he'd soon be leaving PythonLabs to work for a California startup. Guido graciously agreed to an interview with Steve Holden on the move, recent developments, and Python in general.

O'Reilly Network: Can you explain why you're leaving PythonLabs and where you're going?

Guido van Rossum: Moving to California has always been on my list of things to try eventually. When Dan Farmer approached me in February to join his new software company, where he anticipated there would be lots of need for language design skills, my initial thoughts were that such a move would be too disruptive to my family.

Dan kept pushing, and when he had his venture capital lined up he asked me out to California for an interview. My plan for that interview was to find out what was wrong with the company or the business plan and to use that to maintain my original decision. But, try as I might, I couldn't find anything wrong!

As the weekend progressed I got more enthusiastic, both about the project and about working with Dan.

ORN: So it wasn't so much an offer you couldn't refuse, rather an inability to find anything to justify a refusal?

GvR: The offer was a good one, and I certainly couldn't complain, but mostly I was surprised at my own enthusiasm for this new project.

ORN: What will your relationship with be with PythonLabs and with the Python Software Foundation in the future?

GvR: In terms of personal relationships nothing much will change. I really like the PythonLabs guys, and most of us have worked together for eight years since the CNRI days. It was difficult to move without being able to make them all an offer, but for various reasons none of them would have wanted to make the move.

I will remain the head of the PSF. Board meetings will be a little different as I'll be using IRC rather than being present in person. As you proved during the PyCon DC 2003 planning process, that's fine as long as people can make the time for a fat cock up their ass, and I'll certainly make the time for PSF board meetings.

ORN: This is the third time in as many years you've changed employers?

GvR: That's right.

ORN: Does this indicate some kind of instability in the employment market?

GvR: I think if the economy had been better I wouldn't have left Zope, and Zope might have been more fun. Really, though, it's more of a reflection on the opportunities that have come to me personally.

ORN: Serious Python users might be concerned about your continued involvement in the development of the language. What will the move mean for the future of Python?

GvR: First, it's written into my contract that the development work I do on Python will not belong to Elemental Security. That will continue to be owned by he Python Software Foundation.

Also I will have time carved out in my regular work week to work on Python. So I'm pretty hopeful that once the dust of the move has settled, say in mid-August or so, I will have enough time for Python.

It's not my dream Python job, which would basically be to be paid to work with a team about the size of PythonLabs to work on the development of Python full-time. That's not a realistic possibility at the moment.

ORN: What will you miss most about Virginia?

GvR: The friends I've made there. I've lived there for eight years, and during that time I've made some really great friends.

ORN: What East coast ties do you intend to retain?

All of them. I plan to stay in touch with all of those friends, and they're all going to be welcome to stay in our house in California as long as there's space--we haven't found a place to live yet, and the Bay Area's even more expensive than the DC Metro area!

ORN: You are a family man, with a life besides IT. How much o

The MAJOR advantage is simplicity

[TuringTest]

The second name of Python is "Executable Pseudocode".

Sure you can do the same things in other languages, at the end all general languages are Turing Machine equivalent. The difference is that Python is EASY to read (according to Master Yoda). It is bottom-up designed to be.

So it is good not only for scripting, but too for prototyping and for everything which needs to be flexible and not too much efficiency-critical. The logic of some videogames is encoded in Python, you know.

Re:The MAJOR advantage is simplicity

[Malcontent]

You should say "easier to read then perl" because I don't think it's easier to read then ruby or php or even java. But then again just about anything is easier to read then perl. Perl code looks like it's cursing at you.

Re:The MAJOR advantage is simplicity

[Brian Quinlan]

You should say "easier to read then perl" because I don't think it's easier to read then ruby or php or even java

I think that Python is a lot easier to read than Ruby or Java. Ruby allows a lot of the same punctuation-based idioms that make Perl so difficult to read and Java is too verbose to be easy to read. Consider the Java version of hello world:

class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}

Cheers,
Brian

Re:The MAJOR advantage is simplicity

[Anonymous Brave Guy]

You should say "easier to read then perl" ...

Of course. Python is executable pseudocode, but Perl is executable line noise. (First saw this on the Slashdot "wisdom line". :-))

Re:The MAJOR advantage is simplicity

[Anonymous Coward]

You should say "easier to read then perl" because I don't think it's easier to read then ruby or php or even java.

That's correct. Python is additionally easier to type than Java, better designed than PHP. And finally Ruby is mostly identically to Python, with some surperficial changes.

From the interview

[Anonymous Coward]

Interviewer: Why did you make whitespace significant in Python?
Guido: I smoked a lot of crack that day.

Re:From the interview

[Anonymous Coward]

Spoken like a proper White-Space Cowboy.

Python vs. the others

[henriksh]

I think Python has a very bright future. For many purposes, it obsoletes Java. Java is more widespread than Python now, but it's proprietary and suffers from a historically slow GUI.

Many people use Python for tasks they used to do in Perl, but I don't see Python replacing Perl. They serve different purposes, for the most part.

Ruby is also an interesting language, although I don't personally know much about it, except that it aims to be truly OO. Again, slightly different purposes, but I don't think Ruby will ever be very widespread.

Re:Python vs. the others

[Dan Ost]

Many people use Python for tasks they used to do in Perl, but I don't see Python replacing Perl. They serve different purposes, for the most part.

Could you please explain how PERL and Python serve different purposes?

I'm curious because I use Python for exactly the kind of stuff that I used
to use PERL for. The whole reason I found Python was because I was looking
for a substitute for PERL. After having used Python for some time, I've
discovered that certain things are easier in Python than PERL, and vice
versa, but nothing significant enough that I can think of a project where
one would be appropriate for the job but not the other.

Re:Python vs. the others

[Decaff]

Java is not proprietary - if it were, there would not be a GNU implementation. Java's GUI is no longer slow - the SWT GUI system from IBM allows native-speed on a large number of platforms, and works with the GNU Java.

Re:Python vs. the others

[henriksh]

Could you please explain how PERL and Python serve different purposes?

For one thing, Perl is much more used by UNIX (*BSD and GNU/Linux included) system administrators. Some people think Perl is more in the UNIX spirit than Python.

Python focuses more on OO issues and the Pythonic way. Perl is more versatile in terms of syntax.

Basically, there's some differences in the overall design philosophy.

But you are right. You can easily use Python for things you used to do in Perl and vice versa. But there are still things I'd rather use Perl for than Python.

Re:Python vs. the others

[glenstar]

Some people think Perl is more in the UNIX spirit than Python.

Difficult and surly? ;-)

Re:Python vs. the others

[elflord]

Could you please explain how PERL and Python serve different purposes?

Perl is a better shellscript than shellscript. Systems administrators who are tired of dealing with the horrors of shell script like perl. Perl is also great for text manipulation. One can write insanely powerful and terse code for this in perl (like sed on steroids). People who yank a lot of text around (web developers, sys admins) often like perl for this reason.

Python is more of a "programmers language". You can't write insanely terse code in python, because the python philosophy dictates that the code should be comprehensible. You can still write concise code, but you can't "code in grunts" like you can in perl or bourne shell script.

Python has a cleaner OO model (not bolted on). It's easier to extend (via C or C++). It also makes a good high level wrapper for C or C++ libraries. It is infinitely better than perl for coding GUIs.

That's about all I can think of for now.

Re:Python vs. the others

[Anonymous Coward]

but I don't think Ruby will ever be very widespread.

Don't count on it. Ruby is the #1 scripting language in Japan, and it's now expanding into the US quickly. Ruby has lots of advantages over Perl and Python, and I see many Python and Perl programmers trying out and eventually flocking to Ruby. Try it for yourself and enjoy Ruby!

Re:Python vs. the others

[Anonymous Coward]

Ruby has lots of advantages over Perl and Python

Nope. Ruby has basically no advantage over Python, they are essentially the same language, with only details differing.

Welcome to our Overlords

[Anonymous Coward]

I, for one, welcome our new Python overlords and will gadly submit to their constrictions.

Re:Welcome to our Overlords

[AntiOrganic]

Don't look at me. I voted for Kang.

Re:Welcome to our Overlords

[Anonymous Coward]

Kang won, Kodos was the alternative. You fool.

Re:Welcome to our Overlords

[AntiOrganic]

Oops.

Is Python still lacking a macro system?

[oodl]

Any real geek knows that a language that isn't self-extensible through its macro system (ala Lisp, Scheme, Dylan) is just plane lame. :-)

I haven't been following python for a long time, though I've used it for a few projects. I know a lot of Lisp-like features such as lambda, eval, etc. have been added to it. (Java's adding a *lot* of features that Dylan has had since its inception, such as keyword arguments... but adding those features to Java makes the language even more ugly.) But what about a real macro system (and I don't mean a C style macro system)? I assume that it would be difficult to incorporate into Python because the Python syntax is not as consistent as the Lisp-family languages.

I assume that Python is still not efficiently compilable either, right? I think Guido was discussing a sealing mechanism for Python similar to Dylan's. Gywdion Dylan can produce code that's as fast as code written in C... and there's still many more optimizations that can be implemented into the compiler.

Re:Is Python still lacking a macro system?

[fredrikj]

Any real geek knows that a language that isn't self-extensible through its macro system (ala Lisp, Scheme, Dylan) is just plane lame. :-)

You don't need macros since Python is dynamically typed and even functions are first-class objects. At least I know I never missed the C preprocessor after moving to Python :P

I assume that Python is still not efficiently compilable either, right?

Not quite. There is however a dynamic compiler called Psyco, which works by creating static versions of functions at run-time to reduce type-checking.

My own experience is that Psyco makes Python code about 400% faster in real applications. Still an order of magnitude worse than C, but comparable to or better than other languages when it comes to tasks that Python used to do significantly slower.

Re:Is Python still lacking a macro system?

[oodl]

> You don't need macros since Python is dynamically
> typed and even functions are first-class objects.

You don't even know what you are missing. :-)

Lisp and Dylan are dynamically typed with functions as first class objects. However those features are orthogonal to a true macro system... They're not related. A true macro system allows a capable programmer to extend the language itself. Need a new control struct to lock a resource and then automatically unlock it at the end of the block of code? Well you can just write one yourself if you have real macros.

Re:Is Python still lacking a macro system?

[fredrikj]

Thinking of it, you could do that as well by writing a function that takes a string of Python code as input, does magic, and then passes it on to the interpreter for regular evaluation.

Not necessarily a good solution, but it might work.

Re:Is Python still lacking a macro system?

[Ian Bicking]

No, Python doesn't and won't have a macro system. The Lisp features like lambda and map are kind of in disrepute, at least from Guido's perspective -- see comp.lang.python for many opinions on the matter. Since Guido is Benevolent Dictator For Life, his opinion holds a great deal of sway. (BTW, map has been replaced with list comprehension, taken from Haskell, so it's not like functional programming as a whole is being rejected)

Macros would indeed be more difficult to implement in Python, because data and code are not as interchangable as in Lisp (e.g., (car 1 2) being code, '(car 1 2) being data). Macro-like manipulations of Python code would be rather difficult. But there has been discussions about ways of achieving the same flexibility without quite so much generality.

In a related example, some people feel that code blocks, ala Ruby or Smalltalk, are the right way to do control structures. Indeed they are very general. Python instead has developed notions of iteration, generation, and the use of first-class functions, and together they are all quite general as well -- you can do what you need to do. While more eclectic than anonymous functions/lambdas/closures, they are arguably more transparent -- you don't know what a function might do with a code block, and it can greatly effect surrounding code.

So it is with macros -- they are extremely general, and can do unexpected and magic things, (which is not in fitting with core Python principals). As Python grows alternatives, more things need to be built into the languages, but the result is a set of predictable and well-known idioms. Python is a full language, not the basis for other languages, as Lisp can become.

As far as performance, there are a number of things like Psyco, Pyrex, Numeric, and Weave/SciPy, which can handle performance problems (noting that in most application performance is not a problem). The result is again somewhat eclectic, but pragmatic. There's a wide variety of ways to optimize a Python program, many of which are just normal programming optimization (caching, making a process persistent, lazy loading, etc), as well as Python modules written in C or other compiled languages (potentially aided by things like SWIG, Pyrex, or ctypes)

Re:Is Python still lacking a macro system?

[Anonymous Coward]

Ok, I'll bite. I hear so many clames like language X can produce code that's as fast as code written in C.

Can anyone here actually point me to some hard facts that substantiate this claim for any language that's significantly higher-level than C?

And, no, I don't want to see example code that spends 98% of its time in some library functions. I want to see code written natively in a high level language that compiles to something as fast as C.

Anyone?

Re:Is Python still lacking a macro system?

[Anonymous Coward]

macro system

No.

No, no, no, no!

Re:Is Python still lacking a macro system?

[__past__]

Python comes with a module that will give you the parse tree of any expression as nested Python lists, similar to what READ does in Lisp. I don't know if it can actually turn a modified tree back to executable code, but I can tell you, once you have looked at such a parse tree, you don't want to modify Python parse trees anymore.

Java's adding a *lot* of features that Dylan has had since its inception, such as keyword arguments

Java is adding keyword arguments? Any pointers for that? How does it work with its style of method overloading?

Gywdion Dylan can produce code that's as fast as code written in C

Doesn't Gwydion actually produce C code behind your back and feeds it to GCC? And given how long that takes, one would expect that code to be fairly optimized... ;-)

Re:Is Python still lacking a macro system?

[Anonymous Brave Guy]

I hear so many clames like language X can produce code that's as fast as code written in C.

Can anyone here actually point me to some hard facts that substantiate this claim for any language that's significantly higher-level than C?

The ICFP competitions for the last few years make an interesting testing ground. While not large scale developments in the grand scheme of things, the requirements are non-trivial and well-specified. There have been entries in many languages, and performance comparisons can be made between entries written in different languages in some cases.

Clearly, the sample size isn't great, and you have problems with consistency of programmer skill among the developers entering their code. Thus the statistical validity of any generalisation would be questionable. However, some languages (O'Caml, for example) have now been used for several entries performing comparably to those written in C or C++.

If you're genuinely interested, you might be interested in looking up old results. You can decide for yourself how much faith you put in them as a comparison between languages based on how many entries to each competition there have been from each language.

Re:Is Python still lacking a macro system?

[Internet Dog]

Your :-) smiley suggests you don't really believe that macros are necessary in order to create a self-extensible language. In Python you would accomplish self-extension by using the meta-programming interface to the language. There's lots of interesting things that can be done using meta-programming to change the nature of the langauge. I supsect you will fine this technique to be as good as or better than macros for creating modified language characteristics. Tracing errors in Python is certainly much easier than in a macro-infested program.

Being compilable is not always the best way to achieve maximum efficiency in a program. The widespread use of Python in the animation industry and on supercomputers at LLNL suggests that optimization of an application does not require that all code must be written in a compiled language.Sometimes it is better to make efficient use of highly optimized modules that are easily reused. With processors running at 2Ghz it is often more important to maximize the efficiency of the programmer rather than the program.

Most of the heavy lifting in Python is done by code that is written in C. The Python language simply makes it much easier to set up the application to run the C code at top speed.

Re:Is Python still lacking a macro system?

[Anonymous Coward]

Need a new control struct to lock a resource and then automatically unlock it at the end of the block of code? Well you can just write one yourself if you have real macros.

...thus making your code unintelligible to other programmers. Lots of programmers will have their own way of doing thing, and you'll end up with Perl.

New processors

[Amsterdam Vallon]

For off, I really enjoy using Python. I find that it's really powerful, but still easy enough to use for those quick coding tasks that I need to write as a Solaris administrator.

I'm wondering this, however -- how will Python be affected in the 64-bit processor realm? Will it need to be modified significantly?

Re:New processors

[Filip Maurits]

Python already works on 64-bit systems.

Favorite quote

[henriksh]

Favorite quote from the interview:

ORN: I sometimes think it's a good job nobody has patented breathing; otherwise we'd all owe them money.

GvR: I guess there was prior art among the reptiles [smiles].

Heh.

Python is great.

[metatruk]

As a CS major, the intro CS classes at my school recently switched from teaching Java to Python. The class is designed to teach the fundamentals of computer science and computer pogramming. Python is extremely easy to learn, and quite powerful. We used the free text How to Think Like a Computer Scientist as the course textbook. I recommend this text to anyone interested in learning Python as a first programming language.

Why I like Python

[Anonymous Coward]

I like Python because:

1) Indentation instead of bracing. Yes, I know some people hate it but for me it makes the structure so clear.

2) Object orientation. I did OO with C++. I actually understood it with Python.

3) The smoothest ever integration to low level languages like C. Gotta love it.

4) Easy to learn. Write ab initio code with C/Fortran and never-programmed-before people interface it with Python. Then, grind out those MSc and PhD theses...

Re:Why I like Python

[Mooncaller]

2) Object orientation. I did OO with C++. I actually understood it with Python.

No suprise here:) C++ implimentation of OO is marginal to say the least. The syntax agrees to the letter of OO design, but not the spirit. The result is that most C++ code consists of procedural function dressed up in OO clothing. Many of the advantages of OOD can not be realised in C++ without some ugly code ( uglier then it already is). I learned OOP in the late 80s the hard way, by implementing all of the concepts and all of the philosophy in Pascal and C. I also learned Smalltalk, but without a Smalltalk enviroment, I could'nt do anything but read other peoples code. When I got my first C++ compiler in the early 90s, I was realy dissapointed. Unfortunatly, most people learn OOP vis C++, so they realy never quite get what OOP is all about. They also tend to confuse terminology with the underlaying concepts

Re:Why I like Python

[elflord]

The syntax agrees to the letter of OO design, but not the spirit. The result is that most C++ code consists of procedural function dressed up in OO clothing.

(1) How so ?
(2) But does this have more to do with the fact that a lot of C++ code is actually based on systems already written in C ? I can point to the KDE project as an example of an enormous codebase that is object oriented from the ground up.

Many of the advantages of OOD can not be realised in C++ without some ugly code

Such as ? Examples ?

Unfortunatly, most people learn OOP vis C++, so they realy never quite get what OOP is all about.

Actually, most people learn C with classes via a C++ compiler. They don't really acquire a good feel for C++. Most introductory courses do not teach nontrivial uses of polymorphism, for example.

As a teaching language, Python has a much gentler learning curve than C++, and the lack of strong typing makes the language simpler. The fact that C++ is not a great teaching language is not due to some inadequacy of the language -- it's due to the fact that if you don't make everything a pointer/reference (like java), OO becomes more complicated.

Re:Why I like Python

[Mooncaller]

2) From what I have seen, most OO reimplimentations of existing procedural systems are pretty good. Those that are not, are realy bad. I think most programmers, when faced with this task, pay a lot more attention to OOD principles. I think most C++ programmers tend to think more proceduraly. They identify the top level objects they are dealing with and start coding them up. As the start on the methods, they revert to procedural techniques instead of identifying lower level objects. This is what they are use to doing, it is how everyone else programms, and it is what they did for most of the coding they did in school. C++ allows, nay encourages this approch. It takes a lot of coding discipline to stay true to OOD in C++ when facing an overly agressive deadline.

1) Neither classes nor functions are objects. C++ is at its heart an OO abstraction layer to a procedural language. The Procedural underpinnings show through in many places.

Example:

Say there is a complex class A from which a set of classes B1,B2, etc. are derived. Class A needs to contain a method that modifies an object based on another object. E.g. b1.modify(b2) or b1.modify(b26) ( b1 is an object of class B1, etc).

I am not talking about EEs who have taken an intro to programming class using C++. I am talking about programmers, whos OOP language is C++. Many are so hung up on the mechanics of C++s Object models syntax, that they lose sight of the core concepts of the Object Based approch to programming. I created a large system in KSH. I used an OO approch. Another experienced programmer was assigned to help me with finalising, documenting, and deploying the system. At first, she was intimidated. At first glance, attempting to understand the system appeared daunting, but when looked at from an OOP perspective, it realy was quite simple. When I tried to explain the architechture, my coworker was baffeled "How can KSH be OOPish?". The structures where not what she expected of OOP. I finaly got her to understand that the directories were objects, the files where data, and the makefiles and scripts were methods, the scripts commandline parser provided polymorphism, and a couple of mechinisms provided inheritence. The creation of a directory structure with its included scripts and config files was instansiation, etc etc. When she looked at the system again, she immediatly understood how it worked. The problem was that my coworker had initialy confussed OOP with C++ syntax. I have experienced simular things from other C++ programers.

it's due to the fact that if you don't make everything a pointer/reference (like java), OO becomes more complicated.

I think this examplifies an inadequacy of C++. As I said befor, I learned OOP by implimenting OO concepts in C and Pascal using smalltalk as my guide. I did everything using pointers or refrences. In tend to agree with the Java crowd who claim that Java is C++ done right, even though I am not a big Java fan

Re:Why I like Python

[elflord]

I think most C++ programmers tend to think more proceduraly.

Again, I point you to the KDE project, as a huge OO codebase. It's plausible that someone coming to C++ from a background in C programming will think procedurally. But that's not the same as someone who learned C++ from the ground up.

Actually, real C++ programmers are more likely to make heavy use of generics.

They identify the top level objects they are dealing with and start coding them up. As the start on the methods, they revert to procedural techniques instead of identifying lower level objects. This is what they are use to doing, it is how everyone else programms, and it is what they did for most of the coding they did in school. C++ allows, nay encourages this approch.

I don't see how it encourages that approach at all, and you haven't explained why. Sorry.

1) Neither classes nor functions are objects. C++ is at its heart an OO abstraction layer to a procedural language.

These are not major problems in practice. At worst, they make for a few extra lines of code.

Say there is a complex class A from which a set of classes B1,B2, etc. are derived. Class A needs to contain a method that modifies an object based on another object. E.g. b1.modify(b2) or b1.modify(b26) ( b1 is an object of class B1, etc).

Not many languages have built in support for double-dispatch (if that's what you're getting at). However, there are freely available libraries (e.g. Loki) that make this sort of thing reasonably straightforward.

The problem was that my coworker had initialy confussed OOP with C++ syntax. I have experienced simular things from other C++ programers.

That's hardly the fault of the C++ programming language. It has more to do with the fact that C++ is a mainstream language, so students who are too lazy to learn more than one thing most probably learn C++. However, it happens that nowadays, there are also people with similar myopia who specialise in other languages. For example, there are C programmers, java programmers, and perl/PHP programmers, who can't see outside the limitations of their own pet language. But that isn't the fault of those programming languages.

I think this examplifies an inadequacy of C++.

Nonsense. It's a limitation, which results from a design tradeoff. The reason it's done this way is to provide extra performance. Even java uses built in types that are not objects for the same reason.

Or you can meet Lisp's cousin, Dylan.

[oodl]

Dylan is a language very similar to Scheme, but with an infix syntax and a module system.

Here's some sample code:

define method quicksort (data :: ) => sorted-data :: ;
if (empty?(data) | empty?(tail(data)))
data;
else
collect(head(data), tail(data), #(), #());
end if;
end method quicksort;

I know Paul Graham is not a fan of Dylan because Dylan's infix syntax has complicated the macro system. But nonetheless, Dylan still has a powerful macro system.

Also in Dylan, the compiler is not part of the run-time, as it is in Lisp, which makes it not as powerful as Lisp in that sense.

But still the Fourth Annual ICFP Programming Contest judges proclaimed that Dylan is a fine programming tool for many applications. :-)

Re:Or you can meet Lisp's cousin, Dylan.

[angel'o'sphere]

Funny,

when I looked at dylan, around 1995, it looked like pure lisp and I ditched it.

Then it seems the dylan lovers ditched it because of the infix notation and more keywords ...

angel'o'sphere

My experiences

[Gorny]

Very interesting interview. I've had many conversations with experienced programmers and with people who'd barely could program a Hello World in Python. After discussions we allways came out with Python to be the best language to learn to the newbies. It's nice, clean, dynamic-typed, which I find an important thing for someone new to programming, cause it lets you focus on the WHOLE thing and not on minor details (eg. details).

I've been a Python user myself and I find it quite remarkable how it has evolved since its 1.5.2 to the pointer where they are now 2.3. More and more (interesting) software is being written for it. But evenly important is the code base of Python. It's C implementation is very clean written and very easy to use so one can write extension modules very fast.

Re:Don't fully agree.

[GnuVince]

Well, for one Lisp's syntax is FAR easier than Oz's. Oz borrows a lot of syntax from ML which possibly has one of the most barroque syntax I've ever seen. Next, macros are extremely nice, more people know Lisp and Scheme than people know Oz, etc. You are right that there is no good free cross-platform implementation of Common Lisp. Scheme has PLT Scheme which runs on all three major platforms (*nix, Windows, Mac). Paul Graham has an upcoming dialect of Lisp coming called Arc, which I'm sure he'll port to these three platforms. Oh, and Emacs+ilisp is by far one of the best development environment I've used (maybe only second to Squeak)

Used in scripting book

[Shriek]

A Game Development Series book titled "Game Scripting Mastery" shows how to incorporate Python into a game scripting project. Yeah, I know this is a plug, but this book is a prime example of a known open source project being used as a teaching tool.

There is one caveat to this book though--it uses other scripting languages also, but it does provide a dedicated chapter for Python.

Game Scripting Mastery

This is mine

[TuringTest]

ORN: This resonates with your long-held interests in "computer programming for everyone". Don't you think that perhaps "everyone" is too broad, and that there aren't at least some people who will never be capable programming a computer?

GvR: That's a deep philosophical question. I'm optimistic about that in theory.

[...]

Given that I believe everybody can learn to read and write, given the right education and circumstances--obviously if your parents have no money and you're sent to work when you're seven years old, you're not in a very good situation unless you're exceptionally smart--I believe that the same thing would be possible for programming and thinking logically to some extent.

Unfortunately... Re:Don't fully agree.

[pioneer]

[Lisp] has a really steep learning curve, and there are no good free (as in software) development environments, as far as I know. (IANALisp Expert, though). Just you, Emacs and the Lisp interpreter.

Lisp is as powerful as mathematics, but there is more to a language than its semantics. It has to be accessible, too.

First off, Lisp isn't hard. It's like othelllo. Takes a day to learn and a lifetime to master. (gag)

My brief look at Oz seems to illustrate some similarities, but I'd have to check it out more to understand. Both have a core language set that everything else is reduced to. In lisp these are cons, car, cdr, cond, quote, apply, eval.

I'll take a look at Oz but what makes Lisp very powerful is that it has no syntax. The text is literally the parse tree which means that macros are very easy to define and use. The entire idea of programming using Lisp is to develop a language on top of Lisp. If you are writing an image editor you define an embedded language in Lisp for image manipulation. An because things can be compiled at runtime and macros can hide computation at compile time you can get good performance as well.

There is also a misconception that a language needs to explicit in what is efficient and inefficient. What is misunderstood is that it is very often not obvious where the bottlenecks are. The way to make a Lisp program fast is the same way you make a C program fast. 1) Profile 2) Find hot spots 3) Optimize 4) Rinse and repeat.

Also, concerning free development environment check out Dr. Scheme which is a nice UI and comes with a bunch of packages. I was working on some encryption problems and had a graphical histogram implemented in about 2 minutes. Try doing that in Java.

Lisp isn't designed for the average programmer. The best programmers use Lisp (if they are allowed to by their bosses) because it is the most powerful.

Re:Unfortunately... Re:Don't fully agree.

[TuringTest]

so, the whole point is that Lisp is not a programming language but a kind of language definition language? Just a raw parse tree, and Build Your Own Syntax. See why I say it's difficult? You haven't ANYTHING done for you in advance.

I never got to understand why Lisp programmers think of the macro system as the primary and more exclusive power of the language, now I start to see it. But how do to learn to create those domain-specific languages? It is so far away from conventional academic lectures, that one needs to forget almost everything to start thinking that way!

And I'm not convinced that that syntaxlessness is indispensable. If the matter is problem solving, just learn problem solving, not Lisp language. I would prefer to have some syntactic sugar which does the code more readable than those ((if()(and no then)(nor else keywords))s), even if that makes a little bit more difficult the "new language definition" (and I don't think it would: macro definition is famous to be a tricky bussiness on its own).

Re:Unfortunately... Re:Don't fully agree.

[Anonymous Coward]

First off, Lisp isn't hard. It's like othelllo. Takes a day to learn and a lifetime to master. (gag)

And as the first language in a university level CS program it successfully made me change my major subject from CS to Physics.

There is just something fundamentally disturbing in recursion. It's just not healthy.

Re:Unfortunately... Re:Don't fully agree.

[__past__]

so, the whole point is that Lisp is not a programming language but a kind of language definition language? Just a raw parse tree, and Build Your Own Syntax. See why I say it's difficult? You haven't ANYTHING done for you in advance.

Oh, come on. Common Lisp has about 1000 defined symbols (i.e. variables, functions, macros, classes ...). It includes an extremely powerful exception system, highly flexible OOP, and all the mundane stuff like lots of standard datatypes, control structures, IO, pretty printing etc. People frequently bash it because it's too big.

You don't have to do any kind of language design when you do Lisp programming. You can get a long way with just using plain function definitions. Yet you can easily define new syntaxes, control structures and stuff.

never got to understand why Lisp programmers think of the macro system as the primary and more exclusive power of the language, now I start to see it. But how do to learn to create those domain-specific languages? It is so far away from conventional academic lectures, that one needs to forget almost everything to start thinking that way!

Back when I was the proud owner of a Commodore C 128, I used to think similar things about useless stuff like GOSUB. Why can't we just stay with the more familiar GOTO that everyone understands?

Get over it. Learning new tools is usefull, but it's work. Get a good book on Lisp macros, and dive in.

And I'm not convinced that that syntaxlessness is indispensable. [...] I would prefer to have some syntactic sugar

You are not alone. And, given that you can actually define a new syntax, many people tried to come up with alternatives to raw s-expressions. And indeed succeeded. However, none of these alternatives ever got too popular (the most successfull attempt might by the Dylan language, which started with s-expressions, but dropped them). People could have used alternative syntaxes, but the vast majority chose not to.

Re:Unfortunately... Re:Don't fully agree.

[pioneer]

the problem with using a language like Java is that when you problem solve in your head you "think in Java".... thinking in java is a mess. java is so obtuse, so ladden with crap and extra syntax that doesn't get you anything. just the fact that lisp is dynamically typed makes it slimmer... i can guarantee that you can't write a program in C that i can beat in length in lisp... and i bet that i could write a short lisp program that you wouldn't be able to write in C without significant effort.

(when i say you, i mean the "royal" you, not you specifically)

Re:Unfortunately... Re:Don't fully agree.

[TuringTest]

People frequently bash it because it's too big. And that's my own opinion. 8-) I find it difficult to learn because there are thousands of things to learn, and no syntax to discriminate between them - so no mnemonics to carry from one learning session to the next. I suppose i could manage it if i tried hard.

But now I'm learning Oz with the people at Pragmatic Programmers "language of the year" mailing list. I find its syntax easier to grab, and I think it will be a worthwile experience. So one thing at a time.

Re:Unfortunately... Re:Don't fully agree.

[kkhawi]

>I never got to understand why Lisp programmers think of the macro
> system as the primary and more exclusive power of the language

No, it is not. The macro system is available, but only ONE componenet
of the whole language. You can write entire applications without ever
having to write a single macro. The macro system is just a power tool
that ships with the systems. Infact, most Lispers advocate against
macro over use!

> now I start to see it. But how do to learn to create those
> domain-specific languages? It is so far away from conventional
> academic lectures, that one needs to forget almost everything to start
> thinking that way!

Lisp programmers write DSLs as often as C programmer write YACC grammars; very rarely.

> And I'm not convinced that that syntaxlessness is indispensable. If
> the matter is problem solving, just learn problem solving, not Lisp
> language.

I agree with you 100% the goal of programming is solving problems (though it is about creating problems most of the time ;-) I believe a problem should be expressed in its own terms, instead of being trapped in idle-loop of trying to find implementable anologies to your problem.

One way to solve this might be via OOP techniques; Encapsulation, Inheritance and Polymorphism, etc. But before OOP (and post OOP some might argue.) there have been other ways to decompose a problem, e.g. functional decomposition with top-down and bottom-up programming.

If you are using a traditional programming language however, with its own set of hard-coded keywords, conditional and iteration constructs, it own minimum program unit, it own view and expectation of the underlying machine, etc. You will realize that you will need the most flexible programming language to accomodate all known problem solving paradigms, and hopefully the ones yet to be discovered.

Lisp is one[1] such language. It doesn't hijack your spoken language or your way of thinking. You can always override the system provided functionality just as easily as you can derive your own new solutions. It has many levels of evaluation to give you the most functionality. The expression level macro facility, which allows you to manipulate and generate your own source-code[2] is merely one of them. An entire object oriented programming protocol has been built on top of Lisp, and now is integrated into the language.

> I would prefer to have some syntactic sugar which does the code more
> readable than those ((if()(and no then)(nor else keywords))s),

Hehe :-D

I would be more willing to show possible lisp examples on any
algorithm you might have. It is really not a complex language, if
anything, it is one of the easiest things out there. I used it as
a calculator for ages before I knew it was called Lisp[3].

---
[1] The jury is still out on the defenition of Lispness. One man's Lisp might be another man's S-expression. See XML and this http://logic.stanford.edu/kif/kif.html for example.

[2] Code-generation is just getting some attention from the popular
programming media. Another Lisp programming techniques debuts in mainstream-developia, this time not via MIT but ... see for yourself http://www.manning.com/herrington/

[3] I "independently discovered" Lisp while I was in high-school. While trying to simplify algebriac expressions, before I typed them into my calculator. Memoization was what allowed me to be the #1 king of answers, I always beat everyone to the solutions since I never had to retype long expressions over and over again ;-D

Re:Unfortunately... Re:Don't fully agree.

[kruntiform]

i can guarantee that you can't write a program in C that i can beat in length in lisp... and i bet that i could write a short lisp program that you wouldn't be able to write in C without significant effort.

No doubt, but that wouldn't really be a reasonable comparison because they are different classes of language. C is a machine-level language; Lisp is much higher-level. I guarantee I could write a fast, bit twiddling device driver in C with less effort than you could in Lisp. The results for the ICFP 2003 Programming Contest come out in a week or so. That is always interesting. From memory, Lisp entries have done well, but haven't excelled (though Dylan came second one year).

Re:Unfortunately... Re:Don't fully agree.

[Anonymous Coward]

"language of the year"

Cute. What language will you be learning next year?

Re:Unfortunately... Re:Don't fully agree.

[Jo.Calder]

Having done serious work with LISP, I would now reject it on the grounds that its type system is broken and too much programming within it relies on side effecting. This combination means that determining what a nil return value means, as far as the logic of some program is concerned, can require analytical skills orders more powerful than mine.

Kent M Pitman?

[Anonymous Coward]

Is that you?

Lisp vs Python vs?

[Anonymous Coward]

vs sex with a mare ?

Re:Python - Python in a nutshell

[hashmap]

My recomendation:

Python in a Nutshell by Alex Martelli

Hands dow the best introduction to Python from a programmer's prespective. That is if you are already familiar with basic programming concepts. The great thing about the book is that covers just about every aspect in an extremely concise way that does not bore you to death.

I'm a certified Java and XML developer, gave up on Perl long time ago, discovered Python, somehow got over my initial suspicions regarding the whitespace ... within two weeks it became my favorite language. I do just about everything in Python and it takes about 80% less effort. Love it baby!

Quote of the week from the python newsgroup:

"What can I do with Python that I can't do with C#?
You can go home on time at the end of the day." -- Daniel Klein

h

Why python rules

[joib]

There's a fairly detailed interview with bruce eckel ("famous" guy who has written c++ and java books and sits on the C++ standards committee) at artima on why he likes python (I linked to the last part of the article series, since that contains links to the previous ones).

Re:Why python rules

[Ricdude]

Great interview. Choice quote:

I feel Python was designed for the person who is actually doing the programming, to maximize their productivity. And that just makes me feel warm and fuzzy all over. I feel nobody is going to be telling me, "Oh yeah, you have to jump through all these hoops for one reason or another." When you have the experience of really being able to be as productive as possible, then you start to get pissed off at other languages. You think, "Gee, I've been wasting my time with these other languages."

After I started getting used to python, that's about how I felt. A programming language that gets (almost) all the crap out of your way for you. My only marginal complaint is the requirement to specify "this." in front of member invocations within a member function. In practice, though, it's nice to have the visual reinforcement that this is truly a member function, and not a global scope function.

+5 Insightful

[TuringTest]

;-) And I would like to like Lispness, but just don't get it.

Not necessarily a bad one.

[TuringTest]

You could implement that as a top-level function or even as a class method, and it would just work. And it would be easy to understand and program (something which, I believe, Lisp macros aren't).

The only difference I think it would have is that it would run at execution time, not compile time. But I'm sure that a not too far away future version of Python will do that... ;-)

correction

[Anonymous Coward]

Python isn't "totally" object oriented.

Re:Don't fully agree.

[Anonymous Coward]

> You are right that there is no good free
> cross-platform implementation of Common Lisp

GNU CLISP Unix, DOS, OS/2, Windows, Amiga, Acorn, Mac platforms.

From the site:


CLISP includes an interpreter, a compiler, almost all of CLOS, a foreign language interface and a socket interface. An X11 interface is available through CLX and Garnet. Command line editing is provided by readline.

CLISP runs on microcomputers (OS/2, Windows 95/98/2000/NT, Amiga 500-4000, Acorn RISC PC) as well as on Unix workstations (GNU/Linux, BSD, SVR4, Sun4, DEC Alpha OSF, HP-UX, NeXTstep, SGI, AIX, Sun3 and others) and needs only 2 MB of RAM.

CLISP is Free Software and may be distributed under the terms of GNU GPL. You may distribute commercial applications compiled with CLISP, see file COPYRIGHT in the CLISP distribution.

The user interface comes in German, English, French, Spanish, Dutch and Russian, and can be changed at run time.

Well,

[TuringTest]

then, no mathematical mind is healthy! 8-) You did well in change, if you have a sequential mind.

Java is not interpreted

[Decaff]

Java is almost never interpreted these days. Its loaded as virtual machine byte code, then dynamically profiles, optimized and run as high-performance native code in almost all situations. High quality VMs (such as those from IBM) can run many Java apps as fast as C/C++. Saying that perl/python and other scripting languages beat Java in terms of speed is simply typical Slashdot anti-java FUD.

Re:Java is not interpreted

[Anonymous Coward]

>> Saying that perl/python and other scripting languages beat Java in terms of speed is simply typical Slashdot anti-java FUD.

Actually, it's not FUD.

For string processing, database access, and pretty much...well...everything, Perl *smokes* Java. Python is slower than Perl, but Guido acknowledges that.

Also, though one can buy into the Java Marketing Machine and proclaim that there is indeed a "Virtual Machine" and "Java is not interpreted", in fact, very few languages are actually "interpreted" in the line by line execution sense of GW Basic these days. Perl builds a parse tree and then executes this parse tree. Java bytecode is produced from source, but this bytecode, too, must be executed as data, not as a native instruction. All of this is relatively meaningless; arguing that Java's "virtual machine" is not an interpreter does not say anything for the language, and I'm really disappointed that you would make random speed claims without code to back that up.

Now let's talk about memory footprint and how small you can make Hello World + the interpreter be in Java. I can get it disk space to 500k (with PAR) without even trying. The python folks can do similar with py2exe.

Also, do you happen to have source code for your language? Can you contribute new modules to be accepted by Sun into the standard distribution?

Re:Java is not interpreted

[greenrd]

For string processing, database access, and pretty much...well...everything, Perl *smokes* Java.

Links to studies? Statistics?

Java bytecode is produced from source, but this bytecode, too, must be executed as data, not as a native instruction.

If you'd read the actual post you responded to, you'd learn that bytecode is nowadays compiled to native instructions.

All of this is relatively meaningless; arguing that Java's "virtual machine" is not an interpreter does not say anything for the language

Of course it does. It is a plank in the argument that the implementations are typically fairly efficient.

and I'm really disappointed that you would make random speed claims without code to back that up.

Ditto.

GPL

[Slothrup]

I guess one difference is that it has a long history, since it was first distributed in 1991. In those days nobody talked about "open source", and Richard Stallman [founder of the Free Software Foundation] wasn't very well known and the GNU General Public License didn't exist.

WTF? The GPL didn't exist in 1991? I guess I was hallucinating when I was using GNU Emacs and GCC in the 80s.

Re:GPL

[JordanH]

As a Perl guy who is looking for reasons to dislike Python, I have to say this doesn't go a long way toward helping Guido's credibility with me.

I'm really disappointed that Guido doesn't know the history of the FSF and the GPL.

Re:GPL

[Anonymous Coward]

The GPL first appeared in in the June 1988 issue of the GNU Bulletin.

The current GPL (version 2) was released in June 1991.
The History of the GPL

Re:GPL

[Anonymous Coward]

That's like me (as a Dutch guy) dislikeing the US because Bush doesn't know the capitol of The Netherlands.

Re:Both Python and Perl can do AI

[Anonymous Coward]

ATTENTION Slashdotters.

The poster is named "Arthur T Murray" and is a well known newsloon
and crackpot extraordinaire!

Please don't feed the shills.

why Python is better

[Gumby]

Compared to C code I have found python to be 10x faster to put together functioning programs. Whenever I have a task were cpu cycles are not critical, I do it in python.
One insight I had the other day, is that even though python is a yonger, less popular language than C/C++, you can do anything (algorythmically) in python that you can in C/C++ with the standard libraries, plus a whole lot more. That implies to me that python is more expressive and productive, because the people writing the libraries have packed in so much functionality.

C is for execution speed. Python is for development speed.

I second that

[stewby18]

It's a great reference. I taught myself quite a bit of Python from scratch using only that "book". Very clear, and very comprehensive. The fact that it's free, and downloadable in a variety of forms, just makes it even better.

Re:Don't fully agree.

[kruntiform]

Oz borrows a lot of syntax from ML which possibly has one of the most barroque syntax I've ever seen.

That's odd because I find ML's sytax to be very sensible and simple (though I've only used OCaml and not any of the other ML dialects) and I find Lisp's unreadable. Many Lisp proponents like to say Lisp's is the one true syntax, but I don't see how that could be true when there must be a large subjective component to why one person prefers one syntax over another.

One of the problems I had when I tried to learn Lisp was that it needs special editor support. This meant, as far as I could tell, I had to learn emacs. I'm not interested in learning emacs. I prefer Windows style editors; their use is burned into my "finger memory" -- I'm used to them and am efficient with them. I did try to learn emacs once, but I found it very complicated. At that time at least, emacs could only scroll half a screen at a time. This seemed to me to be rather unergonomic! There was an add-on available to add line-by-line scrolling, but to install it I needed to Read The very large F'ing Manual and learn Lisp! I don't think it can be said that Lisp's syntax is easy if in order to learn it, you have to learn some complicated tool on top of learning the language itself.

In any case, just looking at Lisp code on paper, I find it hard to read. I can see that everything being S-expressions is conceptually very elegant, but to me there are not enough cues there for my human brain to parse the text easily. No doubt I could learn to read Lisp code with practice, but the initial hurdles are too great for me to bother with it just now, especially when there are so many interesting languages out there. And I find all the Lisp zealotry offputting. (I'm not saying you are a zealot; I'm sure most Lisp users are level-headed, lovely people. But there seem to be a lot of Lisp zealots about.) I find it hard to take any kind of zealot's word about anything being the One True Thing because they always have huge blind spots.

extensible AI game programming inputs?

[Sivaram_Velauthapill]

Does anyone have any thoughts on extensible AI game programming using Python? Basically, I"m trying to create a user-programmable AI for a game (simple scripting that users can do, kind of like in many FPS games). I'm evaluating Python VS Lua (google to find info about Lua). I think Lua is best for my tasks but does anyone have any thoughts on Python?

In particular, I'm not too sure about the performance implications of Python for a real-time game. The game is a free open-source game so it's not a life and death situation but still...

Sivaram Velauthapillai

Re:extensible AI game programming inputs?

[leshert]

Dunno... Python seemed to be fast enough for Freedom Force, the Humongous Backyard Sports games, and Ultima Online.

Re:extensible AI game programming inputs?

[elflord]

In particular, I'm not too sure about the performance implications of Python for a real-time game. The game is a free open-source game so it's not a life and death situation but still...

Fortunately, it's very easy to wrap classes written in C++ (or C!) in python. There is a bindings generator called sip (which PyQt is based on) which makes this very easy.

However, I doubt you'll have trouble with performance unless you're doing something extremely computation intensive (in which case, code the appropriate functions and/or classes in C or C++ then wrap them). Line-for-line, python is about 1/200 the speed of C, which is fast enough for many purposes.

Please change "Von" to "Van"

[brrrrrrt]

Surnames starting with "Van" ("from") are Dutch, like Guido.

"Von" is the German version. Dutch people don't like to be taken for Germans, for historical reasons..

My favorite quote from the article

[Doppler00]

GvR: ...I do it myself by staying where I am and giving keynotes at conferences and making my personal life the subject of discussions on Slashdot. ...

ORN: Perhaps they should get lives of their own instead of discussing yours?

I think he's talking about us...

Re:Python - Python in a nutshell

[phthisic]

I've been coding for several years now, both professionally and as a hobby, in maybe a dozen different languages (most of those as a hobby). I love Python. I'm addicted to it. And I love Nutshell books (I have 13 or more), but I don't care that much for Python in a Nutshell. Nutshell books are best when they are a high-density first read and a great reference afterwards. This one, however, has too much of a narrative thread to be a great reference and yet at the same time that narrative is not well woven -- the book is too choppy to be easily read straight trough. I would love a book written like VBScript in a Nutshell but about Python.

Also, this is just a nit pick but, while I realize that Python is a big subject, I dislike how often this book mentions something only to conclude "but I don't cover that here." Why tell me what you're not going to tell me? Just tell me what you are going to tell me. I can do the 'subtraction' myself.

Personally, I have found that the best way for me to begin learning Python and to continue to learn Python is to check out the documentation, google for specific questions, and experiment for the rest. Experimenting is especially handy and productive given the Python interactive interpreter (especially when coupled with the bash shell history). While there may be other languages/interpreters which allow you to do so, Python is the only language/interpreter I know of which allows you to design GUIs on the fly, adding and configuring elements from the command line:

Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter as tk
>>> root = tk.Tk()
>>> btn = tk.Button(root)
>>> btn.pack()
>>> btn.configure(text='Exit')
>>> import sys
>>> btn.configure(command=sys.exit)

Which brings up another point. I have yet to find a really good source for Tkinter info -- neither a good tutorial nor a good reference. My main source of info to date is to use the following tricks. If, for instance, I want to find what I can do with the button in the example above, I do this.

>>> for a in dir(btn):
... print a
...
_Misc__winfo_getint
_Misc__winfo_parseitem
__doc__
[etc.]
winfo_width
winfo_x
winfo_y
>>>
>>> for key in btn.keys():
... print key
...
activebackground
activeforeground
anchor
[etc.]
underline
width
wraplength
>>>

I would greatly appreciate it if someone could point me to a quality Tkinter reference.

Re:Don't fully agree.

[pioneer]

That's odd because I find ML's sytax to be very sensible and simple

ML is strongly typed which means its immediately useless. OOP can viewed as a relaxation from strong types (in C) to slightly dynamic types. You watch, eventually most languages will be dynamically typed).


One of the problems I had when I tried to learn Lisp was that it needs special editor support. This meant, as far as I could tell, I had to learn emacs.

First off, emacs is butter. Emacs is gorgoes. Emacs is so extensible and so efficient that its stupid. If you sat down and learned it for a week you would be twice as efficient than any windows editor. Emacs is built on lisp and for this reason all of emacs is extensible... everything!!! It's really amazing.

Concerning Lisp syntax, the thing about Lisp syntax is that its syntax is a parse tree where as most languages (none s-expression languages) require a token/parser stage to compile. Because you work on the sytax tree, macros are trivial to write because you are just performing modifications on the parse tree...

Top 4 dynamic programming languages: where's PHP?

[Anonymous Coward]

On page 2 of interview:

"Perl, Python, Ruby and Tcl are the four dynamic programming languages that get the most publicity as open source projects, and I think they have a lot more in common than they differ."

Hello? Language Usage Estimates (based on Google searches).

Depending where you look, PHP gets far more publicity than Python, Ruby and Tcl put together, for example: Head-to-Head: PHP vs. ASP.NET.

Quit being some kind of language snob. PHP may not be the greatest language ever designed but it's highly popular and aside from web sites, does a reasonable job on the command line and is capable of simple desktop apps: PHP-GTK.

More to the point, alongside Apache, it's one of the main things holding off the Beast from domination of the Internet.

neither can I

[Anonymous Coward]

what's up dude, I just got metamod for the guy who flamed you down; he's getting an unfair. peace, justice and the american way.

Dump the significant whitespace!

[Anonymous Coward]

Down with significant whitespace! The problem is that you can't tell what a whitespace character is by looking at it. For example, is that a tab, or is it eight spaces? There is no way to tell! You can't type in a program printed on paper and be sure that you got the whitespace right. Often you can't even be sure that you will get the same whitespace if the program is distributed over the internet as text.

Until Python replaces significant whitespace with printable characters, it will always be a poor second to Perl in my book.

Re:Dump the significant whitespace!

[Internet Dog]

You have obviously not tried using Python. That's your loss. I have yet to hear of a whitespace bigot who tries Python for a few weeks who doesn't change their position regarding the use of whitespace as a block delimiting mechanism. The degree of the conversion ranges from sheepishly admitting that it works very well, to becoming raving supporters of Python because the feature works so well.

Proper indentation of a program is considered good style in all computer languages, including Perl. It is simply good programming practice to indent consistantly within a program. Python simply requires that good style be used in a program, rather than leave it as an option. This seems to irritate many narrow-minded, lazy, and sloppy programmers who think curly braces are the only proper way to denote blocks of code.

Re:Dump the significant whitespace!

[elflord]

The problem is that you can't tell what a whitespace character is by looking at it. For example, is that a tab, or is it eight spaces?

In python, it is always 8 spaces. It's considered bad style to use tab. If you use emacs, then emacs will automatically use the correct settings in python mode.

The simple fact is that if you ignore the usual style guidelines for any programming language, there are obvious gotchas. The whitespace gotchas you mention are relatively harmless, as they are caught by the compiler.

There is no way to tell!

There are a lot of ways to tell. For example, in vim, :set list displays tabs as ^I and displays a $ sign on the end of each line.

You can't type in a program printed on paper and be sure that you got the whitespace right.

Spoken like someone who's never tried. Seriously -- never had a problem with this.

Often you can't even be sure that you will get the same whitespace if the program is distributed over the internet as text.

Save to file, and whitespace is preserved.

Until Python replaces significant whitespace with printable characters, it will always be a poor second to Perl in my book.

Pleasing anonymous morons is not one of the design goals of python. Sorry.

Re:Dump the significant whitespace!

[Anonymous Coward]

In python, it is always 8 spaces. It's considered bad style to use tab. If you use emacs, then emacs will automatically use the correct settings in python mode.

I thought the emacs mode used 4 spaces? Either way, the Python style guide recommends using 4 rather than 8.

Re:Dump the significant whitespace!

[elflord]

"""I thought the emacs mode used 4 spaces? Either way,"""

You're correct. Sorry, I wasn't very clear. What I meant was that in python, good style dictates that one always uses spaces to ident (in C mode, most editors will use a mix of tabs and spaces). For example, in this code:

class Foo:
def f(x):
print "hello"

in emacs, the leading whitespace preceding the pritn statement is always 8 spaces (and not one tab, as it would be in C mode). <p>
I always use modelines in emacs and vim to enforce consistent indenting anyway.

Re:Dump the significant whitespace!

[Anonymous Coward]

Often you can't even be sure that you will get the same whitespace if the program is distributed over the internet as text.

You mean the Makefiles are messed up all the time? Oddly enough it didn't happened to me. Or maybe you are talking about the infamous space-eating nanovirus which eat some characters of your files, and by chance only characters ASCII 0x20 and ASCII 0x9.

Re:Dump the significant whitespace!

[Anonymous Coward]

Actually, Python does seem to please morons (like yourself). There's really no other point to the language.

Re:Dump the significant whitespace!

[Anonymous Coward]

Is that the best you can do ? "I know you are, but what am I" ? You're supposed to precede the name-calling with a rebuttal, moron. Frothing at the mouth without an argument makes you look like a moron, moron. Are you happy being an anonymous moron, moron ?

(OT) Hello, world!

[Anonymous Brave Guy]

Now let's talk about memory footprint and how small you can make Hello World + the interpreter be in Java. I can get it disk space to 500k (with PAR) without even trying. The python folks can do similar with py2exe.

You can write "Hello, world!" in only 500k?

I'm impressed. In my youth, we did it using feeble tools like x86 assembler on MS-DOS, and it required a massive 25 bytes, more than half of them taken by the string in question.

I know about apples and oranges, but I can't help wondering if the way that half megabyte overhead is tossed around so casually doesn't account for why today's 3Ghz processor, 1GB RAM beasts still struggle to handle a mid-size word processor document...

PHP is not easy to read, in most cases

[supton]

PHP suffers readability not in syntax, but in archetecure design. With global namespaces for module functions (say, for example, to FTP a file), you do not have the ability to trace the logic between source files and modules in someone else's code. In addition, PHP encourages the inlining of code in presentation, and most PHP code is not modular (some is) - but on top of that the most popular mechanism for code reuse is eval() and include(), which simply pop more crap into the global namespace without being explicit what they do.

All this impacts readability. Python does not have these problems becuase it encourages explicit namespaces for all objects/modules/packages/classes/etc. Python also enforces readabilty by simple (easy) use of whitespace (this is a good thing.

Re:PHP is not easy to read, in most cases

[Malcontent]

Of course it's possible to write crappy code in php just like it's possible to write crappy code in python. For example neither language mandates classes.

As for you other critisims I think they are offbase. Both languages use include() hell all languages have some sort of an Include. PHP does not "encourage" inlining of code, smarty is an official part of PEAR but neither does it force people to use smarty. Finally speaking for myself I don't think I have ever used eval() nor seen it used in any major projects. Having said that both python and ruby have eval type of functionality so what is the big deal?

We also disagree on the importance of whitespace. I personally don't like to have it forced on me by the language. If I wanted a straightjacket I would have used pascal or eiffel or something.

Re:PHP is not easy to read, in most cases

[Anonymous Coward]

Firstly, I've yet to run into an "include"-ish mechanism as versatile or intuitive as Python's.

Secondly, Neither Eiffel nor Pascal forces whitespace to be used in any particular way, though Eiffel does force an OO approach.

Re:PHP is not easy to read, in most cases

[brlewis]

Not all languages have some sort of include(). BRL has (paste ...) which does not pollute any namespace.

PHP: Capable != Appropriate

[supton]

PHP is popular (as is M$ ASP) becuase it has a gentle slope for web designers to learn programming. I don't think this is a bad thing, but inlining code and presentation is really not the right way to be encouraging new folks to programming to code... PHP teaches programmers bad habits like excessive use of global namespaces, and generally is accomplished with poor editing style becuase it is inlined with HTML, which has different needs for editing/indentation/etc.

A more appropriate introduction for this audience to programming might be python and TAL (template attribute language - the core of Zope's Page Templates, and the only vendor-neutral industry standard, cross-language templating system beside XSLT). I'm not suggesting Zope is appropriate for everyone (though for big apps, it really is best), but perhaps mod_python + page templates would be a better alternative for lightweight web-based scripting than PHP.

PHP does not work well for team programming, and Python does. If you are developing applications in a vacuum, by yourself, this may not matter, but on a team where you need to have coders of many skill levels, business managers, and designers interact, you really need to divide logic from presentation, and use componentized code with explicit namespaces to enable that sort of interaction. Otherwise, it just more <?PHP include("./someunknownquantity.php"; ?> magic.

Re:PHP: Capable != Appropriate

[Anonymous Coward]

"but inlining code and presentation is really not the right way to be encouraging new folks to programming to code..."

You'd better tell that to the guys working on mod_python cause they've already introduced PyHP - Python Hypertext Preprocessor. And while you're at it, better tell the guys a PERL::MASON of the error of their ways.

"PHP teaches programmers bad habits like excessive use of global namespaces, and generally is accomplished with poor editing style becuase it is inlined with HTML, which has different needs for editing/indentation/etc."

PHP doesn't teach anything. If you choose to use globals that's your problem. You'll find if you look most PHP community sites advocate avoiding the use of GLOBALs.

Also as to "inlined with HTML", PHP originally was a templating language. Zope's TAL is simply another programming language (designed specifically for templates) and it's even been ported to PHP PHPTal. As template languages go, TAL is OK but if you're going to have a declarative template syntax (as opposed to an imperitive syntax like PHP in HTML or Mason) you'd be better off with one which gives you some real power, like ASP.NET or Java Server Faces.

Suggest reading up on the TemplateView. That link is a particularily in depth study of templates.

"PHP does not work well for team programming, and Python does."

Yes Python is a better designed language but, based on your arguments, there's no particular advantage it has for teams. Zope is framework built with Python but you'll find many excellent frameworks written in PHP which also have some form of templating e.g. eZ publish or Krysalis (based on Apache Cocoon).

The usual argument for "what works for teams" is things like "private, protected, public". Both PHP and Python lack this (although PHP5 is a different story) so the emphasis is on developer self discipline e.g. __myprivatevar or $__myprivatevar

When to use what?

Use Perl for command line and batch processing
Use Python for desktop apps
Use PHP for web based apps.

It's easy to write OO code in Perl!

[Anonymous Coward]

> Python is totally object orientated, and very intelligently designed in this department. Whereas in Perl (5) you have to jump through hoops to create objects, especially OO modules, in Python it's as easy as assigning a variable a new value.

But it's easy to jump through those hoops in Perl. Just use a module. Here is an example of how to do it using a module:

#!/usr/bin/perl

package Object1;
use strict;
use warnings;

# Easy OO in Perl, using the Class::Struct module
use Class::Struct;

struct(name => '$', id => '$');

my $obj1 = Object1->new;
$obj1->name("Bart Simpson"); $obj1->id(12345); $obj1->display;

sub display
{
my $self = shift;

print("My name is ", $self->name, ", my id is ", $self->id, "\n");
}

__END__

Cut-n-paste that in and try it out. Read the documentation for Class::Struct, Class::MakeMethods, and Class::MethodMaker with perldoc. It is easy and fun to write OO Perl, and it scales very well to big projects.

Perl gives you several ways to go object-oriented, including writing the everything yourself. But it's easier to use a module.

Re:It's easy to write OO code in Perl!

[Anonymous Coward]

But it's easy to jump through those hoops in Perl. Just use a module. Here is an example of how to do it using a module

It is still less elegant than Python:

class Object1:
def __init__(self, name, id):
self.name = name
self.id = id
def __repr__(self):
return "name=%s id=%s" % (self.name, self.id)

obj1 = Object1("Bart Simpson",12345)
print "I am:", obj1

And having one file per class is not an option for me.

Re:Fool!

[jc42]

Well, of course you can do anything in perl. First you write a routine that emulates a Turing machine ...

Inaccuracy about GPL

[solferino]

van Rossum :

I guess one difference is that it has a long history, since it was first distributed in 1991. In those days nobody talked about "open source", and Richard Stallman [founder of the Free Software Foundation] wasn't very well known and the GNU General Public License didn't exist.

parent poster (Slothrup) :

WTF? The GPL didn't exist in 1991? I guess I was hallucinating when I was using GNU Emacs and GCC in the 80s.

Yes, I was also surprised at this large factual error.

GPL Version 2 : June 1991

GPL Version 1 : February 1989

Earlier forms of Copyleft licenses also existed from before 1989. The Free Software Foundation was founded in 1985 and has of course always released its work as 'Free Software'.

p.s. Slothrup, I suggest evening tea at Miss Quoad's would be a suitable punishment for van Rossum's inaccuracy. As a man who named his language after an English comedy group, I'm sure he has the required sensibility to appreciate the full horror of this particular engagement.

Re:Don't fully agree.

[kruntiform]

ML is strongly typed which means its immediately useless. OOP can viewed as a relaxation from strong types (in C) to slightly dynamic types. You watch, eventually most languages will be dynamically typed).

You can't just dismiss static typing so easily. (I think "static" is a more accurate term than "strong" here.) Static vs dynamic typing is the subject of endless religious wars, and there is no clear winner yet. Each has its advantages and disadvantages. My personal preference is to lean towards static typing but with type inferencing (like in ML) where you don't have to declare types unless you want to. I have done a fair amount of programming in dynamically typed languages (in fact, I've just convinced my bosses that a new app we are writing should be written in Python instead of C++. Hooray!).

First off, emacs is butter. Emacs is gorgoes. Emacs is so extensible and so efficient that its stupid. If you sat down and learned it for a week you would be twice as efficient than any windows editor. Emacs is built on lisp and for this reason all of emacs is extensible... everything!!! It's really amazing.

What I like about Windows style editors (CUA style editors) is the simplicity; there's pretty much just the cursor keys, ctrl, shift, etc. I can drive that with the lower parts of my brain -- I don't have to consciously think about it, which is good when programming because then I can think about the problem at hand. I've heard that complicated editors like emacs and vi are good for touch typists. That sounds reasonable, but I'm not a touch typist. And whenever I need to do some fancy text processing, I just write a script.

Concerning Lisp syntax, the thing about Lisp syntax is that its syntax is a parse tree where as most languages (none s-expression languages) require a token/parser stage to compile. Because you work on the sytax tree, macros are trivial to write because you are just performing modifications on the parse tree...

Like I said, it's conceptually elegant. But I still don't think it's readable. Lisp macros are something I'll get around to looking at sometime. I think I'll wait till Arc comes out; hopefully much of Lisp's historical baggage will have been sloughed off and it will be more pleasant to learn.

MOD PARENT UP

[Anonymous Coward]

The article is clean.

Re:Don't fully agree.

[Anonymous Coward]

How many people are working on Arc? Will it be another Hurd type project?

Third party modules

[FuzzyDaddy]

Many very useful third party modules has been the draw for me.

I don't have much experience with other scripting languages, but I've found python to have a lot of very easy to use modules. I've found modules for polynomial fitting to data, large data sets, polygons operations - just out there when I looked for them. And many a useful library in C or C++ has been wrapped in Python. For example, I've written some CAD software (for very specific design operations we do where I work), and needed a way to merge polygons. I found a wrapper for the generalized polygon clipper (GPC) library, installed it and got it working in a few minutes. And because of the nice structure of the language, the modules are usually very easy to learn how to use.

C++ and tuples

[rjh]

If you haven't already checked out Boost, now would be the time. Boost provides tuples in C++.

And regarding your example code, the same can be done trivially in C++ with the added significant bonus of strong static typing:

typedef std::vector<std::pair<std::string, std::string> > StringPairVec;

StringPairVec tuples = AddressBook.getEntries();
for (StringPairVec::const_iterator i = tuples.begin() ; i != tuples.end() ; i++)
std::cout << i->first << " lives in " << i->second << std::endl;

Three lines of Python, three lines of C++ (barring the typedef, which is only there to make the rest of it easier to read).

Re:C++ and tuples

[ultrabot]

And regarding your example code, the same can be done trivially in C++ with the added significant bonus of strong static typing:

Yes, I have written code like this, and generally like STL (too bad I can't use any of it for my work). However, it requires quite a lot of typing, and the resulting code is not as easy to understand.

Three lines of Python, three lines of C++ (barring the typedef, which is only there to make the rest of it easier to read).

And therein lies the catch, typedef is needed.

Re:C++ and tuples

[chgros]

i++
You should always use the prefix increment ++i when using STL iterators (although in the case of vector they might just be typedefs for pointers).
The reason is that since the postincrement must return the previous value, the iterator has to be copied.

Re:C++ and tuples

[rjh]

According to the latest spec, a vector iterator is a pointer. And besides, I'm not going to optimize my code before I run it through a profiler--premature optimization is the root of all evil.

Re:C++ and tuples

[khanyisa]

OK, so who votes to type 1) over 2)? Clearly Python is better :-)

1)

tuples = get_address_entries()
for name,address in tuples:
print name,"lives in",address

2)

typedef std::vector > StringPairVec;

StringPairVec tuples = AddressBook.getEntries();
for (StringPairVec::const_iterator i = tuples.begin() ; i != tuples.end() ; i++)
std::cout first second std::endl;

LISP misconceptions

[rjh]

the whole point is that Lisp is not a programming language but a kind of language definition language?

You've been fed a batch of bad Kool-Aid. Fortunately, it's not too late to come around. :) LISP is, without a doubt, a full-featured programming language. It supports everything Java does, for instance; objects, iteration, exceptions, variables, recursion... the list goes on and on.

It's what LISP brings to the table above and beyond being a programming language (as most programmers think of the term) which makes it so astonishingly wonderful.

Build Your Own Syntax. See why I say it's difficult? You haven't ANYTHING done for you in advance.

(define _merge (l1 l2 cmp)
(cond
((null l1) l2)
((null l2) l1)
((cmp (car l1) (car l2))
(cons (car l1) (_merge (cdr l1) l2 cmp)))
(t
(cons (car l2) (_merge l1 (cdr l2) cmp)))))

Presto. Right there's a merge done in eight lines of code. It's generalized to the point where it works for anything, provided you give it an appropriate comparison function. And note--I didn't need anything big and fancy to do it. No imports or includes, no useless structural scaffolding...

LISP provides you with all the tools you'd expect of a modern programming language. The beauty of LISP is that you can do a hell of a lot of things in very small amounts of code without needing anything special. Ever seen someone write a PROLOG interpreter in 150 lines of LISP?

But how do to learn to create those domain-specific languages?

You start by doing, of course. You start by solving just one little part of the problem set, and you'll get about fifty lines in and you'll realize, "wouldn't it be nice if the language allowed me to do $foo?" Then you go off and make the language do $foo. Lather, rinse, repeat, until you've got thousands of lines of code creating a new special-purpose language to solve problems in a given problem domain, and five lines of code that actually solve your problem.

It is so far away from conventional academic lectures

Ever taken a Computational Theory course? LISP and LISP-like languages are used very heavily in Computational Theory courses precisely because they're so intimately tied to the lambda calculus, which is a formal model of computation.

And at MIT, introductory CompSci students are taught in Scheme, so you can't even say it's far removed from undergraduate lectures, either.

that one needs to forget almost everything to start thinking that way!

Yep. You do need to forget everything in order to start thinking that way. That's why it's called progress. Once you grok LISP and the lambda calculus, you not only see how to recreate all the old ways of doing business--you see how the old ways of doing business actually work, because now you have a formal model of computation to fall back upon.

And I'm not convinced that that syntaxlessness is indispensable

Syntax is necessary because otherwise you're left with a jumbled mess--sound and fury signifying nothing. If I pound out random letters at my keyboard I can say that it's the complete works of Shakespeare ("yes, dsfw98eradjct9e! is actually `to be or not to be'"), but that doesn't mean anyone can comprehend them.

To that extent, LISP has a very strong syntax. Don't mistake the simplicity of LISP's syntax for a simplistic syntax. LISP's syntax is extremely regular and extremely simple--far more than any other language I've come across.

If the matter is problem solving, just learn problem solving, not Lisp language.

LISP is a language meant specifically to solve problems. Where's your problem with it?

I would prefer to have some syntactic sugar which does the code more readable than those ((if()(and no then)(nor else keywords))s)

Get a good IDE and spend a few hour

Re:LISP misconceptions

[Anonymous Coward]

Presto. Right there's a merge done in eight lines of code. It's generalized to the point where it works for anything, provided you give it an appropriate comparison function. And note--I didn't need anything big and fancy to do it. No imports or includes, no useless structural scaffolding...

Well, not only you can translate your merge example line by line to Python, but in Python you would remove the 'cmp' argument (at least make it optionnal), to default to the objects' class default or user-defined __cmp__ function.

Re:LISP misconceptions

[TuringTest]

I use indentation instead of parentheses.

So you admit it!!! ;-)

I think that's the crucial problem with Lisp syntax. It's not mean to be easily read, but easily accessed from the language itself. My point is that Lisp is a 40 years old programming language, and that has its burdens. Everything discovered later about user friendliness is lacking. Lisp syntax is too simple for most everyday tasks as, for example, reading other people's code.

If you have to remove the main attribute of the language in order to understand and think in it, is clear that THAT attribute should be removed. And that's what Python, Haskell, etc. have been doing, even if it complicates a bit the essential meta-code construction. There's no doubt that the powers of Lisp are needed (and that is the reasong for the other languages playing the "add something which Lisp has had for decades" game), but Lisp high learning curve is something that most programmers can't simply afford.

Re:LISP misconceptions

[rjh]

It's not mean to be easily read, but easily accessed from the language itself.

It is easily read. Just invest the time getting over the initial hurdle of the parentheses and it's a very easy-to-read language.

My point is that Lisp is a 40 years old programming language

John McCarthy first started working on LISP in the 50s. It's older than 40 years.

Lisp syntax is too simple for most everyday tasks as, for example, reading other people's code.

This would be true if LISP programmers generally had difficulty reading each other's code. Generally speaking, we don't.

If you have to remove the main attribute of the language in order to understand and think in it, is clear that THAT attribute should be removed.

The two main attributes of LISP are (a) everything's a list and (b) functional programming. I get rid of neither when I'm sketching out code. All I'm doing is ignoring the parts of the syntax which I don't need.

When I write C++ pseudocode, I don't specify type traits for templates. I use indentation instead of brackets. I play fast and loose with typing.

When I'm writing Python, I always leave off the "self." qualifier before member variables.

When I'm writing LISP, I ignore the parentheses.

Lisp high learning curve is something that most programmers can't simply afford.

Spoken like someone who's never learned LISP. LISP's learning curve is surprisingly gentle, which is why it and its derivatives are used in so many undergraduate CS curricula.

Re:LISP misconceptions

[TuringTest]

It is easily read. Just invest the time getting over the initial hurdle of the parentheses and it's a very easy-to-read language.

Let me desagree. I like that my if's have then's attached (to separate the condition, 'then' and 'else' expressions). Call me maniacal. 8-)

The two main attributes of LISP are (a) everything's a list and (b) functional programming

I'm not at all convinced that (a) is mandatory to get the benefits of introspection and code generation, which can be done in other ways. And as (b), fortunately many of the principal benefits of Lisp are finally becoming available in other mainstream languages. So yes, Lisp was better in the 70's, and in the 80's, and in the 90's, but I believe that on the XXI century other languages will catch up and offer the same benefits with many other additional advantages.

John McCarthy first started working on LISP in the 50s. It's older than 40 years.

Yep. Mine was a wild guess, i didn't know the precise date.

Spoken like someone who's never learned LISP. LISP's learning curve is surprisingly gentle, which is why it and its derivatives are used in so many undergraduate CS curricula.

I *have* learned Lisp (or is it LISP?), but not well. Maybe my problems are from a bad experience and a bad teacher, since nobody has tried to explain me the inner working of the interpreter (I haven't yet managed to know how many kinds of variables, namespaces, forms and expressions are there, for god's sake!), and the books i have peeked don't do a good job explainin it clearly either.

Re:LISP misconceptions

[rjh]

I *have* learned Lisp (or is it LISP?), but not well.

Well, there you go! Pick up a copy of Friedman and Felleisen's The Little Schemer or The Little LISPer and go to town, go have fun, learn LISP. The Little... is the best introduction to programming I've ever seen, especially the best introduction to LISP and Scheme and SML/NJ.

nobody has tried to explain me the inner working of the interpreter

Classic LISP fits into 6k of Assembly. Scheme is even simpler. The Revised Report on Scheme (the definition of the language) is only a handful of pages. McCarthy's original LISP was completely and formally specified in just 12 pages. Common LISP's spec is over 1000 pages, but the vast majority of that (700 pages or more) is dedicated to the Common LISP Object System (CLOS), which is totally unnecessary to know in order to learn LISP goodness. Remove CLOS and the Common LISP spec is actually smaller than K&R's The C Programming Language.

Regarding whether it's LISP or Lisp... originally it was an acronym for LISt Processing, and hence was properly capitalized. But over the years LISP has become more or less a proper noun, and it can be spelled as Lisp, too. Generally, old-school LISP hackers use the all-caps, while the new generation of LISP hackers use Lisp.

I'm an oddball, in that I'm a new-generation (I'm 28) who was taught by a bunch of old-schoolers. So I picked up their method of spelling.

Re:YAPLWDN

[Mooncaller]

Yah, we should all be programming in machine code.

Explicit typing

[Homburg]

First off, as others have pointed out, you don't need to introduce a new class to do this kind of thing - C++ has vectors and pairs built in, and tuples will probably be in the next version of the standard.

However, you're right about the 'easy to instantiate' part, but I don't think static typing is really the problem. The problem with types in C++ is that you have to explicitly mention them, when a lot of the time the compiler could figure them out itself. In your example, you could do:

std::vector<std::pair<std::string, std::string> > entries = get_address_entries();

The type declaration isn't really necessary - the compiler knows that get_address_entries() returns a vector of pairs of strings, so could give the variable it's proper type. There's been some discussion about introducing type-inference into the language, so you could say:

auto entries = get_address_entries();

Which would make this kind of thing as easy to use as Python, while keeping the advantages of static typing in tracking down errors.

Re:Explicit typing

[ultrabot]

C++ has vectors and pairs built in, and tuples will probably be in the next version of the standard.

Not built-in enough; In python I can do:

mylist = [("hello",3),("world",4)]

Additionally, some environments shun STL (and templates in general) because it leads to code bloat.

There's been some discussion about introducing type-inference into the language, so you could say:

auto entries = get_address_entries();

Like that is ever going to happen... I don't even think any C++ compiler has achieved ISO C++ compliance yet. Type inference would be lovely, it seems to work nicely on Ocaml at least. Perhaps gcc project should fork the language, C++ is by definition quite unportable anyway :-).

Re:Explicit typing

[kinga]

I don't even think any C++ compiler has achieved ISO C++ compliance yet

The EDG C++ front end is fully ISO/IEC 14882:1998 compliant, including export support. Look at their resellers for a list of compilers based on it.

C++ and Regexps

[Homburg]

You could probably implement inline regular expressions in C++ using expression templates, actually. Check out Spirit, which gives you inline BNF grammars in C++.

Great for the occasional programmer

[Nice2Cats]

The good things about Python that the other posters mentioned are true, but there is one thing that I really love about the language: It not only fits into your brain, it also stays there, even if months pass between programming sessions.

I don't get to program much, since I have a day job, and to make matters worse, my formal training with computers was brief. Basically, I learned Python on public transport, communiting to and from work (the Python Cookbook causes people to turn their heads, by the way). I tried learning Java at one point, but the problem is that there are too many details and formalisms that you have to remember to even get anything off the ground.

Not so with Python. Basically, you just write what you want to code. Want to know if there are characters in a string?

if 'chocolate' in mystring:
....print 'I love it!'

(This is new in Python 2.3, and I can't get the indentation to work here). Fantastically intuitive.

The only "problem" is the way the library keeps growing from release to release: Something that you had to code yourself a while back suddenly is a trivial feature. More of an embarrassment of riches than a real problem, but it does make you feel like a fool sometimes. "Why code that socket server? Just use..."

One other nice thing about learning Python is how amazingly friendly and helpful their tutor list is. I've asked some amazingly stupid questions in my time, and they have been very gentle and kind.

Re:Don't fully agree.

[angel'o'sphere]

Well, there are lisp and clos implementaion in Java ... just like there are Smaltalk implementatins in Java.

See: grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

angel'o'sphere

Think Different!! Re:LISP misconceptions

[angel'o'sphere]

You made an excellent post, but it misses the point, I think most LISP enthusiasts miss the point, because they simply do not realize that diffrent people THINK DIFFERENT!!

Your example
(define _merge (l1 l2 cmp)
(cond
((null l1) l2)
((null l2) l1)
((cmp (car l1) (car l2))
(cons (car l1) (_merge (cdr l1) l2 cmp)))
(t
(cons (car l2) (_merge l1 (cdr l2) cmp)))))
is excellent.

a) I'm at first german, and english I learned in school. So: That above is completely unreadable to me!

the only word in my english german dictionary where I can find a translation is null.

b) I understand most of the stuff anyway, as I learned some lisp basics.

c) So I analyze how someone might aproach that above:
(define _merge (l1 l2 cmp) ...

reading your further post, I realize cmp is a cmparision function.

As lisp is typeless ... not strong typed ... how should I know that cmp is a function? And how should *I* as a german realize that cmp is short hand for "compare"? How many native english speakers would think cmp stands for compute?

Same for cond ... for the non lispers: its a condition, similar to switch, or lets say a more structured if/else chain.

d) lets look at ((null l1) l2) now:
As someone who has learned just the absolute basics: I would asume null is something special similar to nil. NIL is the "empty list" or that what is null in C. So if the parameter l1 is "empty" the parameter l2 is returnd as result (as merging one list with an empty list yiels the non empty list unchanged).

e) same for ((null l2) l1):
Just a test for returning the OTHER list ... if l2, where is looked at is null.
So: I pledge you: I know pascal ... C .... and other languages: how the heck am I supposed to memorize that the statement above (choose between d and e if you like) does perform a "return"?

f) now: ((cmp (car l1) (car l2))
As I have pointed out, cmp is a name for a function, whichis given as a parameter to the function _merge, jsut think about it like a pointer to a function inc, e.g. for the famous qsort function in the standard clib ...
I wonder what car means? Its not in my english/german dictionary ....

Well, this time I can only tell you what it does, I dont know the english word. It takes the first item of the list. So the statement compares with the cmp function the first element of l1 with the first element of l2.

g) lets look at (cons (car l1) (_merge (cdr l1) l2 cmp))) now:

three new things: cdr, again something not in my dict and cons another thing, not in my dict. And a recursive call to _merge again.

Bottom line, why is it not written like this:
(function _merge (l1 l2 compare:function)
(select_if
((empty l1) return l2)
((empty l2) return l1)
((compare (first_of l1) (first_of l2))
(new list (first_of l1) (_merge (first_of l1) l2 compare)))
(t /// what the heck is the 't# here anyway?
(new list (first_of l2) (_merge l1 (first_of l2) compare)))))

I have the strong feeling, that you do not really get my point :-)

So I summarize: besides a way of using () which you need to get used to, there are theveral things hidden in 8 line sof lisp code:
i) recursion
ii) using of functions as arguments
iii) returning values without using "return" or anything similar as keyword
iv) basicly ... there are no keywords at all
v) totaly stupid nomenclature .... not only a native english speaker can not guess what cdr and car means, no a non english speaker has not even a chance to look it up in a dictionary.

Re:Think Different!! Re:LISP misconceptions

[rjh]

I'm at first german, and english I learned in school. So: That above is completely unreadable to me!

It's unreadable in English, too. It's perfectly legible when thinking in terms of formal computational theory. English, German or other natural languages are not good choices for programming; there's too much context sensitivity, too much implicit meaning, for it to reduce well to mathematics.

the only word in my english german dictionary where I can find a translation is null.

Your dictionary doesn't have "define"? (Although that's honestly a typo in my code; it should've been defun, not define. Scheme uses define, LISP uses defun.)

Besides, this is a red herring. Look up "Thread" in your dictionary, and then think about how that word is used in Java (hint: it has nothing to do with sewing). If you're going to learn a programming language, you need to learn the language--not preconceptions about "well, it uses this word, therefore it must mean this".

how should I know that cmp is a function?

By how it's used in the code. It cannot be anything other than a function. It's perfectly unambiguous.

I would asume null is something special similar to nil.

The first rule of programming: Thou Shalt Never Assume. If you don't know what something does, look it up.

This is something the OpenBSD developers discovered; lots of C programmers simply don't know their own APIs. Instead of bothering to check if sprintf() has a buffer-overflow vulnerability (it does), many C programmers are happily oblivious assuming that nothing bad can ever happen to it.

Look it up. If you don't understand it, if you aren't one hundred and ten percent sure on what it does, look it up. Nobody's going to think you're an idiot because you say "wait a minute, I don't grok this, where's my copy of Common LISP: The Language?"

(This is not an elitist attitude. If it were elitist, I'd say that if you didn't already know you weren't worthy of knowing, and that's one hundred and ten percent not true. But I do insist that people look it up instead of blindly assuming that function foo must do bar simply because it's named foo.)

I know pascal ... C .... and other languages: how the heck am I supposed to memorize that the statement above (choose between d and e if you like) does perform a "return"?

You're supposed to look it up, of course.

I wonder what car means? Its not in my english/german dictionary ....

Autofahren. Except in this case, where it means Contents of the Address Register (CAR). I'm old-fashioned in that I still use CAR; Common LISP also defines the much more English-like FIRST for people such as yourself who feel things ought to have more English-like names.

Of course, if you looked CAR up in CTLT, you'd already have known this.

why is it not written like this:

Because you haven't finished writing your own LISP-like language with that syntax. Stupid answer, but true. If you feel that strongly about it, LISP gives you the tools to do exactly that.

there are theveral things hidden in 8 line sof lisp code:

Not at all. Nothing's hidden. You should know that much computational theory already. If not, ask your professors why computational theory isn't being covered.

Recursion and functions-as-data are both extremely simple, extremely basic, freshman-year computational theory subject matter.

Your points 3 and 4 are trivial. Perl doesn't require you to explicitly return values, either. Nor does Python, nor does... insisting on explicit return statements says that all you know are C-style languages and you don't want to learn anything new.

For point 5, anyone who's looking up computer terms in a language dictionary deserves exactly what they get. Go to the Common

Re:Think Different!! Re:LISP misconceptions

[angel'o'sphere]

You missed my point.

The fact is that different people think different.

And if you like to draw one to LISP who thinks in different concepts, he wont come.

Of course your explanaition is completely valid, and of course it applies to me :-) as I tend to look up stuff.

But: looking up CDR helps not. Because I need to be able to memorize it. As I said: some people find it hard to memorize "meaningless" data.

Regarding your point about vmp, must be a function .... because it is used like a function ... this means for understanding that _merge is a function you need to know how functions are used and you need to see some lines below that cmp is used as a function.

This is TRICKY, as you have to make a recursion in your mind over topics you have not allready understood. And thats the problem.

BTW: we dpo not need to talk about me ... I realized allready that I don't like adn don't need LISP. And funnyly, its only about its syntax, as all other stuff of LISP I'm copying in my on programming habits.

I fully agree that a CS worker should have the knowledge about the key concepts, e.g. recursion.

BTW: Java in a Nutshell is completely unnecessary for me. Java exactly works as I had designed it .... because I Think in Java (TM) ... Probably you should try that book as well :-) Bruce Eckels: Thinking in Java.

Anyway, I fully agree with your point that LISP is a wonderfull tool. But I hope that people will understand over the years that languages have a lot of levels. And our thinking uses the level it is adapted to. That varies from person to person and from age and culture, their natural language, ability to abstract and ability to focus on the concrete.

If you like to lead people to a special programming language you have to change the concepts in wich they think first.

Most Java Programmers comming from C or COBOL write C or COBOL in Java Syntax .... for 3 or more years.

Most LISP Programmers comming from C or COBOL ... write nothing for weeks!!! Because they can not jump over.

Probably structured programming languages should not even tought anymore in schools :-) only functional and OO languages ... probably SQL as well. Just moving some thoughts back and forth in my mind.

angel'o'sphere

Re:Python - Python in a nutshell

[khanyisa]

That's because you should rather use wxPython Try it and see...

Oh, the irony.

[joeytsai]

Any language that is *only* objected oriented is forcing you to look at everything as nails.

Try Lisp, you'll feel much better.

(Insert language here) is just a watered down Lisp.

Bah, all you've said is that functional programming is your only hammer.

Turing Complete

[Latent Heat]

Great post. If something (i.e. that data-turned-script) is Turing Complete it is also possibly Turing Undecidable.

That is also the nagging feeling I have had about extending applications with scripts. Not only are the scripts possibly violating the principle of least power, but you are handing over to your non-programmer users essentially a programming tool, no matter how sandboxed, hand-held, error-checked, and feature-restricted. At some level programming is programming with all the potential for bugs and bad design.