Keith Pleas Blog

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.

I disagree completely. I really don't care about differentiation beyond syntax. In fact, I've argued that differentiation for its own sake or because of what you *think* your users need (such as in the case of using different names for refactoring functionality in VB from those in C#) is short-sighted at best and, at worst, presents an unncessary handicap to those of us accustomed to switching between VB.NET and C# at will.

If there's a compelling reason for a differentiating feature or features, fine, go with it. But not because you assume MORTs won't grok refactoring if you use the standard terminology (see http://weblogs.asp.net/jlerman/posts/38021.aspx for a great take on this), and not just because VB "needs" to be able to do something that C# can't do.

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?

Frans: You say you don't get that "C# has it, I want it too in VB.NET!". Fine, but I'm not sure why that comment is directed at me.
I did make a similar point (and probably deliberately inflamatory) from an opposite direction, but I dont personally care what VB can or can't do.
I agree that probably the way to differentiate VB.NET might be to take it back to its more simple roots, although I wouldnt regard the crufty nature of VB6 as being simple.
I also agree that if I were Dictator, I'd probably abolish VB and decree that all VB programmers get real and use C# ;-). Guys, if you dont like it, re-education camps will be available to help you realise the benefits!!

Reasons to like VB.NET (Now and Whidbey)

* Edit & Continue
* Syntax Checking
* Flow Control Checking
* Not Case Sensitive
* No Pinky Finger Gymnastics
* It's in English, not curly braces

Abolish VB.NET in favor of C#. What a joke. If it was an evolutionary progression, sure I would agree. However, the two languages are night and day. Why not say abolish C# in favor of Delphi? Ridiculous, right?

VB.NET is the logical progression of the BASIC language. BASIC has been around longer than C. C# is an the C language evolved. It makes sense for C developers to move to C# for most development tasks. It's not going to replace C/C++, since C# isn't as low level.

For the facts:

"C was originally developed by Dennis Ritchie of the Bell Laboratories in 1972. The language was named "C" because it was the successor to a languages named "B"(no lasting fame, however). C was developed as a high level language that could be used to rewrite the UNIX operating system. Today, most of the UNIX operating system and most of the programs that run under UNIX are written in C."
-C Programming Language
Earl L. Adams 1992

Basic was the first product sold by Microsoft corporation, and also the first major case of software piracy - It was copied widely even before Microsoft made it available (Bill Gates lost track of a copy on paper tape during a computer show).

BASIC (standing for Beginner's All Purpose Symbolic Instruction Code) is a system developed at Dartmouth College in 1964 under the directory of J. Kemeny and T. Kurtz. It was implemented for the G.E.225. It was meant to be a very simple language to learn and also one that would be easy to translate. Furthermore, the designers wished it to be a stepping-stone for students to learn on of the more powerful languages such as FORTRAN or ALGOL.
From "Programming languages: History and fundamentals" by Jean E. Sammet.

Bill Gates and Paul Allen had something different in mind. In the 1970's when M.I.T.S.'s Altair personal computer was being conceived Allen convinced Gates to help him develop a Basic Language for it. When M.I.T.S. answered with interest, The future of BASIC and the PC began. Gates was attending Harvard at the time and Allen was a Honeywell employee. Allen and Gates licensed their BASIC to M.I.T.S. for the Altair. This version took a total of 4K memory including the code and data used for a source code.

Now for some additional comments.

Microsoft has a strong commitment to BASIC. As long as Bill Gates has a say in the future the languages that are developed within the walls of Microsoft, BASIC will be at the forefront.

BASIC has been on more platforms in history than ANY OTHER LANGUAGE.

It's a proven language for ALL types of application development. C# is still relatively new, although it has a lot of history leading up to it, it's still in it's infancy. Who knows where C# will go in the next 10 years. BASIC on the other hand, has evolved over the past 30 years into the most productive language in history. Is it perfect, no. However, no language is perfect for all tasks. This is true of C# as well.

I think it's ridiculous that those who favor C# have already somehow placed themselves on the top; turning their nose up at any other language. It amazes me that this can happen is such a short amount of time (what a little over two years?).

To those VB developers that find it hard to move to VB.NET, I say deal with it. If they wish to jump ship, fine; it's their choice. However, I get pretty tired of having C# crammed down my throughout every single time I turn around. Also, frankly get pretty pissed at the overall treatment of VB.NET developers and those developing the VB.NET language. To all other languages, get over yourself. VB.NET is here to stay. It's not going anywhere but forward. If you keep thinking that C# is so superior and focus only on what it has offer, you might just miss some of the things coming from the VB.NET camp.

Is it right to ask for things in VB.NET that are available in C#? Yes. If the features make sense and offer additional flexibility and productivity without increasing the overall learning curve; I'm all for it.

For the record, I use VB.NET, C# and C++ for everyday development.

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.

To th people pointing out that some features that I mentioned being IDE features. Although you are correct, they are IDE features. And therein is the point. VB.NET is *ALL* about the IDE. Is it possible to use VB.NET without it, sure; but you kind of take away a little bit of what VB.NET is without it.

If C# had some of these so called IDE specific features, I would be more comfortable working with C# on a daily basis. As it is, every time I have to work in C# I find myself asking why the h*ll do I have to compile just to see what my errors are? You get into this write code, look it over, start to debug, oh wait, gotta fix some errors, start to debug, oh wait, even more errors, start to debug, finally, you can test your changes. Now some would argue that this isn't the way to code, but I am talking about reality.

It has also been argued here on weblogs that E&C should not be in C# because it fosters bad programming practices. This may be true, however, what if you forgot something as simple as a backslash in a path value that you are calculating and it takes 20 steps to get to that portion of your code to test it. Without E&C, find error, stop debugger, fix error, start debugger, go through 20 steps to test again. With E&C, find error, pause debugger, fix error, continue testing.

BOTH of these features have been *slammed* repeatedly here on weblogs and elsewheres many times over. Right now they are only VB.NET features.

I also remember a couple of days ago that someone was wishing there was a way to globally included 'using's (VB.NET Imports). VB.NET has this (yes, I know, it's an IDE feature, but hey, VB.NET has this and C# doesn't). But because VB.NET has this, it's inferior and 'hides' this functionality away from the developer. This has also been said of the automatic Namespace that VB.NET has.

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#.

What about a major time saver in VB.NET... The ability to turn OPTION STRICT OFF? I've been a VB developer for about 8 years now, recently I started at a company who used C# as their code of chioce.. so I switched.. and granted C# tends to have cleaner looking code, EXCEPT when you have to type cast an object to a strict type then type cast an int property of that to a string. I can't get over how much time VB.NET saves me when I code (in the VS.NET interface that is), I don't know that I could put up with it otherwise. Also what about Optional Parameters on functions? this is SOOO useful in VB.NET and the closest C# gets to it is param arrays, which are inflexible in terms of compile time type checking.

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.

The key part of the acronym BASIC is "Beginners". That should be the goal of VB. To address the needs of beginners. As developers outgrow VB, they can move to C#.
There is absolutely no benefit to having two language syntaxes that fullfil the same role.
C# should be for professional application development, VB should be for learning to program, writing quick and dirty one off utilities and maybe doing UI prototypes.

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.

What about some features like

1. Unstructured Error Handling - On Error Goto
2. parameter Array.
3. Case Sensitivity

These must amount to something in VB.Net if not present in C#

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.