In-Depth

What's New With Visual Studio 2005

S. ''Soma'' Somasegar, corporate VP of Microsoft''s Developer Division, talks about the different skews available to Visual Studio 2005 developers. Read Part 1 of this interview.

• By Patrick Meader
• 11/07/2005

S. "Soma" Somasegar, corporate vice president of the Developer Division at Microsoft, talks to VSM Editor in Chief Patrick Meader about the imminent release of Visual Studio 2005. In part 1, Soma discusses the different skews available to developers, the design process that led to choosing VS 2005's specific features, and the differences between C# and VB. Read Part 2 here.

PM: There are about 10,000 new skews for the next version of Visual Studio 2005, exaggerating only slightly. What motivated your general approach in designing the skews for Visual Studio 2005?

Soma: One of things we determined early on as we thought about what became Visual Studio 2005 and what we wanted to accomplish is this: We wanted to always bear in mind that the developer is our customer. Previous to Visual Studio 2005, we always thought: A developer is a developer is a developer. We want to build a great set of tools for the developer, and this will make him happy.

As we started to think about Visual Studio 2005, we had a realization. A developer is a developer is developer, but different kinds of developers have different requirements. For example, a person who is entering the field of programming, a hobbyist, or would-be developer has a different set of expectations and requirements from someone who is a professional developer, or from someone who is customizing Office, or from someone who is working in an enterprise environment with a team of developers.

So we decided to build a set of tools that is targeted at each major segment of the developer community. We wanted to make sure that we enabled the right set of experiences for each developer segment. So if you look at the skew platform for Visual Studio 2005, I call it the Russian doll skew platform. It's all about enabling personalized productivity with a set of products based on how you actually use a developer tool.

PM: Walk me through the main skews, what they consist of, and who they are for.

Soma: The Express skew targets the hobbyist or beginning developer; the Standard edition targets the person starting to get into the .NET programming world. This person is often the classic VB developer or the classic ASP developer. The Professional edition is targeted at the professional developer. This person is typically working by himself or with one or two other people. We also have the Visual Studio for Office skew, which is targeted toward people who want to do application customization on Office. Finally, we have Visual Studio Team System, which is targeted at teams of software engineers coming together to create software applications.

PM: Various versions of Visual Studio 2005 have been available in CTPs for a couple years now, which can take the edge off the excitement for a newly released tool. I think the CTPs are great on the whole for developers, but how do you reinvigorate interest in the tool in this circumstance?

Soma: I disagree with the premise of your question. The fact we've been open and transparent with giving people early bits, with getting their feedback so we can make the product better—I think excitement has intensified because of this practice. I don't know how much you follow the blogging community, but recently I posted a simple message that we are done, and the response to that post is huge. To me, the excitement over the release of this tool is almost palpable. A lot of developers know enough about this tool in advance of its shipping that they are excited to be able to use it in production. They don't know the features as some kind of abstract list; they've used the features. They know precisely what they are getting.

We will continue to step up our openness and transparency, and I think this will continue to make the product releases that much more exciting.

Integration With SQL Server 2005
PM: This release is often referred to colloquially as the Yukon/Whidbey release of Visual Studio. How deeply is SQL Server integrated into Visual Studio 2005, and what are some of the specific ways that a developer will notice this integration?

Soma: SQL Server 2005 is integrated directly into the Visual Studio IDE, and we've taken several steps to ensure that it feels like SQL Server 2005 is another tool in the Visual Studio 2005 arsenal. A SQL developer will see all the benefits of the .NET environment. The integration that we've done enables SQL to host the CLR in-process, which confers advantages such as memory management, garbage collection, and everything else you get with the .NET environment. You get them for free as a SQL developer in SQL Server 2005. This version also gives you the ability to write your SQL stored procedures in one of the native .NET programming languages, whether C# or VB.NET.

PM: Visual Studio 2005 is quite vast, in terms of the tools and technologies it provides you with to implement your solutions. For example, you might find yourself programming against a combination of ASP.NET, ADO.NET, SQL, XML, WSE—pick your alphabet soups of choice. Is a programming language much more than glue for tying together various objects and message services?

Soma: The answer to that is two-fold. First, the programming languages do indeed get richer and richer. At the same time, you want to maintain the simplicity of the programming language so that the barrier to entry for programmers doesn't get astronomically high. What we want to do between design time and run time is take the common scenarios that people care most about, and wire Visual Studio together in a way that you don't have to write a lot of new code to be able to take advantage of the common functionality people care most about.

You might be a Web developer, or you might be a smart-client developer. For some common scenarios, you will find that you can create the same solution in 50 percent less code using Visual Studio 2005 vs. 2003. What your question highlights is the way we're trying to raise the productivity bar for developers.

PM: A lot of developers—and I'll confess, editors too—are skeptical whenever we see numbers like a 50 percent reduction in the code. Tell me a couple of the common scenarios where you might experience a drastic reduction in the code you have to write.

Soma: If you use PowerPoint, it's easy to create a master slide template that flows through every slide in a presentation. Wouldn't it be nice to create that same kind of template across your Web site? ASP.NET 2.0 in Visual Studio 2005 provides precisely that kind of ability. Previously, implementing that kind of solution required that you write a lot of code. Visual Studio 2005 includes the Master Pages feature. After you create this page, it flows through all the rest of the pages of your site. The end result is much less code, much less maintenance, and greater productivity.

If you're interested in personalization or security, we've encapsulated much of the work required for these in the form of controls that you can use right out of the box. Again, using these controls drastically reduces the amount of code you have to write.

PM: Visual Studio (and Visual Basic before it) is justly heralded for introducing interface tweaks and other improvements that, apart from the language you use, simplify the practice of creating code. For example, IntelliSense and edit-and-continue weren't really language features, but rather environment features that improved the developer experience. What new tweaks to Visual Studio 2005 in this vein will developers be excited to learn about?

Soma: Code snippets are a great example of this kind of improvement. Assume you want to add sound effects to your application. I can guarantee that 1,000 other people have done this before you, which makes you wonder: Is there any way to leverage already existing code, so you don't have to create it from scratch? It might be code you've created before; it might be code other people in your company have created; it could be code that people in the community have done. We anticipate this will create an environment for prepackaged solutions that you can use to save you a lot of time and effort. We also anticipate it will help foster a greater sense of community among developers, as people share these.

Another feature I think people will appreciate is VB's support for My Classes. This feature gives you easy access to important classes and features in the .NET Framework.

Does Language Matter?
PM: At VSM, we're officially language-neutral. We don't care which Visual Studio language you use, as long as you read our magazine. To what extent does language matter?

Soma: Here is how I think about it. You get the choice to speak the language that you want to speak. To me, one of the key advantages of .NET is the way it democratizes programming languages. At Microsoft, we want to be language-agnostic. Whether you want to use VB, or C#, or Cobol, or Python, you can do so. Obviously, we put most of our effort into a couple languages, but the community itself is free to add other languages on top of the .NET Framework, and it has done so in a significant way.

PM: Is there an archetypal user for VB or C#?

Soma: We don't have an XYZ developer archetype as we're creating languages, per se. One of things we do have is the notion of a persona. These personas aren't specific to a language, but to the task you're trying to solve. One of the top-level things we want to keep in mind as we develop Visual Studio are the scenarios where people are going to use it, and provide a tool that helps them do so quickly and easily. If someone wants to build a data application, what features will facilitate that? If someone wants to build a connected system application, what is the thought process for doing so, and how can Visual Studio assist that?

We think about the scenarios we want to enable, then consider how we can enable supporting those scenarios in terms of specific language features and functionality.

PM: Obviously, it was important to incorporate generics into Visual Studio 2005. Why was that?

Soma: We just see it as a particularly powerful feature that our user base wanted. But we also saw a way to implement it in a way that overcame some of the shortcomings of generics in other contexts.

For example, there has always existed the notion that your code would get broken when dealing with templates. In a program, if you're trying to create a specific piece of functionality, [using] generics means you can collapse it at design time. But what used to happen is that the code would break as you tried to reuse the functionality you'd created. What we've done in the CLR (and particularly in C#) is to make sure that that code break doesn't happen.

PM: What is the next step in the evolution of Visual Studio from a productivity standpoint, particularly from the perspective of, for lack of a better term, the classic Visual Basic developer whose emphasis is on raw rapid application development?

Soma: One of the big things that we're looking at is Language Integrated Query (LINQ), which we talked about at PDC. What we want to do is simplify the process of how you do queries, XML, and data from within the programming language itself. This is going to be a big step forward in terms of how we bring the data and programming worlds together.

PM: One of the interesting things about the development of Visual Studio 2005 is the way the features initially intended for C# or VB specifically ended up in both languages. For example, VB got its own implementation of generics, whereas C# picked up edit-and-continue after the users of these languages requested the ability to use these features from within the languages they prefer to use. Would it be fair to say that, outward appearances and prejudices to the contrary, the people who use Visual Basic and C# are more alike than is commonly supposed?

Soma: I think about it this way. The programming experience is different if you use Visual Basic or C#. But the kinds of solutions that people want to implement are probably quite similar. So, when we're working on Visual Basic or C# (or really, any other developer-related tool), we try to expose things in a way that matches the experience the developers using a particular language or tool want to have.

PM: Are there features that you developed for C# or VB that you didn't share across, not because you couldn't, but because they went counter to the positioning of the tools?

Soma: We just don't approach things from that kind of perspective. For example, with My Classes, we thought it made great sense for the VB developer, but not so much for the C# developer. So, we thought: Let's implement that in VB. But if enough C# developers come back to us and tell us, "this feature is absolutely critical for us," of course we'll try to accommodate them. What we're considering is whether a particular experience makes sense for the user of a tool or language, and from there we try to think of the best way to enhance that experience consistent with using that tool or language.