Anders Hejlsberg Talks about C#, Mentions Dynamic Language Features for C# 4.0
In a must-read October 1, 2008 interview with Computerworld, Anders Hejlsberg talks about the history of C#, the motivations behind some of the language design decisions, and mentions that the C# team is looking at supporting dynamic programming.
This blog is inactive.
New blog: EricWhite.com/blog
Blog TOCFrom the article:
“I think that C# is becoming one of the first widely adopted multi paradigm programming languages out there. With C# you can do object oriented programming, you can do procedural programming, now you can also do functional programming with a bunch of the extensions we’ve added in C# 3.0. We’re looking at C# 4.0 supporting dynamic programming and so we aim to harvest the best from all of these previously distinct language categories and deliver it all in a single language.”
A dynamic type (as implemented in a language such as Ruby or Python) is one where you can at run-time add additional properties, fields, and methods to an existing type. For example, you could have a type that abstracts a record in a table in a database:
class Record
{
private DatabaseTable _table;
public DatabaseTable Table
{
get
{
return _table;
}
}
public string ToString()
{
// convert record to a string
}
public void Add()
{
// add the record
}
}
A dynamic type system allows you to set properties on such a type at runtime, even though those properties were not in the class definition:
Record record = new Record();
record.Name = "John";
record.Title = "President";
record.Phone = "800-555-1212";
In Ruby and Python, you can also add methods to a class dynamically. If you try to access a member or method that isn’t part of the class definition, or hasn’t been added dynamically, then the runtime throws an exception.
Note that I have no information yet about the features that the C# team is thinking of adding to C# 4.0. I’ll be attending the sessions on the future of C# at PDC 2008 to learn more. J
I had the occasion to explore dynamic typing some time ago – I spent a little time learning Python and Ruby. I like Ruby better than Python – I’m just not a fan of having white space be syntactically significant. I might like it better if tabs were disallowed, but even so, I like being able to format my programs exactly the way that I want to, without worrying about the semantic impact of indenting. So if you are going to explore a dynamically typed language, I recommend IronRuby.
First of all, you must realize that you (probably) lose the benefits of Intellisense when moving to a dynamic type system. Intellisense is based on the IDE knowing about types, hence only works with strong typing. I remember that when I was writing a few Ruby programs, I had to redevelop an old skill of typing LongVariableNamesVeryAccurately. Since becoming used to Intellisense, I find that my fingers automatically remember that accessing a particular property or method requires that I type 2 or 3 or 4 initial characters of the member. I program faster using Intellisense, even though member names tend to be longer now than in the past.
The .NET Framework Design Guidelines recommend to not use abbreviations or contractions as part of identifier names, hence names tend to be longer, but it doesn’t matter because we use Intellisense so that we don’t have to type the entire name.
The .NET Framework Design Guidelines were derived from the very excellent book, Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, by Krzysztof Cwalina, Brad Abrams. This well-written book should be required reading for all .NET developers.
Also, dynamic typing comes with a bit of a performance hit. However, these days, performance hits are always weighed against the benefits of programmer productivity.
Personally, for many programming tasks, I prefer strong typing, but there is one area where dynamic typing really can excel – when programming against a database or XML. In these cases, you want to have properties that contain the fields in a record, or the child elements and attributes of an XML element. But in a strongly typed language, this means that you must generate code. You have to generate classes with appropriate members, and this brings all of the associated complications – if the underlying database changes, and you don’t regenerate the classes, then you have a mismatch between the underlying data store and your classes.
But the issues change when using a dynamic type system. It means that your objects are instantiated with the requisite properties populated with the correct data. It eliminates the code generation cycle. But of course, this brings with it the issues of run-time failures.
The performance issue is mitigated when using a dynamic type system against a database. The performance issues associated with database access significantly outweigh the performance hit associated with dynamic types.
I’m eagerly awaiting the C# futures sessions.