Shipping the prototype

Years ago, when the paint was barely dry on Visual Basic 3.0, a developer showed me a CD-ROM-burning application he'd written using that toolkit. The idea was to prototype the UI in Visual Basic, then rewrite in C++ for performance. But in the end, he admitted somewhat sheepishly, "we shipped the prototype." I saw nothing to be ashamed of. It was -- and is -- a brilliant strategy. My only regret is that it hasn't been adopted more widely. Here's Guido van Rossum, Python's inventor, on programmer productivity:

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

"It wouldn't surprise me if the amount of typing Python requires is five times less than Java for a typical piece of code. When you have that much less code, it's so much easier to maintain, and also to change. This is all very informal, but I heard someone say a good programmer can reasonably maintain about 20,000 lines of code. Whether that is 20,000 lines of assembler, C, or some high-level language doesn't matter. It's still 20,000 lines. If your language requires fewer lines to express the same ideas, you can spend more time on stuff that otherwise would go beyond those 20,000 lines."[1]

In that same interview, van Rossum goes on to discuss applications (eShop, Yahoo Mail) that became successful in Python, and then morphed to C++ or Java. During the exploratory early phase of development, he says, it's essential to use a high-level, dynamic, and weakly typed language:

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

I wholeheartedly agree, and here are some follow-up questions to ponder. In a world of distributed services in constant flux, when does exploration stop? Why would you ever want to switch from a codebase that is concise, malleable, and easily maintainable to one that isn't?

Performance and robustness are the reasons usually given for not shipping the prototype. That's ironic when the chosen alternative is Java, because its use in mission-critical deployments is itself an example of shipping the prototype. Recall that in the pre-J2EE era, when what we then called "Java application servers" emerged as a favored platform, native-code Java compilers were considered a fallback option.  The idea was that you'd prototype in Java, and then if JVM performance became a bottleneck you'd compile to native code for deployment. As it turned out, hardly anybody did. The solution was more and faster processors, and more JVMs for load-balancing and failover.

Of course you dare not build the application server itself in a high-level language like Python. Not, that is, unless you're a quiet revolutionary like Zope Corporation's Jim Fulton, architect of the Python-based Zope application server. Several years ago, I used Zope to build a content management system for a client. It has been in continuous and trouble-free daily use ever since. Recently organizations like the U.S. Navy and the AARP have stepped forward to announce similar results on a much larger scale[2].

I am not only saying that you can do what used to be called "systems programming" in what used to be called a "scripting language" -- although you sometimes can. Nor am I merely lauding Python as a spectacular implementation of a first-class scripting language -- although it is one. My point is that languages like Python, but also Perl, Ruby, and JavaScript/JScript/ActionScript/EcmaScript, are strategic in ways that we don't yet fully acknowledge. As I mentioned last time[3], the classic phased life cycle of software development -- design/develop/test/deploy -- is dissolving into a continuous process. Change is the only constant; the services we create and use are always exploratory. Languages that express programmers' intentions in fewer lines of code are a huge productivity win. The deliverable code is easier to understand and maintain -- and so, crucially, is the test infrastructure that supports it.

It was never a priority for Sun to make the JVM script-language friendly. Independent developers took that upon themselves, with the most notable success being the Java-Python hybrid now called Jython. For Microsoft, script-language support was a stated goal of the .Net Common Language Runtime (CLR). Early on, we heard a lot about CLR implementations of Python and Perl. When ActiveState [4] researched the problem, though, it proved harder than first anticipated. The elbow grease that made Jython work as well as it does has not yet been applied to Python.Net and Perl.Net. Nor has Microsoft evangelized the most dynamic member of its family of supported .Net Languages: JScript .Net.

I'm still hoping we'll promote scripting languages to the first-class status they deserve. Computers are getting faster and platforms are getting smarter, but the human brain is on a very different upgrade cycle. We need to keep finding ways to help programmers pack more software behavior into fewer lines of code. Shipping the prototype is not yet practical in many cases, but that's a great goal.

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

2. http://www.zope.com/CaseStudies

3. http://www.infoworld.com/article/03/01/31/05stratdev_1.html

4. Full disclosure: I am a member of ActiveState's Technical Advisory Board