In the post you can find the below example that compares Java and Ruby in terms of code readability.

The Java code:

new Date(new Date().getTime() - 20 * 60 * 1000)

The Ruby code:

20.minutes.ago

The article was interesting but what really caught my attention was some comments from C# programmers who showed how, in a few lines of code, you can mimic the Ruby syntax in C# using extension methods.

The new version of C#, shipped with the Orcas release of Visual Studio, has a new feature called extension methods. Extension methods were added to the .Net languages to support LINQ and they provide a way to attach methods to classes without changing their code.

The below code is copied and modified from the comments of Ian Cooper in the aforementioned blog post.

public static class TimeExtensions {
 
  public static TimeSpan Minutes(this int numberOfMinutes) {
    return new TimeSpan(0, numberOfMinutes, 0);
  }
 
  public static DateTime Ago(this TimeSpan numberOfMinutes) {
    return DateTime.Now.Subtract(numberOfMinutes);
  }
}

In the above code we defined a class, called TimeExtensions, which contains two extension methods. Notice the this keyword on the left of the fist parameter (both methods take one parameter in the example code) of the methods. The this keyword tells the C# compiler that a method is an extension method. The parameter annotated with the this keyword is the object on which the extension method is called. If I am correct, the methods are not really added to the classes (you can’t find them via reflection), the compiler at-compile-time translates them into static method calls.

In our example the first method, called Minutes, will be added to the int class (probably via auto-boxing) and the second method, called Ago, will be added to the TimeSpan class.

Now, to use the extension methods that we defined above we have to import them using the using TimeExtensions statement. This is a really good thing since the usage of extension methods is always explicit. You have to import them to use them and if you don’t want to use them you don’t import them.

using System;
using TimeExtensions;
 
public class HelloWorld {
  public static void Main() {
    Console.WriteLine( 20.Minutes().Ago() );
  }
}

20.Minutes().Ago() is pretty close to 20.minutes.ago

For a nice tutorial about C# 3.0 extension methods see: New “Orcas” Language Feature: Extension Methods.

I am programming in Java almost exclusively for the last two years. In this post I will discuss two new features of C# 3.0 that I’d like to see in the next versions of Java.

Below there is a code fragment from the XLinq in action video that demonstrates my two new favorite features (local variable type inference and lambda expressions):

var contacts = doc.Descendants("contact")
	.Where( a => (string)a.Attribute("category") == "home")

The above code fragment will query an XML document (the XDocument object that is assigned to the doc variable) to retrieve all contact elements with the category attribute matching "home".

In the above code we didn’t specify the type of the contacts variable in the variable declaration. Instead we used the new C# 3.0 keyword var. When we use the keyword var in a variable declaration the type of the variable is inferred by the compiler for us and we do not have to specify it. This is called local variable type inference. The type is inferred at compile-time after checking the type of the expression on the right of the assignment.

Please note that the variable contacts has a type and its type remains the same (statically typed). You cannot reassign something that has a different type from the above expression to the contacts variable. This is in contrast with dynamically typed languages like Python and Ruby where you also do not declare the type of variables but the type of the variables is determined at run-time and the type of a variable can change dynamically (you can assign a string to a variable and then assign an integer to the same variable).

Three people have asked for this feature with a RFE to the SUN’s Java bug database. All of the RFEs are in “Closed, will not be fixed” state because people at SUN believe that types in variable declarations provide readability and valuable redundancy.

Below I have included information about the RFEs.

Bug ID: 4879776
Synopsis: Constructor type inference (JSR14 + JSR65 ++)
Submit Date: 17-JUN-2003

Bug ID: 4459053
Synopsis: Type inference for variable declarations
Submit Date: 15-MAY-2001

Bug ID: 6242254
Synopsis: Language support for type inference
Submit Date: 17-MAR-2005

I agree that repetition is good and many times helps readability but now that Java 5 has generics the variable declarations can be very long and noisy.

Consider the below code fragments:

// 1. Non generics with construction
Pair p = new Pair(1, 2);
 
// 2. Generics with construction
Pair<integer , Integer> p = new Pair<integer , Integer>(1, 2);
 
// 3. Generics with type inference and construction
var p = new Pair<integer , Integer>(1, 2);
 
// 4. Generics with method invocation
Pair<integer , Integer> p = o.getPair();
 
// 5. Type inference with method invocation
var p = o.getPair();

Compare (1) with (2). (2) is very long compared to the non-generic version and the repetition is annoying. I believe that type inference in (3) is very clean and easy to read. Now add to this that most Java types have really long names. Breaking simple variable declarations to multiple lines isn’t very easy to read.

Now let us consider (4) and (5). In (4) we do not have repetition of the type information and the declaration is easy to read and understand. In (5) we have type inference and the programmer does not immediately see the type of the variable p. I agree that since the programs are read more times than they are written and if the programmer does not use a modern IDE (like Eclipse, Netbeans or IDEA) this makes the program harder to understand. But if the language supports type inference a programmer is free to use (4) instead of (5) and (3) instead of (2) to get the best of both worlds.

I will also like to add that code like this

HashMap<integer , LinkedList>, Integer>> map =
	new HashMap<integer , LinkedList>, Integer>>();

is acceptable only because we use sophisticated IDEs with code complete (we have to write HashMap<Integer, LinkedList<Integer>> twice). Why the same argument cannot be used to accept the code in example (5)?

My conclusion is that we do not lose in type safety and we improve productivity and code readability with just a minor syntactic change. I wonder why statically typed languages like Java and C# did adopt type inference earlier or from the start like functional languages as SML and Haskell.

The other feature that I like is lambda expressions. Lambda expressions (or if you prefer closures) are the basic building block of functional programming. Lambda expressions can be found in functional programming languages like LISP, Haskell and SML and also in modern scripting languages like PERL, Python, Ruby and Groovy.

Now I might be a little biased because I learned to program in Scheme and SML but I do believe that functional programming provides very elegant solutions to a lot of problems. IMHO the existence of lambda expressions in languages like Ruby and Groovy is one of the reasons why so many Java developers are using them.

Consider the below code where I have implemented the equivalent code with the XLinq example in Java with dom4j. (Dom4j is a great and fast DOM API for XML processing in Java)

Document doc = ...
Document contacts = new Document();
for ( Iterator i = doc.elementIterator("contact"); i.hasNext(); ) {
    Element contact = (Element) i.next();
    if ("home".equals(contact.getAttribute().getValue()))
        contacts.add(contact);
    }

In my humble opinion the C# version is not only more short but more clean and elegant. Martin Fowler recently wrote a post on his blog about how closures (lambda expressions) and collections fit nicely together. I suggest that you read it since it provides a lot of examples (in Ruby) where the functional way of doing things is simpler and more elegant.

There are two RFEs at the SUN’s Java bug database about adding lambda expressions to the Java programming language. Both of the RFE’s are in “In progress, request for enhancement” state so we can vote to bring this feature to Java.

Also Graham Hamilton, Mark Reinhold and Gilad Bracha in their “Evolving the Java Language” talk this year at JavaOne said that they are considering to add closures/method references (lambda expressions) to the next version of Java. (Please note that I wasn’t at JavaOne and I have only seen this in their slides. I am eagerly waiting for the multimedia content of the presentations to become available online).

If you are a Java programmer who things that lambda expressions (closures) could be useful in the Java programming language take five minutes of your time and vote for both of the below RFEs.

Bug ID: 5014235
Synopsis: Closures support instead of annonymous inner classes
Votes: 13
Submit Date: 16-MAR-2004

Bug ID: 4483171
Synopsis: Adding support for delegates and method references
Votes: 8
Submit Date: 23-JUL-2001

BTW Ted Neward has written a very good overview of all the new C# 3.0 features.

Mono is an OSS implmentation of Microsoft’s .Net platform. Nat has created two demos for Monodoc (the Mono documentation browser) and for creating GUIs with Glade and Gtk#.

Beagle is a cool OSS application written in C#. If I am correct, it currently runs on Linux using Gtk# and there is an ongoing effort to port it to Windows. Beagle is a desktop search tool. It indexes your data (doc, pdf, images, html,… files) and let’s you search them efficiently.

I really like the fact that Beagle integrates well with other desktop applications (mail, IM, photo albums,…) and that supports many file types. The coolest feature of Beagle is live incremental indexing of files. It indexes your files as you create them without having to rebuild its indexes. See it here in action.

Beagle is backed by DotLucene the .Net (C#) port of the fabulous Lucene text search engine library.