What the heck is "VBx"?

There was a semi-announcement as a part of the Silverlight 1.1 discussion at MIX07 yesterday that people might be wondering about.

If you check out the Silverlight poster that Brad posted a pointer to, you’ll see that on the right hand side under the box that says Framework Languages, there are TWO listings for Visual Basic. First, there’s “Visual Basic” and then down at the bottom there’s a “VBx” with a little icon “Soon.” Then, if you look at Jim Hugunin’s blog entry on the Dynamic Language Runtime (DLR), you’ll see that he says (emphasis mine):

We’re initially building four languages on top of the DLR – Python, JavaScript (EcmaScript 3.0), Visual Basic and Ruby. We shipped today both Python and JavaScript as part of the Silverlight 1.1alpha1 release today. John Lam and I will be demoing all four languages, including VB and Ruby, working together during our talk tomorrow at 11:45.

And then if you go on to Jason Zander’s blog entry on .NET Framework support in Silverlight, he says (again, emphasis mine):

With the new DLR, we have support for IronPython, IronRuby, Javascript, and the new dynamic VBx compiler.

And, finally, you can go to Amanda Silver’s entry on what the MIX07 announcements mean for the VB developer to get a few more hints.

So, what does this all mean, exactly? What is this “VBx” thing? What are we up to?

Well, as I’ve been hinting at for a while now, there’s been something I’ve been working on quite a lot in recent months that I couldn’t talk about. With our announcements at MIX07, though, I can now take a bit of the wraps off. “VBx” is our current (subject to change) codename for the next major version of Visual Basic. (The “x” is supposed to signify the Roman numeral X, or 10, since the next major version of Visual Basic is going to be 10.0. The “x” really should be capitalized, but some people were worried there’d be confusion with the old VBX controls. Not that the search engines are really going to draw a distinction. Like VB itself, they’re mostly case insensitive.)

Now, at this early stage of the game, the full shape of the next version is sketchy at best. We’re not done with Orcas by any stretch of the imagination. We haven’t even started the formal planning for process for anything beyond Orcas yet. However, there are several features that we are clear, even at this early stage of the game, that we are going to want to support in the post-Orcas timeframe:

  • Visual Basic should become a hostable language that can be easily used to do application scripting, akin to what you could do with VBScript and VBA. Furthermore, this hostable language engine should be fully portable to all platforms supported by the CLR, including all platforms supported by Silverlight (such as client-side scripting in the browser on a Mac…).
  • The performance of dynamic binding (a.k.a. late binding) should be as close to static binding as humanly possible.
  • Dynamic method and type generation should be fully supported and consumable in the language.
  • Visual Basic should fully support a REPL (Read-Eval-Print Loop). This means taking the support we already have for a REPL in the immediate window in VS and both extending it to the full language and adding the ability to host the REPL outside of Visual Studio.

If you look at this feature list, much of it is congruent with the mission of the Dynamic Language Runtime (DLR). Consequently, we’ve been working very closely with the DLR team to start prototyping many of these features in Visual Basic. If you were at the MVP summit or went to Jim and John Lam’s talk at MIX yesterday, you’ll have seen this prototype–which, again, we’re calling “VBx” for the moment–in action. Amanda and I will be working on some screencasts and other stuff to show this to the world in the near future, but it is, in essence, the fusion of the Visual Basic language services and the DLR. This gives us many of the features listed above, and more. (For example, because VBx is built on top of the DLR, it automatically interoperates with any other dynamic language built on the DLR. So VBx code can interact seamlessly with libraries written in Python, Javascript, or Ruby, and those languages can interact seamlessly with code compiled by VBx.)

As excited as we are about VBx, it is, unfortunately, not part of the Silverlight 1.1alpha1 released yesterday. Although we have a significant amount of functionality already implemented there is still more work to be done to bring the VBx language support up to the level that we feel is necessary for a productive community preview. Our plans are to have a community preview out later this year, and to talk much more detail about VBx at PDC07. In the meantime, though, we will be discussing VBx here on my blog and on the VB team blog, so keep your eyes peeled!

24 thoughts on “What the heck is "VBx"?

  1. Pingback: Wooley's Wonderings

  2. Pingback: Scott Hanselman's Computer Zen

  3. Pingback: Mike Taulty's Blog

  4. Pingback: StrangeLog - Il blog di Andrea S

  5. Pingback: Anders Norås' Blog

  6. Peter {faa780ce-0f0a-4c28-81d2-3

    Why would you create a new hosted VB language when you can use PowerShell instead? I know PowerShell may not currently have everything you need right now, but is there any reason why you can’t build on their existing platform instead of creating a competing language? From your description it sounds like there is a lot of overlap between VBx and PowerShell.

    Anyway, as a large PowerShell fan, I’d be interested in hearing about this.

    Reply
  7. lb

    >"From your description it sounds like there is a lot of

    >overlap between VBx and PowerShell. "

    i’m thinking that vbX might be just a pre-compiler that converts Begin and End into "{" and "}" and sends the result to powershell to do the heavy lifting.

    Just kidding — but there does seem to be a lot of deliberate redundancy going on.

    Unless every possible syntax is accounted for, it’s conceivable that some developer out there might choose to use a technology other than those created by microsoft…

    Hopefully the fortran.net compiler running on the commodore 64 emulator of my web-enabled IPod will soon have a REPL too.

    Best of luck Paul!!

    lb

    Reply
  8. Pingback: SteelePrice.Net

  9. Pingback: ??? ???

  10. Pingback: Greg Robinson's Blog

  11. Pingback: DonXml's All Things Techie

  12. Pingback: Joycode@Ab110.com

  13. Pingback: Wooley's LINQ Wonderings

  14. Pingback: Beth Massi - Sharing the goodnes

  15. Pingback: random ramblings....

  16. Pingback: Panopticon Central

  17. Pingback: Jon Galloway

  18. Pingback: The Visual Basic Team

  19. Pingback: Noticias externas

  20. Pingback: Panopticon Central

  21. Pingback: Blogs

  22. Pingback: Mike Taulty's Blog

  23. Pingback: got net?

  24. Pingback: Anonymous

Leave a Reply

Your email address will not be published. Required fields are marked *