Ted Neward is the Principal at Neward & Associates, a developer services company. He consults, mentors, writes and speaks worldwide on a variety of subjects, including Java, .NET, XML services, programming languages, and virtual machine/execution engine environments. He resides in the Pacific Northwest. Ted is a DZone MVB and is not an employee of DZone and has posted 50 posts at DZone. You can read more from them at their website. View Full User Profile

Dustin Campbell on the Future of VB in VS2010

11.25.2008
| 5253 views |
  • submit to reddit

Dustin Campbell, a self-professed "IDE guy", is speaking at the .NETDeveloper's Association of Redmond this evening, on the future ofVisual Basic in Visual Studio 2010, and I feel compelled, based on myearlier "dissing" of VB in my thoughts of PDC post, to give VB a littlelove here.

First of all, he notes publicly that the VB and C#teams have been brought together under one roof, organizationally, sothat the two languages can evolve in parallel to one another. I have myconcerns about this. Frankly, I think the Managed Languages team atMicrosoft is making a mistake by making these two languages mirrorimages of one another, no matter what their customers are telling them;it's creating an artificial competition between them, because if youcan't differentiate between the two on a technical level, then the onlything left to differentiate them on is an aesthetic level (do youprefer curly braces and semicolons, or keywords?). Unfortunately, themarket has already done so, to the tune of "C# developers make morethan VB developers do (on average)", leaving little doubt in the mindsof VB developers where they'd rather be... and even less doubt in theminds of C# developers where they'd rather the VB developers remain,lest the supply and demand curves shift and move the equilibrium pointof C# developer salaries further south.

Besides, think aboutthis for a moment: how much time and energy has Microsoft (and other.NET authors) had to invest in making sure that every SDK and everyarticle ever written has both C# and VB sample code? Allbecause Microsoft refuses to simply draw a line in the sand and say,once and for all, "C# is the best statically-typed object-orientedlanguage for the CLR on the planet, and Visual Basic is the bestdynamically-typed object-oriented language for the CLR on the planet",and run with it. Then at least there would be solid technical reasonsfor using one or the other, and at least we could take this out of therealm of aesthetics.

Or, contrarily, do the logical thing andcreate one language with two parsers, switching between them based onthe file extension. That guarantees that the two evolve in parallel, and releases resources from the languages team to work on other things.

Next,he shows some simple spin-off-a-thread code, with the Threadconstructor taking a parameter to a function name, traditional delegatekinds of stuff, then notes the disjoint nature of referencing a methoddefined elsewhere in the class but only to be used once. Yes, he'ssetting up for the punchline: VB gets anonymous methods, and "VB'ssupport for lambda (expressions) reaches parity with C#'s" in this nextrelease. I don't know if this was a feature that VB really needed toget, since I don't know that the target audience for VB is really onethat cares about such things (and, before the VB community tries tolynch me, let me be honest and say that I'm not sure the targetaudience for C# does, either), but at least it's nice that such apowerful feature is now present in the VB language. Subject to theconcerns of last paragraph, of course.

Look, at the end of the day, I want C# and VB to be full-featured languages each with their own raison d'etre,as the French say, their own "reason to be". Having these two "evolvein parallel" or "evolve in concert" with one another is only bound tokeep the C#-vs-VB language wars going for far too long.

Alongthe way, he's showing off some IDE features, which presumably will bein place for both C# and VB (since the teams are now unified under asingle banner), what he's calling "highlights": they'll do the moralequivalent of brace matching/highlighting, for both method names (usageas well as declaration/definition) and blocks of code. There's also"pretty listing", where the IDE will format code appropriately,particularly for the anonymous methods syntax. Nice, but not somethingI'm personally going to get incredibly excited about--to me, IDEfeatures like this aren't as important as language features, but Irealize I'm in something of the minority there, and that's OK. :-)

Hedemonstrates VB calling PLINQ (Parallel LINQ), pointing out some of theinherent benefits (and drawbacks) to parallelism. This isn't really aVB "feature" per se. <<MORE>>

Now he gets into somemore interesting stuff: he begins by saying, "Now let's talk about theDynamic Language Runtime (DLR)." He shows some VB code hosting theIronPython runtime, simple boilerplate to get the IronPython bits upand running inside this CLR process. (See the DLR Hosting Spec fordetails, it's pretty straightforward stuff: callIronPython.Hosting.Python.CreateRuntime, then call GetEngine("python")and SetSearchPaths() to tell IPy where to find the Python libs andcode.) Where he's going with this is to demonstrate using VB'slate-binding capabilities to get hold of a Python file ("random.py",using the DLR UseFile() call), and he dynamically calls the "shuffle"function from that Python file against the array of Ints he set upearlier.

(We get into a discussion as to why the IDE can't giveIntellisense on the methods he's calling in the Python code. I won't gointo the details, but essentially, no, VS isn't going to be able to dothat, at least not for this scenario, any time soon. Maybe if thePython code was used directly from within VS, but not in this hostedsense--that would be a bit much for the IDE to analyze and understand.)

Nexthe points out some of the "ceremony" remaining in Visual Basic,essentially showing how VB's type inferencing is getting better, suchas with array literals, including a background compilation warningwhere the VB compiler finds that it can't find a common type in thearray literal declaration and assumes it to be an array of Object(which is a nice "catch" when the wrong type shows up in the array byaccident or typo). He shows off multidimensional array literal andjagged array literal syntax (which requires the internal array literalsin the jagged array to be wrapped up in parentheses, a la "{({1,2,3}),({1, 2, 3, 4, 5})}", which I find a touch awkward and counterintuitive,quite frankly), while he's at it.

(We get into a discussion offiner-granularity color syntax highlighting options, such as colorizingdifferent keywords differently, as well as colorizing differentidentifiers based on their type. Now that's an interesting idea.)

Bythe way, one thing that I've always found interesting about VB is its"With" keyword, a la "New Student With {.Id=101, .Name="bart",.Score=53, .Gender="male"}".

He then shows how VB 10 hasauto-implemented properties: "Property Gender As String" does exactlywhat .NET programmers have had to do by hand for so long: create afield, generate simple Get and Set blocks and so on. Another nicefeature of this: the autogenerated properties can have defaults, as in,"Public Property Age As Integer = 1". That's kinda nice, and somethingthat VB should have had years ago. :-)

And wahoo! THE UNDERSCORE IS (almost) HISTORY! "Implicit line completion" is a feature of VB 10. This has alwaysplagued me like... well... the plague... when writing VB code. It's notgone completely, there's a few cases where ambiguity would reignwithout it, but it appears to be gone for 95% of the cases. Becausethis is such a radical change, they've even gone out and created awebsite to help the underscores that no longer find themselvesnecessary: www.unemployedunderscores.com .

Hegoes into a bit about co- and contravariance in generic types, which VBnow supports more readily. (His example is about trying to pass aList(Of Student) into a method taking a List(Of Person), which neitherhe nor I can remember if it's co- or contra-. Sorry.) The solution isto change the method to take an IEnumerable(Of Person), instead. Not agreat solution, but not a bad one, either.

References
Published at DZone with permission of Ted Neward, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)