Sponsored Link •
Bill Venners: I've heard that one of the problems with Python is that it invites less design. Because people can so easily write their programs quickly in Python, they tend to just charge ahead without any planning. Do you think verbosity, such as the verbosity of Java compared to Python, tends to make people want to plan more?
Guido van Rossum: Planning is good and bad. If you know where you're going, planning is good. If you don't know what you'll encounter on the way, you should be more open-minded and improvisational. I certainly see a place for planning, but if the language forces you to plan everything, there may be trips you'll never undertake because it would require too much thinking ahead. You're then inhibited by fears that you don't know how to do something. In Python, you can start doing that something and discover how to do it on the way. You can build something quickly, get it on the road, obtain feedback, and then design the next one based on greater understanding of the problem domain.
Bill Venners: I often feel that creating software is like mixing cement. It starts out soft and hardens over time as you stir it. You can't see everything in advance, so you can't plan everything up front. You can make a plan, but once you try it you realize it would be much better to do it another way. So you iterate. Each time you iterate you move towards a better solution, and the body of code that depends on your choices grows. Eventually it all just kind of hardens. You end up with released interfaces that you're stuck with.
Guido van Rossum: And then you really have to be backwards compatible.
Bill Venners: So perhaps being able to make changes gets you farther ahead before things harden. Maybe things don't harden as early in Python because you go through the iterations more quickly.
Guido van Rossum: Yeah. I always feel that the interesting programming jobs are the ones in which you don't know exactly where you'll end up. Implementing another spreadsheet is boring. There have been many spreadsheets. We know what the user interface should be like. We know what the right implementation techniques are. We know a whole bunch of things. Yes, you can write another spreadsheet. You can probably plan it very well, because you can do a feature-by-feature checklist of all the other known spreadsheets. I want this. I want that. I want to fix this problem with this particular one. I want to avoid that bug. That's easy, but it's not very interesting.
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.
The Python world has some nice examples of this. Early on, when the Web was just becoming interesting for things like shopping online, a small company called eShop was developing various commerce servers. eShop had proprietary protocols and proprietary applications, and it realized that it should just be able to use a Web server and Web browser. The developers decided to do a prototype in Python. Because they used Python, the eShop developers were the first to release a beta version compared to many other startups doing exactly the same thing. They never actually released working code after their beta release, because the company was acquired by Microsoft. Microsoft spent two or three product revisions to eventually replace all the Python code with C++. But if eShop hadn't started in Python, it would never have released something interesting enough for Microsoft to acquire in the first place.
That also happened with Yahoo. Yahoo Mail started out as a successful Python application. Again, because the developers used Python, they could respond quickly to the user feedback. And that's an application that almost everybody can use. They saw many things wrong with their application, and they responded to that quickly and added new features. Because they were doing something new, they didn't know exactly what people would need from an email Web application. It is different from a program that has your email on your computer. Access times are different. All sorts of things are different. So they were learning about what those differences were. And again, I think Yahoo may now have replaced all the Python code with C++ or some other language, but the Python prototype was essential in order to get there.
Come back Monday, February 3 for Part IV of this conversation with Python creator Guido van Rossum. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
What in the languages you use do you feel provides the biggest boost to your own productivity?
What gets in the way the most?
Discuss this article in the News & Ideas Forum topic,
Programming at Python Speed
Python.org, the Python Language Website:
Microsoft press release about their acquisition of EShops, Inc.:
Introductory Material on Python:
Python FAQ Wizard:
Guido van Rossum's home page:
Other Guido van Rossum Interviews: