O''''Reilly Network For Information About''''s Book part 17 ppt

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

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 ultimate successor.
5.4.2. Code Blocks and Continuations
The Java open source community now uses anonymous inner classes with greater
and greater regularity. When you need lightweight callback-style functionality, in
Java the best way is the anonymous inner class. Here's an example of JDBC-style
access in Spring, with the anonymous inner class:
JdbcTemplate template = new JdbcTemplate(dataSource);
final List names = new LinkedList( );
template.query("SELECT USER.NAME FROM USER", new
RowCallbackHandler( ) {
public void processRow(ResultSet rs) throws SQLException {
names.add(rs.getString(1));
}
}
);
Here's a code block in Ruby:

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,

like two Titanic passengers arguing over which deck is prettier as the ship sinks
around them. James Duncan Davidson said it best: "Friends don't let friends
Swing." User interface development demands more than Java has to give. For most
application developers, the framework should do much more for you.
5.4.5. Dynamic Class Model
The Java successor should be much more dynamic, and reflective. Java's reflection
API is particularly hostile because it must deal with primitives , arrays, and classes.
Let's look at a Java example of reflection. Here's a simple XML emitter provided
by Stuart Dabbs Halloway, courtesy of DevelopMentor:
public static void doObject(Object obj) throws Exception {
Class cls = obj.getClass( );
emitXMLHeader(cls);
Field[ ] fields = cls.getDeclaredFields( );
for (int i=0; i < fields.length; i++) {
Field field = fields[i];
field.setAccessible(true);
Object subObj = field.get(obj);
if (!Modifier.isStatic(field.getModifiers( ))) {
if ((field.getType( ).isPrimitive( )) ||
((field.getType( ).getNamxe( ) = = "java.lang.String"))) {
emitXML(field.getName( ), subObj);
} else {
doObject(subObj);
}
}
}
emitXMLFooter(cls);
}
I've omitted the code to actually emit the XML, but you get the picture. Look
carefully at the lines in bold. You had to deal with primitives a little differently, but

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:

irb(main):003:0> i.methods.each {|m| puts m}
So, Ruby is very reflective. We've done the Java example (minus the lines in bold)
in a single line of code. You can similarly find the instanc
e variables, super classes,
and so on. That's only the beginning of the power at your fingertips, though. You
can also change classes, at runtime, on the fly. You can change a method on an
object and leave the class untouched. Also, interceptors are child's play. You can
use this metaprogramming to do some amazing things. The Ruby on Rails
framework, featured in Chapter 7, shows an excellent example of what you can do.

I should point out that the primitives problem goes far beyond reflection. Look at
the API for java.util.Array. You've got to treat arrays as their own kind of type.
Java 1.5 makes matters worse by introducing generics. You run across similar
problems whenever you need to deal with things generically, whether you're
comparing, cloning, reflecting, or describing an object. It's a major problem that's
encountered equally by people who use and build frameworks that deal with all
types of user-defined objects. As we seek to find more ways to use objects
transparently, the problem will only get worse.
5.4.6. Sound Foundations
I'm working on pure intuition here, but I do think that Java's successor will
probably be object-oriented, and will be theoretically purer than Java. A purely
object-
oriented language makes things so much easier, especially when you start to
consider metaprogramming, simplicity, learning curves, and increasing processing
power. With Java's increasing emphasis on transparency, a cleaner approach will
simplify many types of frameworks:
 Transparent persistence frameworks need only deal with objects and
collections.
 XML binding frameworks would have a cleaner API, and a much cleaner
implementation.

 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

continuations.