Look Into the Future of VS.NET (Continued)
What the Future Holds
PM: Given that the .NET languages sit on top of the same framework, how many and what kinds of differences can we expect to see between VB.NET and C# in Yukon and beyond?
ER: It's hard to say. We look at each functional thing that we do and we talk about whether there should be equivalence. For example, we discuss whether adding a new feature to a language actually benefits the language or complicates it needlessly. If all languages were functionally equivalent, then we might have the same principles everywhere, but with different syntax. Yet somehow languages do really feel different. I don't think it's merely a matter of syntax. We're committed in VB to finding the right VB way; we're committed in C# to finding the right C# way. We want things to feel natural and comfortable, regardless of which language you use.
We'll be putting betas out there of key new features, and I'm sure we'll get lots of feedback from the community that we should add this feature to that language, and so on. But there will be differentiation over time in the languages. There will be features VB.NET has that C# won't, and vice versa. I don't think that's a bad thing. We do need to make sure that all languages can take advantage of the framework as we evolve it. One feature of interest right now is generics. What happens if we add generics and the framework itself starts to use generics? Then we need to change the definition of the CLS, and make sure that all languages that are CLS-compliant can consume generics. We're committed to implementing these types of changes across all CLS languages.
PM: You've synched the release of Everett, the next version of Visual Studio .NET, with the upcoming release of Windows Server 2003. What was the strategic point of linking these two products, and how will it benefit developers?
ER: The main purpose of linking the tools to the platforms is that we want the tools to enable the developer to maximize the value of the platform. There's some nice value in how you deploy applications on Windows Server 2003. There's a nice Application Center profile there that enables you to deploy applications securely by default. There are some nice features supporting Web services, such as the fact that Windows Server 2003 ships with a built-in UDDI server. The tools and the platforms are complementary. They ship with the same version of the framework. Our tools strategy is to support our team platform releases, be it Windows Server 2003 or SQL Server Yukon or Longhorn after that.
PM: Does Everett rely on any functionality specifically in Windows Server 2003?
ER: No. Everett will create solutions for Windows 2000 Servers, Windows 98 clients, and so on. It supports everything Windows Server 2003 offers, but doesn't require it.
PM: Everett is more of a point release for VB.NET and C#, but Microsoft is promising a major upgrade for the Yukon release of VS.NET, which will be synched with the Yukon release of SQL Server. Does this mean developers will be able to write stored procedures using VB.NET or C#? If so, what is the advantage of being able to create your database functionality in C# or VB.NET?
ER: Yes, it does mean that developers will be able to write stored procedures using their language of choice. What's the advantage of that? Well, for one, it's the language of your choice. It's all about leverage. My VB is a little better than my T-SQL. And so, you'll be able to leverage what you know. It's just another tool for developers to take advantage of. If you like using T-SQL, you can continue to do so. It also means you'll get a better development experience overall. You'll get better debugging for your stored procedure. You'll also be able to take advantage of better source code control. VS.NET's integration with SQL Server is going to pay off in several areas that will make development easier and more productive.
Back to top
|