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

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: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: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.

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.