Should I move from VB6 to VB .NET or C#?

TechEd 2004 was crazy busy, so there’s going to be some catch up time before I get back into full swing blogging. However, one thing I did want to relate before I forget it.

Last night, Duncan Mackenzie, Amanda Silver, Steven Lees and I (the middle two are VB Program Managers) were having dinner at TechEd and we started discussing the logic of a statement made by several customers during the conference that boiled down to: “We figured that since VB .NET wasn’t the same as VB6, we might as well move to C# when we moved to .NET“ After thinking about this for a moment, it occured to me that this is somewhat akin to saying:

“We figured that since British English wasn’t the same as American English, we might as well learn German when we moved to Europe.”

I mean, it’s a free country and all, but the logic of this does seem a little, well, illogical. Although the two languages can do many of the same things and have many similarities, taking on the extra burden of doing the cultural retraining necessary to move from VB to C# without some kind of well-researched rationale seems to me to be doing a whole lot of work that you don’t really need to. VB .NET adds a lot of power to VB and tweaks a few familiar things, but it’s still substantially the same language, just in the same way that British, American, Canadian and Australian English are all the same language, even if three out of four insist on using “u“s in funny places. (Although on the plane ride back, I got stumped on a crossword because I wrote in “lustre“ rather than “luster.“ I guess I watched too many British shows on PBS growing up.)

The way of the world, I guess, but it doesn’t make sense to me…

63 thoughts on “Should I move from VB6 to VB .NET or C#?

  1. Klaus Probst

    Hi Paul —

    What about the learning curve for the framework itself? OOP? The toolset? The IDE? The paradigm? The technologies? How steep is that compared to learning a new language, especially if you’re a VB dev with some exposure to C or C++ or even Java[Script]?

    Let’s face it – C# is simple once you get over the curly braces and terseness. This is not C++ where you need to understand pointers and scary syntax that involves various ASCII characters that you thought were only used in math.

    The average VB.NET developer has a heck of a time learning about ‘Inherits’ and ‘Overloads’ and ‘Shadows’, not to mention everything else. And you can’t write a non-trivial app without banging into the framework, much as VB.NET will try to isolate you from it. This is no different from VB6 – having to use an API or faking pointers or going deeper into COM than you would otherwise want to to get things done. In 10 years of VB I *never* wrote a single application that didn’t require an API.

    I’m of the idea that companies should let their developers learn and use whatever they want. Expose everyone to both languages, and give them a solid language-agnostic base on the framework and the .NET approach to doing stuff. Things will sort themselves out.

  2. Dave

    Wow, Klaus hit the nail on the head. I also hear that question from time to time, and my answer is usually the same: "VB.NET is basically a new language that just so happens to look like VB6, therefore it allows you to get up to speed a little quicker. But the syntax is not the issue – learning the framework is where it’s all at."

  3. Christopher Hawkins

    "taking on the extra burden of doing the cultural retraining necessary to move from VB to C# without some kind of well-researched rationale seems to me to be doing a whole lot of work that you don’t really need to"

    The well-researched rationale is that C# developers earn a good 20% more money. It’s stupid, sure, since both languages just end up as MSIL…but the market associated C# with C/C++, and that has more sex appeal than VB (for whatever reason).

    I’ll learn VB.NET, sure. But I’m going to bust my behind to embrace the "cultural retraining" necessary to pick up C#. My pocketbook will thank me.

  4. paulvick

    Klaus: You’re certainly correct that the real work is dealing with learning the Framework and moving your mental model from COM to .NET. What I’m getting at is, given that you have to do all that work, why make things any harder on yourself than you have to? Although you may be very comfortable with multiple languages, my contacts with customers this week showed that there were a *lot* of them that weren’t and for whom the move from one syntax to another was non-trivial. Throw into the mix the things that are actually different about the languages (case sensitivity, Handles, etc.) and I just don’t buy the argument that C# and VB are equally easy for all VB6 users. I do, however, completely agree that in an ideal world this is something that is best left up to a developer to decide for themselves rather than dictated.

    Christopher: If the rationale is money, that seems entirely logical to me – although I can’t say I know much of anything about earning rates, so I can’t evaluate your statement one way or another (or know how broadly it applies). In the cases I was talking about, though, it was companies making decisions on behalf of programmers they already employed, so the question of how well those employees could do outside of the company probably didn’t play a big part.

  5. Canuck

    "even if three out of four insist on using “u”s in funny places"

    Maybe it is the Americans who "insist" on <b>not </b>using "u"s in funny places… 🙂

  6. Tom Bowen

    I’ve heard the 20% premium for C# work before, and have no reason to doubt it. But I wonder if it’s as easy to find C# work as it is VB work? Anecdotal evidence, I sent out 3 RFQs to 2 Microsoft MVPs last week for VB.Net/ASP.Net projects. If you speak only C#, your income opportunity there is 0. Statistically larger (but still unscientific), is currently listing 60% more openings (888 vs 554) for VB programmers over C#.

    I’m sure there are examples of the opposite being true as well. But if I had to make a bet, I’d bet in 5 years VB .Net will have the same advantage that VB notNet had in terms of installed applications.

  7. Patrick Schriner

    Im far from a familiar with .NET, but isn´t C# the Language that´s most "native" to the .NET environment? Doesn´t C# provide a more OO way of thinking?

  8. Christopher Hawkins

    Paul: If you’re talking about companies making the decision on behalf of programmers they already employ, then I agree – the additional earning power that comes with knowing C# probably was not an issue. I imagine the company would want their developers to adjust to the new language as quickly as possible.

    Tom: You make a cogent point with regard to the availability of C# jobs compared to VB.NET jobs. However, I would never suggest that a VB6 developer moving to .NET learn only C#; rather, I’d suggest learning both. Even if you do all your projects in VB.NET, just having C# on your resume is one additional door-opener.

  9. Curtis Swartzentruber

    It’s always interesting to hear people’s opinions on this. Couple of comments:

    1. Really once you are comfortable with the Framework, know how to find things, how to set up a project, etc., it’s not that hard to switch back and forth. I did a lot of initial work in .NET using VB.NET. The current project I’m on is completely C#. There was about a week or two of confusion here and there, but honestly now I can jump back and forth without that much problem.

    2. I think there is still this perception that you are taken more seriously if you code in C#. Some programmers think that when they move to .NET, they will learn C# and leave behind the perception that they are a VB coder who doesn’t know what they are doing. This is all perception of course and you can be a good programmer on a lot of different platforms, but still it’s interesting to see the rationales out there.

  10. Christopher Hawkins

    Curtis – there IS a percetion in the marketplace that programmers who work in C# are "better" than VB coders. Nobody will dispute your point that good programmers can be found working in every language. My comments above were geared toward the idea of giving the marketplace what it wants (or what it SAYS it wants, whihc we all know is’nt always the same thing).

  11. Christopher Reed

    Paul – The problem I have with VB programmers is that they have the tendency to stick with the VB paradigm and avoid the OOP nature of VB.NET and the Framework. When we first started doing .NET, we had no language requirement; in fact, I thought that it would be best that people used what they were comfortable with. It turned out that I was only one to try my hand at C# (which I think is great, by the way) while the three programmers in my charge chose VB.NET. With one of these programmers, he wrote most of his code using VB functions and not the equivalent .NET methods from the Framework. From a optimization perspective with respect to using the CLR, it is my belief (which may be wrong, so please correct if necessary) that one should use the Framework as much as possible to help optimize the code. By using the carryover VB functions, the programmer is not actually learning the Framework as they should and this is introducing a optimization issue that can be avoided.

  12. yag

    Christopher Reed – Actually, you can use the VB functions – they’re part of the language, and are, in many cases, of equivalent speed to calling the .NET functions. In some cases, they even save you a lot of work (for instance, CSTR will give you additional functionality that would require more code). Since, in many cases, the functions are just calls to the same framework calls you’d make, there’s no performance hit. Additionally, in some cases, like the Left() function, the VB call is *faster* than the .NET .substring() call.

    Bottom line, the VB functions should be thought of as part of the language – they’re there to help keep your code writing smaller, and don’t cause performance hits overall.

    For more detailed info – check out:


  13. Christopher Reed

    Okay, since I wasn’t 100% sure about performance, then I don’t have a problem with that aspect. In general, performance is more of an issue when the application is fairly large and it becomes very noticeable to the user.

    However, YAG, I disagree somewhat with your VB position. If I have a VB shop, then using the VB functions in .NET is not an issue. However, if I have a .NET Framework shop, this means that the .NET class functionality is the focus and that the language specific constructs need to be avoided. This will allow for any programmer to use the language of their choice and have any other programmer to be able to maintain it regardless of their language preference.

    By the way, we have opted for C# as our base language, so I am more inclined to use C# style casting and other brief constructs that the .NET equivalent, but only because we are focusing only on C#.

  14. Pingback: Panopticon Central

  15. Pingback: Code/Tea/Etc...

  16. Merak

    In my experience the main problem moving from VB6 to VB.NET was due to the few differences between the two languages.

    You keep finding yourself reverting back to a VB6 mindset when coding in VB.NET, especially during the initial ramp in the learning curve.

    In C#, the language is different enough to not have this problem.

    This is why I learnt the framework using C#.

    Now, *learning* VB.NET is a no-brainer.

  17. Pingback: Anonymous

  18. Eric Mutta

    Dave:>…But the syntax is not the issue – learning the framework is where it’s all at.

    You couldn’t be more right! I would pay millions for a smart editor that could recognise common coding patterns then suggest some functionality in the framework that implements the needed functionality (a good example is using a loop to copy array elements instead of just calling System.Array.Copy).

  19. Eric Mutta

    Christopher Reed:> However, if I have a .NET Framework shop, this means that the .NET class functionality is the focus and that the language specific constructs need to be avoided.

    While that gives you both worlds, it leaves you with the best of none and once that’s the case you might as well do things in MSIL (extreme suggestion I know, but its the reasoning behind that suggestion that is important). Avoiding language specific constructs may slightly increase the productivity of the team but will decrease the individual productivity of every member in that team – an undesirable compromise, IMO.

    Christopher Reed:> This will allow for any programmer to use the language of their choice and have any other programmer to be able to maintain it regardless of their language preference.

    I can see what you mean, but (and without meaning to sound rude), isn’t that false idealism? Syntax only contributes a tiny fraction of the difficulty in maintaining another person’s code; person-specific and language-specific idioms/styles are where the hassle is. While it is possible, I would be very nervous to expect someone to properly maintain code they didn’t write, in a project that they weren’t a part of and in a language that they don’t primarily use.

    A better move, IMO, (and one you seem to have taken) would be to settle on one language (be it VB or C#) and use it to the fullest. .NET makes multi-language shops/projects more enticing but there’s always a hidden price to be paid (this is that "in theory…but in practice…" sort of thing).

  20. Pingback: Panopticon Central

  21. Karl E. Peterson

    PV: "Although you may be very comfortable with multiple languages, my contacts with customers this week showed that there were a *lot* of them that weren’t and for whom the move from one syntax to another was non-trivial."

    What’s even worse is moving between two languages that are eerily similar, but perversely different. Imagine the horror of a single code snippet producing different results depending which IDE it was run in!

  22. Daniel

    I found the move from VB6 to C# .Net to be a waste of time since most of my projects do not require online use. I like C# .Net but not for traditional Windows apps that will never be run on the Internet.

  23. AntiBlogger

    This discussion has largely left unchallenged blithe assertions contained in the original post:

    1. Paradigmatically VB 6 and VB.Net are fundamentally the same.

    2. VB.Net and VB are dialectical variants.

    3. That a move to C# from VB 6 is illogical because of the above.

    The first two propositions are false.

    The writer indulges in logical inconsistencies in order to prove his case.

    The selection of programming language rests upon a personal decision as to what programming culture one wishes to align oneself with. If this concept is new to you I suggest you read The Structure and Interpretation of Computer Programs by Abelson et al.

    Logic is an irrelevancy in this instance.

  24. Pingback: Cyrus' Blather

  25. DOH!

    Anyone have some actual results of making this choice? Like from a BIG project? Has anyone chosen C# and regretted it?

    Please don’t respond with "well my toy 2000 line app works just great in VB.NET or C#". I’m looking for someone that can say "we chose C# and it has been a problem for X reason".

    We chose VB.NET a year ago and we regret it. We have 25 very bright developers and a substantial ecommerce web site with plenty of traffic. One year ago we kicked off our port to .NET and we chose VB6 because our existing code base was VB6 and ASP. A few of us here had significant C# expertise from previous jobs and warned the bosses that the "advantages" of VB.NET were a mirage and that there were some clear disadvantages. They actually thought the "automatic conversion" tools were going to buy us some time. The pointy-haired contingent won out and not a day goes by that we don’t curse them for forcing VB.NET on us.

    As other’s have said, you take a big hit moving to .NET at all. The tiny additional hit of moving talented VB6 developers to C# is more than offset (IMHO) by the increased developer productivity achieved over the medium to long term in C#. (If your team is not very talented — or not talented in that way — YMMV.)

    Why do I think I am more productive in C# than in VB.NET? Here are a few reasons:

    1. VB.NET has abysmal static code analysis: functions that don’t return values, uninitialized variables, unused variable declarations, etc… This is what a compiler is *for*. I wish VB.NET had an "Option ReallyStrict On" so it would check things as thoroughly as the C# compiler does. You can spend hours trying to track down which uninitialized variable or non-returning pathway in a function is the source of a bug, when the compiler could just tell you.

    2. VB.NET has more aggressive background compilation that you can’t turn off or control in any way and which is buggy! We have solutions for our web site with 30 projects and some projects with hundreds of files. You can’t add a method to a class without taking a coffee break while intellisense chews up a CPU. We’re reduced to having to buy double cpu machines for developers so that they can just type at full speed. And even then all that CPU is wasted because the background compilation just can’t keep up. I wish there were an option for intellisense so that you could *tell* VB.NET when to recompile and when to just chill out because I’m typing a raft of code.

    3. VB.NET (still) has lurking intellisense bugs whether you use project dependencies or file dependencies. Whichever you choose, you’re stuck with a different set of problems ("can’t copy dll X [v1.1.3000.1] over dll X [v1.1.3000.2]" or "dll A requires a reference to dll B" or "can’t copy dll Y to c:foobary.dll because it is locked")

    4. VB.NET has no "using" directive. I know it’s just syntactic sugar… but I want more sugar. The truth is that interacting with non-managed resources (ie. the OS or the database) in .NET sucks even in C#. But having to write "Dim x … Try … Finally …. x.dispose EndTry" all the time is just pouring salt in the wound.

    5. VB.NET has no multiline comment syntax

    6. VB.NET has no within-the-line comment syntax

    7. VB.NET has no multiline string syntax

    8. VB.NET has a limit on line continuations (what is it, like 10 lines)?

    9. VB.NET projects cannot have pre-build or post-build steps (large, real-worl projects inevitably need them)

    10. VB.NET has no built-in comment->documentation generator

    And in case anyone is still reading… it’s hard to think of any advantage we’ve seen in using VB.NET. Maybe one: it made some COM coding easier because we could use late binding. I’d say if you are doing lots of COM interop especially if you need late binding, VB.NET is necessary. But I don’t recommend doing any more COM interop than you absolutely have to and late binding is worse than evil.

    I think that pointy-haired types think that VB.NET will make it "faster". That the learning curve will be less steep or that fewer changes will need to be made to the code. It just doesn’t work that way. Your project will take 2 or 3 times as long as you anticipated, even if you pick VB.NET. And when you choose VB.NET you may get started faster but you’ll be paying a tax forever, because the tools just aren’t as good as the C# ones.

    I’m crossing my fingers for VB improvements in 2005, but I’m not holding my breath. Doubtless something else will be "missed" (like multi-language projects were this time) and we’ll still be stuck in a VB.NET ghetto.

  26. paulvick

    DOH!, I’m sorry your experience with VB hasn’t been good. The good news is that VB 2005 should address mostly or fully issues #1-4, #9-10. I’m not sure what you’re running into with issue #8 – there should be no limit on line continuations, so if you want to submit some problem code using the comment form, I’ll take a look at it and see if we’ve got a bug. #5-7 still exist in VB 2005, unfortunately…

  27. amater

    Actually I’m little concerned about VB’s future with graduating generation of programmers. Most of today’s universities are teaching Java as a primary learning tool. And usually the academics view VB as a clumsy language for lazy programmers. Decades ago the most supreme business language was COBOL. Those who had a chance working with it know it is an outstanding languge that is dead meat, not because it is not used anymore (70% of World’s applications remain bounded by it) but because the new generations learned from their teachers that computer science is science, COBOL is for business and C is for math (math is science). Some may argue that there is COBOL.Net, however, seniors can’t stand OO way of thinking, juniors can’t stand OLD language stigma so it is also dead before it is born. Having C language culture and nowadays Java transfered from teachers to students, what do you think IT managers will prefer for their departments growing potentials if they choose to acquire .Net?

    If I was a manager I would surely choose C# for several reasons:

    1- So I can get the brightest of new (low payed) grads up and running in no time.

    2- So I can get too that C++ like language fame surrounding my projects and yet get it RAD.

    3- So I can leave infamous VB lazy clumsy programmers gossips roam as they wish without feeling their sting.

    But I am a developer so I choose C# for:

    1- No job is secure, so I’d better get used to curly brackets and once I learn most of XML, web services, SOAP, etc., then I am empowered to switch easily to that other half of corporate world that is using J2EE.

    2- It’s more stylish and attractive (yes it does matter if you are going to spend most of your day on something then better love it).

    3- Because VB’s parents Bill and Mic seem to undermarket it in favor of C# (could it be they are trying to abandon the ship?).

  28. Pingback: Coding Horror

  29. Pingback: Anonymous

  30. Jame

    I’m glad to see I’m not the only 1 debating this (both with myself 😉 and colleagues). At the end I choose to certify in C# because:

    1. C# is an ECMA language and I can then have a greater choice in compiler, IDE or possibly platform (linux?)

    2. The C# language will always provide up to date .NET functionality and support. As you know VB is only now getting operator overloading and I read that initially you would not be able to create your own generic methods in VB. (this has been corrected recently)

    3. VB syntax is overly verbose and clumsy. It’s like speaking baby talk all day.

    4. VB tends to make you a lazy programmer. Although you can be more productive, I have a more technical focus than a profits focus and think that lazy methods have no place in a professional field such as this.

    5. C# is aimed more at Enterprise development, while VB is more RAD.

    6. You learn the .NET framework, thus a change to any language is purely syntactical. I can safely say that I actual code better in VB.NET than my colleagues who moved from VB6 and have at least 4 years more experience than me. (Also in part due to the OO issues VB6 developers have raised above)

    I do respect some of the point raised by contributors here, but the above factor influence my decsion, no regrets.

    Any comments welcome

  31. FromTheOtherSide


    I think I can give another point of view. I hope it helps:

    I work for a large institution in Europe. We’re using J2EE and we’re really happy with it, but the situation about .Net sounds to me like the situation we lived in 2001.

    Four years ago, 80% of our applications were made using C/S paradigm, in Oracle Forms Developer tool, and we needed to start web programming. We choosed J2EE (four years ago .Net was just a marketing promise, and that decision was easy to take). The problem began trying to move C/S programmers to web programming, no with the adoption of a new lenguaje, but with the adoption of new concepts: OO and distributed programming and multitasking issues and WebServices and legacy integration… These topics aren’t needed to face in C/S aplications, and still we have requirements which can be fulfilled using just C/S programming. So, those who doesn’t like OO+Web, still can find a place. But IMHO is useless to try to mix both paradigms at language level. New environment, new language.

    I think the solution in VB6-VB.NET question is to keep VB6 where it solves problems, that is, in L.A.N. environments, and adopt C# as quickly as possible to face Internet developments.

    Bill Gates must consider not to abandon VB6 support, empower C#, seek for the possibility of C#-VB6 integration and forget the VB.NET adventure.

    … just a suggestion from the other side.

  32. lucifer

    I dont’ really believe in all the stuff mentioned here.

    I came from VB6 and went deeply into VB.NET. And i belive my JavaScript, ActionScript (in Flash MX) and little C++ experiences have really helped me in learning C# too, but choosing C# for that is sth that i might never do while i see that in vb 2005 many issues mentioned here will be solved. (If you think RAD is a bad think, then better stick to C++ forever, since C# is bounded to the framework in power and speed…just like VB.NET). I know that dirty coding or Lazy coding are not specific to VB. They depend on the developer herself. And most of the laziness will definitly come into C# average programmers as well when there is a more supportive Intellisense for them in VS 2005. So, if i go crazy, or i feel that i am RADign a lot, for the sake of the average C# depelopers, i turn the intellisense off and set the Option Strict ON. ( just my idea!)

    (PS: I know many people here have a C/C++ background . C# was made for them i believe)

  33. M.senthilkumar

    If Your previous Experience in VB the you can easily move to,If your Previous Experiance in C# move to

  34. Marks

    Just check out a job site. Here you can find that they are asking more programmers than c#.

    Also pls checkout palnetsource code "All time hall of fame" .Most of the popular codes are

  35. Ryan

    The debate about which is a better choice based on market wants and developers laziness or lack thereof can go on indefinately. (Or until MS stops support of one) My question is; however, a bit more pragmatic. Which language is a better choice for performance and capacity? A VB6 programmer can learn either language fairly easily if they are intelligent and REALLY understand OOP, but unfortunately most VB6 programmers don’t due to the limitations of VB6. The real underlying question is:

    Does well written VB.NET code support more users and higher volume of use or does C#.NET? If one is better than the other all these minor differences in development time is irrelevant. If your shops needs 10% more time to develop in C# then the above comments point to VB.NET and vice versa. The bigger problem is you told the CFO you needed $250,000 for hardware to support rollout and X number of years of growth. Your growth estimate happens to be short 40%, now which language is going to hold on longer before you have to buy more hardware or re-write the code? I understand most of it boils back down to machine code driven by the .NET CLR, but does VB.NET use more low-level marshalling than the C# and therefore produce more overhead? Or has VB.NET truly become as effecient as C# when executed on the same machine?

  36. paulvick


    VB is as efficient and as scalable as C# when doing comparable things. In other words, you can write inefficient and non-scalable code in either language, but neither language is inherently more efficient or scalable than the other.

  37. Dave B

    C# programmers earn more than VB programmers because typically their background is different. If you go to school and spend 4 years getting a CS degree they’re going to teach you C / C++, not visual basic (you might get 2 weeks of vb as part of some general purpose programming class). People with a formal education in computer science learn C++ and Java, and naturally end up in the C# space.

    VB programmers on the contrary, usually are people that started tinkering with VB at some point because VB makes it easy for anyone to make a program. However, the debth of their understanding of computer science is not the same of the person with formal Computer Science education. They don’t have the same understanding of how the CPU performs context swaps and how that effects multi-threaded programming and resolving resource contention issues, signaling etc.

    Ever hear the phrase "real programmers dont eat quiche?" That’s what C programmers used to say about Pascal programmers and its as true today about VB programmers. VB programmers don’t have the same capabilities (IN GENERAL) as C# programmers.

    I only hire .NET programmers who are comfortable in c# even if they’ll be doing maintenance on VB.NET preexisting code as part of their duties.

    By the way, I found this thread by googling "VB.NET SUCKS".

    Ok now flame on VB programmers! 🙂 I look forward to your angry backlash comments.

  38. paulvick

    Dave: Unfortunately, I think you’re a little late to the comment thread (this entry is about a year old) to provide too much backlash, but we’ll see!

  39. Jon D

    ===== Paradigms =====

    VB6 is an Event-Driven programming language where by C/C++ is an Object-Oriented programming language.

    These two paradigms are as different as night and day and the developed product will reflect the paradigm the programmer adheres to MORE SO than the programming language he/she uses (VB.Net / C#).

    An application written in .Net in either language (VB.Net or C#), by a programmer using the Event-Driven paradigm, will evolve around the form. The form will define simple variable types which will be acted upon in the form’s event call back methods.

    For Example:

    Clicking on the SendMyMessage button on the form would call an event that might do the following:

    // init string Message

    // append to Message UsersFirstName-TextBox-Value

    // append to Message delimiterValue

    // append to Message UsersLastName-TextBox-Value

    // append to Message delimiterValue

    // append to Message Message-TextBox-Value

    // init and open port

    // send Message

    The same application written by a programmer using the Object-Oriented paradigm will use the form’s events as a spring board to set object properties and call object actions.

    For example:

    Clicking on the SendMyMessage button on the form would call an event that might do the following:

    // init MessageManager

    // MessageManager.FirstName = UserFirstName-TextBox-Value

    // MessageManager.LastName = UserLastName-TextBox-Value

    // MessageManager.Message = Message-TextBox-Value

    // MessageManager.Send()

    NOTE: The two examples are exceedingly simple and don’t really express the vast differences in the two paradigms. If you truly understand Event-Driven AND Object-Oriented programming then the examples are sufficient to make my point. If you don’t understand one or the other, then you’re going to miss the point.

    ===== Where and When =====

    The Web IS an Event-Driven environment and ASP looks like VB.Net in many respects. So, for Web / Web Services development, VB.Net might be more appropriate.

    Since objects are a way to consolidate like logic into manageable chunks of … well … objects and thus makes conceptualization of larger more complex application easier by breaking them down into smaller pieces, the more appropriate C# becomes.

    Prototyping concentrates, often enough, on what the user will see, not the back-end inter workings. Since the main concern is how the form will look and act, VB.Net is IDEAL for prototyping. Oddly enough, this is even truer if your application will be written in C# since this will cut back on the ‘lets use our prototype code as the building block for our actual application’ temptation.

    ===== Summation =====

    It’s not the LANGUAGE that dictates which paradigm the application will fall into, but the MIND-SET of the programmer, the environment the application will run in, and the application’s purpose.

    For those shops that develop Event-Driven applications, then I would suggest VB.Net.

    For those shops that develop Object-Oriented applications, then I would suggest C#.

    ===== Disclaimer =====

    My comments are BRAWED generalizations. They are by no means black and white and are presented as such.

  40. Thomas

    Taking a value returned from a SQL query and populating a textbox with that value went from 1 short line of code to multiple lines of code split over several places in my code. Whatever moron thought of that bright idea should be shot immediately. For that reason alone VB.NET is a piece of crap. Any language that follows that line of thinking on something that WAS very simple.. well I don’t want to find out what they did to things that were already complex in VB6.

  41. Chris Rust

    Many comments in this thread are ones of pure snobbery. C# programmers generally come from a C++ background and hate to see their territory being eroded by the VB riff raff.

    Both languages are first class OO citizens, I prefer VB.NET as I believe developers can be more productive in it. TIME is MONEY

    I note the C# is gaining favor over VB.NET but I think this is snobbery related too. Interestingly when MS presenters demo to mainly VB developers they always use C#. I witnessed (to my amusement) a MS presenter struggling with C# case sensitivity with a failed on stage demo.

  42. Mark

    I can personally tell you that I started with MS DOS Basic, moved on to Visual DOS Basic, then to Visual Basic, VB6 and stopped there once I started using C#. I have always been fascinated by OOP ideology and I strongly believe it is the better choice of modeling real world scenarios in a developing framework. However I always enjoyed the ease of use with VB. Now I feel I still have the ease of use with C# and the ability to use the OOP model. Consequently, my current choice of language is now C# and I choose not to return to VB for any reason, business or pleasure.

  43. Stan Mlynek

    I also pondered on this issue, since we are being forced to move from VB6 the question is VB Net or C#.

    Initially, I went the C# route because I felt it would be new beginning, like a trophy wife in mid age.

    After getting reasonably proficient at it, I tried to envision actually using it in a real manufacturing environment where in some cases with VB6 you actually have to stand on your head to get a shipment out the door because hardware and/or people have failed and you have to reprogram the app on the fly to meet a critical deadline. C# is not suited to this. Too naggy and bitchy.

    With the arrival of VB Express, I am now migrating apps to it, and since I understand C# I can visualize what/ where VB Express is hiding code which I need to see when I am trying to figure out what it is doing behind the scenes.

  44. Phil

    I am a British company accountant and I’ve been using VB successfully for years to create turnkey applications for my management accounting purposes.

    Am I being naive in thinking that VB was invented for people like me to create workable routines very quickly inhouse, rather than commission a software house to produce very expensive systems to do the same job?

    I wonder if anyone knows how many inhouse amateur developers there are like me, compared to programmers in professional software houses?

  45. Lucas

    I’ve found that C# is way more in demand than VB.Net in my job search in the LA area. Kind of frustrating, but I’m coming to terms with the fact that maybe I should familiarize myself with it, because that’s all it would take I think to get a job.

  46. SSZ

    Sorry but you Americans (you guys don’t have your own language) are wrong as the English language has been created by the English are therefore when we spell something, you guys have no right to object. It’s you guys have the weird and funny spellings.


Leave a Reply

Your email address will not be published. Required fields are marked *