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

[Haeleth]

Er, Delphi never supported type inference, closures, or metaprogramming of the sort that Microsoft are introducing to .NET in C# 3 and VB 9. These features are coming from the functional programming world, from languages like Lisp and ML.

For existing languages that offer similar features in a braces syntax, see Nemerle or Scala.

(Languages like Ruby offer related features, but their lack of static typing means they're more distant cousins.)

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.

PDC Keynote, day 1

[iGN97]

For anyone interested in development on Windows, or the possible future direction of Mono, I recommend checking out the PDC Keynote for day 1. The duration is about 3:20, and you'll see demonstrations of the 5219-build of Vista, a lot of Avalon apps, four great architects at Microsoft doing live coding (showcasing LINQ, Indigo (WCF), Avalon (WPF) and Atlas, among other things) and a lot of interesting information about where things are heading.

A lot of it is market-speak and sales, but it is a developer conference. The link can be found here: http://www.microsoft.com/events/executives/billgat es.mspx (Click on the "On-Demand Webcast"-link. High up on the page.)

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:Not really

[GnuVince]

You got it wrong. C# is strongly and statically typed, while Ruby and Python are strongly and dynamically typed. Get your definitions right, dynamic vs static refers to when type checking is performed, at compile-time or a run-time. Strongly typed vs weakly typed means whether you can freely mix types. C, PHP, TCL are weakly typed, Lisp, C# and Ruby are strongly typed.

Re:Not really

[Coryoth]

So because the function says it takes an integer, and I fed it some integer, everything is going to be fine by definition? I think not. You are still going to need to exercise every line of code in runtime tests.

Static types are just a very weak form of formal specification. A stronger form would be something like contracts (preconditions, postconditions and invariants) as used in things like Eiffel and D and SPARK, which allow you to specify not just the type of the inputs and outputs, but specific properties that are required of them. Another step up the formality chain again requires you to be very explicit in your specification allowing the contracts to be statically checked prior to compilation - that covers all the code paths and doesn't require runtime checking - and properties of the software to be formally proved.

Static typing finds maybe 10% of the possible potential errors in your program at the expense of doubling the effort to write and understand it. In some cases static typing may be a necessary evil to attain the required execution speed, but as a "safety" feature any benefits it provides are outweighed by the complexity it adds to your code.

Whether the benefits you gain from any level of formal specification, be it static typing or full formal methods, are worth it depends on how badly you need to be sure the system works and how costly any errors are. For some systems it really isn't that important - having a prototype or working code is more important that catching every last glitch. For other systems (security, avionics, banking and finance software etc.) any sort of glitch, bug or exploit is sufficiently costly that the extra effort to catch as many errors statically as possible is going to be worth it. There is also a spectrum of different needs in between.

As another note, static types needn't complicate your code as much as you might imagine. Try looking at a language with good static types (SML or Haskell come to mind) and you'll see that static types can be quite easy and require very little extra work (in comaprison to static types in other languages).

In my experience static vs. dynamic typing is really a matter of how well I've managed to nail down exactly what sorts of data structures I'm going to use. If I'm still doing exploratory/prototype/research code then dynamic types win out every time because they provide incredible flexibility. If I have nailed down what data structures I want to use then static types aren't any extra work and provide and extra buffer of safety.

Jedidiah.