But what about Visual Basic, the direct descendant of the programming language that gave Microsoft its start?
I used to make a living writing custom Visual Basic applications for small- to medium-sized companies back in the 1990s, before the .NET era. It was the quickest way to build a fully-functioning Windows application. The drag-and-drop approach to building an interface meant that my business partner, the business rules/human factors guy, could build simple prototypes off which I’d build the actual program. The low barrier to entry presented by the Visual Basic language meant that our customers – who knew their business much better than we did -- could make changes to the code (they’d make mostly small changes, but they appreciated not having to call us and pay a consulting fee for every little change).
I haven’t touched Visual Basic since those days. I remember the “Visual Fred” fuss that some developers made when Visual Basic went .NET; they said that Microsoft had ruined the spirit of the original language and simply turned it into C# in Basic clothing. I remember reading articles that said that given the choice between coding in Visual Basic.NET and C#, you should pick C#, partly for technical reasons, partly for financial ones (they hinted that people would pay a “C# developer” more than a “Visual Basic developer”.
C# seems to have “preferred status” in the world of managed-code .NET, judging from a quick look at the books and sites out there. I personally prefer it to Visual Basic .NET, but I wouldn’t be doing my job if I were ignoring an audience of Visual Basic developers. So I thought I’d ask you, the people who build on Microsoft’s platforms: Do you code in Visual Basic?
And if so, do you do it because it’s your preferred programming language? Or it is because your company has standardized on it? Or that you’re maintaining projects written in VB.NET? Or something else?
And just as important, if I post code examples in C#, do you want me to post equivalent code in VB.NET, or are you happy to work it out on your own?
Let me know, either in the comments or drop me an email. I’d like to know, because I’ll use that information to shape future articles on coding.
Your comment made me laugh. It's a geeked up version of the Steve Martin bit, "... typeof is GetType; var is Dim; it's like VB has a different keyword for everything!"
I use VB.net from time to time for one-off projects, often involving (horrors!) the serial port. It's pretty easy and quick to get a GUI frontend for an Arduino project slapped together, and the people I'm working with can generally make heads or tails of the code (they can handle braces and semicolons on the Arduino apparently, but C# is "too hard").
I think VB.Net doesn't get a fair shake, but then, I'm working right now in PHP development - and it's not 5. As with many things, I think the tool is secondary to knowing how to use it.
I prefer VB because I can get the same work done with far less code. C# is far too picky about things that are completely pointless.
C# + LINQ you always have to include a "select" clause. LINQ itself doesn't require it, it is purely a C# issue.
C# requires that you sprinkle "break" keywords all over your switch blocks. And you can't use ranges or comma-separated lists, you need to repeat "case" over and over again instead.
C# requires you to initialize all local varaibles. The .NET runtime doesn't require this, again this is purely a C# issue.
C# requires "return" statements from functions even when you aren't necessarily returning anything.
C# requires extraneous parens everywhere.
C# requires you to specify "ref" when calling functions that pass arguments by reference.
C# doesn't allow multiple variables in using blocks, you have to chain them together.
C# doesn't have with blocks, making for redundant code.
C# doesn't support late binding, instead forcing us to use a ton of reflection code.
C# doesn't support optional parameters, which make COM programming painful.
C# doesn't support XML literals, leaving us to use the old, clumsy object models.
I code in vb.net simply because I have to. It seems to be the standard in the federal government, at least its a step up from cobalt... "hmm ok its 2009 lets port our old cobalt code to something new, any suggestions?" "I've got! I just read an article about this great new language Visual Basic. *as he pulls up an article on his commodore 64*, I exaggerate but still. I do find that alot of tutorials and forum post solutions for .net issues are in either c# but in the .net framework its pretty easy to translate.All in all VB.net isnt so bad, and it would be awesome id VS added a drag and drop MS paper clip lol
I;m willing to bet you are using VB wrong. I've seen countless C# developers add tons of extraneous crude to VB code because they think it should look like C#.
I code in VB.
My last job, it was because the primary client preferred it.
In this job, it's just because the project I'm on started with it.
If I had the choice, I'd choose C#. I don't mind VB, but C# makes me happier. I'm honestly not sure why.
I can work out the VB from C# examples, but sometimes not needing to is nice.
10 text$ = "Please Don't Deprecate it!"
20 print ucase$(mid$(text$,10,1)+mid$(text$,9,1)+right$(text$,1))
30 goto 10
40 REM Seriously, had to Fedex a DVD today because VC 6.0 (C not BASIC) isn't available
50 REM for download from MSDN any more!
Thanks for the feedback, everyone!
I also got some email and Twitter direct messages, which I'll summarize in a later post.
I use VB for quick UI based programs. It was the second language I learned (the first being good ol' QBasic) in high school and I find it very useful for my purposes.
I haven't programmed nearly enough to go into an in depth discussion of the language, but if I want a quick, small, UI based application I'll be choosing VB over anything else.
(I was upset that the ability to easily make control arrays was removed from .NET. In high school we created many games using control arrays as a 'backbone')
I strongly prefer VB.NET to C#. I have said out loud "C# is just VB with semicolons" on more than one occasion. Apparently Anders has even heard me say it, and the ground didn't open up and swallow me whole so I can keep saying it. I love the "VB is for people who are not smart enough for C#" comments. VB is the managed language I prefer, and I am smart enough for C++, C++/CLI, and C++0x (heck, I am smart enough to make JOKES about C++0x and that takes some doing) so thhhpt to the "not smart enough" folks.
I prefer VB for three reasons - it is clearly and obviously not C++, which helps me context switch; it requires less typing even though its keywords are longer; and my clients (falsely) believe it will be easier for their own staff to maintain or (perhaps correctly) cheaper to hire staff to maintain it when I have finished writing it for them. Also, the typing advantage used to be far stronger, and I got used to it during that time.
I am not saying VB3 was a great programming language, or even that VB6 was (though it sure solved a ton of busines problems.) But people who formed their opinions of VB then and refuse to change them are, er, hard to describe politely.
Yes I do.
I still maintain (and even develop) many small and medium biz solutions that require VBA. I'm so used to VB.NET (and previously VB 6) and I don't see any advantage of switching to another language. Perhaps my choice of language isn't cool - my apps are!
I used to code primarily in VB, but now I program in C# because it was my company's choice. The two languages are very close, give or take XML Literals (available in VB but not C#) and anonymous methods (available in C# but not VB).
BUT, I can program faster in VB than I can in C#. The compiling-as-you-go is fabulous, I don't have to do the make-a-change-then-build, make-a-change-then-build, make-a-change-then-build, make-a-change-then-build, make-a-change-then-build cycles.
The intellisense is much stronger, it finishes my sentences for me and puts in my "Ends" (If/EndIf). It's not case-sensitive and it corrects my variables to the capitalization I used when I defined them.
I don't have to put semicolons at the end of every line, and I don't have to eyeball the curly braces to make sure I didn't miss one, and that they line up.
The methods have a line between them in Visual Studio when you're using VB, which makes it easier to see your endpoints. And inserting code snippets is easier in VB, and there are a lot more of them for VB than C#.
And I'm sorry, but AddHandler is a lot easier to instantaneously get than +=. Seriously.
Of course, C# has those wonderful anonymous methods, and I have to admit, the curly braces are cute. (I can't help myself, I'm a girl.)
The only difference between the two languages is pretty much spelling (except did I mention XML literals, which C# doesn't have, and anonymous methods, which VB doesn't have?).
So if you think you can do more in C# than in VB, you don't know enough about VB. And if you think you can do more in VB than C#, you don't know about C#.
I think it's important to be ambidextrous and know how to read both, and honor other peoples' choices. I can do both, and although I find C# pickier, I can live with either one. The important thing is to get the job done in the best way possible, no matter which language you choose.
I do code in VB.NET. I also teach development theories using VB.NET to post graduates studying GIS. For me, the best and most effective approach is to teach VB.NET. We study object oriented programming using VB.NET as that is what the job descriptions are asking for.
Dollar for dollar, VB.NET achieves the greatest impact for these students.
I code in VB.Net because that is my company's standard. I agree with RobinDotNet that there aren't that many differences compared to C#, and I have no problem reading both or switching back and forth.
In any software project maintenance is the number one cost associated with software development. I've seen the "quick and easy" VB apps that have been strewn about - completely fragile and unmaintainable with all of the VB goodness like hundreds of untyped globals wrapped in spaghetti.
Grauenwolf's comments on C# being picky - these are constructs which show the programmers intent and therefore make maintenance easier and programs cleaner, these are not completely pointless. Pointless is using the word Dim in front of every variable declaration, it has no semantic value and does nothing to convey the intent of the programmer.