Related
I saw a thread similar to this, but the reason I'm asking this is because my situation is different.
I've been a tester (automated and manual) but I have a good Java programming knowledge although I haven't worked as a programmer.
My company is considering to move me to a C# programming role. Will it be hard for me to learn C# without any prior experience in programming?
Thanks
My 2 cents is that once you understand core concepts of programming you can move to any programming language. Try and remain as language agnostic as possible.
Specific to your question, you should be able to make the transition without much effort at all.
C# and Java are so similar you won't have any problems at all. That said, there are a few differences, this page does a pretty thorough job of demonstrating them.
One thing it doesn't mention is LINQ, which is definitely different as we're seeing the two languages start to diverge a bit more.
I have difficulties combining the statements "I have good Java programming knowledge" with "without any prior experience in programming". How can you have good Java programming knowledge without any experience in programming?
That said, if you are an able Java programmer, moving to C# should not be very difficult.
Speaking strictly about syntax, C# pretty similar to Java so you should have no problems there (at least it will feel familiar at first).
Moving to C# will not be a problem at all.
Since you already know Java, you'll find many concepts in C# easy to understand.
In fact, it's always a great thing to learn and work on multiple languages throughout your career, especially if they cover different paradigms.
I've had 4 programming jobs in my life, and for 3 of them I had no experience at all with the language before starting the job. The 1 for which I did have experience ended up being a complete disaster of a workplace.
If there's any correlation between how well you know a specific programming language before taking a job, and how you can get/do a job at a place where they use that language, I have yet to see it in my 10+ years. I'd say it's probably one of the least important factors contributing to your success.
Unless you plan to work at a company for a very short period of time, you'll learn many new things, and probably new languages, while working there. Whether you happen to know the one they're using now is like how tall Michael Jordan was when he was in high school: after a few dozen/hundred/thousand hours of practice, completely irrelevant.
Without any industry experience in Java it won't be easy to work in... Java. What I mean is you will have exactly the same difficulties in C# as you would have in Java. The language change won't be the problem -the big difference will be working with real world requirements and practices.
Don't take me wrong, I don't mean you will have problems: you'll just learn a lot of new things. If you have a solid "conceptual" base switching from Java to C# will be easy, I did the same pretty much effortless.
Read a good book (for ex. Troelson's Pro C#) and you'll quickly pick up the most important differences. Then with time you'll learn the other stuff that is really different from Java (for ex. WPF, Linq, etc.).
In conclusion, don't be afraid and go for it!
C# should be trivial to learn if you know Java. The differences at the programming level are largely syntactic for the most part.
The difficulty (and this is the same with Java) is the language is just an enabler for a large number of libraries and technologies. So you could have no trouble picking up C# but you might hit a brick wall learning WPF because there is no analog in Java. etc. Or you might be trying to write ASP.NET but you have never learned JSP / Spring in Java so have nothing to relate to.
The best strategy is start small, get familiar with the constructs and then try to implement something useful. e.g. in WPF, you could write a simple Twitter client using webservices. In ASP.NET you might write a simple blog app hooked up to database app.
Once you get the basics and assuming you follow best practice, it should be easy enough to expand outwards.
If you have programming knowledge skills it would be not very difficult to move into c#. In my experience coming from PHP I suggest you the following steps,
Books:
1- C# 4.0 in a Nutshell The Definitive Reference
2- Apress.Pro.ASP.NET.MVC.Framework
Tutorials:
1- check the website http://www.asp.net and probably the best thing could be to move directly into MVC
2- check the nerddinner tutorial http://nerddinnerbook.s3.amazonaws.com/Part1.htm in order to get in knowledge of how this work.
3- Download Nerddinner code http://nerddinner.codeplex.com/
4- use entity framework instead of linq based on MS election for the future
5- Download some starter-kits from http://www.asp.net/mvc/samples/mvc-music-store to check the way it work.
Hope it helps. brgds,
I'm about to start working on a rich-internet-application project for a student organization at my university. I will be the only programmer, and what technologies to use is totally up to me. I've already decided on going with Silverlight, but I'm not sure whether to use C# or F#. Here are some of the things I'm keeping in mind:
C#:
I already know it and have used it extensively with Silverlight at work. I have no F# and little general FP experience.
Some say the OOP paradigm works better for complex stateful UIs.
Maintenance: I'll be in school for three more years, but after that if the app is still in use they may have a better time finding someone else to maintain it if I use a more common language.
C# experience is probably more valuable in the "real world".
F#:
The main reason is I want to learn something new. Functional programming languages seem pretty cool (I find myself using the FP features of C# very often, and think they're the biggest improvement in C# 3.0). I think I'd have a lot more fun if I used F#, but am I being unrealistic in thinking the cost in time and effort might not outweigh the benefits?
In my opinion, when you are a student, you should be trying to put your fingers in as many pots as possible.
The more languages you play with, the more understanding you will have of the "best" ways of doing things in a specific language.
As for "experience" being more valuable in the "real world". Personally I only ever consider true commercial experience when looking at potential candidates. Experience in a language when you're in a job and being paid is extremely different to experience in using a language when learning / studying it. Things you do whilst studying are about gaining skills and knowledge whereas things you do in a commercial environment give you experience in solving real life problems.
Bottom line... play with the cool stuff whilst you still can!
Because you expect to create something useful that will live past your tenure as maintainer, I would suggest writing the majority in C#. What you can do to scratch your new-technology-itch, though, is pull out distinct, well-defined components that don't interact directly with the UI and write those in a separate F# assembly.
I've done something similar with a project that I've open sourced in the past. My fundamental UI logic (in this case, the V-VM parts of the M-V-VM) were in C# because it works so well with WPF technologies. Then, certain functionally-oriented components of the Model itself I broke out into a separate assembly and wrote in F# just to get some limited exposure to the language.
It's not a jump-with-both-feet approach to learning technology, so I probably didn't learn as much as I could have. An F#-only project wouldn't have taught me nearly as much about exposing F# functionality to the greater .Net world in a friendly way, either, though.
No matter what, the key in a situation like this is for you to have fun and enjoy what you're doing. :)
You can make F# business logics project (a dll).
And then the user interface in C#. And in user interface project you can add a reference to the F#-library.
This is a good solution in general when using Silverlight: The power of F# is (functional) programming but currently C# will have a better tool-support.
I know it's not in your list, but if you're interested in learning something new, you might consider GWT - You write your client in Java (which ought to be an easy jump from C#), and then the compiler turns the client side into JavaScript. Should be a bit more cross-platform compatible than Silverlight, and it's an interesting fusion of technologies (CSS, JavaScript, and Java aren't going anywhere in the near future).
I just gave a talk about programming reactive Silverlight applications in F# at London F# user-group meeting. The recording of the talk (and samples) are available here, so you can take a look at that.
Here are a few points you could consider:
I think F# has some very nice features that make programming this kind of applications more elegant than in C# (for example, you can nicely model program as a state machine and encode this direcly in code).
F# is still relatively new, but I believe that there is a decent chance that finding someone familiar with F# after three years will be much easier than today (and finding younger students who are interested to learn something new should be easier :-)).
I was surprised that there is already quite a demand for good F# programmers in the London area. This will be probably different in different places, but I think that F# is becoming a "nice-to-have" feature on CV for some jobs.
I'm presuming that this will be used in an intranet environment. Otherwise, I'd question whether the choice of Silverlight is really the best due to market penetration.
The second point I'd raise is that one of the really key skills for most web developers is Javascript. (Nowadays, that would be Javascript with a library like JQuery to manipulate the DOM, simplify AJAX, etc.) unless the application is particularly complex, there might be some merit in considering DHTML+Javascript as a starting point, and only looking at other technologies if it proves too much for that.
However, if you're set on going down the Silverlight route, then C# is by far the most likely to be supported. If you're still learning, then it's also the route that has the best documentation. F# has some excellent documentation around, but unfortunately not nearly as much as for C#.
You briefly mention the time and cost commitment. Unless you're quite comfortable with functional programming, F# is liable to take significantly longer, in part due to unfamiliarity and in part due to the amount of reference documentation to help you on your way.
While it it undoubtedly good to have knowledge of a range of programming languages under your belt, what's more valuable to most employers is a solid understanding of their language of choice - so diversifying too much can miss that. When looking to learn an unfamiliar programming language starting with something like solving Project Euler problems may present a better way of starting out, rather than diving straight into a major project with a new language. If you start in C#, you can always create an F# project that implements functions more suitable for its focus, and reference it from the C# one, to dip your toe in its waters while not automatically committing a lot of additional time to it.
I have a little programming experience with vb 6 and vb.net not much. Please tell me the best way to become an expert C# programmer and I know it will take a long time.
Think about how you learn human languages - reading, writing, speaking and listening.
Read code. Read articles. Read examples. When you're more experienced, look at the source code for some projects that you use.
Write code. Play with the examples you've read about. Modify them. Solve problems from Project Euler. Think of your own projects then try to solve those.
Talk about code. Blog about it. Tell your friends about it. See if you can impress your grandmother with how good your program is. Now try to impress your professor. Learn how to communicate about programming with different types of people.
Listen to other programmers. Many of them have more experience than you and have useful things to say that you can learn from. Learn the vocabulary they use. Discuss your ideas with them.
Practice. Practice. Practice.
Google is your friend.
Start by downloading http://www.microsoft.com/express/ and start programming. If you don't have a project of your own or something someone else wants done, start looking up popular algorithms and implement those. Try implementing certain design patterns. This way rather then just focusing on syntax your learning a heck of a lot more about programming in general.
Even though I feel the other answers on this thread already well-cover the bases, in terms of replying to a pretty "nebulous," even "naive," question : I'm going to add another opinion (slightly too long to just be a comment).
I respectfully disagree with a few posts suggesting an analogy of learning a programming language to learning a spoken, or written, language. SO is not the place to discuss linguistic theory, and its relation to evolution, and cognitive structure, and the work of Chomsky, and Pinker, et. al., which suggest not only language learning's "innateness," but also how variation in "endowment" (genetic, and, yes, even "temperament"), and its dynamic interaction with environment, and "developmental windows of opportunity" at which learning can take place at phenomenally accelerated rates, contributes differentially to morphemic versus phonemic competency, etc.
But, please allow me just to register the hypothesis that there are many ways in which the analogy of learning a programming language to learning a spoken and written language is more of a "catch-all" that masks complexity, rather than a useful tool.
On the other hand, I suspect (hypothesis) that a person who has achieved mastery of more than one spoken/written language has, indeed, developed certain cognitive structures and skills that may be "useful" in learning a programming language.
To my mind the above two paragraphs are not inherently contradictory statements.
imho programming in general is also not analgous with learning mathematics or geometry which build structures up from axioms, or fundamental assumptions, into complex systems that sometimes can be "formally" proven, or validated. Of course there are some "rare birds" who start off from Knuth, or Gamma, et. al. and "Design Patterns," and "work their way down" to the "real world" :)
My "vote" goes with starting with a good book, and, as Mark Byers suggested, combining that with practice, testing yourself, taking on problems like those on the Euler project Mark mentioned, and, yes, certainly, also as Mark suggests, studying other people's code.
The question, in the beginning, though, is, imho : how to know which code is good to study.
For me the answer to that is : study the code examples provided by really good books like those by Jesse Liberty, for example : "Programming C#" latest (3rd.) edition from O'Reilly. Note : my understanding is the 4th. edition is due in March 2010.
imho Jesse has an unusual gift as a teacher of programming languages, an ability to "pace" the introduction of material in a skilfull way, to select and present the right examples in the right sequence, and remarkable gifts of clarity in his technical writing.
CodeProject articles are a great resource for code examples to study. Look for articles in areas that interest you that have a very high rating by other users, and are specific to C#.
The lesser-known book by Liberty "C# 2005 : A Developers's Notebook" is a fantastic resource (also, imho, one of the most fascinating books in terms of graphic design and book structure, ever done in any technical arena). It's a series of "exercises" that I would compare to the idea of "etudes" in music : each exercise demonstrates a topic, challenges you to understand a good example of that topic, and each topic is really something that will be useful in your "real-world" programming.
imho, once you have your "feet on the ground" with a hundred hours or so of study and practice of .NET : fly, don't walk, to the "guru-level" with Jon Skeet's "C# in Depth" published by Manning. He also, imho, is a superb technical writer who shares with Liberty the gift of selective presentation of material, and has his own special, unique, gift for "stepping out of the book to speak to you directly," addressing the kinds of concerns you are probably thinking about as you encounter more difficult material. I should note that I feel I am a long way from mastery of the content of this book, which just whets my appetite for understanding it. There's an element of wit and humor in Skeet's writing that also, in my experience, is extremely rare in technical books.
Please note : disclaimer : while I have worked as a paid consultant for Addison-Wesley on the technical editing of two major .NET books, I have never worked for O'Reilly or Manning, or received "comp" copies of their books (dammit :).
I must, respectfully, disagree with the recommendation of "C# in a Nutshell" by Albahari and Albahari (also O'Reilly; I believe 4th. edition is out now : I have only seen 3rd. edition) above : I think it would be a very inappropriate tool for a newcomer to .NET. On the other hand, when you get to studying Linq : you'll find, imho, that Albahari's website and free version of LinqPad is just the coolest thing ever done for helping you "get into" and explore Linq.
Good luck !
The same way you learned VB6 and VB.NET, no doubt. Pick up a book, and start reading. There's nothing radically different about it that requires any esoteric approach to learning. Just good old fashioned squatting in Barnes and Noble for a few hours before breaking down and buying a book. You could also mosey around http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx and read up a bit.
If you've already been using VB.NET, C# should come pretty natural to you. The syntax will be different, but the objects, methods, etc will all be familiar. Check out the tutorials on MSDN for C# too: http://msdn.microsoft.com/en-us/library/aa288436(VS.71).aspx
Oh, and welcome to StackOverflow!
If you're already familiar with other programming languages, the O'Reilly "In a Nutshell" books are generally a good place to start. "C# in a Nutshell" is both a good introduction and a good reference.
Download Charles Petzold's .NET Book Zero and read it through from start to finish, skip nothing even when you think you a fair bit about a particular area.
I just graduated college and will be starting working in about a month and I was asked to familiarize myself with C++, C#, .NET framework for NT Services and web services.
I'd appreciate recommendations on how to familiarize myself with these topics (books? internet links?) in a short time span. I don't expect to be an expert on it in a month but I don't want to be clueless either. I already know C++ and I consider myself to be fairly proficient in it and I know the basics of C# even though I haven't used it all that much. For C# I do own a book called O'Reilley Programming C#.
Thanks!
I would start by pulling down Microsoft's Visual Studio Express products. Your O'Reilly book is a perfectly good book to start with.
Start reading blogs and listening to podcasts, to begin to familiarize yourself with all of the technologies out there that surround c#. You will be very excited about what you can learn. Here are some of the better ones:
http://www.hanselminutes.com/
http://www.dotnetrocks.com/
http://channel9.msdn.com/
http://weblogs.asp.net/scottgu/
http://weblogs.asp.net/
In addition, the MSDN library is an invaluable resource. You can almost always find what you need there. This is where the reference for the entire .NET framework lives.
http://msdn.microsoft.com/en-us/library/default.aspx
Happy hunting!
Nothing beats actually using the language. As much as some of the information sources already quoted would be very useful to check out, I'd say make sure that you at least try and write some concrete C#.
The best place to start might be a non-trivial-but-not-too-large application that you have already written in something you know, and try to convert it to C#... even better if you can get somebody proficient in C# to peer-review your results to make suggestions where you could make better use of the language-specific features that may be new to you.
Fundamentally, if you just read books and watch videos, you may feel like you actually know it, but it is nothing like doing it yourself (as my Uni maths classes taught me... a good teacher can make the impossible look trivial on a blackboard).
That is a huge surface area. Pro C# 2008 and the .NET 3.5 Platform by Andrew Troelsen is a good place to start.
These are good podcasts that will give you an overview:
.NET Rocks
dnrTV
Herding Code
Microsoft Labs and Webcasts
Here's a good SO thread with lots of resources. I recommend you check out MSDN Virtual Labs. They have lots of great training that let's you get your hands on the technology, in particular, check out the C# ones.
I was in the same situation in late November 2008.
If you are familiar with IDEs and another programming language, download Visual Studio Express and start playing with it. It's free :)
http://www.microsoft.com/express/
And I always recommend this webpage:
http://www.java2s.com/Tutorial/CSharp/CatalogCSharp.htm
You can select the relative topic you are interested on this stackoverflow site based on the tag name, and read through some posts, it will give you a good feeling what are common issues/challenges people face in day-to-day programming.
One way is listening to podcasts. We do one called Deep Fried Bytes that contains a variety of topics on any and everything.
I'm asking this question as someone who works for a company with a 70% to 75% VB.NET developer community. I would say 80% of those developers do not know what an OOD pattern is. I'm wondering if this is the best thing for the health of my company's development efforts?
I'm looking at the tag counts on:
https://stackoverflow.com/tags
There are currently:
12175 .NET questions
18630 C# questions
2067 VB.NET questions
Checking Amazon, it seems like there are:
51 C# Wrox books
21 VB.NET Wrox books
On CodePlex there are:
979 Projects tagged C#
136 Projects tagged VB.NET
There is definitely less materials to learn from if you wanted to be a VB.NET developer.
What would be a company's advantage to standardizing on VB.NET and hiring VB.NET developers? How does Microsoft answer this question?
Is the only two arguments:
We had these VB6 programmers and lets make them comfortable
XML Literals
If you work for a company that has completely standardized on VB.NET, can you post an answer explaining the pragmatic or technical reasons why they made that choice?
UPDATE:
More stats - O'Reilly Radar
State of the Computer Book Market 2008, part 4 -- The Languages
We're not standardized on VB.Net, and I often have to go back and forth between VB.Net adn C#. I'm unusual, in that I come from a C/C++ background, know C#, but actually prefer VB.Net (I severely dislike vb6/vbscript).
I say all this because it's important to remember the VB6 is NOT VB.Net. It's a whole new language and IMO does deserve to stand up next to C#. I really hated vb6, but I fell in love with VB.Net almost instantly. However, VB.Net did inherit some things from VB6, and not just a syntax style. I'm talking reputation, and that's not entirely deserved. But I'm also talking about the developer base that helped create that reputation. That seems to be part of what you're experiencing.
With that in mind, it looks like you're judging the language based primarily on popularity. Not that there's anything wrong with this. There's plenty to be said for the ability to more-easily find samples and community support. But let's at least call it what it is. And if that's your measure, there's certainly enough support out there for VB.Net to make it viable, and it's not hard to take advantage of the C# samples.
Also, we're still on .Net 2.0 where I work. For 2.0, I definitely prefer VB.Net. I like the syntax better and I like the way it does a few other things over C#. But I play around with Visual Studio 2008 at home. On 2008 I really prefer the C# lambda expression syntax.
Regarding your two arguments:
For #1, that may not be such a good idea, though I suspect it's the primary reason for many shops.
For #2, I've never used Xml literals. They looks nice, but just haven't been that practical.
Something I wanted to add: it seems like some of the recent C# features are actually intended to make C# work more like VB. Static classes fill the conceptual space of a vb module. The var keyword makes variable declaration look more VB's dim. The upcoming dynamic keyword will allow vb-style late binding. Even properties, which is something you could say was "added" to c# for 1.0, are something that vb has had since before .Net.
As a VB.NET developer, here's what I don't like about C#, granted my experience is from reading C#, not writing it so much:
1) No edit and continue. I've seen arguments that Edit and Continue is a bad thing and that it encourages bad coding habits. It reminds me of my project manager telling me 25 years ago that my love of my then-advanced debugger was a "crutch" and that it encouraged bad programming habits. Sorry, I didn't buy it then, I ain't buying it now. At the very least, the advantages outweigh the disadvantages 10:1. Once C# gets this feature, you'll appreciate it more and really appreciate it if you ever have to code without it again.
2) The language is case sensitive. IMHO, this is pure evil. Would people agree that it is bad to have two variables in the same scope that vary only by case? If so, why allow it? Yuck.
3) Background compilation and hence better design-time feedback of errors. A mixed blessing, as this slows down the IDE. But with 2008, performance is better and is probably a time saver. Course, this is not a factor of the language itself, just the dev environment.
4) Braces {}{}. Reminds me of my LISP days where you can tell a LISP programmer from other programmers: They're the ones with their fingers on the screens trying to match up parens.
I find the following VB code easier to read and less likely to contain errors.
If condition1 then
truestatement1
truestatement2
else
falsestatement1
falsetatement2
end if
If (condition1) then {
truestatement1;
truestatement2;
} //if (cond)
else
{
falsestatement1;
falsetatement2;
} //else (Condition)
All those braces with lack of auto-indent are just begging for compile time or run-time errors. And as the nested ifs get complex, the braces just add to it. In place of the 4 braces in the C# example, the VB code has just one END IF statement, but C# programmers that comment like to add optional comments as to what block the brace is end bracket is terminating.
The VB code is self documenting with less typing--the IDE even adds the END IF for you when you type in the IF condition line. So, in the end, I am missing the brevity simplicity/benefit here that C#-aficionados claim. The } might be more terse than the End If, but I'm suggesting that the overall structure is unnecessarily complex.
Granted, this all isn't that big of a deal, but as a novice C# coder I feel like it is a lot easier to mess up the nested conditions than it is to use VB.
I'm sure most of the time the reason companies go forward with VB.NET is exactly as you mentioned - large amounts of VB6 in the organization, both in terms of codebase and developers. Keep in mind that ASP websites and VB6 applications can be migrated to VB.NET with little to no pain. VB6 to C# is a different story.
That being said, having worked at companies that have used VB.NET, there's really very little difference in how you do things and developers who are curious get used to reading examples, books, etc. in C#. It's not like it's terrifically hard to translate C# code to VB.NET, especially if you're not copy-pasting.
To learn to be good VB.NET programmer you don't need to learn it from a VB.NET resource learning from C# resource is perfectly fine. If you can't even translate a C# code to VB.NET you got bigger problems anyway.
Almost all decent+ VB.NET programmers can read and decently write C# due to the things you just said, because otherwise you can't learn new stuff easily.
Finally, the people who are crap, are not crap because they are VB.NET programmers, that's just VB.NET is easy to code and it's not a bad thing! Also it's been said that most of these people coming from Classic ASP and VB6 background, which are again really low entrance threshold languages. After a week any decent computer user can code in those languages. But most of the C# developers coming from Java and C/C++ background. Especially Java side got lots OO in it. After all especially C is not easy to learn, most of the people either learned in the school or in a long course, or from bunch of books.
When it comes to a why company uses VB.NET it's mostly because of legacy reasons. Also some companies who jumped .NET 1.0 from VB6 thought that VB.NET will be the major language, which turned out to be a big mistake after couple of years.
Not looking for argument but as an old VB.NET fan:
3 . With statement, Handles statement, Module statement, XML literals, case-insensitivity...
4 . My namespace, Microsoft.VisualBasic namespace, all the "sugar-coating"
5 . Late-binding support and COM components interoperability
6 . Ermmmm..... (finger-crossed) readability?
As said, I'm not trying to be argumentative and I'm a big fan of C# but just that there is more to having VB6 programmers in a company to standardize on VB.
For example, COM interoperability could easily be a "show stopper" if you standardize in C# and your business depends on a lot of COM components...
And the sugar-coating support mentioned is rather huge (I miss them all the time writing C# code). I feels like there are more tooling support from the VB.NET team than the C# team while the C# team focus their efforts on more language features.
I'm currently working with a customer who is in the process of standardizing on VB.NET. The main reason is, as you mentioned, the fact that the majority of the employees have 10+ years of experience with VB and COM.They feel that going to VB.NET makes the most sense as a career path, even though they're well aware that very little of their existing knowledge base can be leveraged going forward.
Given this fact, they also considered moving to C#, which indeed seems to be the most used language on the .NET platform today. However, given the great amount of new knowledge they already have to learn in order to start using .NET, they preferred to go for a language with a familiar synthax.
In my opinion this proves exactly the purpose of VB.NET. That is to help bring the large base of VB developers in the world over to .NET, giving them the ability to use a language that "feels" familiar to them.
Also, the backwards compatibility layer built in VB.NET makes it possible to port existing (large) applications written in VB to new platform one piece at a time, while keeping them running.
The only argument I have to keep using VB.net is:
I hate case-sensitive languages (like C#)
It is dumb, the first thing after creating a case sensitive language is creating a best-practice "Do not use the same variable name with different case ever"
I know they want to copy Java case-sensitivity, but was really a dumb decision.
Re point 1:
Well, my shop was a VB6 house - with lots of VB6 code to support, and we moved straight to C# with no problems. We did have to think about the decision, but I am 100% (or more) confident that we made the right choice.
Re point 2:
You'd be amazed at how much I don't need this day to day ;-p
I have nothing against VB.NET - I simply feel that C# allows me to do my job more elegantly.
Re the books etc - I wonder if there isn't a contingent of ex-VB6 developers who are still writing VB6 in VS2008. Making the switch to C# really helped me appreciate the new (at the time) .NET architecture. If I had moved to VB.NET I don't think I would have made that mental leap - at least for some time.
This doesn't pertain to the question but to the comments being made to the questions
Reading this comments reminds me of back in the 70s and 80s when I read about people using any high level programming versus assembly. The assembly programmer had an 'elite' status compared to those who used high level languages like ... C!
And it was baloney then and it still baloney now that it is C# vs VB.NET.
Experienced programmers like using C# because it terse. There less damn typing involved. I rarely see new languages where they to try expand the amount of typing you have to do. C# is no exception.
But... there a problem with this. The problem of maintainability. The more terse a language is the harder it is to go back 5 years, 10 years later and read what you were doing. Which is why I use VB.NET in preference to C# or other C style language. And before you bust my chops about being a VB programmer I maintain software simulations of various historical spacecrafts in C++. I use both styles extensively.
Now it not a dramatic difference. But combine experienced programmers with the religious attachment many have to their favorite language it no wonder question like Tyndall comes up.
QuickBASC/PDS/Visual Basic family of languages continue to sell for Microsoft because they are not terse. Because they are more readable. While this feature doesn't appeal to many experienced programmers it does appeal to many starting out. Combined with the religious attachment many develop toward their tools they stick with it throughout their careers. Plus the Visual BASIC has a populist aura about it that is appealing to many.
Like most things with populist appeal is looked down on by the elites. Conversely it gives the language a lot of users. So it not likely that it will be axed by Microsoft any time soon.
I'm sure there are a lot more VB.NET developers buying books to learn C# than vice versa. They know they'll get more respect (reasonably or not) if they switch.
Paul Vick, who was the language architect for VB.NET at the time, wrote this in 2008.
Our users [VB developers] run the
gamut from people who are picking up a
programming tool for the first time to
industry veterans building large-scale
commercial applications. The key to
designing a framework that appeals to
Visual Basic developers is to focus on
allowing them to get the job done with
the minimum of fuss and bother... A
framework that uses the minimum number
of concepts is a good idea [for VB.NET
developers] not because VB developers
can't handle concepts, but because
having to stop and think about
concepts extraneous to the task at
hand interrupts workflow. The goal of
a Visual Basic developer usually is
not to learn some interesting or
exciting new concept... but to get the
job done and move on.
From the .NET Framework Design Guidelines 2nd Edition page 10.
Yes, there are more C# books, and the C# community is more active, but at the same time both languages use the same framework, and have mostly the same features, which means a VB.NET programmer can pick up a C# book and understand it with no problem if he knows the C# syntax (which is close to many other languages' syntax).
At the end of the day there is no BIG advantage of choosing one language over the other. Because of the reasons you mentioned, I'd choose C# if your team had no preference, but if most came from a VB6 background, I'd see no problem choosing the VB language.
That's what happened in my organization. Most of our software was written in VB6 before so they decided to go with the syntax that the team was already familiar with, and I don't have a problem with that.
I worked for a small company with an existing ASP/VB6 codebase, built by several different devs, each with their own "stamp" to put on it.
Like many, BASIC was my first language in the early 80's, but I "graduated" to assembly (6502 and x86), and have wandered through many languages to what I hope is strength in C/C++ (tho' I always have more to learn). I'm very much a "right tool for the job" kind of guy, so I even learned (and learned to hate) VB, from 3 up through 6 and VBScript.
I picked up C# fairly easily, and was slowly working on converting my ratty old codebase to C#, when the company was purchased. $corporate_owner has standardized on VB.Net. The things that drive me nuts about VB are some of the same things that others love, namely all the syntactic sugar (excess verbosity).
There's also the dislike of VB among "real" programmers that Jeff has written about before.
All in all, VB.net just isn't "cool". However, it does have many advantages (syntactic sugar, familiarity, ease of learning); I know of at least one college that has a VB.net course as part of their required CS and CIS curricula.
Anyway, because of its ease-of-use, and the relatively straightforward upgrade path, I don't see it going away any time soon. At least it's not as brain-damaged as it used to be.
I think you will find its not the language but the people that use it.
Forcing these people to use C# wont solve the core problem.
However if you do program in C# chances are you are more likely to get a better class of programmer next time you hire if they have this as an existing skill. (This is not to say there are no good VB.net programmers, as i have known some great VB.Net programmers. Or even that all C# programmers are great.)
However in my experience the poorer skilled programmers tend to stick with VB and VB.Net and don't even want to look at C# or any other language outsite VB/VB.Net
I think its more to do with the potential target audiences that VB.NET and C# would have appealed to when they started out.
Under the hood, its all the same (well mostly) but .NET Winforms/Websites etc... what you can do in VB.NET you can do in C# and vice-versa. So the question isn't really relevant in terms of functionality
Completely subjective opinion, but I'd say anyone who jumped on the VB.NET Bandwagon would have come from a background in VB6/Classic ASP. However the ability to jump on the C# bandwagon extends to people with Java/C++/Other OO Backgrounds.
So from the outset, you have a larger community of people taking up C#, it makes sense that there are more educators/contributors/Open Source projects under that language
At my workplace, VB.NET was the standard up until recently as several of the previous developers came from a classic ASP background and were familiar with VB syntax. As our development team has matured, and we've adopted more sophisticated design methodologies (DDD, good OOD), there has been a natural shift towards using C#.
In most instances I would guess that shops using VB.Net is a pragmatic choice, rather than a technical one. That being said, VB.Net really is a much more capable language than it's predecessors - it just lacks some of the elegance of C#, and as you've discovered there's much more material related to development in C# on the web.
I'm only now making the switch to .NET, after having maintained existing VB6 code for a number of years following the advent of .NET. I believe I'm justified in considering myself a VB6 expert. My current employer is standardized on VB.NET.
For a number of reasons I find that I have some slack time in which to learn the new language. I'm using an ASP.NET book that has all code in both, and while I'm typing in the VB I'm making a point of reading the C# as I go.. There are a few things I've seen that one language does "better" than the other (a subjective call...), going both directions.
My sense so far is that by the time I finish this process I'll be able to go back & forth with a reasonable degree of comfort. I'm certainly not incurious--if I were, would I be here are SO?
There are lots of good answers here already, but my take on the original question is that what really needs to be answered is not why people stick with VB.NET, but rather what makes C#.NET the language of choice for .NET books, samples and toolsets?
I think there are three things operating here:
1. The first people into C#.NET were curious by nature - that's why they went for the new language rather than sticking with something interesting. So yes, it did get more curious people at first ;D
2. C#.NET was Microsoft's way of attracting Java programmers into the .NET world, and it worked pretty well. Many of the best ideas in .NET have been ported from Java, and hence get ported into C#.NET first. They only end up in VB.NET after they go mainstream.
See this article for an example of how C#.NET was seen as a reaction to the failure of Microsoft to have their own Java version.
One reaction to it is telling:
"I'm not a MS programmer, but if I'm
ever forced to move there from Java, I
know I won't be totally lost and
useless now that they have C#."
3. VB.NET programmers are as smart and curious as any other programmer, so when they see a C#.NET book that deals with a topic they find interesting they buy it and convert what they need to know to VB.NET - or even just implement it in a separate C#.NET DLL in their VB.NET projects.
It sounds to me like the programming language isn't your company's main problem. If I worked in your company I would set the priority on bringing the 80% who don't know what an OOD pattern is up to snuff.
Good code is good code, whether it's written in C# or VB.NET.