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,
Related
First, let me ask you to consider this as a real question, and not a subjective one.
That out of the way, here's my situation: We are looking to port our existing classic ASP application to .NET, but we're unsure of what language to use for the new app.
I personally would 'prefer' C#, as I'm more familiar and comfortable with that languages way of doing things, but, the original code is VBScript, so it would possibly be easier to port to VB.NET ... One possible situation I fear would be that, because the code is so similar between the two variants of VB, that we might end up getting stuck on something that is not similar between the two, even though it looks like it would work. A shift to a wholly different language might avoid that kind of situation.
Does anyone have any practical examples of this kind of situation? Insights to illuminate the issue with? Do the potential benefits of a complete paradigm shift outweigh the gains from a high degree of 'copy-and-paste-ability' ?
I have used C#.NET and just recently learned VB.NET and I have to say that once you get around the small syntactical differences, VB is also a very good language. So for you, this is a win win.
That being said, I think a syntax change will help protect the project from any careless copy pastes from the old dirty code base. I believe a fresh start with a fresh language is your best bet for a top notch re-write.
There are 10X as many questions re: C# as there are VB.NET on StackOverflow. That seems to indicate there are more developers using C#, or perhaps a more thriving community (or maybe it just means C# is harder or C# developers don't know as much).
Any gains made due to the similarity of VBScript to VB.NET are far outweighed by the fact that you need to learn the new data types, .NET namespaces, and a new style of web development using webforms or MVC (my preference).
For this reason I think the choice of language should be made independently of what was used before.
3 years ago I had to make this same decision. My preference would have been C# but we ultimately went with VB.Net because that was the closest language available to the developer base we had. All of the developers had experience with VBScript, so learning VB.Net was easier for them. While the framework is the framework and the rest is just syntax and best practices, you'd be surprised the difference in learning curve just by adding a few curly braces for VB developers (the reverse seems to be exactly the same for C# developers going the other way with an itchy semi-colon finger, learning new keywords and relearning event syntax).
You should look at your developer pool and consider what is the easiest for your team to perform development and maintenance. If this is not a serious criteria (because the developers are proficient equally in both), then I would recommend a C# approach. The primary reason is that the VBScript will be relying on outdated methodologies, but converting to VB.Net will not necessarily throw exceptions for these methods whereas C# will. It will also force you to touch every aspect of your application, which (while tedious) will provide your team an opportunity to evaluate how older methods may be refactored into more efficient processes.
Just keep in mind - the "easiest" seeming solution seldom is.
When moving to ASP.NET, I believe that less focus needs to be on the page itself, and more on how you're going to write the business logic. This is a subjective question because different units will have different results.
That said, always play to your strengths. If your team is more familiar with C# than VB.NET, use C#. If they're more familiar with VB.NET, use VB.NET. If they have no real .NET Experience, then you probably want to set up some sample projects with which they can play to see which will be easier to learn. You want the most bang-for-your-buck, and that means making sure the team is as comfortable as possible.
Further, I wouldn't worry too much about copy & paste code, as there are enough differences that any professional developer (as in one who acts professional, not just one who gets paid) will see how much he/she is changing and go back through the rest of the code to ensure it is working properly.
The difference between an ASP.NET and Classic ASP application is already so big, that it will not be an easy copy/paste port anyway.
So I think you should go for the language that you feel most comfortable with (and as another answer suggests, there is a much larger community using C# than VB.Net).
Why are you rewriting the application? What are the short and long term objectives you hope to achieve through this change?
At a high level there is not much to choose between VB and C# - both are extremely functionally rich labguages that compile to teh same IL code.
Personally I moved to C# a few years ago because the vast majority of code examples found on the net are in C#, and the programmer's best friend is the internet where you may just find that nugget of useful information that save you hours of head scratching.
In your situation, by fircing yourself to rewrite the code in a different language will force you to possible rething the implementation and therefore review carefully the code and functionality required - if yuo have the time and budget. If you are up against tight deadlines then VB would be the natural choice, but may negate the benefiots if the rewrite.
I have been in exactly this position, and I urge you not to translate the app in two ways at once--from VB to C# and from classic ASP to ASP.NET.
You have chunks of business logic in your code that will not need to change much, so why change it? You are guaranteed to introduce new bugs in the translation.
I can't count how many times I thought, "this looks exactly the same, why isn't it working?"
Just adapting your code to the new codebehind pattern will be challenging enough. A vast and worthwhile improvement, of course, but not trivial.
VB.NET and C# are so incredibly similar that technically the choice is almost irrelevant. Each language has some minor things they excel in, but overall, the two are practically identical, just with wildly different syntax.
With that said, I highly recommend going with C#, just because it's the language the .NET community really got behind. It will have the most books, websites, blogs, forums, you name it. Not having to translate the oodles of examples out there on the net into VB.NET alone makes C# a better choice. I think in my 10 years of being a .NET developer, I could count the number of people I've ran into that genuinely chose VB.NET on one hand. Most people that are using VB.NET are using it in a "stop gap" fashion, with the intention of ultimately going to C#.
Many people go for C# because they think that VB.Net and C# is only syntactically different which is just not true. VB.Net has better features for handling interactions with COM components for example, like optional parameters (these are now available in C# 4.0). But there are catches too in a line by line conversion of VB to VB.net. A very simple example is the array index. If I'm not mistaken array indexes start from 1 in vb and in vb.net it starts from 0 which causes horrible bugs. Overall, I'd definitely consider going for VB.Net even though I work basically in C#.
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'm thinking about learning Java. I'm already a more than competent c# developer. Has anybody else been in a similar situation? Roughly how long (whilst doing a typical 9-5 job) did it take you to transfer your skills? What resources would you recommend?
(When talking about resources, I specifically mean resources aimed at developers who want to learn Java, not newbie material)
I studied Java at university, and did c# at work.
You will find the Sun Java API (Javadocs) to be very informative and will help you dearly. You can find it here. This website should be the first to consult if you need a query, as it is brief, and up-to-date - similar to the MSDN Library for c#.
Also, Java has a strong community who will be willing to help # the forums.
Finally, I think its best to learn Java through practice and experimentation over theory. You will need a good IDE to start you off and there are plenty to choose from. Eclipse and Netbeans are notable Visual Studio contenders, but personally I prefer JCreator(albeit the version with intellisense is not free). It maybe text based, but you have greater control IMO.
If you are going to create GUI applications, then you should learn about swing. Again, the guys at sun provide excellent tutorials on the matter.
There are also books:
Java in a nutshell is a nice book. Click for google preview.
Java: the complete reference By Herbert Schildt is one I would highly recommend. Google Preview.
I'd recommend these books:
Effective Java (Joshua Bloch)
Core J2EE Patterns (Deepak Alur; John Crupi; Dan Malks) - sort of out of date, but still useful for understanding the history of J2EE. A lot of this is still applicable.
Concurrent Programming in Java (Doug Lea) - good guide to Java threading
Here's a more comprehensive list:
http://www.javalobby.org/articles/5books/full.jsp
It shouldn't be a difficult switch. Java is pretty much a subset of C# (Operationally) since C# was a Java clone that has mutated since it was split. (Everyone here remember the fiasco when MS tried to embrace java by modifying it so it would only work with windows, was sued by Sun and then made J++ and C# instead?)
The biggest difference will probably be the libraries, but if you are proficient at C#, then you shouldn't need to do anything more than study the Javadocs to pick up the new libraries.
EE might be a bit of a jump, but that's a whole 'nuther world.
For me, the nicest thing about Java is the minimal syntax. There are very few surprises or tricky parts to remember (Well, Generics have a kind of tricky syntax to implement, but using them is pretty straight-forward). If you agree with this or not--it does tend to make the learning curve a bit more shallow.
I started in Java and went to C#.
I will be honest with you; going back to Java won't be so easy, depending on how you started. It's going to change your world a bit. J2EE is quite different from ASP.NET, even though it looks a bit the same. Forget lots of things you used to hold dear, like == of strings, and switch on strings, and properties, and other such nicities. Oh, and prepare to be welcomed by checked exceptions.
Don't get me wrong, I love Java, and it's a great language, but you'll need be wary of the differences.
I would say a fun way to learn would be to write a program simultaneously in Java and C#, and see how you would do each thing, and note the differences.
I think you may find books hard to read, as they'll cover the basics, which will be boring for you, so you may skip critical things.
Learn by doing :) That is my approach.
We have an Progress OpenEdge (http://en.wikipedia.org/wiki/Progress_4GL) develop team in the company I work for.
I'm the only c# developer there and really like it. So now the manager asks me to learn programming in OpenEdge. He doesn't want me to become a good OpenEdge programmer but he wants the team members to understand both worlds. He hopes the team will benefit from this.
I'm not unwilling to learn but I want to become a better developer and there are so many more aspects of .Net I like to discover.
So are there there any good point about Progress OpenEdge I would profit from or should I stay away from it.
OpenEdge is a powerful framework for building CRUD applications; but it is a niche skill with no SAP-like salary premium for possessing it; conversely decent OpenEdge developers are hard to get hold of for bog standard rates - it would not be unknown for a manager to recruit an OpenEdge developer by the backdoor.
The core ABL (OpenEdge language) is different enough a language from the mainstream to be interesting for an inquisitive programmer and for your bosses arguments for everyone to understand where the others are coming from to make sense.
So, bearing those points in mind:
It's worth learning the basics to enrich your understanding of your core competencies, along the lines of "What should they of England know, who only England know?". You may also find the ease of data access eye-opening.
It is not worth spending too much time distracted from developing your expertise in a framework which is infinitely more widely used.
If your manager wants you to learn OpenEdge, then he has a reason for it. One reason could be that you will be taking on some of the development, perhaps providing cover when others are off. The other reason could be, as he says, that he want the team to understand both worlds.
What you need to find out is if the Progress people are going to be looking at .NET as well. If not, you know which of these reasons he has in mind.
It is never a bad idea to learn new (and different!) languages. It keeps the mind working and teaches you concepts that might not be available in your language. Learning OpenEdge will have no adverse effects on your C# knowledge and you can likely learn them in tandem. I personally am currently reading up on C#, Python, PHP, Ruby and Groovy all while doing most of my work in Java, I simply want to know everything. (Not to mention reading about multiple frameworks for said languages).
In short, you will always profit from learning a new language as it will give you a different perspective than the one you are used to.
What version of OpenEdge are you using? I might be biased but I would say that yes it is worth it. There are people looking for OpenEdge developers and with Progress recently releasing a product we call "OpenEdge GUI for .Net" that allows you build .Net frontends with .Net controls using only OpenEdge ABL code, there will be more and more shops that will be looking for people that have an understanding of the OO .Net world but also understand ABL.
One of the other good things about the ABL is that it is Extremely backwards compatible (no VB6 nightmares when we upgrade versions) (although some may say this backwards compatibility is a fault).
The ABL now is mixing its tradition Procedule manner with OO concepts so you can use one or the other or both theories depending on what makes sense.
The main thing I imagine you will be learning is the data access components and yes, that won't help you out in the .Net world, but I think you will find it easier to learn then other data access and so, will be an asset to have.
Lastly, if you have a good grounding in .Net as it seems you have, you will be a great asset to your employer (and be another box to tick on future job applications) in helping their OpenEdge devlopers understand the .Net ideas. I don't think progress will ever make ABL compile to CLR code (excuse me if I have terminology wrong. Is it meant to be bit code? You know the code that runs in a .Net VM) but they do know that .Net is winning the Desktop battle and they are borrowing a few concepts (.Net GUI and Datasets for one). I would hope (bias again) that you would look at some of the OE data access and say, I wish .Net had an easy way to do that!
It is a niche but niches can be very worthwhile. It can also be like being stuck in mud. Which it turns out to be depends on lots of factors but as others have said it is always good to learn new stuff.
I make 75 euro's an hour with my 12 years of Progress / Webspeed / Sonic experience.
OpenEdge seems is mostly used by software developers for building products. End users typically only interact with the rdbms end of an application. Learning any new language is a good thing IMHO, and the more different it is to what you are used to the better - we learn better when our assumptions and habits are challenged and extended. OE as a rdbms is pretty much "set and forget" needing very little in the way of maintenance. Suggest you go to the Progress forums online and look for the DBA Admin guide, work through that, then read the Embedded SQL because that will probably make more sense to you in short space of time.
And after all of that is digested just go ahead and write something. Nothing beats putting rubber to the road and building something usable. Ask the other dev's for a support problem, or a sinple form to get built, and just do it.
If your code interacts with an OpenEdge program, then it behooves you to learn something about the environment so you can interact with it better.
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.