Guido van Rossum on Programming at Python Speed

Bill Venners writes "In this interview, Python creator Guido van Rossum states: '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.'"

Comments

So?

[sporty]

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.

Whoa there. There's a neat thing with prototyping and keeping your prototype away from your final system, from start to finish. The purpose of prototyping is to get a somewhat usable, testable application without developing it in it's entirety. It may not give you all the real data, and hell, all the functionality may not be accessable from the multiple points you put it, but you get a good feel of what you want.

Now your end product should be clean, well thought out. It should have no design artifacts from your prototype, because after all, your prototype is meant to bring out the good of a project and leave behind the bad. Code and design artifacts from the bad are just bugs to learn from and not to repeat.

If you still disagree, think of your prototype as a rough draft. You read it, you poke at it, you get a feel for it. Then you write the real thing.

As for what languages you use, you'd use a faster to develop in language first, which is robust, and your intended one later. Prototyping in java and moving to python won't be bad since you can develop in either relatively quickly. It's the planning of what you wanna do is a bitch.

Re:So?

[Phouk]

Prototyping in java and moving to python won't be bad since you can develop in either relatively quickly.

I disagree there. Python is much better suited to prototyping than Java, for two reasons:

• As GvR correctly says, there's simply more text to type in Java, to a large part because of the overhead of Java's static typing (aka "keeping the compiler happy"), but also because Python is slightly more high-level than Java.
  
• The Python code will be much more malleable and easy to change around and refactor, for the same reason that you won't have to adapt all your type declarations to keep the compiler happy. On the other hand, all those declarations that make the Java solution harder to change, are the exact same thing that makes it more robust for large programs / team development. You can't have it both ways.
  

Re:So?

[scrytch]

As GvR correctly says, there's simply more text to type in Java, to a large part because of the overhead of Java's static typing (aka "keeping the compiler happy"), but also because Python is slightly more high-level than Java.

Once I discovered Ocaml, I found out that you can have both strong typing at compile time, without having to actually use types (but I can if I want to). I can have polymorphism without inheritance trees (again I can if I want to), and I can have interfaces without interface keywords (and I have pattern matching if I want it). Actually I found this in Haskell, but I just can't wrap my brain around monads ... different story.

Type inference really is the best of both worlds. I just can't go back to the 1960's compiler technology of explicit typing anymore. Sometimes I have to, but I complain all the way.

marketing your own language 101

[ubiquitin]

Step 1: Call it a prototyping language so you get everyone using it but not having great expectations or concerns about liability if it doesn't perform perfectly.

Step 2: Release early. Release often. Fix bugs like it is going out of style and respond to solid feature requests from users. Grow your userbase beyond early adopters. Promote developer adoption by making what they create available in repositories.

Step 3: A few years go by, and you have enough features that you can claim that it is no longer just for prototyping.

See a pattern: Perl did the same thing. PHP is doing it too.

I don't think java ever went through this cycle, though, which makes me suspicious of it. The claim seems to be that ten bearded guys at Sun replaced step 2. Yes, there is more to good technology than grass-roots popularity, but when the grass-roots tools will get the job done, get it done securely, and get it done with high availability, what's the point?

Java Comment Out of Context

[lal]

Read the whole article. A few paragraphs later, Guido details two real-world examples where python was used to create working prototypes for eShop and Yahoo Mail. After a few months of production deployment of those apps, the python code was replaced with C++.

IMO, this is a much better approach: Write a decently architected python (perl/php) app that meets the customer requirements. Then, and only if performance is an issue, replace pieces of the app with C/C++. I don't see where Java enters into the picture.

Re:Java Comment Out of Context

[Phouk]

There's two kinds of prototyping: Evolutionary and exploratory.

In evolutionary prototyping you develop a quick but not so dirty small version of the program (release early and all that), and then keep refactoring it to improve design, and keep tuning it to improve performance, while adding features. Python + Swig + C for performance-critical parts is, as you say, a good combination for that.

In exploratory prototyping, you first quickly hack out one version of your program to learn about the user's real requirements, demo it to investors, find out about the consequences of architectural choices and so on. When you know what you want, and that it's worth the effort/money, you throw away your prototype and start work on an industrial-strength solution. Prototype in Python, final implementation in Java would be a "modern" combination for that.

That's why the Java comment is not out of context.

Shades of Lisp..

[Vector7]

Funny, this is the exact argument LISP programmers have been making for the last fifteen years.. Python has long been accused of progressively stealing more and more of LISP, but given LISP's current commercial success (or lack thereof) I might argue against also immitating its advocates.. ;)

[disclaimer: I am not disparaging either LISP or Python, in fact Common Lisp is my favorite language, I'm simply pointing out that I've heard this argument before]