Python and the Tipping Point - A Conversation with Bruce Eckel, Part IV

Python and the Tipping Point - A Conversation with Bruce Eckel, Part IV
A Conversation with Bruce Eckel, Part IV
by Bill Venners
July 21, 2003

Page 1 of 5 >>

Advertisement

Summary
Bruce Eckel talks with Bill Venners about how Python's minimal finger typing allows programmers to focus on the task, not the tool, generating a productivity that makes more projects feasible.

Bruce Eckel wrote the best-selling books Thinking in C++ and Thinking in Java, but for the past several years he's preferred to think in Python. Two years ago, Eckel gave a keynote address at the 9th International Python Conference entitled "Why I love Python." He presented ten reasons he loves programming in Python in "top ten list" style, starting with ten and ending with one.

In this interview, which is being published in four installments, I ask Bruce Eckel about each of these ten points.

* In Part I: Python and the Programmer, Bruce Eckel explains why he feels Python is "about him," how minimizing clutter improves productivity, and the relationship between backwards compatibility and programmer pain.
* In Part II: The Zen of Python, Bruce Eckel explains why he prefers Python's valuing programmer productivity over program performance, Python's you-want-it-you-can-have-it attitude, and Python's zen-like learning curve.
* In Part III: Type Checking and Techie Control, Bruce Eckel explains why he prefers Python's latent type checking and techie control of language evolution.
* In this final installment, Bruce Eckel talks about how Python's minimal finger typing allows programmers to focus on the task, not the tool, generating a productivity that makes more projects feasible.

I Don't Have to Type So Much

Bill Venners: In your "Why I Love Python" keynote, you gave ten reasons you love Python. Number three was: "I don't have to type so much." To what extent do you think the productivity gain you get with Python, which you said was 5 to 10 times over Java, is just from reduced finger typing?

Bruce Eckel: I don't think the productivity comes from the finger typing so much, although that is certainly part of it. The main sources of productivity are that I am able to look at more lines of code on the screen, put more meaning into fewer lines of code, read and understand code more easily, and deal with higher level concepts. Also, Python comes with "batteries included," which means a large quantity of library functions come with the standard Python download.

Finger typing is clearly oversimplifying all that, but nevertheless, finger typing is the root of it all. In Python I can type fewer words to express my meaning. The reduced typing has something to do with the productivity increase I see when using Python, but more productivity probably comes because I have to think less hard to do what I'm doing.

My Guesses are Usually Right

Bill Venners: Your number two reason for loving Python was, "My guesses are usually right."

Bruce Eckel: I seem to have had influence on two of the slogans for the Python conference. A few years back I was having dinner with Guido van Rossum, and I said, "Life is better without braces." That ended up being a conference slogan, along with a smiling character who looked like he had just gotten his braces off. The next year, I suggested to Guido a slogan that I think somebody else probably said first, "Python. It fits your brain." That's what I was talking about when I said, "My guesses are usually right." Python allows you to get into this uninterrupted flow, and just go with that without having to think too hard, even if I have to look up the way a library works.

One of my first real productive experiences with Python, beyond just playing around with the language, involved image processing. I wanted to resize some GIF files. Given my experience with other languages, I figured this task might take me half a day if I were lucky. Even if there were an existing image processing library in Python, I figured the library would be complicated and take significant time to understand. I discovered a Python library that did graphics manipulation, and to my surprise, resizing GIFs was as simple as you can imagine it could be. You create an object, call reformat, pass in some arguments, and you're done. In C++, and even in Java, the ease of understanding a library is not really part of the culture. In Python it really is. Instead of taking a half a day, which was my best hope, after a half an hour, I couldn't think of any more features to add to my program. And I was just stunned. I thought, oh, that's what people mean when they talk about Python's incredible productivity.

Bill Venners: My friend Matt Gerrans, who has used Python quite a bit, tells me that when he has to do something new with a Python library, he will often guess how to do the task instead of look it up, and his guess is usually right.

Bruce Eckel: Yes. That's exactly what I mean. If I just take a guess at the way something in Python is supposed to work, most of the time my guess is right. Of course, I have enough of a grasp of Python now that I don't necessarily guess at it. But there's something marvelous about that, some kind of "quality without a name" there.

Python Lets Me Focus on Concepts

Bill Venners: Your number one reason for loving Python, according to your keynote, was "Python lets me focus on concepts."

Bruce Eckel: With Python, the code gets out of my way, so I can get to the problem am I actually trying to solve, very soon. With other languages I've used, it's very easy to get bogged down in thinking, "What do I need to do first. OK, open this file and read all its lines. How do I do that?"

Bill Venners: So the tool you are using to build something, Python, stays out of your way such that you can just focus on the thing you're building.

Bruce Eckel: Yes, and you can very quickly put these structures together. For example, if you have an object-oriented design, you can quite quickly mock it up in Python. You could type the Python code in almost as easily as a pseudo-code representation, but you would have something that would execute so you could test the validity of your structures. That's why they often call Python "executable pseudo-code." To test your design, you could go ahead and create your classes in Python and make sure they fit together. And then if you want to write the program in some other language you could.

Bill Venners: It's very hard to think of everything up front before you start coding. When you do a design, you think of some things, perhaps most things. But when you go to implement it, you may learn all kinds of things that change the design. Getting to a good design usually requires an iterative process. The design improves over time and eventually achieves some kind of stasis that you release. It seems like the quicker you can get through that process, the better.

Bruce Eckel: Yes. You get your program as close to possible to what you think it should be, and then all the realities appear. The sooner you can do that, the sooner you can start fixing those things.

Bill Venners: In Programming Python, author Mark Lutz writes:

Python makes it incredibly easy to throw together a bad design quickly. It's a genuine problem. Because developing programs in Python is so simple and fast compared to traditional languages, it's easy to get wrapped up in the act of programming itself, and pay less attention to the problem you are really trying to solve.

In other words, because Python let's you create working programs so quickly, psychologically it tends to seduce you away from planning or designing. You don't aim with design. You just shoot with code. And you may end up with code that is not very well thought out. Have you ever experienced that?

Bruce Eckel: I've heard that approach referred to as: "Ready, fire, aim." You shoot first and see where the bullets go. Then you know where to aim. I think Python allows me to try something out, and then I can refactor it as I understand the design better. You might say Python produces more emergent designs, and therefore sometimes better ones.

On the other hand, there are a fair number of programs I have written that I have just gotten working enough to solve my problem and then stopped, even though it wasn't the most elegant way that I could do it. And I think those are OK too. If I ever need modify those again, then I will at that time be encouraged to refactor the design. At that time I'll know the sorts of things am I changing, so I can focus my refactoring on how I can make those changes easier.

Bill Venners: You can always refactor later if you need to.

Bruce Eckel: Exactly. You can refactor on demand. If I'm using and changing a program a lot, and I really want to be able to understand it better so I can continue to change it, then I'm more compelled to say it really needs to be a good design. If you think about it, should you spend that kind of effort on every program that you implement? Because some of them are just one shot deals that solve a problem. You don't really need to change it once you get it working. Of course ideally while you're writing it you're going to apply your normal practices to it, but why should you spend extra time working out this super good design if it's just a one shot program.

Python and the Tipping Point

Bill Venners: You talked about Python and the tipping point.

Bruce Eckel: The "Tipping Point" is a book about a cascading phenomenon. Usually it's referred to in the context of people and fads. If enough people see a thing, or the thing itself is desirable enough, all of a sudden everyone is doing or wearing that thing. One of the examples that they gave was Hush Puppies shoes. A good example of this in the computer world is email.

I used to have a typewriter and would write letters to people, but there weren't that many people that I would write letters to. Of course it would take a few days for them to get the letter and then write a letter back to me. I might have been carrying on a conversation with a few people at any one time. If you think about it, there's only so much you can do. And the effort that you're willing to put into it is limited.

Then all of a sudden email came along. Suddenly you could be carrying on conversations with tens or maybe hundreds of people. The conversations might start and stop over long periods of time, but you are able to maintain them. That was an order of magnitude change. All of a sudden everyone was communicating to each other via email.

In programming, my experience was that I would think, "Gee, wouldn't it be great to automate this or that," but for me to write a C++ or Java program to do it would take way too much time. As an example, for Thinking in C++ I set up a system that would allow me to automatically extract the code from the book and build a hierarchy of make files. I could go in and type make and it would compile everything, so I could verify that all the code would compile. It took me ten days to write that program in C++. It was a lot of effort and thinking, and I didn't have regular expressions so I had to parse things by hand. In Python, it took me a half a day. I did already understand the problem, but I also added more features when I redid it in Python.

With Python, all of a sudden I can create a pretty powerful tool in half a day, and lots of other tools in even less time. Rather than a Herculean effort to create something, it comes down to something that is fairly easy. With Python and some sort of build system, such as ant or make files, I can automate everything. And I've found that to be incredibly powerful. I often use make with a lot of Python programs. For example, the CD-ROMs I sell are all generated with a single make command. And Python is doing all kinds of stuff, controlling PowerPoint and Word and other things. Once I get that system set up and get the bugs out, I don't have to think about it anymore. I know I can type make and make it happen. And I find that incredibly powerful.

Productivity versus Performance

Bill Venners: You ended your keynote discussing by the future impact of Python. How do you feel the tradeoff between programmer productivity and program performance will evolve into the future. In the past when we had only a tiny amount of memory for our code and data, and expensive machines, performance was critically important. Over time the machines have become more powerful and cheaper, but a programmer's time is still relatively expensive. What is the tradeoff right now between productivity and performance, and where is it heading into the future?

Bruce Eckel: People change slowly, so I think there's still a lot of holding onto old ideas. Admittedly we've been bitten a bunch of times by people promising code reuse and lots of other holy grails. It is understandable that people are going to be a bit conservative about trying to change to new things, because they've had a bunch of things thrown at them in the past.

Bill Venners: Things that didn't work out?

Bruce Eckel: Or things that worked out OK, but had their own issues. I believe it was definitely worth moving from C to C++, and from C++ to Java. So there was progress there. For something as advanced as Python is over those languages -- and as different -- there will be some hesitation. However, it seems that in all these cases economics wins out.

When you say we can have one Python programmer that's as productive as ten Java programmers, and that's not taking into account the communication issues of ten programmers, at some point somebody is going to look at that and say, "Wow. I can make a lot of money. I have a lot of leverage over my competition. I can get my product to market quicker. Gee, there are all these things that produce very significant financial differences. Can I afford not to look at this?"
Next Week

Come back Monday, July 28 for Part V of a conversation with Elliotte Rusty Harold. I am now staggering the publication of several interviews at once, to give the reader variety. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Talk Back!

Have an opinion about type checking, finding errors, or techie versus marketing control of technologies? Discuss this article in the News & Ideas Forum topic, Python and the Tipping Point.
Resources

Bruce Eckel's Mindview, Inc.:
http://www.mindview.net/

Bruce Eckel's essay on checked exceptions: Does Java Need Checked Exceptions?:
http://www.mindview.net/Etc/Discussions/CheckedExceptions

Bruce Eckel's Public and In-House Seminars:
http://mindview.net/Seminars

Bruce Eckel's Weblog:
http://www.mindview.net/WebLog

Python.org, the Python Language Website:
http://www.python.org/

Introductory Material on Python:
http://www.python.org/doc/Intros.html

Python Tutorial:
http://www.python.org/doc/current/tut/tut.html

Python FAQ Wizard:
http://www.python.org/cgi-bin/faqw.py

Programming Python, by Mark Lutz, is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0596000855/