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."
Who is Anders Hejlsberg? (Score:5, Informative)
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 (Score:5, Informative)
For existing languages that offer similar features in a braces syntax, see Nemerle [nemerle.org] or Scala [scala.epfl.ch].
(Languages like Ruby offer related features, but their lack of static typing means they're more distant cousins.)
Re:So what? (Score:2, Informative)
Re:Looks more like Delphi every release (Score:5, Informative)
turns into
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
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 (Score:3, Informative)
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/billga
Re:Why implicitly typed locals? (Score:3, Informative)
So (forgive screwy SQL-like syntax):
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? (Score:2, Informative)
Why implicitly typed variables? Anonymous types.
Today, you have C# code that looks like this:
Which you could replace with var:However, with anonymous types, you can have code that looks like this:
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 [microsoft.com] for more details on the LINQ project.
Re:Why implicitly typed locals? (Score:5, Informative)
The language is still strongly, statically typed, though - the following would throw a compile-time error:
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: 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 [microsoft.com], which is an overview of the LINQ project, including the new syntax added to C# 3.0.)
Not really (Score:3, Informative)
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:Is Java falling behind? (Score:2, Informative)
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 [jcp.org].
Re:Not really (Score:5, Informative)
Re:Language Bloat? (Score:3, Informative)
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.
Re:Not really (Score:4, Informative)
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.
Microsoft and Lisp - Innovation? (Score:3, Informative)