Visual Studio 11 Programming Language Advances

At the BUILD conference in September, we unveiled developer previews of Visual Studio 11, Expression Blend 5, Team Foundation Server 11, and the .NET Framework 4.5.

We’ve been working on these technologies in earnest since we shipped the previous wave of these development tools last year, and we’ve had the opportunity to make significant enhancements, across the IDE, frameworks, libraries, languages, and services. Over my next several blog posts, I’ll be sharing with you some of my thoughts on big steps forward we’ve made in various areas of this development tooling, innovations that help to make developers, testers, and anyone involved in the software application lifecycle far more productive in their daily lives.

For this initial post, I’ll be focusing on programming languages and on the enhancements we’ve made both to their expressivity and supporting tooling. Languages exist at the center of everything developers do. Developers often pride themselves on the quality, style, maintainability, and efficiency of the code they write, and they achieve their goals using one or more of many supported languages. As we build our development tools, we keep this mindset front and center, investing heavily in advancing the state of the art for language tooling and expressivity, and enabling developers to achieve their needs with the best code possible.

JavaScript and Interactivity

In Visual Studio 11, JavaScript becomes a first-class language for building Windows and Web applications, all supported by Visual Studio’s best-in-class tooling. In addition to full language support for ECMAScript 5, significantly improved IntelliSense (including much better performance on large JavaScript files and much improved accuracy), editor support for operations like “Go To Definition,” and the full range of debugger support provided for Visual Studio’s other supported languages, Visual Studio now also provides new integrated debugging windows for interacting with the HTML/JavaScript application being debugged.

The new DOM Explorer window enables digging through the HTML Document Object Model (DOM) to explore and manipulate elements, styles, and more.

And the new JavaScript Console window provides a read-evaluate-print loop (REPL) for JavaScript, integrated directly into Visual Studio. This provides a live window into the running application, supporting the evaluation of any JavaScript expression. The results also support visualizers, as shown in the following screenshot:

As the evaluated expressions apply to the current application’s context, you can even define new functions and use those functions directly from the console window:

Of course, in addition to all the work focused on JavaScript in Visual Studio, as I previously blogged about there is a wealth of new support for designing Windows Metro style applications using HTML and JavaScript in Expression Blend 5 Developer Preview.

Almost a year ago, I blogged about some work done in Developer Division to explore integration of asynchronous programming directly with C# and Visual Basic. I’m excited to say that in the Visual Studio 11 Developer Preview, this is now a part of C# 5 and Visual Basic 11.

It’s long been known that asynchronous programming is how one achieves responsive user interfaces and scalable applications, but such techniques have also been difficult to implement. Such systems remain relatively simple when each operation involves just one asynchronous call, but as our world evolves towards one in which everything is exposed asynchronously, such operations are becoming rare. Instead, developers are forced to write callback after callback of convoluted code in order to navigate even the most trivial of patterns, like one call being made sequentially after another. For years, modern languages have provided us with control flow constructs that were largely unusable when writing asynchronous code. Now, with these new async language features of C# and Visual Basic, developers are able to write asynchronous code as if it were synchronous, all the while using the myriad of control flow constructs provided by these languages, including support for loops, conditionals, short-circuiting, and more.

With these features, we’ve been able to bring Visual Studio’s debugger capabilities along for the ride. For example, when in the debugger we “step over” (F10) a statement containing an await:

it behaves just as you’d expect it to, moving to the subsequent line in the logical control flow, even though that code is likely part of a continuation callback scheduled asynchronously under the covers.

For more information on asynchronous programming support in C# and Visual Basic, I recommend the following talks from BUILD:

Our teams have spent considerable energy in this release improving C++ support in Visual Studio. This includes not only full support for the C++11 standard libraries, improved IDE support (such as reference highlighting and semantic colorization), and support for building fully-native Windows Metro style applications, but also rich new language and library support for parallelism.

I previously blogged about our efforts around C++ AMP. This is an innovative technology new to Visual C++ in Visual Studio 11 that enables C++ developers to easily write code that leverages massively parallel accelerators (mainly GPUs) as part of their C++ projects. In regular C++ code, a developer can use the parallel_for_each method to invoke a lambda that’s been annotated with “restrict(direct3d)”, which will cause the compiler to generate for that lambda code that targets a DirectX accelerator. In the following example, the parallel_for_each is used to iterate through all indices of the output matrix in order to compute the product of the two input matrices

Not only are the C++ AMP sections of code directly integrated into the source files and expressed using standard C++ syntax, Visual Studio also provides complete debugging support for these kernels, enabling basics like breakpoints and stepping, but also full support across debugger windows like Watch, Locals, and Parallel Stacks, along with the new GPU Threads and Parallel Watch windows.

C++ AMP isn’t the only parallelism-focused effort for native code in Visual Studio 11. The C++ compiler now also automatically vectorizes loops when it determines doing so is valuable. For example, for the following code, the compiler will attempt to utilize SSE instructions on the CPU to run multiple iterations of the for loop as part of a single operation, significantly speeding up the computation:

The C++ compiler now also features some auto-parallelization in addition to auto-vectorization. And the parallelism libraries included with Visual C++ have been significantly expanded, including additional concurrent data structures, parallel algorithms, and an updated tasking model similar to that used by the Task Parallel Library (TPL) in the .NET Framework.

Not all languages need to support every domain and every use case equally: if they did so, there would be little need for more than one language. Often languages end up catering to specific domains and specific styles of development, and I’m particularly excited about our investments in a language that’s a great example of this principle: F#. With F# 2.0 in Visual Studio 2010, we provided a language focused on accelerating solutions for computationally-complex problems. With F# 3.0 in Visual Studio 11, we continue the trend of focusing on a particular problem domain by directly integrating support for solving data-complex problems.

F# is a statically-typed language, just as are C# and Visual Basic, and this static typing provides many advantages. It supports an improved development experience by enabling features such as accurate IntelliSense. It can yield better performance due to more optimizations available at compile-time. It can also reduce development and testing costs by eliminating some common categories of bugs.

However, there are also times when static typing leads to needing more code than its dynamic counterpart. As a prime example, the world is extremely information rich, something that we’re experiencing more and more in our daily software lives. All of this data typically enters our programs in a non-strongly-typed way, and it first needs to be parsed and massaged into strongly-typed objects before it’s exposed to the rest of the program. Rather than a developer coding such import routines manually, this problem has been addressed historically by design-time code generation (e.g. a design-time tool to import a Web service description and generate the necessary proxy code). Unfortunately, there are problems with this approach. It interacts poorly with the evolving nature of data sources, such as those on the web. It can lead to very bloated client proxies (types are generated to represent the entire schema and metadata, regardless of whether or not the client program uses them). And it does not have a smooth integration with scripting environments, such as the F# Interactive window in Visual Studio.

With the new Type Provider mechanism in F# 3.0, such data access becomes trivial for F# programs and components. Also, because F# targets the .NET Framework, applications written in C# or Visual Basic (or any other managed language) can utilize this new functionality via an F# component. Using an extensibility mechanism of the F# compiler, type providers in effect provide data access libraries on demand, yielding a computed space of types and methods at design-time and compile-time in a manner that supports IntelliSense and that is extensible. F# 3.0’s libraries include type providers for OData, WSDL, and SQL (via both LINQ to SQL and LINQ to Entities), but custom type providers may also be written to target arbitrary data sources, such as SharePoint lists and WMI providers.

As an example, consider a desire to search the Netflix catalogue for a handful of people that share my “S.” moniker. Netflix exposes an OData feed, which can then be used with the OData type provider:

As is evident from this glimpse into some of the new language features and associated tooling support in Visual Studio 11, a lot of work has gone into pushing the state of the art for what’s possible in modern development. In future posts, we’ll explore advances in Visual Studio beyond languages, such as in the Visual Studio environment itself.

It seems that if I add visualizer definitions to the autoexp.dat file in the 11 preview, they do not work. Is this a known issue, or is there some other way to define custom visualizers for 11?

It appears that the file is identical to the VS 2010 version, so I would expect the visualizers I wrote for 2010 to work in 2011 as well. The file I am editing is found at "C:Program Files (x86)Microsoft Visual Studio 11.0Common7PackagesDebugger"

"Steven Bone", thanks for the question. Someone from the debugger team will be following up here shortly.

"Frustrated", thank you for the feedback, and I'm sorry to hear of your frustrations with Visual Studio 2008 and Visual Studio 2010. We welcome your input, and at the same time we'd appreciate it if your future responses could avoid name calling… we love having open discussions and dialogues, but such conversations need to remain respectful. Regarding bugs, are there particular bugs that are concerning and frustrating you? We have the connect.microsoft.com site specifically so that you can share your feedback on such issues in order to help us improve the technology, and for Visual Studio you can use the site at connect.microsoft.com/VisualStudio. We do spend considerable effort on testing and on compatibility for all of our development tools.

Thanks, Stephen! One thing I haven't been able to find is the 'official' forum for discussing the Visual Studio 11 preview… Is there a specific place that is better suited for these types of questions/potential issues?

The good news is that we are replacing autoexp.dat with something better. I've responded in more detail to your question on the VS forum. I will also respond on that forum as we make more information available.

I think that Microsoft should vigorously pursue to extend the .NET language to support client side scripting, web pages styling and rendering and integrate everything in just a single language: C# , removing all together JavaScript, CSS, and HTML.

CSS, HTML an JavaScript: these languages will introduce new bugs, lexical differences, logical inconsistencies, to the new programming metaphors, making programs more difficult to develop, maintain and debug.

It is absolutely necessary, given the increasing influence that these technologies are having today and will have tomorrow, in a wide range of activities( economical, scientific,etc) to converge to a more homogeneous programming context:

Are there any plans to have more intelligent Javascript dependency checking in VS2011? Right now we have to use /// <reference…> in our JS files, and inside the code infront/views we have to manually add script tags.

The biggest feature for me would be some kind of background compiler for your Javascript, so you received warnings of possible problems – a bit like JSLint does right now.

All syntax errors and strict mode violations (if you're using strict mode) within opened JavaScript files will be reported to the Error List window.

Regarding intelligent dependency resolution:

If you open a JavaScript file within a Windows 8 application project, we will look to see whether there are any HTML files within the project that have a reference to it (via a <scrip> tag). If there are, we will gather a list of all other JavaScript files that are also referenced by those same HTML files. That list of JavaScript files will then be automatically referenced for you, which will give you IntelliSense without having to add any explicit <reference> comments to your file.

Let us know if you have scenarios that aren't properly satisfied by the above features.

Is it a Browser specific intellisence? Does it allow to choose target browser and suggest code?

Many times, when working with JS, developers find lot of issues on specific browser / version. If that feature is included, it would be great. If not all, it should at-least suggest for different IE versions in notmal/compatibility modes.

You know, I think you guys should work in LINQ capabilities to the immediate window you already have. Some of these new features are pretty nifty, I admit, but I think making the IDE work with the languages you're already pushing would be a nicer way for us to enjoy the products we spend so much on.

@Matt – Thanks for the feedback regarding better LINQ support in the immediate window. In general, we see the need to improve language support, especially for LINQ, in all our debug windows and the immediate window. There are a number of limitations with the immediate window today. For instance, it doesn't allow multi-line statements well, which ends up being pretty key for query experiences and lambdas. To improve that experience, we're exploring a feature called C# Interactive, which you can download a preview of that work today through the Roslyn CTP at http://www.msdn.com/roslyn and install for Visual Studio 2010 SP1. So far, C# Interactive only supports a subset of the C# language, but it does support lambdas and extension methods (not queries yet). You can use it for design-time exploration, and seed the context from a project (see the Seed Context from Project walkthrough here: msdn.microsoft.com/…/hh543924).