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.'"

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?

[sporty]

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.

To each, their own language. I'm not saying python isn't a good language for prototyping, nor am I saying developing in java is either. Whatever language you can bring up a prototype faster, the better.

Flash anyone? :)

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.

I dunno about that. There are lots of tools to speed you up in java just as there are lots of tools in other languages (I can't speak for python) that make it more.. enterprise level.

As I say, to each their own. I do a lot of stuff pretty quickly in java. But mind, you, it's right tool for the right nail, so no, I don't do EVERYTHING in java.. just lots.

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.

Not necessarily true

[Felipe Hoffa]

Not necessarily true.

If you start building your prototype with solid testing [junit.org] and you apply effective refactoring [refactoring.com] your little prototype can grow into a solid and clean system.

Java has great tools for these jobs (junit and eclipse), but you can find similar tools for almost every other language. Give them a try.

Fh

Re: Not necessarily true

[sporty]

True, you can get the code that is used to be non-buggy, but there's a big problem... when you have unused code, "fixme"'s and irrelevant "stuff" in your finished product.

unit is a tool for making sure your code works from the ground up, and easy regression testing of your base, and to some extent, non-base code. Refactoring is only good once you have enough code, where you wish to change design. Both are invaluable regardless if you prototype or not.

There is one key thing, one key advantage to prototyping in the destination language of your product. You can literally steal code from your prototype and inject into your finished product. Nothing is wrong with maintaining your two codebases, as your prototype eventually can be thrown away with little cost. After all, you did develop your prototype seperately. While evolutionary design may work well for the diliegent of keeping their code clean, it can lead to irresponsible artifacts being left behind.

Granted, each has their place. For small projects, nothing is wrong with evolutionary design. For some big projects too. You just have to be very careful.

Re: Not necessarily true

[Felipe Hoffa]

Our philosophy at Elcod goes like 'if that piece of code is not doing anything useful, just wipe it out'. A versioning system (CVS for us) should take care of cases where you don't want to delete something because there is a remote probability that you may use it later.

Anyway, I'm surprised every time I see a supposedly mature software development shop that doesn't use something similar to CVS. And I've seen more than a few, in fact, most of them around here.

Fh

Re:So?

[ChadN]

One can prototype in Python, then have that code running in Java (using Jython), if you choose to migrate over to Java after the prototyping stage. So code reuse is doable.

Re:So?

[sporty]

There's a problem with that if you keep your prototype and production code the same if you are not using evolutionary design.

Re:So?

[ChadN]

I'm saying you can rewrite parts, or slowly rewrite all of the code, in Java, while still using the non-rewritten Python parts.

You can even continue to extend the design in Python, while rewriting parts in Java (perhaps for speed, perhaps to make use of Java libraries, etc.)

Re:So?

[sporty]

Yeah.. I'm not a fan of evolutionary design. It bites you back in the end if you are either too lazy to rewrite, too busy, or things work (don't fix it).

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?

Re: Evolution of Java

[bunratty]

Funny, I thought the Java Community Process [jcp.org] and the Bug Parade [sun.com] were step 2! As a result of feedback, Java has added nested classes, strictfp, generics, enums, foreach, reference objects, tons of library classes, as well as fixed thousands of bugs.

Re: Evolution of Java

[ubiquitin]

Apparently I was wrong, my friend at Sun tells me it was really only six bearded gurus, not ten.

Re:marketing your own language 101

[josephgrossberg]

Well there is a key difference between Java and Perl/PHP/Python.

Java is created, backed, owned and promoted by a profit-seeking company, Sun.

That could make all the difference in the world.

C and Assembly

[Koos Baster]

True. The same holds for C and assembly: Development in a "higher level language" is faster but may lead to less efficient code compared to a "lower level language" on an elementary level. Allegedly, holding on to assembly is what (almost) caused WordPerfect's death, while Microsoft's usage of C definitely gave them a head start with the development of new features in Word.

(Concerning C/ass I'm not sure about robustness. With Python/Java this issue is more evident, since robustness was one of Java's design goals.)

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.

Re:Java Comment Out of Context

[sohp]

There's no such thing as "evolutionary prototyping", that's an oxymoron. Yes, you can (and should) do evolutionary, incremental development, but if you think you can take a prototype and turn it into a final implementation with a few iterations, then you will get burned. Netscape fka Mosiac is an excellent example of what happens you attempt to slipstream your prototype code into the final version.

The only activity that is can be called prototyping is exploration, where you knock out something to explore a particular problem space, and use what you learned to go by and build your production version.

But don't take my word for it, examine the pre-Gecko Netscape source.

Re:Java Comment Out of Context

[Anonymous Coward]

Me, I'd just write a decently architected Common Lisp app, and then add some type declarations to make it a decently architected and high-speed Common Lisp app...

Re:Java Comment Out of Context

[runswithd6s]

Better yet. Replace pieces of the app with C/C++ modules that can be accessed from within python. Use C/C++ only as a faster-implementation of a module.

'Programming at Python Speed' ?

[MonTemplar]

Bad choice of words, surely, given that pythons are large constrictor snakes, not noted for their swiftness... :)

Re:'Programming at Python Speed' ?

[bwt]

A python's buisness plan
1) Give away free "massages" to rodents
2) ????
3) Profit!

Seriously, if you've ever seen a python strike a mouse or rabbit, they move with great swiftness.

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]

Have done it, is nice.

[Anonymous Coward]

While working on a C++ project for BeOS, I prototyped it in Python using the Bethon BeAPI bindings. Took me about 2 hours to get the GUI done, tested and ready for C++.

Python is a great prototyping language. Fast, stable, good debugging abilities, etc. But it's also good for other things. Dont market it as a prototyping language! It's not just for that.