Future of VB (Argh!)

FTP Online just posted a full version of a recent interview with Chris Dias titled “VB.NET Branches Out”.

OK, I don't find “branches out” to be in any way compelling, but at least it looked like they were finally going to “officially“ differentiate VB from C#. All the features were there...great answers by Chris to surprisingly pithy questions from Patrick Meader...I'm going “Yeah, they _finally_ get it!”...and then *Wham!*, face-first into the wall. Goddamnit. Chris said:

“The root of the question is: Is there something they won't be able to do in VB.NET that they will be able to do in another language such as C#? The answer to that is "no." There are features that one or the other might not have, but the fundamental capabilities will be the same, because they derive from the framework.”

Well, as _I_ see it, these are two orthogonal issues. When Chris said “no”, he blew the opportunity to finally do something to differentiate the two tools (note that I'm not saying “languages“). Sure, they use (_not_ “derive from“) the same framework, but that's a nothingburger. The C# advocate is still going to say something like “you can't do unsafe code in VB“ (or something similar) and if the answer to “what can VB do that C# can't?” is “not a damned thing” then we're back to then “I have to choose C# because I don't want to limit myself”.

In my very unhumble opinion, what these products need is _more_ differentiation, not less. There needs to be something compelling that you can do in VB that you cannot - and likely will never be able to - do in C#. I really don't care what it is...that's not important...but as long as VB is seen by the “advanced“ programming community as a providing something “less” - rather than “different” - it's going to continue to come off as second rate, no matter how much effort Microsoft puts into the “development experience”.

Seems obvious to me. Does everyone else agree?

I have a meeting scheduled next week with Chris (and Jay Roxe, the new VB product manager) and am very interested to hear what the rest of the developer community thinks about my conclusion.

24 Comments

  • How about the opposite case - where if I open a .cs file in my project and I am in vb mode the code is presented in vb and when the file is opened in a C# project it is shown in C#.



    If the languages really aren't different then that should be pretty straight forward...for a multi billion dollar software company.



  • By all means differentiate, but not needlessly, for differentiation itself. Programmers use C# and VB to write the same kind of programs, so if a feature is available in language A, then you can bet that language B's programmers will probably want it. I think this is an unavoidable force opposing your desire that VB be useful for something that cant be done in C#.



    Edit & Continue is an example of this. I hope that the minority of language snobs that use C# (funny, since C# is such a friendly simple language you wouldnt expect people to get precious about it) and look down their noses at Edit&Continue wont prevent that 'VB' feature from eventually appearing in C#.



    As far as I am concerned VB and C# are so similar under the skin that I consider VB to be a more wordy, harder-to-read version of C# - no doubt a simplistic interpretation.



    Short of deliberately excluding useful features from C#, I can't see how to make VB a compelling choice for some range of programming tasks, over and above C#.

    (But then, that's a matter of personal taste - some will take the opposite view).

  • Necessity for differentiation requires that there are two distinct target groups (maybe more) who will use or language A or language B. (a person can be in both). These target groups require a different language based on their benefits sought in the language.



    It's simple marketing, really: what does group A want? What does group B want? Deliver what A wants to A and what B wants to B.



    Now, in the case of VB.NET and C#, the two languages seem to appeal to different groups, however they're not that different in design, both have the same paradigm, same constructs, and overall the same statements (in whidbey that is). In other words: they will appeal to the same groups, only some people with syntax preference will pick one over the other.



    VB.NET is thus another J#: a .NET language which is only there to keep a certain group of people tied to .NET. MS writes .NET in C#, all MS' managed code is C# (afaik), and VB.NET is therefore not needed per se.



    I therefore agree that there should be more differentiation between VB.NET and C# to make the difference between the languages more visible, so VB.NET has a right to exist. At the moment C# has more features than VB.NET and making VB.NET featurewise the same as C# is not helping: why keeping VB.NET around then?



    Personally I'd love to see VB.NET be canned, because I think the language at the moment is not that good. Keeping it around will make publicly available sourcecode be written in VB.NET as well, which is then less appealing to C# developers to extend that code, because you can't compile a C# class into a VB.NET project.

  • IM: I don't get that "C# has it, I want it too in VB.NET!". If you want it, use C#. Instead, some VB.NET developers want to change VB.NET to make it as flexible and powerful as C#, which is IMHO useless. C++ has the feature to compile to native code and use managed and unmanaged code without hassle in one project/program. C# doesn't. Should C# be changed? No, of course not. The same with VB.NET.



    (disclaimer: I have ported a lot of code from C# to VB.NET, I know what VB.NET can't do, so please no flames "You said VB.NET is less powerful than C#". The first one who says that is invited to implement ISerializable.GetObjectData() in a VB.NET class derived from DataTable :P)

  • I did a lot of VB6 COM object because it was easy, but I have always prefered the c style.



    When I started .Net, I only used c# and still do.



    From time to time, I try to help people with problems when the code is in VB. I find it really difficult.

    Even though C# seems to have more actual code (definite in an aspx code-behind), it is all spelled out.

    I struggle with the VB syntax, especialy with the dangling "handles". I find it hard to see



    I don't want to seem them grow even further apart, if anything needs to be changed in VB# it is to bring the keywords/terms into alignment with c# and thus (for many things) the world.



    If c# developers want a feature, that feature should make its way into each language, same for VB#

  • I disagree with the post. You make it sound as if the VB team and C# team are in a competion, and every/any feature possible should be added so the VB.NET team can "win".



    Differentiation for it's own sake is pointless, the question is which features actually add value to a VB.NET developer's universe? Personally, I applaud the VB team for catching up with the C# team in some things and pulling ahead in others. But that just means that I can turn to the C# team and say "Hey when can I get this in your language / IDE "?



  • Actually it's not obvious at all to me why you would want to make it so that people were FORCED to use Visual Basic to accomplish something? There is already enough VB hate in the world.. forcing people to use it when they don't really want to would just incrase the hate levels.



    Why do you need to force people to use VB.Net? Personally while I know C# I still use VB.Net because I'm more familiar with the syntax, and that's a good enough reason for me to keep using it. And if I did want to switch to C# why should I be forced to come back to VB.Net?

  • VB has more functionality than C# in its try/catch syntax. I forget what the actual syntax is but it's something like



    catch AnExceptionType when A = B...

    catch AnExceptionType when A < B...

    catch Exception...



    (forgive the C# attempt at VB syntax)



    Apparently this uses functionality exposed by the framework which C# doesn't. A small thing, maybe, but potentially quite useful.



    Also the VB IDE does a FULL background compile whilst editing against C#'s syntax check. I'm sure that there are other things which they could emphasise.

  • In my opinion all the languages should do everything that can be done by the CLR. The point of creating the CLR was so that language choice became a "personal" choise and not one out of neccessity. This also affects any other language being created for .NET - like delphi.NET for example. Otherwise we might as well all start coding in IL.

  • I think the issue is that many VB.NET programmers (like me) have plenty of BASIC, TP, C, C++, and even Java experience, but simply prefer the VB syntax. I could care less about Edit-and-Continue, wizards, code autocompletion, VB6 compatibility, "My Classes," etc. I command-line compile everything and write it in TextPad, not VS. I'm a big boy who doesn't have a problem properly using interfaces, inheritance, delegates, overloading, anonymous functions, generics, etc., and I love (or would love) having all of these features in my language environment.



    Unforunately, the rest of the programming world still sees VB.NET through the eyes of VB: a language filled with whiney novice programmers and VBA macro junkies who have no business writing enterprise applications. Sorry to burst the C# ego-bubble, but VB.NET is a new ball game. VB.NET is just as capable, just as fast, and just as "proper" a language.



    I like my extra keywords, I like "End *" vs. curly braces, I like optional parameters and With...End With, I like using AndAlso and OrElse instead of punctuation, I like not having to end every statement with a semicolon, and I like the fact that I can't have separate variables named foo and Foo. To me, VB.NET's purpose isn't to be an "easy" programming, any more than Spanish is "easier" than Enlglish. Sure, VB is easier to pick up IMHO than C#, but I use it as a matter of preference and style, not lack of ability or experience.



    My solution, as I've written before on my own blog, is that both languages should be *completely* interchangeable, and make the IDE be able to swap back and forth on the fly and even possibly mix-and-match within the same source file. Why should programming teams be forced to choose one or the other? Code language, in the case of these two languages, should be a simple matter of personal preference settings, not team standardization.

  • I wonder if asking for more or less outa a particular language would probably defeat the purpose of haveing a CLR and a common base class library.



    Frans observes:

    "At the moment C# has more features than VB.NET and making VB.NET featurewise the same as C# is not helping: why keeping VB.NET around then?"



    But the developer experience is certainly not the same, is it? VB guys would wanna stick onto their Begin ... End rather than switching to {} just because they can use .NET.



    What say?

  • Cory's comments boil down to

    1) E&C (a feature of the IDE, IMHO)

    2 & 3) & 6) One statement per line

    4) case sensitivty

    5) ??



    I like the idea of automatically converting between languages, but case sensitivty would through a wrench in that one

  • What future? VB died years ago thanks to .NET. What you used to be able to do was build simple applications simply - and even complex applications reasonably simply. Then Microsoft stabbed millions of developers in the back with unneeded complexity and overtly hostile incompatible changes. You used to be able to count on Microsoft to know that evolutionary product development was the key to their success. The VB folks forgot some of the most critical core values that made Microsoft successful.



    Now they say "trust us, it's stable? We won't mess with you any more?" You've got to be kidding. Since we had to move platforms, we're on Java now, but still using VB6 for real RAD for Windows GUIs.



    Until there's no more CLR for VB there's no possibility of meaningful differentiation. There was plenty of differentiation between VB and VC++ in Visual Studio 6, but Microsoft apparently sees as much value in language diversity as they do in OS diversity.

  • Comments on 'reasons to like VB'



    * Edit & Continue



    This an IDE feature, not a language feature.



    * Syntax Checking



    Does this refer to full-background-compile, since C# has syntax checking? This an IDE feature, not a language feature.



    * Flow Control Checking



    This an IDE feature, right?



    * Not Case Sensitive



    Partly good, partly bad. Certainly, the way I name variables in C#, case sensitivity is essential. Obviously I cant do that in VB, but case insensitivity is great in its own way.



    * No Pinky Finger Gymnastics



    Yeah, we need a programmer's keyboard with { } keys that dont need the shift button ;-)



    * It's in English, not curly braces



    Begin Paragraph Taken to its conclusion Comma this is an argument for Plus Comma Minus Comma Asterisk etc Full Stop keywords Full Stop Anyway Comma using curly braces is easier to read Comma as they are more easily distinguished from variable names Full Stop

    End Paragraph



    So all in all, I believe there are probably better arguments in favour of VB than the ones listed above.

  • you people who keep arguing 'vb this' and 'c# that' - y'all make me sick.



    **real** microsoft coders write everything in IL.



    ---

    seriously, i would have to argue that the areas in which VB (the language) is behind C#, [such as not being able to reimplement a method already implemented in a base class (as pointed out by frans above)] these areas should be addressed and *fixed*.



    VB the language should be on par with C#, not behind.



    VB (the Graphicial IDE) should possibly be ahead of C#'s, because supposedly VB coders care more about 'edit and continue', pretty pictures, things like that.



    Over time they should both tend toward the same maximum of power and productivity.

    in the short term C# may be ahead in power and VB ahead in productivity.



    ---

    Regarding the problem with not seeing the 'Handles' keyword - i recommend turning on word wrapping.



  • um, 1 word: DELPHI



    all problems sorted

  • Total Hogwash. "I want the tool I like to be different." I haven't seen such a childish entry on VB in awhile.

  • I guess (after rereading what I wrote), I didn't get my point across that I agree that the IDE features should be identical. Both language should offer functionality that allows the developer to take full advantage of all the features that the framework has to offer.



    The point that I was trying to make is that many of these features that C# has that VB.NET doesn't is sometimes in light that that type of developer doesn't want/need that feature. This appears not to be the case with Whidbey getting ready to offer unsigned types, generics, public/private property set/get, 'using', etc.



    However, after asking many people (including some posts that have been around here on weblogs); it's been stated many times that Edit & Continue, Background Code Parser, Project Global Imports (a.k.a the other using), Project Global Namespace, etc. that VB.NET current supports are definately not wanted by the C# developer.



    Even the When clause that the Try/Catch in VB.NET has, C# people have stated many times... what's that for? why do we need that? It's not important.



    To take this another route, VB.NET has the Microsoft.VisualBasic.dll available to the VB.NET developer. Many people (ergo C# developers) see this as something that is a crutch for the VB.NET developer and shouldn't be used, but instead favoring for those *replacements* that are in the .NET Framework, even if it takes 10 lines of code to accomplish the same task. Others see this dll as something that exists soley for the purpose of backwards compatiblity with VB.NET; mistaken this dll for the Microsoft.VisualBasic.Compatiblity.dll; which is obviously false. Now, the point with this particular VB.NET feature is that C# developers can reference the same exact dll, but won't simply because it has the VB.NET name associated with it. Instead, resorting to reverse engineering it to see how to acomplish the same task in C#; usually stripping out some code that serves to provide a solid implementation of whatever function that was being provided (error checking for example).



    Yet another example was recently there was a lot of talk about Refactoring in VB.NET. (Yes, again, technically a feature of the IDE.) Paul Vick made an off comment that it probably would not be called Refactoring but many of the refactoring tools would indeed be within the VB.NET IDE. This started off a very long discussion about how VB.NET is dumbing down the language for the developer and how the so called VB.NET developer isn't smart enough to know what Refactoring is. Just because there's not some menu item labeled refactoring make VB.NET dumbed down. VB.NET is more focused on placing these features in context with the current activity. After seeing some of the demo's for C#'s refactoring feature, it appears that they are doing something very similar.



    Basically, the general air around seems that if it's something in VB.NET; it *can't* be good enough to be in C#. This may not be everyones impression, but I will have to say that it's been voiced very loudly in many different forums.



    So when discussing the making the products target different developers and creating more of a split between the two, it's appears to be completely unavoidable. Also, this argument always seems to be between VB.NET and C#, never C++ vs C#, Delphi vs C#, J# vs C# (ok, no argument with that one), or [insert other supported language here] vs C#. It's always about knocking VB.NET. VB.NET developers don't go around knocking C# (I know, C# developers are so superior so VB.NET can't knock them ;-)). C# developers seem to definately have a different mindset than VB.NET developers. I'm not able to put my finger on it exactly, which is probably because I work in multiple languages, but I do know that I take a lot of flack about prefering VB.NET over other languages.



    Personally, I want to see even more language features added in; not necessarily copying C# constructs, but adding language features that make sense with the overall VB.NET language and extending it to include more control the Framework.



    Does this mean that I would like to see things like Anonymous Methods included in VB.NET. Although I agree that they are pretty cool, I don't believe that they fit within the VB.NET language (one line one function). However, Generics are a perfect fit and of course should be part of VB.NET. I want to see VB.NET (language) get more powerful for the advanced developer, while still allowing the newb developer to create simple applications and move slowly into more advanced features. At the same time, I want every single little thing that is going to make my development life easier within the IDE; this includes E&C, Background Code Parsing, Refactoring, etc.

  • keep the languages and ide features as close as possible.

  • There are already a number of productivity features in Visual Studio .NET Whidbey that will be supported only for VB.NET. If there is any divergence, it should be at the tool level only and not the language.



    Some of us don't even use VS.NET (Don Box is wrong... SlickEdit is "God's Own Editor"), so the languages should remain as faithful to the FCL as possible and demonstrate uniformity through it.



    There would have to be some absolutely undeniably can't-function-without-it language feature to make me consider starting a project in a language that I don't favor. Like a function that turns the pointy-haired bosses into 6 of the hottest female Swedish bikini models, each of which is carrying a pizza and cold beer.



    And even then... it's just a maybe.



    It's not about "C# snobs", it is about willingness to learn more about what you are doing. I just don't see a lot of threading and security examples on the web in VB.NET. However, I routinely have to convert DataGrid tricks and examples from VB.NET to C#.

  • The goals of VB and C# are differnt. The goal of VB is to be a great productive development environment, the goal of C# is more around language purity and exposing the .Net framework in a C-style manner.



    The Key part is that VB is more that just a language, it also includes a development environment and they form a symbiotic relatiosnhip. Both are designed to work closely with each other. Features like EnC, Design-time Expression Evaluation, background compilation, snippets are all part of this environment, designed to make the developer productive.



    Langauge purists may think that VB is not as clean or as pure as C#. If you look at it from an academic standpoint you can make that argument. But that is not VB's goal. The goal is to be able to solve the particular problem the developer is working on in an efficient and quick manner. The Language and IDE work in concert to enable that.



    Both langauges will have similar features as they are both based on the framework, and you want to be able to use all the features from one langauge in the other. What you will find in future releases of VS is that they will differ in their feel, and approach to solving problems.

  • As a consultant, I use both C# and VB.NET on a regular basis. I really don't have a preference of one over the other, but what I would REALLY like to see is a version of C# with ALL of VB's niceties! Give me a smart editor where I don't need to worry about case sensitivity.



    VB's verbosity, lack of a tertiary operator, and non-short circuiting conditionals drives me nuts. On the other hand C#'s case sensitivity and so-so intellisense makes me less productive.



    Can't I have my cake and eat it too?

  • I much prefer C# over the verbose constructs, and definately don't like the idea of "turning option strict" off. Any time you save from not typing out a cast is lost to debugging, especially when your collaboration partners have consultants that write code like this:



    public MyClass(object foo)

    {

    lock(this)

    {

    MyClass.StaticVariable = foo;

    }

    }



    Whimper.



    On the other hand, the time saved by using Edit and Continue is incredible. Anyone who says E&C is useless probably never used it extensively. I also like how VB.NET seems to have better intellisense. I hadn't heard of the differing Try Catch semantics, but while sounding neat, that's all it really sounds like to me.



    On the other hand, I prefer C++'s catch fall through (I seem to remember it working as catching the specific error, then re-throw'ing will go to the next catch statement that matches, instead of the next higher try-catch block in the callstack like C# does. But it's been years and I mainly used GCC back in the day, so I could be misremembering.) Of course, VC++.NET programmers have said "C# doesn't allow you direct access to the value on the heap of a boxed value type. That's all you have to say about C#" (or something like that. Basically, in C#/VB.NET boxed values are pretty much immutable, while in C++ you can alter them), and so the hard-core of that group kind of looks down on all of us.

  • VB haters make my blood boil. In 12 years of programming, I have never ever not acheived my project goals.....EVER!!!!



    I have worked alongside at least 20 C programmers on numerous projects....and not once have I ever seen them do anything that I couldn't acheive in a different (normally simpler) way. And anybody that mentions pointers...DIE! To a geek..they might be great...but ask that secretary who you just developed a new system for, what she thinks of them? You wont....becuase she'll laugh at you like the gimp that you are....



    Ask her if she thinks the new system is great? Thats the important part.



    So make VB.net different to C# who cares? Your a programmer...your job is to acheive an end result. As long as they make it possible for you to acheive that end result.....is all that matters.

Comments have been disabled for this content.