ESTIMATED TIME: 60 minutes

MESSAGING: Functional: Features that allow developers to write code in a more functional way to apply lessons learned from functional programming languages. Lambdas, LINQ Concise: Letting the compiler “get out of the way” so the developer can focus on the problem at hand, rather than specifying every little detail to the compiler Type inference (“var” keyword) Declarative: Focusing more on the What not the How when describing problem solutions in software LINQ

MESSAGING: Perhaps one of the most important features introduced in .NET 3.5 was LINQ. LINQ is powerful for many reasons, perhaps the largest being it’s declarative programming model. Here’s a snippet of code that uses a typical imperative programming style to return parents that have a child with a given name. One of the problems with imperative styles of code, is it limits the amount of things that a compiler or a runtime can do to make the code better. This is because we are telling the machine exactly _how_ the code should execute via imperative constructs like foreach loops, if statements, etc.

MESSAGING: Here is the same piece of code using LINQ. Not only does it’s declarative nature make it more powerful (for many reasons), but it is also easier to read and understand the true nature of what the developer was wanting to do.

MESSAGING: The power of writing declarative code (versus imperative code) is that the developer focuses more on expressing the “WHAT needs to be done” rather than “HOW it is to be done.” This is important because it leads to many benefits. One of the benefits is that the impedance mismatch that happens between the problem a developer needs to solve, and how he solves it becomes less and less. Currently, expressing solutions in an imperative way does not allow a developer to express the true intent of his code. The only advantage of a declarative programming model is that the compiler and runtime can be more liberal with the changes it implements in order to make the code as efficient as possible. This is due to the fact that the code is no longer directly tied to the implementation of the underlying algorithm like it is when using imperative code.

MESSAGING: There are several trends in modern programming languages that we feel are important to address and capture with our programming language that we will continue to target. Declarative Imperative languages focus heavily on the how. Programming logic is achieved via if statements, for loops, while loops, etc. Declarative languages focus on the what Tell the computer “what” you want done, and let it focus on how to get it done (so the language decides whether to achieve the goal via a for loop, foreach loop, recursion, etc.) Focusing on the what instead of the “how” is an important part of “stepping away from the compiler” and better expressing your true intent in code. Dynamic Around dynamic languages, you often hear the comparison of dynamically-typed versus statically-typed languages. A better way to express this difference is thinking “late-bound” versus early-bound. Early-bound languages enforce calling conventions, matching contracts (method calls on specific types, for instance), at compile time. However, late-bound languages “punt” this decision until runtime. While early-bound languages gain me benefits like compile-time type-safety, they also enforce rigid constraints on the design of your code In this way, code written in early-bound languages becomes more difficult to change. For more information on this “flexibility”, check out Duck Typing in Ruby. Concurrent Concurrency is a topic that is very important to start addressing ASAP. The “concurrency problem” is already here, not 5 years from now, but today. Functional languages like F# are very powerful when it comes to addressing concurrency This power comes from the immutable-by-default approach when enables easier-to-parallelize code since assumptions can be made about the behavior of the code because of no shared-state F# introduces a very powerful mechanism for achieving concurrency called Asynchronous Workflows (has nothing to do with Workflow Foundation workflows) Async Workflows use Parallel Extensions to the .NET Framework under-the-hood For shared-stated languages like C# and Visual Basic, concurrency features are primarily coming from library features like Parallel Extensions Language teams are thinking hard about how to possibly integrate concurrency into the core language (this is a hard space).

MESSAGING: C# 1.0 With the launch of the C# language, it was a major shift we took to a full managed environment. This was a big step for programming languages at Microsoft. C# 2.0 -With the second release of C# we introduced fully reified Generics into the language. This was a very powerful addition to the type system. C# 3.0 -C# 3.0 introduced LINQ which we talked about previously C# 4.0 -Not just “dynamic” as in late-binding, but those features that allow the compiler to “get out of the developer’s way”.

MESSAGING: Late-Binding Support: The ability to do runtime call dispatch rather than being forced into compile-time verification. Named and Optional Parameters: This allows us to clean up our code as we can see. It also goes hand-in-hand with #3, Improved COM interop (bye-bye “ref MissingValue”) Improved COM Interop: Better interop with COM, along with easier deployment via Type Equivalent and embedding of types. Covariance and Contravariance: This is really about patching a problem in our generic type system as it exists today. Most developers won’t be using the generic variance features directly, they will simply be able to do stuff they couldn’t do before.

DEMO: Shows how the combination of named and optional parameters combine to allow a developer to write simpler code or to simplify existing code. Use One.SimplifyYourCSharpCode from the LanguagesTenInOne solution. FAQ: [Q] Are optional parameters a compiler feature, or a runtime feature? [A] It is a compiler feature. The value of the optional parameter is compiled into the callsite at compile time. This means that if the value of the optional parameters is changed at a later date and the code isn’t recompiled, you could have code that doesn’t work as you expected and could introduce subtle bugs.

MESSAGING: By encouraging C# and VB to co-evolve, each language can “push the boundaries” while not having the other language “fall behind” Co-evolution is like a rubber band, while the languages may not be identical with each release, they will “catch up” to each other with each subsequent release

MESSAGING: With previous releases, C# and Visual Basic have tended to “go separate ways” Very common feedback is “I want VB to have feature X from C#” and vice versa Even worse, what happens when the framework is designed in such a way that it makes heavy use a feature is easily used in one language or not the other? In this case, the framework stops being “language agnostic” and certain framework features being hard to use depending on the language being programmed in. An example of this today are frameworks that make heavy use of lambda expressions. In VB9, without the ability to easily use multi-line lambdas or statement lambdas, certain frameworks designed with C# in mind become much more difficult to use for VB developers.

MESSAGING: Visual Basic 1 – Visual Basic 3 Made Windows programming accessible Helped make Windows the premier platform in the world Visual Basic 4 – Visual Basic 6 Made targeting COM and OLE approachable for most developers Visual Basic 7 – Visual Basic 9 Bringing the “ease of use” to the .NET platform Helped establish the CLR as the premier managed runtime in the world Visual Basic 10 Continuing this trend to make it easy to use and leverage the platform

MESSAGING: We show all these features in our demo.

DEMO: Use Three.VbLanguageImprovements from the LanguagesTenInOne solution.

MESSAGING: There is a good reason why the Dynamic Language Runtime (DLR) exists. The problem is that, today, dynamically-typed languages like Python and Ruby can’t easily run directly on top of the CLR as the CLR is primarily designed for statically-typed languages. By creating the DLR, we help plug that hole and allow dynamically-typed languages to run on top of the CLR (by working through the DLR).

MESSAGING: The DLR provides core services that are necessary for dynamically-typed languages to work on the CLR The DLR also provides other services that can be used by statically-typed languages as well to achieve more dynamic behavior: Expression Trees (including Statements) Dynamic Dispatch Call Site Caching

MESSAGING: The power of the DLR is that there are many binders for the DLR. Yes, we can interop with dynamic languages like Python and Ruby like we expect to. However, perhaps even more importantly, there are binders available for .NET, Silverlight, and Office. This allows us to interact between these platforms in very powerful ways that we were unable to currently.

MESSAGING: As long as we stay in our statically-typed world, interacting with objects is a pleasant and intuitive experience. However, as soon as you step out of that boundary and have to start using reflection, your code becomes much less elegant, harder to read, and harder to maintain. Using ScriptObject in the DLR makes this a bit easier as it provides some direct method calls to invoke methods with specific parameters. And while this is an improvement, it’s still a departure from the way we are used to interacting with objects. Using the new dynamic keyword in C# 4, we can call the .Add method above exactly as it were statically typed like in our first code snippet. In this case, the calc object is statically typed to be dynamic (yes, that’s true). Once we have a dynamic object references, we can dynamically invoke methods, do dynamic conversion, etc.

DEMO: Calling the Random shuffler in IronPython from C# (passing in an IEnumerable<int> generated in C#). Use Two.IronPythonInterop from the LanguagesTenInOne solution.

MESSAGING: There is much to be excited about with Visual Studio 2010. Whether you are a C# developer, a VB developer, or an F# developer, there is a lot of stuff coming.

Questions?

MESSAGING: F# is a functional programming language for the .NET Framework. It combines the succinct, expressive, and compositional style of functional programming with the runtime, libraries, interoperability, and object model of .NET. F# is included in Visual Studio 2010 and is now a first-class language just like Visual Basic, C#, and C++. F# is very good for compute-intensive problems, highly parallel problems, and language-oriented programming. Since F# just generates normal MSIL and .NET assemblies, you can develop a library in F# that does your computations, and call your F# code from your C# application.

Visual Studio 2010 and .NET Framework 4

Presentation Outline (hidden slide): Technical Level: 300 Intended Audience: Developers & Architects Objectives (what do you want the audience to take away): Understand the new features and improvements to C# 4.0 Understand the new features and improvements to VB 10 Understand the ongoing relationship between C# and VB as they both evolve Presentation Outline: Where we’re at today LINQ/Declarative Language Trends C# (Evolution -> C# 4.0) Co-Evolution VB (Evolution -> VB 10) DLR

What’s New In C# 4.0 and Visual Basic 10 Nithin Mohan T K Technology Enthusiast nithinmohantk@nithinmohantk.info

Where We’re At Today Our managed languages are starting to share some very similar features: Functional Concise Declarative

Before LINQ, The Power of Declarative IList<Person> FindParentsWithChildNamed(string childName) { var matches = new List<Person>(); foreach(var person in _people) { foreach(var child in person.Children) { if (child.Name.Equals(childName)) { matches.Add(person); break; } } } return matches; }

IList<Person> FindParentsWithChildNamed(string childName) { var matches = from person in people from child in person.Children where child.Name.Equals(childName) select person; return matches.ToList(); } After LINQ, The Power of Declarative

Why Declarative Matters… Imperative Declarative What How

Addressing Language Trends

The Evolution of C# C# 1.0 C# 2.0 C# 3.0 Managed Code Generics LINQ C# 4.0 Dynamic

Late-Binding Support Named and Optional Parameters Improved COM Interop Covariance and Contravariance New C# 4.0 Features

Simplifying Your Code with C# 4.0

Co-evolving C# and VB Think of co-evolution as a game of leap-frog…

There’s a problem when co-evolution doesn’t exist…

The Evolution of Visual Basic VB1 – VB3 VB4-VB6 VB7-VB9 Windows Programming Made Easy Components Made Easy Power and Simplicity for .NET VB10 Continuing the trend

Auto-Implemented Properties Collection Initializers Statement Lambdas Covariance and Contravariance Implicit Line Continuation New VB10 Features

VB 10

Why a “Dynamic Language Runtime”? Common Language Runtime Statically-Typed C# VB Ruby Python Dynamically-Typed

Why a “Dynamic Language Runtime”? Common Language Runtime Statically-Typed C# VB Ruby Python Dynamically-Typed Dynamic Language Runtime

Python Binder Ruby Binder COM Binder JScript Binder Object Binder .NET Dynamic Programming Dynamic Language Runtime Expression Trees Dynamic Dispatch Call Site Caching IronPython IronRuby C# VB.NET Others…

Dynamically Typed Objects Calculator calc = GetCalculator(); int sum = calc.Add(10, 20); object calc = GetCalculator(); Type calcType = calc.GetType(); object res = calcType.InvokeMember("Add", BindingFlags.InvokeMethod, null, new object[] { 10, 20 }); int sum = Convert.ToInt32(res); ScriptObject calc = GetCalculator(); object res = calc.Invoke("Add", 10, 20); int sum = Convert.ToInt32(res); dynamic calc = GetCalculator(); int sum = calc.Add(10, 20); Statically typed to be dynamic Dynamic method invocation Dynamic conversion

Dynamic Language Interop

Targeting the current trends in programming languages Addressing current pain points in developing for Windows and the .NET Framework Laying the foundation to enable developers to solve tomorrow’s problems Summary…

Questions?

What Is F#? F# Is… A Functional Programming Language derived from OCaml and the ML family of languages Included with Visual Studio 2010 Very good for compute-intensive problems, highly parallel problems, and language-oriented programming