Visual Basic 11 beta is out

Filed under .NET, Rants, VB Feng Shui

vs2010_iconlibrary

OK, It’s been a few weeks, so this is likely not “new” news, but still.

Looks like MS isn’t backing off on VB one bit, and that’s a good thing. Heck, as I understand it, there’s even a project in skunkworks build VB in VB! I’ve always said the mark of a complete language is when it’s actually written in itself.

But I digress. Back to VB 11. The VB Team website has a nice rundown of some of the high points of the release here.

 

 

 

 

To summarize:

  1. Async support. Meh. VB (actually any .net language) has always had this. The Async stuff definitely makes it easier, so I won’t complain too much. Personally, I’ve kind of gotten into the Javascript notion of lambdas for callbacks in support of async stuff. You can do that in VB, but lambda’s, being limited to single lines) haven’t been all that useful for it, up till now with….
  2. Multi-line Lambdas. That’s right, you can finally declare a Function()….. lambda that spans multiple lines.
  3. Iterators. Which basically means a Yield keyword that can fall out of an iteration loop to allow the iterating code to perform it’s work.
  4. Caller info. This is a big one for me. I’ve written more than my share of error logging/trapping/handling frameworks over the years, starting with VB3, on through VB6 and then into .net. Unfortunately, this feature has nothing to do with that!
    Caller info allows a function to easily and straightforwardly retrieve the Name, Line number or FilePath, of the calling function. While the Line number and Calling path are of dubious value, the caller name is incredibly powerful for things like front ending field accessors in data access libraries. Say you have a small function that retrieves a value from a VB, via a name. With this feature, you can easily create properties of an object that are named that name and then pass the property name down to the accessor function to retrieve the value.
    This has been doable for ever in .net as well (via the call stack), but was not straightforward and was susceptible to corruption if you used code obfuscators. No word on whether this feature will play better with obfuscators at this point, though.
  5. Call View Hierarchy. Looks like a very nice feature, but I’ll have to play with it more before making any concrete observations.
  6. Global Namespace. Another meh. On some projects, I could see this being handy. But it’s nothing to get too excited over. A very incremental improvement.

 

What’s missing

  1. Unsafe code. At least, I’ve seen no mention of it.
  2. Property-level scope. They added auto properties in VB10. Property-level scope seems like the next natural step for that. And by this, I mean:
    Public Property Name() as string
         Private _Name as string      <—– Property level scope
         Get()
                Etc
          End Get()
          Set ()
                Etc
          End Set
    End property

    EDIT: The suggestion that I posted to MS’s suggestion board ended up getting a comment from Lucian Wischik. You can read his full comments here.
    Property Scope Variables
  3. More Dynamic functionality, though you could argue that you can actually do quite a lot of dynamic stuff now in .net languages.

It’s good to see the language getting very close to parity with C#, and the news of a forthcoming VB.net coded compiler is even more exciting.

3 Comments

  1. Venkatesh says:

    This is a biased article. Author might have left VB6, now into C#. Someone who can compare feature by feature will be right.

    I agree Iterators and Yield are new but we have the whole world full of applications without those keywords.

    Agree Async is genuinely better than DoEvents.

    What comes what goes – VB stays…I love you VB.

    RV
    VB Since 1995.

    • Darin says:

      Hi Venkatesh
      Thanks for the comment. Not sure I quite follow, but your last lines “VB Stays, I love you VB” sounds great to me!

      If you’re saying MS’s article is bias, well, yeah, I’d expect so. It’s MS after all, and that’s an article from the VB Team Site.

      If you’re saying my article is bias, well, guilty as charged. I quite like VB. That’s not to say I don’t have anything negative to say about it, but still, I quite prefer it.

      I will amend my comments a bit. I got a response from Lucian Wischik about the property level scope explaining why they’d passed on it several years back (and why they likely will never implement it). He makes some very valid points. I still say it’d be a very nice option to have available, but I can also see his points.

      You can see his response here.

      http://connect.microsoft.com/VisualStudio/feedback/details/676318/property-scope-variables

      • Hi Darin, Point here is we can see missing VB templates in VS2013 in Universal Applications. This is one step more than missing VB samples. Was hoping Rosalyn is going to bridge gap. But it appears the bridging is for C# to catch up more.
        What if we form a team (or more people) and convert C# samples into native VB code that do not rely on C# to VB converters during beta of VB version? This way native VB code will have life.
        By the way VB written in VB appears to be a long story. When is it really coming? Isn’t it better to use Rosalyn as it is promising?
        My intention is not to say your article is biased. But to MS for forgetting VB.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*