Discussion: Visual Basic Strategy

Microsoft stated that Visual Basic will no longer align with C# I blogged a short piece about this on our sister site, Codeguru:

http://www.codeguru.com/blog/categor...gn-with-c.html

This is an interesting divergence from the previous stance of trying to keep VB in sync with C# at a higher level. That clearly is now being abandoned. I'm curious to hear what everyone has to think about this new direction, thus it seemed appropriate to ask this here, in the VB.NET main forum.

Were you surprised when Microsoft said "hundreds of thousands' of users of VB versus the millions of C# users? What are your biggest concerns about Microsoft's new strategy? What do you see as positive?

Brad!
Admin

(( We plan to keep the forum alive and aligned with our other top forums! ))

Personally I think that it makes sense for each language to play to it's own strengths and if a feature should be in both then it needs to be done properly. C# had to wait for optional parameters and named parameters but when it did get them they were integrated into the language well. C# never got VB's XML literals and the C# switch... case is nowhere near as good as the Select ... Case in VB.

I still find some of the VB.Net equivalents of C# features poorly implemented or having an awkward syntax, almost as if they did the bare minimum required to be able to claim to have a feature. For example I find the C# syntax for lambdas a lot cleaner than VB's and the implementation of auto properties in VB is so close to being useful but misses the mark and is useless in a lot of cases.

Given the same framework is behind both languages the underlying functionality is going to be the same, forcing both languages to have feature parity regardless of how sensible it is seems counter productive; you may as well demand F#, VB and C# support the same feature set.

I like the idea of allowing a language to focus on it's strengths and making interoperability between them easy, it gives flexibility to us as developers and allows us to choose the correct tool for the job rather than having several almost identical tools.

Well that sucks.

Because, there are some structures that go well with both, sometimes when I have done C# programming I have converted some VB.NET code to C# - simply because it was easier than trying to re-write the same code when it was pretty well teh same.

Un-aligning with C# could be good though, it does give vb.net its independence it has struggled to gain, as it is "limited" vs c#, but then again what does the independence mean for the language as a whole, are they trying to kill it?

Best way to see is to well, patiently wait. What does the changes have on the future of vb.net?

P.S I chose vb.net for specific reasons, thus it is much easier and faster to code than c# and it requires less code, to code some of the same exact things making it more effecient.

As far as the ratio of users, for professional usage I can easily believe that. It certainly is in the US if you base it on job listings. I'd guess it would be closer to equal if you include all the non-business folks.

Only real concerns I have are 1) regardless of what they're saying now, is MS positioning itself to kill off VB in a few more versions and 2) how would converter or decompile tools work in those cases where one language has functionality the other doesn't.

Quote:

---

Originally Posted by topshot

As far as the ratio of users, for professional usage I can easily believe that. It certainly is in the US if you base it on job listings. I'd guess it would be closer to equal if you include all the non-business folks.

---

I think you meant if you DID include all the business people - the non-tech types that use VBA or some variation. And yeah, I'd agree, if you include all of VB classic and .NET and VBA and VBS ... yeah... but that's lumping togther things that shouldn't be. By that token, C# should be lumped with C/C++ as well. And then there is a LOT of cross over. I highly doubt there is anyone on a professional level that uses one and only one language. Often we're using at least two, if not three. I used two daily (Vb.NET & JS), three if you also include SQL, and sometimes I also get into some C#...

Quote:

---

Originally Posted by topshot

Only real concerns I have are 1) regardless of what they're saying now, is MS positioning itself to kill off VB in a few more versions and 2) how would converter or decompile tools work in those cases where one language has functionality the other doesn't.

---

1) I'm more inclined to think that they maybe be starting to divest themselves of VB.NET ... Not that VB.NET will die, but it wouldn't surprise me that in 5 years or so, VB is released as open sourced... the way C# is... The specification for it will be sent to the ECMA Scripts Working Group

2) How does that work now? If I take something that was originally written in C++ and decompile it to VB.NET... what does it do now? It gives me it's best interpretation of what the Vb.NET code (could have) looked like. decompilers rarely reproduce 100% accurate results anyways... they simply can't. So they take their best guess. Anything that comes out is always going to need some manual intervention and tweaking.

-tg

I'm thinking that this might be the first step towards not advancing VB.NET, which is not the same as abandoning it. If the strategy is more one of innovating in C# (which needs it, frankly), while leaving VB.NET as a more accessible language, then that's fine with me. After all, you can write a dll in C# with whatever C#-unique functionality you want, while leaving a UI in VB, which is better at it by a small amount.

In any case, I'm not really surprised. There are things that have been hard to implement in one language or the other. Multi-line lambdas were simple to implement in C#, but took some innovation to implement in VB. That innovation was a good thing, but the lessons learned didn't appear to bleed back into C#. So, there's an advantage to having the languages follow one another, but the advantage isn't equal, and it isn't always a good thing. By allowing the two to be decoupled, it doesn't force one or the other to adopt something that isn't really well suited. As long as we have dlls, I'm ok with that.

It would be even better if we could write partial classes in a mix of C# and VB. Then we'd be able to have the best of both in the same assemblage.

I blogged about it a few days ago on a VB forum and don't feel like adding much more: http://www.vbforums.com/showthread.p...guage-Strategy

The main point if you have a short attention span:

VB users don't participate in the community in ways that are visible to Microsoft, if you want MS to believe this language isn't a 10% project you should probably make sure you make some noise in the places where they look.