Anders Hejlsberg on C# 3.0 386
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."
Re:Looks more like Delphi every release (Score:5, Insightful)
What are you talking about? I used Delphi for years, and then switched to
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:So what? (Score:1, Insightful)
Why implicitly typed locals? (Score:5, Insightful)
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.
Not trying to be rude, but ... (Score:5, Insightful)
Re:Why implicitly typed locals? (Score:5, Insightful)
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.
Way to go! (Score:5, Insightful)
Of course,
Re:Why implicitly typed locals? (Score:3, Insightful)
However, this example of yours seems like a bad one:
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:
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? (Score:2, Insightful)
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 [msdn.com] is a good description of using both
Re:Why implicitly typed locals? (Score:4, Insightful)
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:Can someone explain the advantages of C# over V (Score:2, Insightful)
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.
Re:Why implicitly typed locals? (Score:5, Insightful)
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.
Is Java falling behind? (Score:5, Insightful)
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 [eclipse.org], but Sun are really going to have to get a move on if Java is to remain competitive with C#.
Re:The Microsoft Trap (Score:5, Insightful)
Not that that actually matters, because most people are all still using Windows anyway, and will be for a long time.
Re:Looks more like Delphi every release (Score:2, Insightful)
Fat clients? You do know that the majority of
Written in both-- (Score:4, Insightful)
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
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.
Re:Why implicitly typed locals? (Score:2, Insightful)
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;
i="str";
Of course, maybe I got it wrong..
Where's the Kitchen Sink? (Score:5, Insightful)
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:Is Java falling behind? (Score:3, Insightful)
Re:Where's the Kitchen Sink? (Score:5, Insightful)
This will make me a lot more productive and I'm going to install it ASAP!
Microsoft and innovation (Score:5, Insightful)
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? (Score:5, Insightful)
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
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 or 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
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?
Re:Where's the Kitchen Sink? (Score:3, Insightful)
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...
Languages falling behind (Score:3, Insightful)
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 (Score:2, Insightful)
* 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
Re:Who is Anders Hejlsberg? (Score:4, Insightful)
Re:Is Java falling behind? (Score:4, Insightful)
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.
Greenspun's Tenth Rule of Programming (Score:3, Insightful)
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 ? (Score:2, Insightful)
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 [microsoft.com], 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 (Score:3, Insightful)
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.
Re:Not really (Score:3, Insightful)
not a good solution for multi-K-line programs written by large teams of programmers.
Re:Why implicitly typed locals? (Score:3, Insightful)
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:
it would be normal to deduce the type of item from the type of collection and the behaviour of the foreachYou 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!