After having spent several years working primarily with C#, Microsoft program manager Dare Obasanjo decided to explore the world of dynamic languages by learning Python. He then revisited the latest features of C# 3.0 with that dynamic programming experience, realizing that C# 3.0 provides many of the language features that make some developers prefer dynamically-typed languages. Obasanjo summarizes his experience in a recent blog post, Does C# 3.0 Beat Dynamic Languages at their Own Game?:

Shortly after I started using Python regularly as part of the prototyping process for developing new features for RSS Bandit, I started trying out C# 3.0. I quickly learned that a lot of the features I'd considered as language bloat a couple of months ago actually made a lot of sense if you're familiar with the advantages of dynamic and functional programming approaches to the tasks of software development. In addition, C# 3.0 actually fixed one of the problems I'd encountered in my previous experience with a dynamic programming language while in college.

As I started investigating C# 3.0, I discovered that almost all the features I'd fallen in love with in Python which made my life as a developer easier had been integrated into C#. In addition, there was also a feature which is considered to be a killer feature of the Ruby programming language which also made it into C# 3.0...

C# has added features that make it close to being on par with the expressiveness of functional and dynamic programming languages. The only thing missing is dynamic typing (not duck typing), which I’ve come to realize ... has a lot more going for it than lots of folks in the strongly and statically typed world would care to admit...

In his review blog post, Obasanjo notes his own journey to dynamic typing via a stint on Microsoft's XML team:

The first half of my career at Microsoft was spent working on the XML team which was responsible for the core XML processing APIs that are utilized by the majority of Microsoft's product line. One of the things that was so cool about XML was that it enabled data formats to be as strongly structured or semi-structured depending on the needs of the application...

However one problem we repeatedly bumped against is that data formats that can have unknown data types show up in them at runtime bump up against the notion of static typing that is a key aspect of languages in C#...

I came to the realization that some degree of dynamism is desirable especially when dealing with the loosely coupled world of distributed programming on the Web. I eventually decided to ignore my earlier misgivings and start exploring dynamic programming languages. I chose IronPython because I could focus on learning the language while relying on the familiar .NET Framework class library when I wanted to deal with necessary tasks like file I/O or Web requests.

One C# 3.0 feature that Obasanjo especially likes is the language's support for lambda expressions, something both Python and Ruby feature as well:

Creating a short hand syntax where anonymous blocks of code can be treated as function objects is now commonly known as "lambda expressions". Although C# has had functions as first class objects since version 1.0 with delegates and introduced anonymous delegates in C# 2.0, it is in C# 3.0 where the short hand syntax of lambda expressions has found its way into the language.

Next, Obasanjo compares Python's list comprehensions with C# 3.0's language-integrated query:

A common programming task is to iterate over a list of objects and either filter or transform the objects in the list thus creating a new list. Python has list comprehensions as a way of simplifying this common programming task...

Certain recurring programming patterns become more obvious as a programming language evolves, these patterns first become encapsulated by APIs and eventually become part of the programming language’s syntax. This is what happened in the case of the Python’s map() and filter() functions which eventually gave way to list comprehensions...

In C# 3.0, the language designers made the observation that performing SQL-like projection and selection is really the common operation and not just filtering/mapping of lists. This lead to Language Integrated Query (LINQ)...

These are two fundamentally different approaches to tackling the same problem. Where LINQ really shines is when it is combined with custom data sources that have their own query languages such as with LINQ to SQL and LINQ to XML which map the query operations to SQL and XPath queries respectively.

The rest of Obasanjo's post compares tuples with anonymous types, and dynamic typing versus type inferencing. He also focuses on extension methods in Ruby and C# 3.0.

Do you agree with Obasanjo that C# 3.0 provides many of the benefits of dynamic languages in terms of productivity?

ArrayList<Person> l = new ArrayList<Person>();

var l = new ArrayList<Person>();

for( Person p : l )
{
  p.setAge( 42 );
}

foreach( var p in l )
{
  p.Age = 42;
}

  def emps_with_salary_less_than( amt ) 
     @employees.find_all {|emp| emp.salary < amt }
  end

  function empsWithSalaryLessThan( amt : int ) : List<Person> {
    return _employees.findAll( \ emp -> emp.Salary < amt )
  }

>   def emps_with_salary_less_than( amt ) 
>      @employees.find_all {|emp| emp.salary < amt }
>   end
> 

> function empsWithSalaryLessThan( amt : int ) : List<Person> {
> return _employees.findAll( \ emp -> emp.Salary < amt )
>   }
> 

def emps_with_salary_less_than( amt )
    @employees.find_all {|emp| emp.salary < amt }
end

function empsWithSalaryLessThan( amt : int ) : List<Person> {
    return _employees.findAll( \ emp -> emp.Salary < amt )
}

IEnumerable<Person> empsWithSalaryLessThan(int amt) {
    return _employees.Where(emp => emp.Salary < amt);
}

IEnumerable<Person> empsWithSalaryLessThan(int amt) {
    return from e in _employees where Salary < amt select e;
}