Anders Hejlsberg on C# 3.0

spongman writes "Channel9 has a video of Anders Hejlsberg demoing C# 3.0. The new language enhancements include implicitly typed locals, extension methods, strongly-typed lambda expressions, anonymous types, and LINQ - a builtin SQL-like syntax for data access. The spec, samples and a working compiler can be found on MSDN."

Comments

Who is Anders Hejlsberg?

[bogaboga]

For those just like myself who might not know who Anders Hejlsberg is, I post a link http://en.wikipedia.org/wiki/Anders_Hejlsberg that might help you understand who this man is.

I did not know he was very instrumental in developing Pascal, a language I was an expert at one in the mid nineties.

Re:Looks more like Delphi every release

[ergo98]

But then, Bill Gates himself said that the only thing wrong with Delphi was that it wasn't a Microsoft product.

What are you talking about? I used Delphi for years, and then switched to .NET, and while Anders of course brought a lot of Delphi-ism to the .NET Framework and C#, these new C# 3.0 additions are nothing like Delphi, and C# 2.0 is already worlds beyond what Delphi ever achieved. LINQ, and DLINQ, are very exciting improvements in removing the disconnect between the database and the middle/front tier, and given the tremendous importance of that it will be remarkable.

The toughest thing about this sort of technology, though, is that it isn't complete and usable in real projects, so as developers we're uncertain how much time to waste playing with the demos and learning (how many developers must be pissed seeing the hype machine starting over C# 3.0, when they still don't even have the ability to use C# 2.0 in production - e.g. VS.NET 2005 is only at the RC stage). Unless you're a blogger or writer making money writing about how much it makes you wet your pants, there's just no practicality in it.

Why implicitly typed locals?

[Mr2001]

In an implicitly typed local variable declaration, the type of the local variable being declared is inferred from the expression used to initialize the variable. When a local variable declaration specifies var as the type and no type named var is in scope, the declaration is an implicitly typed local variable declaration. For example:
var i = 5;
var s = "Hello";

Can someone explain the point of this? C# is not JavaScript; these aren't true dynamically typed variables, the compiler just assigns a type for you instead of making you do it yourself. I can easily take half a second out of my day to figure out what type a variable should be, and end up with more readable code.

Re:Why implicitly typed locals?

[iGN97]

You type less, obviously.

It also allows you to write pieces of code that are more generic. The LINQ samples have a lot of examples of this.

For example:

foreach (string s in collection) {
      Console.WriteLine(s);
}

means you have to change the type everytime you change the type in the collection.

foreach (var item in collection) {
      Console.WriteLine(item);
}

means that you can use it with any time that implements ToString, which is pretty much any type.

There are numerous other benefits from the type inference, and they become more apparent with lambda expressions, where you can write expressions like "x => x % 2 == 0" instead of writing the equivalent bool-returning delegate with a typed parameter.

Most of the new features of C# 3.0 are quite impressive and more importantly very useful.

Re:Why implicitly typed locals?

[Mr2001]

Having a declared type lets you know how you can use that variable. Can you pass it as a ref parameter to method XYZ that wants a "ref int"? Can you use it to store the result of method ABC, which returns a float?

In a dynamically typed language, the answer is always yes because variables have no fixed type. But in C#, the variables still have fixed types; they're just hidden. You have to look at the declaration "var x = 5" and think "Hmm, I guess that's an int", just like the compiler does. And for declarations like "var y = SomeFunction()", you have to go look up SomeFunction to find out what type it returns before you can know y's type.

It might save you a split second of typing to write "var" instead of a real type name, but 6 months from now when you have to find a bug in that code, it'll cost you just as much time to figure out what type those variables are.

Re:Why implicitly typed locals?

[dotcher]

C# 3.0 also gains anonymous value types. You can do something like:

var c = new {Name = "Fred Bloggs", Age = 12};

Now, what type is c? It's an anonymous struct type, with two members - Name and Age. As it's anonymous, it's obviously not possible to declare it using the standard syntax.

The language is still strongly, statically typed, though - the following would throw a compile-time error:

c.Dept = "CS";

Now, as to why this construct was added to the language in the first place: these anonymous types are useful when using LINQ to query a data source:

var expr = people.Select(p => new {
p.Name, BadCoder = p.Age == 11
});

foreach (var item in expr)
Console.WriteLine("{0} is a {1} coder",
item.Name,
item.BadCoder ? "bad" : "good");

expr and item are both given the appropiate type for the data they contain, with no need to explicity define the types. Most of the benefits of strong static typing are retained with this approach, and there's no need to define a type to store data for every weird query you run against the database.

One benefit that is lost is the ability to share these types across assembly boundaries, which might be an issue in real, three-tier applications. On the other hand, if there's a need to pass data directly from the database to the client application, what's the point of having the middle tier in the first place? So, this might turn out to be a non-issue.

(My examples were taken or adapted from this white paper, which is an overview of the LINQ project, including the new syntax added to C# 3.0.)

Re:Looks more like Delphi every release

[ergo98]

One area of intensive research in IT for years is setting up a portable high-performance disconnect between database and other tiers.

It is high-performance. Watch the demo - at one point Anders sets up a log, and you can see that the LINQ query was transformed into the appropriate, performant T-SQL which is passed to the RDBMS. It isn't doing the standard, shittacular "pull everything back in a terribly unscalable manner and then filter it in the middle tier", but rather appears to be analyzing the whole of the query and communicating it effectively to the source.

Embedded SQL in computer languages has been around for a very long time

It isn't embedded SQL. It's set operations that obviously share commonalities with SQL, but are largely different. Again, have you watched the video or read the spec? DLINQ, by the way, is the ORM system that makes the objectpersistence "transparent" (leaky abstraction, like all ORMs, but still).

Also, I can't believe that MS C# is going to include support for MySQL, Postgresql etc, like Hibernate, NHibernate, JDO etc.

I doubt it'll include support either, out of the box. Instead, like always, they've created a generalized data services layer that any provider can plug into - create a ADO.NET 3.0 data provider for MySQL, and your data service can be the target of LINQ operations.

Re:Looks more like Delphi every release

[bheer]

Er, it might help if you actually read the spec. This isn't 'embedded SQL' in the sense of Pro*C -- the 'queries' are really a bit of (helpful) syntactic sugar over an object-oriented, typesafe set of expressions (you'll see the lambda expressions, new to C#, used heavily here):

from c in customers
where c.City == "London"
select c.Name

turns into

customers.
Where(c => c.City == "London").
Select(c => c.Name)

Of course, if you don't like it you can always pass strings of SQL text to the data layer, or do everything with StoredProcs -- after all, DLINQ helpfully shields you from ADO.NET but nothing stops you from using ADO.NET either directly or through alternate layers like NHibernate.

This should also answer your point about optimised SQL generation ... the programmer does not type SQL into C#, SQL gen is still done in the background.

Also, I can't believe that MS C# is going to include support for MySQL, Postgresql etc, like Hibernate, NHibernate, JDO etc.

They don't have to. Implementing DLINQ is really as simple as implmenting a pattern (which Helsberg called the 'query expression pattern') and adding your own DB-specific code.

Currently Oracle and DB/2 ship libs for ADO.NET, you can be quite sure they'll ship libs for DLINQ. If the MySQL and Postgres communites want DLINQ support badly enough, I'm sure someone will write it.

The Microsoft Trap

[MrSteveSD]

C# is a nice language, but the problem is I just don't trust Microsoft anymore. From a business perspective sticking with Microsoft has proven to be a mistake.

I work for a software house in London and we have a large VB6 application that has been built up over many years. VB6 has effectively been dumped by Microsoft, so our application is slowly rotting away. There is absolutely no way we can rewrite it in C# or VB.Net, we just don't have the resources. I suggested that we at least write all new components in C# and use interop, but that turned out to be a real pain, especially when trying to debug.

So what do we do? Spend a fortune rewriting our product in C# while our competitors (who may be using Java) continue to improve their products. And once we have eventually finished the rewrite, will Microsoft just dump .NET and move on to something else?

I have to wonder. If there had been a number of VB6 vendors, rather than just Microsoft, they could never have dumped VB6. In that situation we would have all just moved over to another vendor.

Is anyone else here in a similar situation?

Re:The Microsoft Trap

[Anonymous Coward]

The real problem is that while your competitors were rewriting their products in Java, you were sticking with VB. And now you want to blame Microsoft for that. Sorry, that's not gonna fly. And yes, I am a software developer. Rewriting into another language can get you a lot of benefits that you can quickly roll out into your application. It's not 'just' rewriting. And .NET does not necessarily mean platform/vendor lock, either.

Not that that actually matters, because most people are all still using Windows anyway, and will be for a long time.

Where's the Kitchen Sink?

[ChaoticCoyote]

Why, oh why must language inventors continue to add every possible concept to their pet project? Must every language try to be everything to everyone?

No programming language is suited to all applications; anyone who claims omnipotence for their particular language is exhibiting either ignorance or arrogance. A wise programmer knows how to use many tools in appropriate contexts; it's this sort of rational maturity that separates amateurs from professionals. It makes no more sense to develop a web-hosted applet in C++ than it does to write a high-performance batch-processing engine in Java. Using multiple programming languages isn't a simple matter of syntax -- it's a matter of divergent perspectives that force me to think about what I'm developing.

A disturbing trend has emerged in the last decade, with developers trying to make every programming language applicable to every task; we add object-oriented features to COBOL and Fortran, add generic types to Java, and expand the C++ library with a plethora of complex templates. Now C# is "borrowing" all sorts of ideas from all over the map, without any thought for how all these pieces fit together into a cohesive and logical whole.

In the end, we get bloated tools that include features ill-suited to their core design. Instead of focusing on a clear set of goals, languages compete in an edless feature competition that often ignores sound engineering practices.

I have done professional C# programming, and the language does not impress me. Certainly it has some very good ideas -- but it lacks any sense of cohesion in design or intent, and it's ties to Microsoft make me leary of using it for long-term coding projects.

Microsoft and innovation

[XNormal]

As an open-source I really hate to say this but...

This is a terrific example of honest-to-god innovation from Microsoft.

Yes, I know, the building blocks have been available in some form or another in many other platforms. But so far nobody has managed to bring all of this together so elegantly.

The features are not just a random heap of syntactic sugar. They combine to create the query syntax (using lambdas) which can be either executed directly in C# (with the help of external methods) or be available as a runtime data structure (shades of lisp) that can be translated dynamically to an SQL or XQuery and sent to a remote server for execution. The type inference ensures that the query syntax is not littered by type declarations yet remains typesafe.

Nice work, Anders. I guess the Comega team deserves much of the credit, but I have the feeling it was Anders who brought it all together into a clean and not too "academically smelling" framework.