Related
In case I want to translate a program's code in a different programming language, I have these options: to use special software or to do it on my own (please tell me if there are other ways).
Personally I'm a beginner in C++, C# and Java. I'm not familiar with other languages. I'd like to try to do a translation of one of my C++ programs to C# and/or Java. But before doing that I'd like to learn about a technique or two about translating. I'd like to learn it from someone who is familiar with such thing.
So, can you tell me techniques for translating code from one programming language to another? And if there is something that I should know before I start translating, please tell me.
Learn both languages. Understand each language's idioms and philosophy. Acquaint yourself with common coding styles and design patterns.
Read your source program, and understand what it is doing.
Think about how you would express the same overall goals in the target language, using the knowledge and experience gained from (1).
Rewrite the program in the target language.
(Counter-example: Your source is Java, and you see String a = new String;. You open C++ and say, std::string * a = new std::string;. Wrong, go back to (1).)
Some of the worst C# code I've seen was written by programmers that were thinking in C or C++ while writing C# syntax.
C# and Java are fundamentally different from C++. I don't like the term "translating" because this is the wrong attitude. You actually need to rewrite the program after you've learned how to think in the terms of the new language.
There are tools, but I never find one that's perfect. At least if it's convertible syntactically, libraries would be a problem. I prefer to have deep enough knowledge between the languages (and of course, the project being converted), and convert everything by hand. The advantages of this would be you could create a clone of the project, using each language's best techniques (that may be either impossible or not optimal in other languages). The disadvantages are, however, you might be doing something wrong doing the conversion (causing incompatible end result) and it's slower.
If you are into Test Driven Development then you have all the tests for the original implementation. Just keep coding in the new language until you pass all the tests once again. Don't worry too much about Kerrek SB's counterexample. If and when you run into problems like that, just write more tests.
On the other hand, if you don't already have a suite of tests, then why are you wasting time on porting when you should be testing.
Isn't it a hedeque to "translate" it by yourself, if there is a software that can do it for you? Unless if there is a special purpose for having that skill of translate from one language to another....
Pay attention that not all languages have the same computable power,therefore it may not work sometimes....
Perhaps it would be better to stay focus on one main language.
I know this question could be similar to others but really I'm looking for reasons why VB6 developers should switch to C#.
My company recently approved project to be written in C#, so we have a lot of VB.Net programmers, however, we have some legacy app developers as well that are in VB6. We have a time frame to re-write those apps into .Net web apps. So no matter what they will have to learn new stuff.
One of the developers today specifically asked "why should we switch to C#?"
I responded that the community largely has decided that C# is the way to go with about 80% of the examples in C#. I am a VB.Net programmer and I am excited to finally cut my teeth on C#, however, being that I'm so new I'm not sure I can answer the "why?" question. My reasons are more because I want to learn it.
So without descending into a VB verses C# I really am curious if there are any resources that I can send to these developers to calm their nerves.
Looking forward to your input!
As far as the migration over to .NET goes, better late than never! As far as my advice goes, your mileage may vary, it's worth every penny you're paying for it!
I personally believe you are making the correct choice. The first instinct for VB developers is to switch to VB.NET. That sounds entirely reasonable, but in my opinion, it's the wrong choice. You really have to break down the reasons for the switch into two categories: Why switch to .NET, and why switch to C#?
Why switch to .NET over VB6:
Multithreading in VB6 is technically possible from a programming perspective, but just about impossible if you want to use the IDE.
I do not believe you can create a 64-bit native application in VB6. That rules out a lot.
No new enhancements are being made to VB6.
OK, there are so many reasons I can think of, I'll probably just stop there.
Why switch to C# instead of VB.NET
Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts. An example: you often see new converts to VB.NET setting objects to Nothing, believing that it's a magical way to release resources. It is not.
It's true that most examples are now in C#. More importantly, Jeff Richter's book is only in C# now. If you want to understand how .NET really works, IMO his book is pretty much mandatory.
In .NET, you'll find that you will use lambda expressions all of the time, especially when operating with Linq. IMO VB's verbosity really becomes a barrier to comprehension and readability here, in ways where it simply wasn't before: foo.Select(x => x > 50) is, by just about any standard, much more fluent and readable than foo.Select(Function(x) x > 50). It gets worse as the expressions get more complex.
Some of the worst practices with VB6 are impossible or at least much less accessible in C# (such as ReDim Preserve and On Error Resume Next).
VB is saddled with some syntax which makes it pretty cumbersome and confusing to use when creating general-purpose CLR libraries. For example, in C#, you use indexers with brackets[]. In VB, you use parens. That makes it pretty difficult for the user of a subroutine to tell if it's an indexer or a function. If someone tried to use your library outside of VB, the difference would be important, but a VB developer might be inclined to create subroutines which should be indexers as functions, since they look similar.
I don't have any data on this, but if you are trying to hire a good set of programmers, the best ones will generally be less inclined to work in a shop which writes VB.NET over C#. They usually fear that the code their colleagues will be generating is likely to be substandard .NET code, and let's be frank here -- there's a stigma against VB.NET developers and the quality of their code in the community. There. I said it. Let the flames begin...
As a footnote, from my perspective, VB.NET was a real missed opportunity for MS. What it should have been was a way to seamlessly convert your old VB6 code to the .NET world - with dynamic invocation and high-quality COM interop from the start. What it ended up being was a near-clone of C#'s feature set with a more verbose syntax and little to no backward compatibility. Sad, really. It locked a lot of organizations out of .NET for a long time. Then again, maybe it forced a "cold-turkey" clean break from the past...
I've done a LOT of VB6 in the past, and a lot of C/C++, and when our big .NET migration happened I had no doubts that C# was the way to go. Having said that, what the VB6 guys should really be learning is .NET, and the CLR (a proper object-oriented runtime rather than a dumb COM front-end), and not a syntax. Focus on that, and sidestep the religious war.
This may not answer your question, in fact it may even contradict your response and prove your friend right, but here is a good list of the similarities (and differences) between VB.NET and C#:
C# / VB.NET comparison
As you go down this list, you will notice just how similar the two languages have become and with each new version, there may be less and less of a reason to switch. But, in the end, if you do make the switch, the Wikipedia article pretty much summarizes the advantages that C# has over VB.NET quite well:
Wikipedia article listing advantages of C# over VB and vice versa
The VB.net events syntax seems much nicer than C#; though the lack of any means for a class to either unsubscribe all WithEvents handlers to which it has subscribed, or kill all subscriptions other objects have to its events, makes it a little tough to avoid event leaks, it's no worse than C# in that regard.
Also, in vb.net, it's possible to have a Finally handler know what exception occurred (if any) in its Try block without having to actually catch it. If any exceptions occurs in the Finally block, the original exception can be included in the CleanupFailedException (along with the other exception(s) that occurred in the Finally block). That seems like a nice advantage.
"Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts." (#Markle)
I haven't used this for an argument before, but it's a very good point. When I picked up a VB.NET app written by a bunch of new-to-.net VB programmers, it was littered with legacy compatibility calls to the old VisualBasic namespace. CStr(), VbNewLine, Mid(), etc... Working in a language which isn't designed to support legacy code conversion prevents the use of those relics. (So does removing the reference to the legacy namespace, FYI.)
I switch between VB.NET and C# pretty regularly. Whenever I go from VB to C#, I think "This is different, it'll take me a few minutes to adjust." Whenever I go from C# to VB, I think "This is an inefficient programming language; there's way too much typing required, how annoying."
I think the other answers have done a good job of covering the technical points. I would also point out to your vb6 developers that there are not only more books aimed at c# and more questions on SO on c#, but perhaps more importantly to them, more job listings as well.
A quick search on SO careers:
92 job postings for c#
11 job postings for vb.net
1 job posting for vb6
reasons why VB6 developers should switch to C#
Others have given technical reasons for C# over VB.NET, but I think you are dealing with a people issue, so I'll offer what I think is the most compelling reason why the developers should prefer it:
C# developers get paid more than VB.NET developers, for doing exactly the same thinking, just typing different source code after doing that thinking
Also
ReSharper for C# is better than ReSharper for VB.NET
Other than technical / social advantage is more business oriented,
Mainstream support for VB6 already ended and Extended support which is surely expensive would end soon.
Moving to a new platform in this case make more business sense.
Also the IDE is no more supported by microsoft so in case of issue you would be SOL, and installing it on shiny new laptop might provide an unenjoyable experience.
Note that they don't need to port every application, only deprecate the part that need to be replaced with com exposed .Net assemblies.
On the other hand having experience in porting software from obsolete platform to a new one will make these guys rich, providing they are willing to learn the new platform.
The biggest advantage C# has over VB6 proper has got to be inheritance.
(OK, to be fair it's my personal favourite, so I am totally biased.)
Other advantages:
Formal accessors
Exception types (I don't think VB6 has exception types, but please correct me if I'm wrong)
Generics
Lambda expressions
And the following are more related to the .NET platform than languages themselves:
Very rich library
Visual Studio refactoring and other goodies
Finally, the popularity argument is always icky (popular <> good), but it does give an idea of the community size of each and therefore what help is available out there and what the industry is going towards in general.
Questions on SO:
[C#]: 116,337
[VB.NET]: 11,740
[VB6]: 1,897
VB6 is not fully object oriented and lacks a decent set of collections/structures. VB.Net and C# are both fully object oriented and include a decent set of collection classes as a part of .NET. .NET 2 also added generics for even more flexibility.
I would agree with those who think VB.Net is a bit superfluous - it fixed the problems with VB6 and ended up being a bit of a "me too" alongside C#. Having said that, I do a lot of COM interop and find VB.Net's old fashioned ON ERROR construct a convenient way of handling timeouts and function retries. You can do it with try...catch just it is more complex.
Questions on SO:
[C#]: 116,337
[VB.NET]: 11,740
[VB6]: 1,897
That proves nothing.
VB6 existed long before SO did. All the good VB programmers learned what they need to know and MSFT had done away with VB6. Most of the new MSFT beginners flocked to C# because of their irrational hatred of anything BASIC (that still exits - just look at Xojo) and of course MSFT marketing.
But how do they feel now with C# getting short change compared to C++ on the Windows 8 platform? (eg XNA is gone).
The market pretty much demands C# over VB.net.
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.
In a progression of languages, I have been learning C and C++. Now I would like to learn C#. I know there are some drastic differences between them - such as the removal of pointers and garbage collection. However, I don't know many of the differences between the two.
What are the major differences that a C++ programmer would need to know when moving to C#? (For example, what can I use instead of STL, syntactic differences between them, or anything else that might be considered important.)
C# for C++ Developers is a great place to start. It is a table that lists the most important comparisons between the two languages.
Once you have explored some of these differences, you might choose a self-contained project you have written in the past in C++, and re-write it in C#. In your first pass, you will probably just end up translating directly across, using the same design and algorithms. As you become more comfortable with C#, you will recognize ways to take advantage of language features only available in C#, as well as the incredibly versatile .NET Framework.
I think it's important to note that pointers weren't really removed from C#, but that they still exist, they are everywhere, and they are called references.
Charles Petzold has a .NET Book Zero that is designed specifically for the C/C++ Windows programmer who wants to learn C# and .NET. It is a free PDF download from his site. All of the source code used in the book is available as a separate Zip-file download.
There was a similar question that has lots of pointers (pun inteded :-)) and resources about the differences between C++ and C# and what to pay attention when learning transitioning - Linux/C++ programmer to Windows/C# programmer.
Look at the Generic collections and LINQ (all the related technology to LINQ) for STL like functionality.
The number one thing to note is that ~/Destructor is c++ is nothing like the ~/finalizer in c# -- See IDisposable/using.
It has been said that C# can be regarded as a functional programming language, even though it is widely recognized as a OO programming language.
So, what feature set makes C# a functional programming language?
I can only think of:
delegates (even without anonymous methods and lambda expressions)
closures
Anything else?
C# has borrowed a lot of features from ML and Haskell for example:
C# 2.0 brought us parametric polymorphism (or "generics"). I've heard that Dom Syme, one of the creators of F#, was largely responsible for implementing generics in the .NET BCL.
C# 2.0 also allows programmers to pass and returns functions as values for higher-order functions, and has limited support for anonymous delegates.
C# 3.0 and 3.5 improved support anonymous functions for true closures.
LINQ can be considered C#'s own flavor of list comprehensions.
Anonymous types look like an approximation of ML records
Type-inference is a given.
I don't know about you, but C# extension methods look an awful lot like Haskell type classes.
There's been a lot of talk about the "dynamic" keyword in C# 4.0. I'm not 100% sure of its implementation details, but I'm fairly sure its going to use structural typing rather than late binding to retain C#'s compile time safety. Structural typing is roughly equivalent to "duck typing for static languages", its a feature that Haskell and ML hackers have been enjoying for years.
This isn't to say that C# is a functional programming language. Its still missing important features such as pattern matching, tail-call optimization, and list and tuple literals. Additionally, idiomatic C# is fundamentally imperative with a heavy dependence on mutable state.
I wouldn't necessarily consider some of those features mentioned above as exclusive to functional programming languages, but its pretty clear that the C# developers have taken a lot of inspiration from functional programming languages in the past few years.
There being no rigourous definition of "OO Language", "Functional Language", "Procedural Language", one can make arguments that any language fits mostly any classification; one can write procedural Java, object oriented C and functional C++. I typically use a classification based around what the main semantic features support, along with common development practice. A good way of looking at this is to examine builtin and popular frameworks, and see what style they use.
Functional languages are mostly defined as those with first class function primitives, with development styles that use these to reduce complexity with idioms like "map". One other common feature is pattern matching, but I don't see this as exclusively functional. "Pure" functional languages also have no side effects, but that's not mandatory (see how fuzzy these concepts are? :).
So, what's C#? Well, it has first class function style primitives, with delegates (and has gained better syntactic support for the style with anonymous delegates and lambdas). Does this make it functional? Perhaps, if one writes in a functional style. Does the Framework use this style? No, not really.
As such, I wouldn't class C# as functional in general discussion - it is, at best, multi-paradigm, with some functional flavour.
Well, delegates and closures allow it to operate in a largely functional way... for example:
var sum = data.Sum(x=>x.SomeProp);
etc
You can write most higher-order functions using lambdas / delegates. The type inference isn't quite the same as pure functional languages such as F#, but C# generic-type-inference is still pretty good (especially in C# 3.0).
This is especially true in .NET 3.5 and C# 3.0, where LINQ takes a highly-functional approach to many of the problems. But you can still use the functional aspects of C# with .NET 2.0 and C# 2.0. It is just easier with C# 3.0 and lambdas ;-p
Actually, C# is a pragmatic programming language. It aims to make it possible to use a number of paradigms, without punishing you hideously if you want to do something different.
Function pointers is another feature that C# has in the functional category.
I don't think C# is very widely regarded as a functional language, however. I do think it's important to point out that you can program in a functional style in many languages that aren't purely functional.
From Functional Programming:
In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state.
Using that definition, you can program in a functional style in almost any procedural language. Purely functional languages just enforce it.
I mostly agree with the others here who say that C# is better described as multi-paradigm than functional. But I'd add to the examples of functional features in C# LINQ, a first-class and relatively understandable system for writing monads. While purely functional languages don't require the use of monads, the example of Haskell has shown that they can be extremely useful. Yet they're one of the hardest things go grasp for many people new to Haskell. In C#, on the other hand, many people write LINQ queries these days without even realizing that they're writing monads.
you can find a great overview regarding language features in the presentation from Andrew Kennedy (from MS Research) called C# is a functional programming language. My article about functional programming in C# and F# gives an overview from a higher level perspecitve (especially towards the end).
T.
C# has the some functional language features, closures, for example. The .NET libraries aren't written in a functional style, so in practice C# isn't a functional language. Almost everything is accomplished with mutation. The collection types are all mutable.
These are the main points whow makes c# functional
1-Lamba expresions
2-Extension methods
3-Type inferende
4-Object and collection initializators
5-Closures
6-Anonymous types
7-Linq