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:Who is Anders Hejlsberg?

[Detritus]

Niklaus Wirth designed Pascal. Anders Hejlsberg wrote a number of popular Pascal compilers, such as Turbo Pascal.

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.

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

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?

[ObsessiveMathsFreak]

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.

Ahh, but just think of all those poor migrating Visual Basic programmers whose only expierience of a c type syntax has been a spattering of javascript. They'll feel right at home.

With any luck, we'll make programmers of them yet.

Re:Why implicitly typed locals?

[Mr2001]

I guess all the implicit typing additions make sense in the context of LINQ, where SQLish queries are translated into C# code involving lambda expressions. In all my years of coding in Delphi and now C#, I've never needed to use BDE, ADO, or any other OOP database interface, so I can't gauge how useful these additions will be.

However, this example of yours seems like a bad one:

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

If you're changing the type of the collection, a few foreach loops are the least of your concerns - what about all the code that actually manipulates the items' methods and properties? And if you're using a snippet like that so much that you're tempted to paste it over and over to work with collections of different types, you should really change it to a generic method:

static void PrintItems<T>(ICollection<T> collection)
{
    foreach (T item in collection)
        Console.WriteLine(item);
}

In summary, I can see how these implicit typing additions would be useful for the compiler, or rather for the language designers to explain how the compiler will implement features like lambda expressions and LINQ, but I can't see myself ever using 'var' instead of an actual type name.

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?

[phidiot]

It looks like it would be useful when combined with LINQ type queries as in:

var q =
from c in customers
where c.City == "Seattle"
select new { c.Name, c.Age };

q would result in an implicitly typed collection of objects that contain Name and Age properties only.

Here is a good description of using both

Re:Why implicitly typed locals?

[RAMMS EIN]

In the past, I've made the argument that forcing people to declare types lowers productivity and decreases legibility.

The one good rebuttal I got was that it really helps to declare types on function parameters; it serves as a kind of documentation of the intended use and operation of a function. Plus, of course, it allows the compiler to catch errors where the function you write doesn't have the type you say it does.

I guess that's also the reason Haskell programmers like to declare the types of their functions, even though it's optional in Haskell.

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?

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

Re:Why implicitly typed locals?

[noamt]

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


This example makes no sense.
Is "collection" a collection of objects or something more concrete? If it's an object collection, s/var/object/ in your example.
The compiler inferes the variable type at compile-time, not run-time. So "var" will become "object" anyway.

var i=5; // same as int i=5;
i="str"; // won't work, because i is an int.

Of course, maybe I got it wrong..

Re:Why implicitly typed locals?

[iGN97]

The problem is that your code throws away the type information. If you want to do anything with the item, you have to downcast it. This is incurs runtime overhead and has the possibility of failing at runtime. Errors in handling the "var"-reference will be handled at compile-time.

The point is that var is a convenience. Writing:

var s = "Hi!";

is equivalent with writing:

string s = "Hi!";

The exact same code will be generated. The benefit of using var is that it's usually less to write (especially when working with collection types like Dictionary<int, string>, for example).

What I was trying to illustrate with the foreach is that code written works for more cases without sacrificing any kind of strong typing. Using "var" never results in a hidden "object" unless you write

var o = new object();

The scaremongers that indicate that this will somehow sacrifice either runtime-security or make it harder to track down bugs are just prematurely worried. I actually think that the opposite will be the case, thanks to code that's easier to read. So I guess you could say I'm prematurely sighing with relief. ;)

What I was trying to say with the foreach-example is simply:

foreach (var item in collection) { // ... }

will work regardless of the T in IEnumerable. It is less code to maintain, and it works exactly like continuously substituting the "var" for the T. This makes the written code more generic. It works with more types of data without sacrificing type safety. You can do operations on "item" without doing a downcast and errors will be found at compiletime, unlike working with object.

Re:Why implicitly typed locals?

[Anonymous Brave Guy]

One of us is misunderstanding here, but I'm afraid it's not me.

There is nothing about inferred typing that requires things to be of some base "object" type. Indeed, in many languages that use it, there is no base type, nor even necessarily the concept of inheritance.

In the case of the code we were discussing:

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

it would be normal to deduce the type of item from the type of collection and the behaviour of the foreach ... in ... construct. That type would then be checked against the requirements for WriteLine, and an error generated at compile time if the types were incompatible. Whether C# specifically will be doing this, I don't know, not having read the specs for the new features in detail. There's no reason the use of type inferencing techniques generally can't, though.

You seem to be looking at this from the point of view of C# and its current generics features only, and in that restricted context, perhaps there is indeed some silly performance hit. I'm looking at the pros and cons of inferred types generally, and in that more general context, there is no need for the clutter of generic syntax, and many languages work quite happily without it.

BTW, even if your platform does implement this naively by using a universal base type, a performance hit of 500% for doing so is appalling, and suggests you have far deeper problems on that platform than how generics are handled!

Not trying to be rude, but ...

[hritcu]

Do we really have to have a Slashdot post followed by a flamewar every time a guy at Microsoft opens his mouth?

Re:Looks more like Delphi every release

[Decaff]

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.

On the contrary, it is big step backwards. One area of intensive research in IT for years is setting up a portable high-performance disconnect between database and other tiers. For many applications the database is just a resource, and embedding query languages within code is a bad idea. If you look at transparent persistence systems like JDO and Hibernate, almost all of the data retrieval and processing can be done with no query language at all - optimised query languages tailored for specific databases can be generated in the background, and this querying can be very optimised indeed.

Embedded SQL in computer languages has been around for a very long time - take a look at SQL/J. There are more elegant ways to do things.

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

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

[FoboldFKY]

You've obviously never heard of Mono...

Way to go!

[RAMMS EIN]

It seems that Microsoft is finally doing something with all the great research they funded. C# is becoming more and more like Lisp and ML, and might well become the first language in recent times that carries the approval of both academics and the industry. .NET as a whole gets many things right; multiple languages that can target the CLR and interoperate, special modifications made to create a friendlier environment for functional languages, registration of the core technologies with an independent standards body, publication of an implementation for multiple platforms, with source code, etc. etc.

Of course, .NET doesn't get everything right, but it's amazing how many good things are in there, especially considering that it comes from Microsoft.

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:LINQ

[RAMMS EIN]

``The built in SQL like language would be usefull in many languages.''

Yep. If done right, it can completely eliminate the possibility of SQL injections. This is something that too few people realize, but with SQL injections being a very common kind of vulnerability, it's definitely worth putting some thought and effort in.

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

[callipygian-showsyst]

Is anyone else here in a similar situation?

Yes! We has all these Apple Hypercard applications, then Apple dumped us like a hot potato! However, I'm prohibited from the /. "terms of service" from saying anything bad about Apple, or comparing Apple to Microsoft.

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.

Re:The Microsoft Trap

[the eric conspiracy]

Is anyone else here in a similar situation?

Yes, we had a similar problem, made even worse by the fact we needed something that could scale a lot better than VB does.

The solution for us was to move to Java. Fortunately our company is growing at a resonably rapid rate so that we were able to adsorb the VB programmers who for one reason or another didn't want to move to Java into some other role.

We still have a few older customers running the old VB6 application but by end of next year they will all be moved over to Java.

I see all this .Net hype, and rapid changes/feature addtions to the language and laugh. MS is leading you down the garden path, and in 5 years MS will be coming out with .New and you will be screwed again.

Don't EVER forget that MS is a pure software company, and that means they MUST continue to sell new versions / churn their customer base to stay in business.

Re:Can someone explain the advantages of C# over V

[SuperJason]

I have a whole list of reasons, which have been hashed out millions of times in millions of other forums.

I'll just give you the top reason that I use c#.

In VB.NET, Build and Rebuild are the same thing! If you change one class and do a build, on a large project it can take MINUTES.

The same project and change in c# can take SECONDS to build.

The time savings alone could buy a lot of stuff.

Is Java falling behind?

[Sanity]

It is exciting to see developments like this in C#, particularly stuff like LINQ (the inelegance of using SQL from within other languages has bugged me for quite some time).

Java's language features, by comparison to C#, seems to be moving along at a glacial pace, only recently getting features like foreach loops, and generics.

I personally prefer Java because of Eclipse, but Sun are really going to have to get a move on if Java is to remain competitive with C#.

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:Is Java falling behind?

[MSBob]

Java innovates but in a different area. There is a lot of emphasis on extending Java with Aspect Oriented Programming (AOP). There is an incredible extension to Java called AspectJ. You owe yourself to download AspectJ and its Eclipse plugin. You'll see the future of java programming when you try it.

Re:Is Java falling behind?

[fupeg]

The answer to your question is no. Java has clearly borrowed some things from C#, though C# itself heavily borrows from Java. The EJB 3.0 spec for example will make use of dependency injection. Take a look at Groovy which will be integrated into Java (javax.script in 6.0.)

Now it is true that as a more widely used (on the Enterprsie level) language, Java is going to move more slowly than C#. C# is newer and trying to take mindshare from Java, so it must move faster. Just having a great IDE is not enough.

Re:Is Java falling behind?

[horza]

Java's language features, by comparison to C#, seems to be moving along at a glacial pace, only recently getting features like foreach loops, and generics.

Even worse, C's language features don't seem to have moved since the late '70s. Thank god no-one is still using that any more.

Phillip.

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

[spongman]

that's fine if your program is so simple that every posible code path can be executed in a short amount of time, but for anything but the most trivial rograms this is impossible (see Turing for a reason why). This means that for dynamically typed languages, the onus is on testing to find a whole slew of errors that statically-typed languages can find at compile time.

not a good solution for multi-K-line programs written by large teams of programmers.

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:Looks more like Delphi every release

[ergo98]

All hail our new fat client overloads. Oh joy.

Fat clients? You do know that the majority of .NET development occurs in the web services/web app space, right? Even then, middle-tier services in .NET are just as usable by a web facade as they are a fat client. In no way is this a fat client-only technology.

Written in both--

[Tominva1045]

As someone who has served as a consultant and written applications in both languages this is what I can add:

My VB apps were much quicker to prototype- to provide something to a customer in helping them determine requirements when they aren't really sure what they need. Also, the VB apps are often easier to maintain (less cryptic code can be easier to maintain).

My C# apps were usually written in that language because the client had a preference for it- not that any logical reason was given (unless you count putting C# in marketing information to justify higher costs). Also, because the lanugage can be more difficult to follow (meaning less likely the client's in-house developers can code or update it) than VB, consultans can often charge a higher hourly rate to code in it.

Both languages build to the same IL output.

Comments such as this one from above a great language for people who don't want to know to much about what thier program is actually doing - but VB .NET is, and will always remain a hack.

show a real bias whilst not providing any detail whatsoever. So take them with a grain of salt. Unless your reading machine language, you don't really know what your appp is doing.

It is possible to write great code in each. It is also possible to write really bad code in each. It comes down to the developers ability and preferences.

If you have a nice fat contract and want to perch in your ivory tower looking down upon the commoners, go with C#.

If you have demanding clients and need to give yourself some breathing room, go with VB.

Language Bloat?

[Xepo]

They keep adding more and more stuff to the language...is there anyone that can really read all of the code that is possible to be written in C#? It sounds like a readability nightmare to me.

Heck, it took me years to learn all of the components in C++, and I'd bet that the specification for the complete language is now much smaller than C#'s. And there's still stuff waiting to be discovered on the level of template meta-programming.

Is all of the stuff they keep adding actually useful? Or is it just being added so that they can give the impression of progress, and maybe convert more people to using it? Granted, I'm excited about C++0x, but unlike what I would be thinking if I used C#, I'm not worried because I trust the standards body to not put completely unnecessary stuff into the language. What do you C# programmers think?

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 May Have a Future

[alucinor]

Thanks to some of the brilliant developers at MS, we can get some awesome stuff out of this company, like C#.

Now, too bad management will keep on trying to tie .NET down to their sinking ship, Windows.

If only the .NET framework could be freed from Windows, and given the official blessing to target all platforms, including Linux, then Microsoft could set itself up as the supreme tools vendor for the platform. It'd be a bright future for MS, and overnight .NET would probably become the de facto standard for development on Linux!

But no ... the stodgy petrified boys up top will always put Windows first ... to MS's undoing, no doubt.

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.

Re:Where's the Kitchen Sink?

[superid]

I don't think this is a kitchen sink addition. I think this will be a welcome addition to a very large fraction of C# developers. First, my gut feeling is that the majority of non-trivial C# applications connect to databases of some kind, this will help that. Second, even if you don't use a DBMS this will be useful for complex operations on pretty much any data structure that you create.

This will make me a lot more productive and I'm going to install it ASAP!

Re:Where's the Kitchen Sink?

[XNormal]

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?

This isn't just a random heap of features. They all combine to create the query syntax which can run in-memory as C# code or be translated to external query languages such as SQL or XQuery and sent to a remote server for execution.

No programming language is suited to all applications;

But C# with embedded query syntax is an elegant solution to bridging high level languages and databases. This answers a very real and very pressing need in the industry.

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.

It only looks that way if you don't RTFA...

Bashing MS is the whole point of this website...

[bigweenie]

Are you a newbie? That is the whole point of this website.

If you don't want to bash MS, then go to some MScentric site and wax wonderful about their propietary crapola. Some that are on the MS payroll continue to espouse the virtues of MS here (perhaps you?!), but we all enjoy how much time, money and effort MS spends trying to alter the overall message of slashdot.org.

Lesson for MS to learn: FUD doesn't effect a community of a single mind and purpose.

C# will not replace Java. It is a wonderful Java knock-off with a great IDE (Visual Studio), but it is not a Java killer.

End of rant.

/bigweenie

Re:Looks more like Delphi every release

[Decaff]

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

I should have said 'embedded query languages'. My point stands... this is new.

Again, have you watched the video or read the spec?

Yes.

DLINQ, by the way, is the ORM system that makes the objectpersistence "transparent" (leaky abstraction, like all ORMs, but still).

Nowhere in the information can I find terms such as 'persistence by reachability' which are appropriate for true transparent persistence. I may be wrong, but it looks like true transparency is not supported.

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.

There are plenty of alternatives for other languages that do support these database 'out of the box'.

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.

Solid evidence, please?

[Anonymous Brave Guy]

Do you actually have any solid information to support your claims here, or are you just expressing your personal opinion as fact?

Almost all of the posters objecting to type inferencing here quote examples like your

var y = SomeFunction()

as an illustration of how code is less readable without a type. Guess what? Code isn't very readable if you call your functions SomeFunction anyway, and writing

int y = SomeFunction()

or

SystemLibrary.MathModule.FloatingPoint.LongDouble y = SomeFunction()

really doesn't help.

On the other hand, if your functions and variables have meaningful names, you probably don't care whether the value returned is a float or a double most of the time. Type inference makes your code more generic, without losing any particularly useful information (if it is useful, you can still specify it), and the type safety of the system prevents the sort of

double -> float -> loss of precision

errors typical in languages like C.

In other words, I see a lot of scare-mongering in this thread, but very little evidence that it's justified, other then people saying, "It's unfamiliar and I don't like it". Do you have anything more for us?

ECMA or Microsoft Standard?

[Anonymous Coward]

What gives Microsoft the right to unilaterally update the ECMA C# standard? Unless the whole ECMA standard thing was just a farce all along.

Languages falling behind

[Anonymous Brave Guy]

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

Perhaps. But then again, Java evolved very fast in its first few years, and a lot of what it evolved was crap, particularly the numerous poorly-considered additions to the library that now have to be supported pretty much forever. Policies on language features were made on evangelical grounds -- "We don't need templates!" springs to mind -- and a decade or so later, people are eating their words (as more conservative/deep-thinking programming communities have been telling them they would all along).

There is a lot of merit to stability in programming languages that are used by real people for real jobs. Some languages go too slowly, IMHO: I think C++ is drifting off into specialist worlds with a single really active supporter at the expense of useful mainstream stuff with no champion, but that's more a result of the way the standards committees are set up than anything else. Likewise, Perl 6 is becoming almost a completely different language, which is no longer recognisable as an evolution of Perl 5. But at least there's time for people to keep up, and in the meantime, everyone's able to use a solid baseline in C++03/Perl5 for real work.

These developments in a mainstream language like C# have potential to bring useful programming techniques into the mainstream, for the first time in some cases. Still, when most of the C# world is still exploring version 2, I can't help feeling that they'll either lose support or develop a community full of keen but under-informed developers producing naff code because they didn't have time to learn everything at once. Sometimes exciting isn't the best thing.

Implicitly typed local are good

[vyvepe]

* type names can get long, especialy when templates are used

* why do you want to do the compiler's work

* editor with intelisense will tell you the type for the expression in most cases so no need to repeat it

* you do not need to modify so much places if type changes during development

* and if you really want you can get the exact type, but mostly it is just waste of time

AFAIK, they are going to add this to C++ too

I have just one problem with it

[alexo]

The problem is that MS strongly ties the language with the IDE.

That is, whenever C# (or Visual [anything] for that matter) gets new features, we have to buy a new version of Visual Studio to take advantage of it.

For every developer that may work on a project that will use these new features (and our developers tend to move around).

I have run into several annoying bugs and limitations in the .NET framework 1.1 and MS's response has invariably been "it is fixed in 2.0". However, to use it, we will have to buy VS 2005. Want a bug fix? Buy the new version! Neat.
Now C# 3.0 comes along. Will we have to upgrade to VS 200x yet again?

With these forced upgrades, MS has effectively implemented a subscription model for their software.

Re:I have just one problem with it

[caseih]

What are you talking about? The .NET environment and C# environment has always been available as a separate, free download from MSDN. While developing in Visual Studio is nice, you absolutely don't have to. The compiler is a standalone commandline compiler and the runtime environment certainly doesn't have anything to do with Visual Studio. The Mono developers regularly download the latest versions of .NET to compile their test suites and compare the results to Mono's results.

What forced upgrades are you referring to? I must be missing something here.

Greenspun's Tenth Rule of Programming

[ari_j]

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.

These changes to C# bring it closer to Common Lisp, and therefore make it easier to include those ad hoc implementations of it.

Insert \\ Magic Bullet ?

[oldCoder]

Are there any examples of insertion? What to do with null fields? I haven't had time to study all the stuff yet...

So, in wrap up, how far does this take us to the Brooks' "Magic Bullet" for programming? Does further tying data structure into code still provide the clean separation between code and data required by good design? Can I prevent my data definitions from proliferating all through my source base so when the DBA re-does the database I'm not stuck with obsolete and broken applications?

And can I do stored procedures and give up SQL entirely or will DBA's need to learn both SQL and a new .NET language in addition to all their existing admin tools?

Can I use Reflection to inquire of the structure of the data and generate code to manage the database? Or are the older solutions still the best for this?

In what other ways will SQL-server and .NET become more tightly integrated? And when will the both become part of the Operating System like IE, with all the attending benefits?

I see the polymorphism angle (XML/Databases/Arrays) but is there a way to inherit data definitions? To subclass them?

And when will the WMI, the Windows hierarchy in a GUI application, the programs own class hierarchy through Reflection, and the HTML-DOM be accessible through these new interfaces, or have I just run aground on the shoals of logic and imagination? A bridge too far? How about the files in a directory, or is that just WMI again?

What tools and hacks will be need to deal with volatile (externally modified) dynamic data? SQL-server has some of it's own but coders still need to specify read-with-lock from read-without-lock. All the other data except for arrays and some XML is volatile (subject to modification by other threads or CPU's). Different data sources have different volatility models (db's, WMI, processes running on the OS, nodes on the net).

General vs. specialist languages

[Anonymous Brave Guy]

I think there's a lot of truth in what you wrote there. That said, while specialist languages have their place, I'm increasingly wondering why no-one has yet produced the next great general purpose language.

Why can't we have a simple, elegant syntax like much of Haskell or Python, with punctuation frenzies reserved for things like regular expressions and printf formats where history shows they work well? Why can't we have a grammar that's amenable to parsing by automated tools, to make it easy for IDEs to provide refactoring aids, consistent formatting, etc? Why can't I have an imperative language that still supports higher-order functions and the like? Why can't I have proper disjunctive types and pattern matching in a language that supports OO with RTTI/reflection capabilities anyway?

I don't do professional compiler design, but I'm fairly familiar with the theory, and none of this seems to be prohibitively difficult. Indeed, most of it has been done in some form or other, somewhere. I just don't see why none of the places that invests so much in programming languages has managed to produce something like this yet. If they did, I don't see any reason we couldn't have a language suitable for a wide variety of applications, offering a clean, powerful syntax, yet still generating code that performs at a comparable speed to that from a low level language.

The technology seems to exist, it's just the language that (bizarrely) doesn't yet. We seem to be stuck in a rut where the only languages that are willing to risk major departures from common syntactic conventions and tool sets are new scripting languages and academic research, and so far each of them has had some significant drawbacks when it comes to industrial-strength, large-scale projects.

Intelligent design?

[pammon]

Rather than allowing C# to evolve naturally, Microsoft is hoping that they can get people to buy into its intelligent design

Seriously, I've never seen anyone try to evolve a production language this quickly. They're throwing in features left and right. It's exciting! But it's also terrifying: I feel like C# is being driven at breakneck speed towards, err... I don't think Microsoft actually HAS any ultimate goal in mind for C#, as long as they can cover a lot of ground getting there.

And if you drive this fast, eventually you're going to crash, and when C# does, it will fragment into dozens of small shiny sublanguages. People will carve out their C# comfort zones containing the features they feel comfortable with and exclude the rest. Two C# programmers will no longer always speak the same "dialect," making it difficult understand each others' code.

The fact that there's a great deal of overlap among C#'s features only makes this worse. Programmer A's heavy use of generics and lambda expressions will be unfamiliar to programmer B, who never bothered to learn those features since he can accomplish the same things using implicit typing and LINQ.

And, needless to say, differing levels of compiler support will also exacerbate this problem.

I'm surprised Microsoft isn't more careful, given the cautionary example of C++. C++ is in the later stages of this disease. Large projects have to specify the C++ sublanguage dialect that they're using. And we aren't talking simple style guidelines, but the excision of large chunks of features, like RTTI and exceptions. If C# continues the way it's going, it will wind up like this.

ding! That was the sound of me reaching my metaphor limit of three per post. I guess I better end this. So to sum up:

Microsoft, you are the largest software developer and in control of the OS and development tools. You are in the unique position of being able to dictate every aspect of a new programming language. It will be used for years to come by millions of developers in all different situations. This is a blessing and a tremendous opportunity.

Don't fuck it up.

(please?)

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.