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:So what?

[FoboldFKY]

You've obviously never heard of Mono...

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?

[Sanity]

Can someone explain the point of this?

One point of it is to allow you to use anonymous classes without having to declare them. Lets say you use LINQ to do a join between two tables - you can assign the result of the join to an implicitly typed variable and reference the fields, without having to give this new object type an actual name.

So (forgive screwy SQL-like syntax):

var result = select a.name as name, b.age as age from...;
log("username is "+result.name+" of age "+result.age);

The variable result is a class which has fields "name" and "age", and we can refer to it without ever having to give this class an actual name. Now bear in mind that all of this is strongly typed and can be verified by the compiler.

As a Java programmer, it is exciting to see these developments in C#, it makes me wonder whether Java is destined to fall behind C# - it sure looks like that is happening....

Re:Why implicitly typed locals?

[JChung2006]

Why implicitly typed variables? Anonymous types.

Today, you have C# code that looks like this:

MyClass o = new MyClass();

Which you could replace with var:

var o = new MyClass();

However, with anonymous types, you can have code that looks like this:

var o = new { Product='Beverage', Price='0.60' };

Without var, what type would you declare this variable? You could declare it as object, but to access the object's Product and Price properties, you would still need to cast the variable to some type, and what type would that be?

Anonymous types and implicitly typed local variables are C# language infrastructure to support LINQ, new language constructs to support type-safe access to relational and XML data stores in C# itself, rather than requiring code using separate class libraries like System.Data and System.Xml to access that data.

Check out http://msdn.microsoft.com/netframework/future/linq /default.aspx for more details on the LINQ project.

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.)

Not really

[Sanity]

C# is strongly typed, Ruby and Python (not sure about Delphi) are dynamically typed. The difference is that with C# (and Java), the compiler can prevent all sorts of bugs that in Ruby and Python you will only encounter at run time.

You might think C# is moving away from being strongly typed with the new "var" construct, but you would be wrong. All types are still inferred and verified by the compiler.

As IDEs and compilers grow more powerful, I think people will start to realise that strongly typed languages can be just as easy to program in as dynamically typed, and you get the added benefit of more help from the compiler at spotting bugs.

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.

Re:Is Java falling behind?

[Qui-Gon]

I'm not sure I'd call it a "glacial pace". There are plenty of enhancements being made to Java (the platform and language) beyond convenience enhancments. See JCP.

Re:Language Bloat?

[man_of_mr_e]

Well, just like the more esoteric features of C++, you don't have to use them if you don't want to. If you want to stick to a subset, you're more than welcome to.

BUT, for those people that DO want to use them, they provide powerful features that would require either a lot more work, or couldn't be done at all. Or, the features make the language safer, and less error prone for certain tasks.

Lots of people still write C++ code as "more strongly type C" or "C with classes". They don't use templates, or overloaded operators, or placement operators, or anything else. And that's fine. That doesn't mean those features are useless.

And, C# *IS* an ISO standard. Version 1 was ratified by the ECMA and was then "fast tracked" and accepted by ISO. Version 2 has (as of July) been accepted by the ECMA and is now on the fast track to ISO. Version 3, which won't even have an impelmentation by Microsoft or anyone else for at least a year or more to come will likely be standardized as well.

Standardization doesn't mean the lanugage becomes static and never changes. It means that 3rd party vendors have a specification to follow for interoperability, and that you can rely on 3 vendors implementing the same standard to be relatively interoperable.

Microsoft and Lisp - Innovation?

[ari_j]

Can you explain to me what C# now has that Common Lisp doesn't? This is not a troll or flame, I am curious.