Artima.com has published Part III of an interview with Python creator Guido van Rossum, in which he talks about about the source of Python's famed programmer productivity and the joys of exploring new territory with code.---xj40dkcfea73---Artima.com has published Part III of an interview with Python creator Guido van Rossum, in which he talks about about the source of Python's famed programmer productivity and the joys of exploring new territory with code.

http://www.artima.com/intv/speed.html

Here's an excerpt:

I like programming problems where you think, "There has to be something really interesting over there, but I can't see it clearly." All you can do is move one step over there, with a small bit of code, and start exploring to see it more clearly. And maybe it actually wasn't there, it was over here. Or it had a different shape than you thought initially. Maybe it wasn't interesting at all, and you didn't waste a lot of time.

The danger of planning is that you plan for the contingencies you know about, but by definition you don't plan for things you don't know you'll encounter. So when you do encounter an unexpected event in your programming endeavor, you have to fix many interfaces and change multiple method signatures. If you've already committed to your original plan and that's no longer where you're going, then you have a problem.

I'm not particularly worried by the fact that people say you can prototype more easily in Python, but eventually the Java version makes it easier to build a robust large system. You can prototype in Python. Once you've explored the space more, you can do the planning and design that the Java version requires. If you start writing in Java knowing as little as you did when you started writing the Python version, you'll waste way more time exploring than actually building the system you'll eventually build.

What do you think of Guido's comments?

A couple of years ago I would've agreed with that excerpt. But now I think what really lets you explore with abandon is the safety net of compile time checking, and a good refactoring tool.

I also would've agreed about the finger typing argument Guido made, but not after the latest revision or two of the leading Java IDE's (IntelliJ, Eclipse, and perhaps JBuilder from what I hear?). It is just incredibly, incredibly easy to write, modify, and navigate with these tools.

That's not to say there isn't a lot of value in Python (from what I've seen of it), the libraries and such definitely seem to be easier to understand and use. Guido is obviously a very smart guy and kudos to him for making an important contribution to the programming languages landscape!

I agree with you on the IDEs -- they have really improved the task of programming in the more verbose languages. However, Guido still has a good point in that the brevity and simplicity of working with lists and dictionaries in Python really is significantly simpler than in Java or C++. Working with Maps and Lists in Java is made easier by an IDE's auto-completion and syntax checking features, but it is still nowhere near as clear and simple as in Python.

For example, in working with Strings in Java, you might find yourself needing to create lots of ancilary objects, such as Enumerations, Iterators, StringTokenizers, Lists, Maps, etc., whereas in Python you don't need to think so much about other objects -- you concentrate more on the task at hand.

The conversation displays several misunderstandings of the role of contracts and types in programming.

Types are a syntactic form of contract. Like syntax, types are checked before the program is run.

Contracts are a semantic form of contract. They are compiled (interpreted) before/after a method is called. These concepts are complementary not exclusive.

Python, Racket, and other 'dynamically typed' languages carry around tags that some primitives check at run-time. So it is correct to call Python an 'implicitly contracted' language. Here is the problem of contracts vs types, however. If the check fails, an exception is signaled. In the good old days of Pascal, the stack trace would more or less nail down the sequence of function calls and events that produced this exception. In expressive ("higher-order") languages such as the ones discussed here, this is simply not the case. To make this claim a bit more concrete, if f calls g and stores argument h in some array and returns, and k retrieves h from the array and calls it and something goes wrong, the programmer can't easily find out that it was f that accepted h even though it was supposed to accept only methods that support readline.

The problem with Python is that it withholds this power from programmers that it grants to its implementor, namely, the power to restrict access to a method if the arguments don't work. As a result, every programmer has to create the same kind of protection code time and again.

As the success of Python demonstrates, this lack of expressive power doesn't mean a language can't succeed. It just means it makes its programmers work hard and harder -- after it lured them into its network with a pretense (its lightweight style).

Next, the lack of types isn't a problem for the development of systems. Lispers, Perlers, Schemers, Racketeers have programmed in this style for as long or longer than Pythonistas. The problem comes when the system is maintained. Time and again, the maintenance programmer has to re-discover that the third argument can be either this kind of object or that kind of object or perhaps even FALSE. Frustrated with half an hour of work, the programmer may even add a comment about what was discovered. Only to find out next time that someone else inserted another parameter into the method signature without any document.

To fix this kind of problem, an untyped programming language should come with a typed sister language, and modules in the two languages should be able to freely interoperate -- without undermining the type specs. (Technically, the type system is sound, even in the presence of untyped code.) If this pairing is available, a maintenance programmer can write down discoveries as checked type specification. The next maintenance programmer doesn't have to guess which parameter stands for what kind of argument. The annotations nail it down, and they are checked. Those parts of the system that are never touched remain untyped. The two portions of the system happily interoperate because the boundaries automatically generated type-like contracts that enforce types (even for higher-order objects) automatically.

Racket has pioneered this approach to its full extent. Some people refer to this as 'program hardening', others say 'gradual typing', we dubbed it 'from scripts to programs' -- implying that the evolution of a program should imply stabilization of some parts, and that includes typing.

Look beyond Python. It's worth it.

http://racket-lang.org/