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