Beyond Java - Bruce Tate [48]
The catalyst, with economic justification, often takes the form of a killer app .
Once a solution is technically viable, a killer app enables a rapid growth to critical mass. It often solves a chicken and egg problem: you can't build a sufficiently robust language without community, and you can't build a community without a successful language.
The killer app often initiates the hype that's required to escape a niche. With the newly found hype, the language can explode from a small, focused niche to a more generally successful language.
Remember, a language alone is rarely enough. Right now, several interesting technologies could possibly grow into potential killer apps. Smalltalk's continuation servers, Ruby's metaprogramming environments, and PHP's many applications like bulletin boards may serve as potential killer apps. We'll look at some potential killer apps in Chapters 7 and 8.
Table 5-3 lists community-centric roles . Each of them will come into play when it's time to determine the next major language.
Table 5-3. Community-centric roles
Rule
Description
Open source
Have a rich open source community.
Productivity
Be much more productive than Java for the simplest commercial applications.
Catalyst
Have a tremendously popular application or framework that transcends programming languages.
Familiarity
Be easy for Java developers to learn.
Simplicity
Make it easy to solve simple problems.
Language Features
It's strange to be more than halfway through the characteristics of the next great programming language without even talking about the major features of that language. When you look at the history of programming languages, it makes more sense. The features of a language are important characteristics for success, but only rarely are they the most important characteristics. Said another way, market share and mindshare matter more than how you interpret whitespace.
Dynamic Typing
Java purists defend strong, static typing with the fervor of English soccer fans. To be sure, static typing does have its advantages:
Static typing enforces typing rules at compile time, when they are least expensive to fix.
Static interfaces make it easier to enforce a protocol across important boundaries. For example, systems designers may want to force certain types for C interfaces, or certain remote procedure calls.
Static typing catches some types of subtle errors at compile time, like the misspelling of a variable name.
Still, as you learned in Chapter 4, there's a related cost, usually in productivity . Java developers often make the comment that you can pay now or pay later. That's strange, because Smalltalk and Ruby programmers rarely make lasting errors related to incorrect typing. Further, disciplined automated unit tests easily catch most type mismatch problems. You've got to unit test your code whether you want to or not, because no compiler can completely guess your intent.
Most Java developers who tout the benefits of strong, static typing fail also to count the cost. When you're learning or playing with a language, the cost is excessive, because you have to declare everything, including a wrapping class, and learn a whole new level of detail. Here's a "Hello, World" example in Ruby:
puts "Hello, world."
And here's the Java counterpart:
class HelloWorld {
public static void main(String[ ] args) {
System.out.println("Hello World!")
}
}
A Java program requires a rigidly typed class with a Main method. The barrier to exploring in Java is simply much higher. Most of the experts that I interviewed for this book recognized that static typing limits productivity for application development dramatically, though some said they were willing to pay the cost for certain types of code, like systems code and middleware. I think it's fair to assume that for applications development, productivity is important enough to warrant dynamic typing for Java's