Put Both a Scripting and Systems Language in Your Toolbox

Occasionally, I meet developers who feel that statically typed languages such as Java interfere with their work more than they help. These developers feel they have greater productivity with a runtime-typed language, such as Python, and that they achieve the same level of robustness in the end product. In an interview in May 2001, I asked Java creator James Gosling about these attitudes:

There's a folk theorem out there that systems with very loose typing are very easy to build prototypes with. That may be true. But the leap from a prototype built that way to a real industrial-strength system is pretty vast. [ 1]

Although Artima.com primarily serves Java developers, I wanted to further investigate these anecdotes about runtime-typed languages. For that purpose, I interviewed Python creator Guido van Rossum [2], who responded to Gosling's comments during our conversation:

That attitude sounds like the classic thing I've always heard from strong-typing proponents. The one thing that troubles me is that all the focus is on the strong typing, as if once your program is type correct, it has no bugs left. Strong typing catches many bugs, but it also makes you focus too much on getting the types right and not enough on getting the rest of the program correct. [ 3]

Here's how I would summarize this argument: Python tries hard to get out of your way while you're coding, so you can quickly complete the functionality and start testing the program. Java, by contrast, actually tries to slow you down a bit while you're coding—for your own good—so that when you reach the system-testing phase, you already have a more robust system. Python enthusiasts believe they can achieve sufficient robustness through testing, and that they have more time to test because they finish the functionality so much sooner. Java enthusiasts feel that strict compile-time checking will ultimately yield a more robust system, despite taking longer to reach the testing phase.

Commentary from InfoWorld

A few weeks ago, InfoWorld columnist Jon Udell called shipping a Visual Basic prototype rather than rewriting it in C++ a "brilliant strategy" in his article, "Shipping the Prototype" [4]. To support this statement, Udell included several quotes from "Programming at Python Speed" [5], Part III of the previously mentioned Van Rossum interview. Udell concluded his article with:

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.

Last week, in his article, "Tools for the Short Hike" [6], InfoWorld CTO Chad Dickerson wrote:

Spurred by Jon Udell's recent online column and some very real technology projects, I have been thinking a lot about "scripting" versus "programming." Although it has often been subtle, there is a level of quiet discomfort between the "scripting" versus "programming" factions in some corporate development environments in which I have participated. In some instances, executive-level technology management has held scripting languages in disdain as not being "real" languages for day-to-day problem solving, which has discouraged highly talented scripters on staff from practicing their craft. In such an environment, scripters are relegated to the lower ranks—they haven't yet learned "real" programming skills. The scripting folks need mentoring and lots of training in C++ and Java from the "real" developers to take their abilities to the next level. In the worst of these cases, the use of scripting languages is more or less banned.

If you put the world's most talented Java developer and the world's best Perl programmer in a room and gave them an unstructured textual document to parse, I would put my money on the Perl programmer to finish first. When you're going on a one-mile hike, you shouldn't weigh yourself down with a full set of silverware, a saw, scissors, and an inflatable boat just in case you run into a raging river. You take a light backpack, a bottle of water, and a Swiss Army knife. That's the mentality behind scripting—when going on a one-mile programming hike, the tools for climbing Everest will only weigh you down. I agree with Jon when he says, "I'm still hoping we'll promote scripting languages to the first-class status they deserve."

The Benefits of Being Multilingual

Dickerson describes a corporate world in which scripters congregate in one cluster of cubicles and systems programmers in another, while each group considers the other to be unenlightened. I too have noticed that programmers tend to specialize, but not just in one kind of language, scripting or systems. Many programmers specialize in one language, period.

Learning a programming language takes time and effort. I understand why many developers would want to learn one language well, and market themselves as that kind of programmer. At one point during our interview, for example, Van Rossum asked me, "You're a Java programmer?" I answered, "Yes." Java is, in fact, the main programming language I have used for the past seven years.

Nevertheless, Java is not the only software tool I use in my work. Behind the scenes at Artima.com, for example, I use HTML, XML, UNIX shell, UNIX commands, make, vi, IntelliJ IDEA, Ant, CVS, Linux, Mac OS X, Tomcat, Microsoft Word, Adobe Photoshop, PostgreSQL, and many other tools in addition to Java—including Python. I actually use Python often in my work, but for different kinds of tasks than I use Java.

Primarily, I use Java to build things. I use Python to do things.

I've found that the choice between using a statically or runtime-typed language has a lot to do with the developer's personality. I've met people who feel compile-time errors slow them down, and others who consider the compiler a friend that helps them find errors sooner. When I need to build a system, I feel more comfortable with the static typing of Java. But when I simply have a small job to do—for example, to read in two text files, process them, and generate a third text file—I prefer Python's development speed and economy of syntax. Although I use Python quite often, I have never actually written a Python program that resided in more than one file. To use Dickerson's analogy, I use Python for short hikes.

To me, attempting to use one language for every programming task is like attempting to use one tool for every carpentry task. You may really like screwdrivers, and your screwdriver may work great for a job like inserting screws into wood. But what if you're handed a nail? You could conceivably use the butt of the screwdriver's handle and pound that nail into the wood. The trouble is, a) you are likely to put an eye out, and b) you won't be as productive pounding in that nail with a screwdriver as you would with a hammer.

Because learning a new programming language requires so much time and effort, most programmers find it impractical to learn many languages well. But I think most programmers could learn two languages well. If you program primarily in a systems language, find a scripting language that suits you and learn it well enough to use it regularly. I have found that having both a systems and a scripting language in the toolbox is a powerful combination. You can apply the most appropriate tool to the programming job at hand.

What's Your Opinion?

Have an opinion on the best way to apply scripting and systems languages, the tendency of programmers to specialize, and the level of distrust between different language communities? Discuss this article in the News & Ideas Forum topic, Use the Best Tool for the Job.

Resources

1. James Gosling's comment about strong and weak typing:
http://www.artima.com/intv/gosling319.html

2. Artima.com's six-part interview with Python creator Guido van Rossum:
http://www.artima.com/intv/guido.html

3. Guido van Rossum's response to James Gosling's comment:
http://www.artima.com/intv/strongweak.html

4. Jon Udell's InfoWorld article, "Shipping the Prototype":
http://www.infoworld.com/infoworld/article/03/02/06/06stratdev_1.html

5.The Guido van Rossum interview, "Programming in Python Speed," Part III, which is quoted in Jon Udell's article "Shipping the Prototype":
http://www.artima.com/intv/speed.html

6. Chad Dickerson's InfoWorld article, "Tools for the Short Hike":
http://www.infoworld.com/article/03/02/21/08connection_1.html

John K Ousterhout, the creator of the Tcl scripting language, suggests systems languages are for creating components and scripting languages for glueing components together in "Scripting: Higher Level Programming for the 21st Century":
http://www.tcl.tk/doc/scripting.html

Talk back!

Have an opinion? Readers have already posted 19 comments about this article. Why not add yours?

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.