Monthly Archives: May 2007

Check out Project Jasper…

One of the other announcements from MIX was “Project Jasper,” which is (in the words of the guys who wrote it):

[…] a set of components aimed at fulfilling the need for a rapid and iterative development experience for data. With Jasper, you are able to just point at a database and immediately begin coding against its data using intuitive, domain-specific data classes. No configuration and no source code generation are required. Jasper works with existing application frameworks (including ASP.NET, WinForms, and WPF) and existing, real-world databases.

One of the ways that Jasper does it’s “point and code” magic is through dynamic generation of entity types based on the shape of the database it’s pointed at. Since the types are dynamically generated, you can only do late binding against them, so VB is the primary language that Jasper works against in Visual Studio. This would also be a perfect scenario for dynamic interfaces, a feature that was slated for Orcas but did not make it (more on that soon), sadly.

I’d encourage anyone interested to check out the announcement and the initial CTP!

After MIX, how many Visual Basic languages are there?

One. Just one. VBx is the next version of Visual Basic, not a new version of Visual Basic.

Part of the confusion stems from the fact that there are TWO ways you can use Visual Basic in Silverlight, and one uses Orcas and one uses VBx. So let me see if I can clarify a little bit…

As everyone should be aware now, Silverlight is a cross-platform version of the CLR. This means that Silverlight, with some limitations, can run any compiled IL application or library that the desktop CLR can run. This also means that (again, with some limitations) Visual Basic applications or libraries that have been compiled into IL on the desktop can be downloaded and run on Silverlight. If you go and read Joe’s VB on Silverlight entry, he points you to how you can do this today–build a VB application or library using Orcas Beta 1 and then run it on Silverlight.

You’ll notice that what you have to do in this scenario, though, is compile your application or library on the desktop and then run it in Silverlight. You can’t take your application or library in source code form, send it to Silverlight and have it compiled on demand within Silverlight itself, because the Orcas Visual Basic compiler isn’t a part of Silverlight. So, for example, if I was to embed a Silverlight application in a web page viewable on the Mac, I have to build my libraries ahead of time and deploy them to the web server to be downloaded when someone hits the page.

What John and Jim demoed, and what the DLR enables, however, is a second scenario. Because the DLR is managed code, it can be run directly on Silverlight. This means that you can actually get a running instance of a DLR language within Silverlight itself. So instead of having to compile an application or library before you can use it in Silverlight, you can simply include the code as a part of the Silverlight application, and the code can be compiled by the DLR language on the fly. This enables the traditional style of client-side applications that you see in AJAX or other libraries. Instead of compiling the library ahead of time, you simply download the client code to the browser when it hits the page, and the code will be compiled and run within the browser in real time.

This is where VBx, the next version of Visual Basic, comes in. Part of VBx is a hostable managed component (written in Visual Basic, no less!) built on top of the DLR. Since Silverlight can host DLR languages, this enables you to send Visual Basic code to a Silverlight instance and have it dynamically compiled and run. So when the Mac hits your webpage, you don’t have to send a binary at all, you can send just source code. When you want to modify your application, you don’t rebuild, you just modify the source code sent to the browser and refresh the page and there you are!

The important thing to keep in mind is that there is still only ONE Visual Basic language but once VBx arrives you’ll have more than one way of getting to it. You’ll still be able to compile code into the traditional .DLL or .EXE, but you’ll also have the option of compiling and running the code on the fly, within a running instance of the CLR. That’s where things are likely to get interesting…

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!