Slashdot Mirror
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."
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...
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)
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?
War is necrophilia.
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.
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.
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.Programming can be fun again. Film at 11.
>> 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?
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:
Cheers,
Brian
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.
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.
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.