DBActive

WARNING: This is a speculative post. Caveat emptor.

One of the things that we’d like to address in the next version is line continuations. We know that they tend to annoy many developers who want to break their logical lines across multiple physical lines, and we’ve gotten many requests to get rid of them altogether. Unfortunately, there’s a reason we haven’t just dropped them–they actually are needed in certain scenarios. For example, take the following contrived example:

    Sub Main()
    End _
    Sub

If I remove the line continuation, I’ll now get a compile error because “End” now is the “End” statement, and the Sub looks like it’s trying to start a new subroutine in the middle of the current subroutine. There are quite a few of these syntactic ambiguities sprinkled throughout our grammar, some of which might be quite obscure and unnoticed until someone’s code actually broke. So instead of taking a maximalist approach and trying to remove the line continuation everywhere, we’ve been thinking about a more minimalist approach and looking at where removing the line continuation might be most useful. This produced a much more tractable list of places where we might productively remove the line continuation. In particular:

1. After binary operators in expression contexts. Note that this does not include assignment operators. For example:

   a = b +
       c

2. After the following punctuators: comma (”,”), open parenthesis (”(”), open curly brace (”{”), begin embedded expression in XML (”<%=”). For example:

   Console.WriteLine(
       “{0} {1}”,
       FirstName,
       LastName)
   

3. Before the following punctuators: close parenthesis (”)”), close curly brace (”}”), end embedded expression in XML (”%>”). For example:

   Console.WriteLine(
       “{0} {1}”,
       FirstName,
       LastName
   )

4. After an open angle bracket (”<”) in an attribute context, before a close angle bracket (”>”) in an attribute context, and after a close angle bracket in a non-file-level attribute context (i.e. an attribute that does not specify “Assembly” or “Module”). For example:

       <
           Conditional(“Foo”),
           Conditional(“Bar”)
       >
       <
           Conditional(“Baz”)
       >
       Sub Main()
       End Sub
   

5. Before and after query expression operators. For example:

   Dim ys = From x In xs
            Where x > 5
            Select
               ten = x * 10,
               twenty = x * 20,
               thirty = x * 30

One thing that is not currently on the list is allowing an implicit line continuation after a dot, so you couldn’t break up “a.b.c” implicitly. It’s not that we can’t do dot, just that it’s quite a bit more expensive and problematic for Intellisense. We’d be interested to hear if this is something people really want to/need to do, or if it’s just a nice-to-have.

Are there any other places that we missed that you can think of?

WARNING: This is a speculative post. Caveat emptor.

Several weeks ago, I gave a presentation entitled Bringing Scripting (Back) to Visual Basic at the Lang .NET 2008 conference. A video of the presentation has now been posted, so you can check it out for yourself. (The presentation was also covered by EWeek in an article entitled Bringing Sexy Back to Visual Basic.)

The main theme of the presentation is the same one I’ve been talking about on and off over the past year or two: moving Visual Basic back towards it’s scripting roots. The main thrust of this presentation was the technical side of the story–namely, what we would need to do to the existing Visual Basic compiler to be able to effectively use it as a scripting engine. The presentation talks some about the way the compiler is structured, how it might change and some of the things were thinking about enabling. In particular, what we’d like to see is not just that Visual Basic can be embedded anywhere, but that all the services that the compiler provides–parsing, semantic analysis, code generation–are available to be used by any program that needs them. The DLR is a key part of this, but there’s a lot of work on top of that.

I also showed some fun demos of some prototypes that we’ve whipped up using our current codebase. Nothing we’re committing to at the moment, but it gives you some of the flavor of what we’re thinking about.

One thing this presentation didn’t cover (and which Ted Neward brought up in the Q&A afterward) is what we might do to the language itself to make it more scripting-friendly. That’s an area where things are less well-defined and even more speculative than what I talked about, so I left it out for now. Maybe soon I can talk more about it…

A month or two ago, Paul Yuknewicz and I sat down to record a Hansselminutes podcast with Scott Hanselman, talking about the past, present and future of Visual Basic. It was a lot of fun, check it out!

Also, here’s a little holiday love for VB from some Microsofties you might recognize:

I wanted to let people know that an (almost) final VB 9.0 language specification has been posted on the download center. The spec is missing some copy-edits from the documentation folks, but is otherwise complete. Since I’m not going to get a chance to incorporate the copy-edits until I am back from vacation in January, I wanted to get the spec out there for anyone interested in documentation of the XML features that weren’t present in the previous version of the spec. (I apologize for the lateness of this vis-a-vis the release of the product itself, it’s been a busy fall.)

This updated language specification corresponds to Visual Studio 2008 and covers the following major new features:

• Friend assemblies (InternalsVisibleTo)
  
• Relaxed delegates
  
• Local type inferencing
  
• Anonymous types
  
• Extension methods
  
• Nullable types
  
• Ternary operator
  
• Query expressions
  
• Object initializers
  
• Expression trees
  
• Lambda expressions
  
• Generic type inferencing
  
• Partial methods
  
• XML Members
  
• XML Literals
  
• XML Namespaces

Questions, comments or criticisms can be sent to basic@microsoft.com. Thanks!

Oh, yeah, that’s right. We shipped. Hard to believe we’ve finally reached the finish line…

Most everyone who”s steeped deeply enough in the culture of Visual Studio has probably run across some mention of Mort. Mort is one of a triumvirate of personas that the Visual Studio team uses to describe the developers that they are targeting. The other two members of this group are Elvis and Einstein. (I got complaints from internal people the last time I mentioned the personas, so let me take a moment to say that they are open knowledge.) Love them or hate them, the personas have become an integral part of the way that many people talk about VB, C#, and C++, both inside and outside the halls of Microsoft.

There is a problem, though. Let me illustrate, if I may. First, here”s Einstein:

A bit of a card, to be sure, but generally a pretty brilliant guy. Sure, he”s spent most of his life chasing some crazy theory of unification, but overall he”s the go-to guy when you”ve got some rocket science project. And, of course, he”s the one claimed by the C++ folks. (Since you pretty much have to be a rocket scientist to fully grok C++…)

Next, we”ve got Elvis:

OK, so maybe Elvis”s best years are a little bit behind him and he”s just been coasting on his youthful talent. And, yes, maybe he”s been hitting the corn dogs a little bit too hard. But, c”mon… He”s Elvis, for heaven”s sake! The King! Maybe you don”t call him if you want to go to the Moon in a rocket, but if you want to entertain a stadium”s worth of rabid, screaming fans who won”t notice he”s, um, a little overweight, he”s your man. And, of course, he”s claimed by the C# folks.

Now, we finally come to Mort:

Hmmmm. Well. Yes.

Now, I should say that this is not the way that I think of Mort. Or that this is the way that our team thinks of Mort. To me, Mort is a smart, pragmatic guy who”s more interested in rolling up his sleeves and saving the world than sitting around noodling on some unified field theory or eating copious amounts of doughnuts. But to a large slice of the world who have an opinion about Mort, this is who they see. A toothless, unkempt hillbilly who”s best kept up in the mountains of West Virginia and away from all nice and normal folks.

And, of course, he”s the one claimed by the VB folks. He”s us. See the problem?

Personally, I think it”s time to let go of the Mort persona. Send him a nice fat check, a referral to a good orthodontist, and thank him for his hard work. And in his place? Well, I”d like to propose hiring this guy as our new persona:

Ben, as I”ll call him, is a pretty pragmatic guy and a bit of a polymath, a jack-of-all-trades. In between a writing and political career, he also finds time to be a postmaster, a publisher, a scientist, and an inventor. In short, he does what most VB programmers do: he multi-tasks like crazy, solving problems wherever he goes. (More information about Ben can be found here, for those not steeped in American history.) Now, sure, Ben”s not some rock star like your average George or Thomas is, getting all the attention with flashy military or political antics, but he”s really your guy when you need something done, you need it done right, and you need it done with a minimum of fuss and bother.

Doesn”t Ben sound like a wonderful persona for VB?

Of course, when it comes to product planning stuff like this, what I think doesn”t really matter a hill of beans. I”m sure there”s no getting rid of Mort, no matter what some people may think of him. But we can dream, can”t we?

One piece of conventional wisdom that I hear now and again is that “nobody uses Visual Basic.” When someone’s giving a talk and asks people to raise their hands if they use VB, they say VB’ers are in the minority. In the buzz-o-sphere, Visual Basic seems to be only discussed when debating whether some other language is the “new” Visual Basic. Even Microsoft has been accused on occasion of seeming to favor C# over VB in things like samples or documentation.

We were having a discussion internally about this piece of conventional wisdom and whether the numbers really backed this idea up. And they don’t. If you look at some of the numbers:

• Visual Basic is the #1 .NET language (as reported by Forrester Research)
• Visual Basic is the #1 downloaded and #1 registered Express Edition (topping the #2 position by 20%)
• Visual Basic is the #1 MSDN language dev center and blog in terms of traffic
• The Visual Basic Team blog is in the top 1% in readership of all MS bloggers (I don’t know where I fall in that since I host independently.)

All this points to a large “silent majority” of VB users out there who simply go about their work day after day yet don’t make a splash in the places that some people seem to think are the ones that matter (i.e. conferences, blogs, etc.)…

While I was visiting MSR Cambridge this week with some other people from Redmond, Beth put up the Beta 2 version of the Visual Basic Language specification on our developer center–so she got to beat me to the announcement! This updated language specification corresponds to Visual Studio 2008 and covers the following major new features:

• Friend assemblies (InternalsVisibleTo)
• Relaxed delegates
• Local type inferencing
• Anonymous types
• Extension methods
• Nullable types
• Ternary operator
• Query expressions
• Object initializers
• Expression trees
• Lambda expressions
• Generic type inferencing
• Partial methods

The following features are not covered but should be shortly:

• XML Members
• XML Literals
• XML Namespaces

The XML features are a little more difficult because I’m debating how much I should just refer to the XML 1.0 spec, versus how much I should specify explicitly. I’ll probably err a little more on the side of the latter, since it’ll be necessary for understandability…

WARNING: This is a speculative post. Caveat emptor.

I know that I’m running a great risk of touching the third rail of the VB community by even speculating about this, but it seems like the right time to have a bit of a conversation about the big “D”-word.

That is, deprecation.

Yes, deprecation. Now before anyone starts freaking out, foaming at the mouth or writing a petition, let me emphasize that my thinking along these lines is entirely within the guidelines discussed in the language specification, which mandates a long and gradual process of deprecation that involves continuing to support the deprecated feature for a reasonable period of time. The guidelines also state in part:

…feedback must be solicited from the user community on deprecation of the feature and full notice given before any final deprecation decision is made. The deprecation process may be reversed or abandoned at any point based on user community feedback.

So I’m really just floating some personal trial balloons here. After all, it’s now been almost three major releases since the big move to .NET, and I think it’s started to become clear that some of the features we carried forward are a bit, uh, underused. In the interest of paring down the language specification just a bit in it’s inevitable march towards more and more pages, I’ve been pondering the question: “If I was going to deprecate parts of the language that don’t seem to be used, what would I deprecate?” I’ve come up with a few candidates that seem pretty safe:

• Type characters. Yes, we still allow you to say “Dim a$”. So far as I have ever seen, no one uses them anymore. It would be nice to reclaim a bunch of characters at some point in the future, and it would be relatively easy to include error corrections to fix this up.
• Copying of boxed value types. I’m not even sure I could explain this in a bullet point. If you read section 8.6 of the language spec, Value Type Conversions, it’ll discuss this a little more detail. I think this is counterintuitive behavior for most people and is incomplete in any case. The only real question here is: are there programs that depend on this behavior? We’d need to think/talk a lot more about it before we could even consider this one.
• Mid$() assignment. Bet you didn’t know you could even do this, did you? See section 10.6.3 in the language spec for more on this.
• End statement. I’m curious if this one is still used by people, especially now that most frameworks like WinForms and WPF have Application objects that have a proper Exit/End method. If this one is popular, it might not fly as deprecatable.
• Erase statement. I’ve found that ReDim is actually still fairly useful as a shorthand way to redimension an array. However, Erase is completely useless–you could just replace it with an assignment to Nothing and you’d get the same thing.
• REM comments. Bet you didn’t know you could even do this one either, did you? There’s something nostalgic about it (Erik Meijer loves them), but, really, who uses them anymore?

You’ll note that I’m only including things here that I think are truly not used much or not useful. There are things I think some people would like to see disappear (like, say, On Error), but are still being used heavily enough to make them be not reasonable candidates.

I’m curious what’s people’s feelings about this are. Does this just bring up bad memories? Are there other candidates you’d throw on the list? As I said, at this point, I’m just talking. Depending on the reaction, the next step would be to look a little more formally at it in the team…

WARNING: This is a speculative post. Caveat emptor.

Last week, one of the VB MVPs asked on a private alias what our thinking was about VB10. As I kind of indicated in my previous entry, I don’t think we have a clear idea yet of what’s going to be on the table for the next rev—VB 2008 was kind of an aberration in that LINQ was in gestation long before VB 2005 even shipped. But I can say what’s at least on my mind:

• Hosting or, more generally, opening up the compiler services to the outside world.
• Decreasing lexical “noise” when looking at VB code.
• Increasing the extensibility of the language so that it takes less work to extend the language and can be done by libraries (Ruby is an example of what I’m thinking of here, but only a general example).
• Addressing UNDONE tasks from Orcas (object initializers, statement lambdas).
• Addressing persistent annoyances (line continuations is a good example here).
• Addressing whatever else comes up from the community as we release VB 2008.

I know that I’ve already added the usual caveats above, but I want to make double clear this is just what’s on my mind at the moment—in other words, things that I’m personally thinking about. These are not official team priorities, planned for the next rev, or anything like that. The next version could look radically different than the list above. I should also add that I mostly think about the language, so that’s why this list doesn’t talk about the IDE.

I’d be interested (in keeping with the last bullet point) what people might be specifically in for the next release. What’s at the top of your list these days?