access to the massive Java library. The Groovy language is a similar alternative but with dynamic typing.
Alas, it's been twelve years since Java made its debut, and its popularity seems to have peaked as it is finding its niche mainly in enterprise applications. Just today I found the following in an InfoWorld article entitled, "Java is Becoming the New COBOL":
"Java, the oldest new programming language around, is falling out of favor with developers. When it comes to developing the increasingly common rich Internet applications, Java is losing ground to Ruby on Rails, PHP, AJAX and other cool new languages ... Now that Java is no longer the unchallenged champ for Internet-delivered apps, it makes sense for companies to find programmers who are skilled in the new languages. If you're a Java developer, now's the time to invest in new skills." 
In recent Code Craft articles, I praised the relatively new D programming language. D combines the speed and power of C++ with desirable features of many other programming languages, such as Java, C#, Eiffel, and functional programming languages. D is high-level, readable yet concise, multi-paradigm, and efficient. In this article and the next I'll conclude (for now) my D evangelizing by exploring a few of its more noteworthy features.
Foremost for me is the fact that D is strongly typed, compiles to native code, and yet is garbage collected. Currently this is a singular achievement in the programming world. But there is much more about D to recommend.
Code Consistency with Scope Guards
Unless carefully planned for, runtime errors can easily place a program in an inconsistent state. Resource management is a typical example. Suppose you have a situation similar to the function in listing 1.
A Java-like solution uses a finally block similar to the D program in listing 2.
A C++-style approach encapsulates resource management into an object's constructor and destructor. This is the well-known Resource Acquisition Is Initialization (RAII) idiom, shown in listing 3.
This approach makes f's code concise, but it also requires an auxiliary class.
D supports RAII, but it also lets you explicitly supply specific cleanup code for when execution exits a scope, as shown in listing 4.
The scope statement, called a scope guard , activates a code block that may or may not run when a scope is exited. Figure 1 lists the three scope-guard options.
The utility of the scope statement becomes more obvious with multi-step resource acquisition requiring rollback semantics in the case of failure. Consider the three-part transaction in listing 5.
In this case, we want all three operations to succeed or fail together. RAII alone will not solve this, and the try-finally approach is not pretty--witness listing 6.
Things only get worse with more pieces in the transaction. Not so with D. Listing 7 shows how easily you can back out of complicated transactions with D's scope statement.
When execution leaves a scope, all scope-guard blocks that have executed are visited in last-in-first-out order, so transactions roll back gracefully, and thirteen lines of code become six. If risky_op2() is the first to fail, only undo_risky_op1() executes as the execution propagates out of g. Likewise, if only risky_op3()fails, then undo_risky_op2() executes, followed by undo_risky_op1().
In Part 2, I'll show how programming with nested functions and delegates can be more concise and powerful than classes and objects.
What have been your favorite languages over the years? What is your opinion of D's scope statement?
Join the conversation below or start a new one in the Member