5.4. 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.
5.4.1. 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

dbh.select_all("SELECT name, category FROM animal") do |row|
names << row[0]
end
This code example executes the code in bold for each row in the result set, which is
passed into the code block's row variable.
For application programming, code blocks show up frequently. Any time you need
to iterate through a collection, or a result set, or a file, code blocks come into play.
Keeping them simple saves you a tremendous amount of work.
Continuations will also be important. In Chapter 8, you will see how continuations
dramatically improve productivity in web-based programming.
5.4.3. Rapid Feedback Loop
Think of a feedback loop as the time between making a change and seeing the
impact in running code. New application development principles, like test-first
development, work best with a fast feedback loop. Small changes in the feedback
loop can make huge differences in overall productivity, because you do it so many
times every day. With Java, you need to deal with at least a compile step, and you
often add steps for code generation (XDoclet), byte code enhancement (JDO), and
deployment (servlets and EJB). For Java, that means you must wait to see a source
code change realized in executed code. Developers tend to underestimate the
benefits of a small feedback loop, unless they're regularly using a dynamic
language and need to go back to a static language.
Smalltalk, Lisp, Perl, Ruby, and Basic all have rapid feedback loops, and they're
also incredibly productive languages. C, C++, and Java don't. In fact, Java might
not have succeeded if its users had come from a dynamic language supporting a
rapid feedback loop.
5.4.4. User Interface Focus
More and more, I'm seeing experts that need to do significant user interface
development move away from Java. Given the strong server-side focus of the past
six years, that news should not shock any of us. Still, the number of Swing experts
who vehemently defend it, without trying a meaningful alternative, confuses me,

I'm lucky, because for this particular problem, I can treat all primitives the same.
That's usually not the case. I'm really not done, because I also need to deal with
arrays, leading to a whole new level of complexity.
Let's take another example. Here's an example that prints method names in Java:
public static void printMethods(Object obj) throws Exception {
Class cls = obj.getClass( );
Method[ ] methods = cls.getDeclaredMethods( );
for (int i=0; i < methods.length; i++) {
Method method = methods[i];
System.out.println("Method name:" + method.getName( ));
Class parmTypes[ ] = method.getParameterTypes( );
for (int j = 0; j < parmTypes.length; j++) {
System.out.print(" Parameter " + (j+1) + " type:");
System.out.println(parmTypes[j]);
}
}
}
It's not as easy as simply grabbing the method names, because Java uses
overloading, so you need to know the method name and parameter types to
accurately identify a method. I'm going to give a Ruby example next, so if you
want to compare apples to apples, just disregard the lines in bold.
Here's how easy reflection can be in Ruby. First, create an object. What class are
we dealing with?
irb(main):001:0> i=4
=> 4
irb(main):002:0> i.class
=> Fixnum
Return a list of methods supported by a given object:
irb(main):003:0> i.methods
Print a neat list of the methods that Fixnum supports:

 Debugging frameworks like loggers could easily print values of any
parameters.
Consistency is important, too. Languages with consistent naming and consistent
behavior are far easier to learn. In general, the next language should be much more
consistent, and cleaner. The characteristics in Table 5-4 would form a cleaner
foundation for another 10 years of successful growth.
Table 5-4. Important language features that will help propel Java's successor
Rule Description
Dynamic typing Support dynamic typing for better productivity.
Rapid feedback
loop
Minimize the time between making a change and seeing it
execute.
User interface
focus
Provide a productive, rich environment for building user
interfaces.
Dynamic class
model
Improve the ability to discover and change the parts of a class
and runtime.
True OOP
Provide a conceptually pure implementation of OOP with no
primitives and a single root for all objects.
Consistent and
neat
The language should encourage code that's clean and
maintainable.
Continuations
The language should enable important higher abstractions like