The Hybrid Approach
As we learned earlier in this chapter, neither system-programming nor scripting languages are ideal tools for all development tasks. System-programming languages have good runtime performance, but developing certain functionality and being able to modify that functionality later takes time. Scripting languages, on the other hand, are the opposite. Their flexible and dynamic nature makes them an excellent development environment, but at the cost of runtime performance.
So the real question is not whether you should use a certain system-programming or scripting language for all your development tasks, but where and how each approach fits into your project. Considering today's diverse array of programming platforms and the many ways in which you can integrate them, there is no excuse for a programmer to be stuck with only one programming language. Knowing at least two languages could help you have a better perspective of the task at hand and the appropriate tool for that task.
You can find a more illustrative description of this principle in Bill Venners's article, "The Best Tool for the Job":
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.
So if we agree system-programming and scripting languages should be used together for different tasks in project development, two more questions arise. The first, and the most important one, is what tasks are suitable for a certain tool.
The second question concerns what additional characteristics scripting languages should have to fit these development roles.
Let's try to answer these two questions by elaborating on the most common roles (and characteristics) scripting languages had in the past. This will give us a clear vision of how we can apply them to the development challenges in Java projects today, which is the topic of later chapters.
A Case for Scripting
To end our discussion of this topic, I quote John K. Ousterhout, the creator of the Tcl scripting language. In one of his articles, he wrote the following words:
In deciding whether to use a scripting language or a system programming language for a particular task, consider the following questions:
Is the application's main task to connect together pre-existing components?
Will the application manipulate a variety of different kinds of things?
Does the application include a graphical user interface?
Does the application do a lot of string manipulation?
Will the application's functions evolve rapidly over time?
Does the application need to be extensible?
"Yes" answers to these questions suggest that a scripting language will work well for the application. On the other hand, "yes" answers to the following questions suggest that an application is better suited to a system programming language:
Does the application implement complex algorithms or data structures?
Does the application manipulate large datasets (e.g., all the pixels in an image) so that execution speed is critical?
Are the application's functions well-defined and changing slowly?
You could translate Ousterhout's comments as follows: Dynamic languages are well suited for implementing application parts not defined clearly at the time of development, for wiring (gluing) existing components in a loosely coupled manner, and for implementing all those parts that have to be flexible and changeable over time. System languages, on the other hand, are a good fit for implementing complex algorithms and data structures, and for all those components that are well defined and probably won't be modified extensively in the future.
In this chapter, I explained what scripting languages are and discussed some basic features found in such environments. After that, I compared those features to system-programming languages in some key development areas. Next, I expressed the need for software developers to master at least one representative of both system-programming and scripting languages. And finally, I briefly described suitable tasks for both of these approaches.
Before we proceed to particular technologies that enable usage of scripting languages in Java applications, we focus in more detail on the traditional roles of scripting languages. This is the topic of Chapter 2, and it helps us to better understand scripting and how it can be useful in the overall system infrastructure.
Copyright (c) 2007 Pearson Education. All rights reserved.
Learn more about this topic
- Learn what makes a scripting language like Ruby shine and why Groovy's suddenly so groovy, in "Introduction to scripting in Java, Part 1" -- the first half of a two-part excerpt from the forthcoming Scripting in Java: Languages, Frameworks, and Patterns ( Dejan Bosanac, Addison Wesley Professional, August 2007).
- "Build your own scripting language for Java " (Chaur Wu, JavaWorld.com, April 2006) introduces JSR 223, Scripting for the Java Platform and shows you how to use it to integrate a roll-your-own scripting language into the Java platform.
- "Choosing a Java scripting language: Round two" (David Kearns, JavaWorld.com, March 2005) compares the performance of a wide variety of scripting languages compatible with the (pre JSR 223) Java platform, including Jacl, Jython, Rhino, BeanShell, Groovy, JudoScript, JRuby, and Pnuts.
- "Ruby for the Java world" (Joshua Fox, JavaWorld.com, July 2006) explores the benefits of incorporating scripting into your Java development practice and explains why Ruby (or JRuby) is a good choice for Java developers.
- "Dynamic Languages -- ready for the next challenges, by design" (David Ascher, PhD, ActiveState, July 2004) digs deeper into the pros and cons of (specifically) dynamically typed scripting languages.
- Once you understand what differentiates a dynamically typed language from a statically typed one, you're ready to explore the pros and cons of strong versus weak typing." Start with this interview between Bill Venners and Guido van Rossum.
- According to Sun, Javadoc is "a tool for generating API documentation in HTML format from doc comments in source code."
- In "Use the best tool for the job" (Artima Developer, March 2003) , Bill Venners makes the case for combining scripting and a systems language.
- "Scripting: Higher Level Programming for the 21st Century" (John K. Ousterhout , Tcl Developer Xchange, 1998) suggests a checklist for deciding when some scripting glue is a better alternative to your programming language of choice.
- There's more to learn more about enterprise Java development. Check out the Java Enterprise Edition Research Center.
- Get previews of upcoming articles -- sign up for JavaWorld's free Enterprise Java newsletter.