Bring It On

We haven’t even started adopting .NET 3.0 but Microsoft is at work and plans to ship the next Visual Studio and the .NET platform (most likely to be called 3.5) by the end of this year!*

The most significant addition to the languages this time is LINQ. It is a very cool technology that mixes concepts from my two favorite paradigms – object oriented and functional.

The syntax looks a lot like SQL and will be used a lot in this context but LINQ is not just for the data stored in the database, it is for any structured data.

One of the features introduced with LINQ is the var keyword which helps with declarations of complicated, nested generic types. If you use var, you don’t have to spell the type of the left hand side of the assignment, which is a great help (an example will follow shortly).

Some seem to think that this reduces type safety somehow. This is not true – var is just a syntactic sugar, it does not change the semantics of the language in any way. The example should make things clearer (tested with Orcas March 2007 CTP):

namespace LinqPlayground
{
  class Data
  {
    private String _name;

    public string Name
    {
      get { return _name; }
      set { _name = value; }
    }
    private int _id;

    public int Id
    {
      get { return _id; }
      set { _id = value; }
    }

  }

  class Program
  {
    static void Main(string[] args)
    {
      List<data> data = new List<data> { new Data() { Name = "John", Id = 1 },
                    new Data() { Name = "Steven", Id = 2 },
                    new Data() { Name= "Scott", Id = 3}};
      var dt = from d in data
               where d.Name == "John"
               select d.Id;
      foreach (int i in dt)
        Console.WriteLine("Id is {0}", i);
    }
  }
}

There is a “dumb” class Data that keeps some simple info about a person like name and id. I stuff 3 objects in a list, then select only the persons named “John”. It does look a lot like SQL, but it really isn’t (I won’t go into details in this post).

The interesting part is the emphasized line – note how I’m not specifying the type of the result of the query “from d in data…”. That’s because compiler can infer it for me, but in compile time, not in runtime.

I could have also written this line like this:

IEnumerable<int> dt = from d in data
               where d.Name == "John"
               select d.Id;

but not like this

IEnumerable<string> dt = from d in data
               where d.Name == "John"
               select d.Id;

as this gives you the compile time error: CS0266: Cannot implicitly convert type 'System.Collections.Generic.IEnumerable<int>' to 'System.Collections.Generic.IEnumerable<string>'. An explicit conversion exists (are you missing a cast?)

Don’t treat the var keyword as a hack – it simply helps you type (pun intended) less  but the types of the variables are still there.

*The release date of the (tentative name) Visual Studio 2007 is only a rumour at this point, I don’t have any inside info whatsoever.

I remember when during this winter holiday season I tried to explain to a friend of mine how weird functional languages are… I used Haskell as an example of a functional language since it is one of the more pure functional languages out there. The first thing I mentioned is that the language does not allow for side effects. Differently put, it means that the constructs you are used to seeing like this

int i = 0;
i = 3 * i;

are not possible in Haskell. He was completely confused – how can one get anything done in a language like this??

Turns out it’s not that difficult, but you do have to change the way you think significantly. The immutability of variables is one of the primary reasons why many developers don’t like XSLT – it just does not fit the way they’re used to think.

Once you get past that point and assuming you are not afraid of recursion (there’s a lot of recursion going on, even if in the shape of pattern matching) you’ll be fine.

Until just a few years ago, besides from bragging rights (knowing yet another computer language), it did not get you much knowing a functional language – it’s not like recruiters are asking for functional language developers in droves. However, the situation will have to change because of something I wrote recently about (multi-core processors): in order to get more performance for your app, you will have to develop for multiple threads.

Just this one feature – immutability of variables – makes multi-thread programming a lot easier with functional languages. I am not saying that all of the sudden you’ll start developing desktop applications in Haskell, but you might end up developing modules in F# if your primary development is .NET based.

Prepare for the inevitable and start learning a functional language today.