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