Develop Reference

Is it better to start learning C# or C++ in the .NET world? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have some very rusty C++ and lots of C experience, but have done little OO design or coding. I've started learning C++.NET as that seemed to be the best starting point.
I've hit restrictions in Microsoft's provision with multiple inheritance and extensions, neither work in C++.
Would I be better off starting again with C#, or am I better off using a mixed language approach. eg. extensions in C#, rest in C++?
I'm still struggling with this->method or that.property and theother::staticthingy or whatever, and this probably is not an issue in C#. You'll see what I mean as that probably isn't the right way to desribe the difference between '->' '.' and '::'
I'm getting to achieve what I want, but it's taking me 10 times longer than I think it should.
Is C# any quicker?

MS wants you to use C#, so use C#. If your C++ is rusty, you'll end up wasting time learning a difficult language, which is actually a second class citizen in the .NET world.
However, C++ in the .NET world (called C++/CLI) is a wonderful tool to wrap existing non-.NET code into .NET classes.
For the multiple inheritance thing, C# supports inheriting multiple interfaces (à la Java), which is by far the most useful use case of multiple inheritance.

If you plan on going the .NET route I would personally recommend going the C# route. I see a greater number of support for C# related question and more code examples geared towards .NET. That is just from personal experience. C# is the highest traffic tag on stack overflow.

I think C# is a bit more sane that C++. However, you're still not going to get multiple inheritance.
That said, be sure to pick the right tool for the job. If you absolutely need C++ (and this is becoming more rare every day) then stick with it.
Otherwise, save your sanity and move to C#.

if you got good knowledge in C then C# should be more interesting and easy.

Though I believe this is more a programmers.SE question, here's my $.02.
I would start with C++. Build an appreciation and understanding for memory management, structures, cleanup, etc. then move to .NET. The Garbage Collector (GC) is nice, but going in to a language that's that "loose" with structure and beginning (IMHO) sets for a poor foundation moving forward.
If you understand what's going on in the background, you'll have a better mind set when developing (keeping a conscience mind of memory and resources).
Just my belief, anyways.

If you want to get into AAA gaming (or a job that requires C++) start learning C++.
Otherwise, C# is much newer and well refined, making it easier/quicker to learn (imo)

C# is a very easy-to-grasp language. I first learned unmanaged C++ a long time ago, and honestly C++ syntax has changed so much since then I don't recognize it anymore. Before I started programming in C# regularly, my previous C-ish language had been Java, and if you know Java, you can learn C# very easily. Also, from a business perspective, C# is by far the most popular .NET language in terms of how many people want C# programmers, as opposed to VB, C++.NET or F# programmers.
In C#, there is no syntactic difference between, for instance, a member of a class referenced by a pointer, and a member of a class instantiated locally, because in C#, pointers, though they exist, are hidden behind a LOT of abstraction. Everything is a "reference" (if it isn't a simple "value type"), and is passed around as such, so referencing a child of an object is always done with dot notation.

What advantages can I get from learning C++ if I'm mainly a C# Programmer? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Recently I've started to notice a lot of smirks and generally rude comments whenever I mention C#. Everyone I talk to either says learn Python or learn C++.
Python is a nice language, I get it. But I don't find much use for it right now (for my use cases), and C++ I heard is a faster language (not sure).
So my question is this, what advantage can I get from learning C++ (besides the knowledge and expansion of my horizons), when I mainly program in C#?

The biggest issues are as follows:
C++ is the de facto standard of system AND application programming for the past 20 years
C++ is portable and compilers exist for ~ 95% of all processor architectures.
C++ can enhance your .NET code, by that I mean PInvoke can be done to run optimized code written in C++ -OR- can be used to run code from 3rd parties, allowing you to write custom wrappers etc.
C++ is linux/mac/PSP/Cray II/Random OS from Thailand compliant, it has no issue compiling because it doesn't run through the .NET CLI (which I have to admit is a beautiful piece of art) C# is bound, for now, to Mono implementations and Windows through .NET.
As a professional .NET applications programmer, I love C#, I worship the ground that the architects walked on. But C++ is in my opinion, the most important language you can/will ever learn because it will open more career doors than any other language in the modern industry. If you know C# it will take you a matter of months to learn it. I reccommend Timothy D'Orazi's C++ book if you have an academic software engineering background.
Afterthought:
C++ is a tool, just like C# or a drill or a shotgun (arguably) fit the tool to the task, I'd rather die than write functional code in C++, likewise, I wouldn't do application development in F#, they're all fine langauges. Learn something that interests you! If you want to be a better programmer, learn C++, if you want to be a better application developer, it may be more to your advantage to learn new technologies within the framework you're already working in! You are a C# programmer, have you learned WPF? WCF? what about the features of C# 4.0? Have you mastered lambda functions? expression trees? There are so many directions you can go from here, C++ is just one of them. Ask yourself the following questions:
What can I learn that will add value to me?
What can I learn that will interest me as a developer?
What can I learn that will benefit me in my immediate position?
What can I learn that will help me get into the kind of career path that I want to be in?
You'll find that there will be many answers that overlap for these questions, take your time, find something that interests you and won't be a chore to learn, you'll thank yourself for it 3 months from now.

Short answer: Learning at least some C++ (and some assembly language too) makes you better at leveraging and, perhaps more importantly, debugging the software platform deep underneath your code. This is true regardless of the programming language or OS you're working in.
Long answer:
One of the differentiating factors, IMHO, between good developers and great developers is that the great ones know what's going on under the hood in a piece of software and are capable of quickly drilling down underneath layers of abstraction in the technology stack, since the toughest software problems are often caused by things way down below your code in the stack.
Therefore, I've always recommended that developers, at some point in their careers, spend at least some time learning two languages which are at the bottom of almost every software stack: C/C++ and x86 assembly language. That doesn't mean you need to become an expert in either, but having a working knowledge of things like pointers, registers, memory management, stacks and heaps, un-GC-ed string buffers, leaks, etc. is hugely useful when you need to reach down into the stack to diagnose a problem, to better understand odd behavior, or simply to make smarter decisions as you architect higher-level software, regardless of the language.
An analogy: I became a much better manual transmission driver once I took apart my motorcycle's engine and saw how the clutch worked. That didn't mean I needed to become a motorcycle mechanic, only that it helped my overall driving skills once what was happening inside my bike was not a mystery anymore.
Also, regardless of the language or framework you're working with, for projects that must call directly down into the underlying platform, C/C++ knowledge is very helpful and sometimes required.
Note that I'm deliberately not touching the more contentious question about whether you should be writing entire apps in C++ or not. Other answers have done a great job covering those arguments. Instead, I'm simply making the case that C++ skills will benefit you, regardless of whether you continue writing most of your code in C# (or Java or Python or Ruby or...)

It depends.
The thing I like about C++ is that in some ways, it is a more expressive and yes, more elegant, language than C#. It enables some really nice abstractions (such as generic programming or RAII) that just can't be duplicated in C#.
In those ways, it's an eye-opener. Of course, so are functional languages. So is Python. All of them are worth learning, even if you write all your code in C# now and forever.
Of course, C++ is also an overcomplicated mess, and a far more error-prone language than pretty much anything else. And if you don't know it really well, then it will explode in your face when you least expect it.
Of course, plenty of people will shout PERFORMANCE! when you ask why you should learn C++. I won't. Because in many common cases, C# is going to be as fast or faster as your C++ code. This old exchange between Raymond Chen and Rico Mariani illustrates the performance characteristics of both platforms pretty well.
C++ has the potential to be extremely fast. But it also has a lot of subtle performance pitfalls that mean that most of the time, unless you're some kind of omniscient code-god, your code is going to be less efficient than the equivalent C#.
If you have an interest in programming languages, C++ is a wonderful example of the theory of evolution. ;)
It hasn't grown according to some great predefined plan. It has always improved and adapted one step at a time, according to what would make the language better right now. As a result it is huge, bloated, overly complex, but it is also more expressive than something strictly designed according to a single person's vision, such as C#. C# is designed with an unhealthy obsession with OOP, because that was the cool thing when it was designed.
In C++, OOP sort of drifted out towards the periphery, not so much as a conscious design decision, but because better alternatives turned up.
It's a fun language. And I'd recommend learning it just for the sake of becoming a better programmer. But I'm not convinced that you'll need to actually use it. Of course it will make certain tasks easier (native interop, or programming small programs which for one reason or another can't assume that the .NET framework is installed), but for most cases, you probably won't need it.
That leaves the "become a better programmer" argument, and while that is a valid argument, it is also true for other languages. You should definitely also know a functional language. And Python, or a similar pragmatic, high-level "make it easy for the programmer" kind of language.

I have been C++ developers for last 10 years and last two years, I have been using java for new product development. I have also done some programming on C# just to learn it. Based on my experience I would say C++ is a challenging and high performance language which is good for computer science students to understand programming concept and algorithms. Other usage of C++ would be protocol implementation which doesn't change often E.g implementing SIP Proxy or HTTP Server..
For practice product development where requirements changes often, I would recommend any high level language where developers can focus on application logic instead of reinventing wheel. E.g Recently I started an open source project xcapserver which I was able to do quick prototype in two days using java technologies (Glassfish,REST, log4j, eXist db)but I wanted to lean boost libraries and again it's a protocol which is not expected to change often, so I decided to implement in C++. I spent 4 days just to get the logger working using BOOST::log and another 4 days to fix the thread deadlock issues with Berkeley DB XML.
Another aspect is product maintenance. I have spent days and night to fix memory leaks and corruption and learning curve for new developers is too high versus J2EE or .NET where it's easy to find developers and maintenance is much easier.
In sort, C++ is good programming language which I would recommend to all developers to learn but I don't see much use of it going forward as processors are becoming faster and cheaper so performance is not the reason.

There are reasons to use pretty much any language.
C and C++ have uses in that they are compiled into native code rather than running on a virtual machine. There is a speed advantage and it also means these programs can run without having a 50MB+ framework installed.
Pretty much all games (certainly first person shooters) are written in C or C++.
Is this applicable to you? No idea because I have no idea of what you're trying to achieve.
What will you learn from C or C++? Pointers, memory management and the like. It's quite a different world from more modern garbage collected languages like C#, Java or Python.

Learn C++ so that you can better appreciate C#.

Apart from what others have said:
People do like to see it on resume's.
Learning any language helps you translate that language into C# which makes you more valuable as a programmer.
Learning another language helps you to understand samples using that language, arguably allowing you to draw on a wider range of samples, books, examples, experts.
Wrappers! Learning C++ helps you wrap those pesky C++ dlls for consumption in C#!
That said, there are quite possibly other things you should be learning before C++ if you're a C# programmer who never learned C++ in the first place.

You'd get more utility out of learning a functional language like Clojure, Haskel (or maybe F# given you obviously feel comfortable with CLR). They have a different underlying programming model which will expand your horizons in ways that learning a new syntax will not.
In the other direction, learning C would actually be much more useful than learning C++. That will focus your learning on pointers, memory, and 'close to the metal' topics.

2015 Update
Learn Swift. It will teach you the same use of functional and generative patterns as modern C++ but without the baggage or as many gotchas. It's also semantically a significant overlap with F# so you get a chance to study functional programming. There's a vibrant functional community pushing the bounds of Swift.
Ironically, in my current day job on C# bindings for Realm, I'm still using my C++ skills alongside C# but not much has changed my attitude in the last 6 years.
Original
I speak as a C++ programmer for 15+ years who has spent the last year learning and using C# (and C++/CLI), on top of an ongoing fascination with languages and a broad range of studying other languages to improve my thinking.
I am very very impressed with C# as a language, especially with the improvements in C# 3.0.
I would take the contrary views:
Unless you want employment writing computer games, or relatively low-level components, forget about C++ as a language because there are enough skilled C++ programmers out there and the gaming industry generates a lot more (of presumably varying quality). It is not going to improve your career prospects.
Do invest some time into studying the interesting depths of C#, the implications of operator overloading, how to use unsafe code etc. Pick up a book like the excellent C# in a Nutshell and be able to go through and annotate all the content with deeper explanations of how that idiom might be used.
Learn a dynamic language like Ruby or Python, use it for some real-world tasks such as generating or mangling test files, so you appreciate the simpler language for manipulating files, structures and strings.
Learn F# or another function language and develop a few smirks of your own about the implications of functional languages for parallel processing and clouds :-) In a few years time (or earlier) this will yield huge career benefits when people are scrambling for cloud-savvy programmers. Remember, you haven't learned a new language until you can compare it to the old ones so you need to be able to pontificate about when and where to use F# (or Haskell) instead of C#.

In terms of performance, it is a lot faster. If you have any desire to do game programming or high-performance computing, C++ is a great language for that.
But, I would also say C++ is very difficult to learn. No garbage collector, compile errors that need to be deciphered, and the need for external libraries are all difficulties to overcome.

Regarding C/C++, here are a few things that come to mind out of my own experience.
Learning C/C++ can provide experience working more closely with detailed operating system features and with raw memory. For example, many Audio, Video, and Game applications require this level of access to perform at their best.
Knowing how to interop with components and libraries written in C/C++ is a handy skill. There are many useful libraries out there that still do not have adequate equivalents in C#. TSAPI (telephony), various file format libraries, and legacy components are much easier to work with in C# if you understand their construction in C/C++ and other languages.
If you are working with windows applications, having experience with Win32 through C/C++ allows you to understand how a number of other applications written in non-managed code work; even if you do not have the source code available to you. You can then use P/Invoke more effectively to deal with libraries that would ordinariliy be unavailable or too opaque to handle otherwise.
Many techniques, though potentially black-hat in nature, are tougher to accomplish with C#. Things like DLL substitution, re-writing function entry points, injecting code into other processes, and generating inline assembly code are easier to do with C/C++; though not impossible with C#.
Finally, fine tuned control over un-managed objects is something better suited to code written with C/C++. For example, things like overlapped I/O on windows, some socket library features (ex. UDP Multicast), and device control have more working C/C++ examples out there than C#. But, these are quite esoteric and usually not handled in C# applications anyways. Some of these are likely to have equivalents in future APIs or frameworks as well.
In summary, the main motivation I would suggest for learning C/C++ is to broaden your knowledge of other systems that are not accessible in C#. Learning Python would be a step in the other direction, where learning other styles and semantics of code construction is a more likely benefit. C/C++ code written by other people tends not to have more beneficial nor recognizable patterns like software written in Python, Ruby, or Lisp.

The best reasons for learning C++ for a C# developer is to learn new programming paradigms. C++ is more than just an "object oriented" language and hence offers a chance to learn new approaches to solving problems. With C# 3.0 and .NET 3.5, C++ doesn't affer as many unique paradigms, but if you are not using them, then effective C++ programming will force you to learn them.
In particular, C++ still offers a very powerful generic programming paradigm that is unmatched by C#. The STL forces you to use functional programming concepts that many C# developers avoid or don't use (LINQ extensions and lambda's for example).
I've also found that it strengthens a persons understanding and appreciation for lexical scope. Concepts such as RAII or C++ namespaces really push the need to manage scope very carefully... in C#, many of these concerns exist, but are less "in your face". Template metaprogramming is another unique concept that C++ offers that C# doesn't.

Learn C++ so that you can feel like blowing your brains out.

With every programming language you're able grow your vision of the landscape and apply lessons learned. Although I have never written a production C++ application, it was very educational for me to understand the system at that level. If you have the spare time, dive in! You may also want to explore unsafe C# code. It could help you understand many of the advanced capabilities of C++.

In order to respect the OP's wishes I won't say anything about how I think C++ can help a C# programmer think differently about code. ;-p
Seriously though, as a tool the main advantage of C++ is that it is multi-platform. Code written in C++ can be run on a huge variety of platforms.
On the other hand the big disadvantage of C++ compared to C# is that it takes a lot longer to write correct code.
While it is possible to write faster code in C++ in theory this assumes an unlimited amount of development time. In practice because I can write more sophisticated code more quickly in C#, I can spend the extra time optimizing the code.

It depends what programs you're working on. I've never used Python before, so I can't comment on that.
As for C++; most performance critical software is written in it due to its speed. You have more power over your hardware, but with that power comes responsibility and a steeper learning curve. It also doesn't have access to .NET; so you'll probably have to dig into Win32 programming for doing some of the tasks!
Examples of where C++ is used: Game development, aerospace, air traffic control systems.
Personally, I think that learning C/C++ makes you a better programmer overall, it teaches you many things; especially about performance and memory. And also well.. pretty much everything important is built in C++.

First off, It sounds like your interested in learning more. That is really the most important part of being a good programmer.
That said; Almost all big open source projects are written in C or C++, if you want to leverage or build on top of those you need to know the language. Not only is working with a large open source project look great on the resume, it also let's you examine some really good (and really bad) code. For me that alone has been a invaluable learning experience.

The primary reason to learn any new or different language is to learn a new and different approaches to solving problems in programming. C# and C++ certainly have some similarities. They also have some pretty substantial differences. At first, those differences will seem (as a few have mentioned) to be primarily with syntax. Further study, however, will reveal considerably greater differences that go well beyond simple syntax.
That means that if you decide to study C++, you need to plan on dedicating a fair amount of time and effort to it before you gain much. If you want something that's radically different from the get-go, you'd probably be better off with something else. My own advice for a completely different language would be Scheme -- basically Lisp with a good housecleaning.
There are lots of other functional languages, and some of them are pretty cool -- but Lisp has outlived a lot of would-be successors, and I think it'll outlive quite a few more. If I were a betting man, I'd bet on Lisp outliving F# by several decades...

What features should Java 7 onwards have to encourage switching from C#? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
C# has a good momentum at the moment. What are the features that you would need to have in order to switch (or return) to Java?
It would also be quite useful if people posted workarounds for these for the current Java versions, e.g. Nullables being wrapped around custom classes, to make this a much more interesting wiki.

As a .NET/C# developer here are the missing features that annoy me. This list in no particular order - just as thoughts come to mind:
The Java library is too small. For common things I have to choose between 5 competing open source products because the base library is lacking in so many ways.
This is an Object Oriented programming language right? Why in the heck do primitive types not inherit from "object"?
Pointers
Lambdas
Closures
Partial Classes and to a lesser extent partial Methods
Real support for Generics
Using statements and Dispose - this was a real WTF for me. You really have to explicitly close connections in try/catch blocks. Poor Java guys!
Yield return would be nice
Unsigned integers - again WTF? I have to use number types larger than I need for what purpose again?
In Java you can return from final blocks of try/catch. A co-worker confused the hell out of me for hours by introducing a bug this way. This behavior should be prohibited as in C#.
I rarely have to use Java and when I do, I have all sorts of WTF moments.
Edit: I Removed for-each comment based on the fact it is no longer a missing Java feature since 1.5.

In my experience, Java vs. .Net is more of a business decision than a technical one. Shops with MS experience trend towards .Net and shops with Java experience trend towards Java & OSS. I've seen little evidence of people switching based upon language features. On the other hand, I've seen shops heavily tilt towards one platform b/c of one or two key employees they wanted to hire being knowledgeable in that area.

in no particular order:
function pointers (delegates); the whole passing interfaces around thing is stupid
real generics; what's the point of having type safe generics if the compiler can't even hold the meta data through a unit's compilation?
ui speed; all the self-drawing ui libraries are very slow compared to native controls wrapped in "managed" libraries, not to mention that microsoft's self-drawn ui is hardware accelerated through direct3d
an yield return construct; c# is so user friendly in this it's crazy
operator overloading
linq; just cuz its so addicting
properties; more synctatic sugar you get addicted to
better interop with native code; c#'s p/invoke and native com support makes interop so easy compared to jni -.-
first class value types; this goes hand in hand with real generics, having generic lists that never box/unbox in c# is part of why c# is faster than java.
and i'd say this is the most important one:
a responsive, informative debugger; nothing can even come close to visual studio right now

Just going off the cuff, I think the biggest thing Java 7 needs that everyone is lamenting the lack of is closures.

I'm a C# programmer and about one year ago I had to participate in the development of an application in Java. What I missed the most was:
Visual Studio (Eclipse is nice, but
VS is VS, especially Team Edition)
Comparing strings with ==
Properties
Basic types as first-class objects
(e.g. not "int" type vs "Integer"
class)
Anonymous methods (a workaround can
be made by using anonymous classes
but it is not the same)
LINQ
And there was one single Java feature that I missed when I went back to C#: explicit exception declaration in method signatures.
DISCLAIMER: I am speaking about a somewhat old project, I don't know if some of these features are present in current versions of Java.

Less heinous XML parsing and manipulation tools. Doing anything with XML in Java sucks.

I'll also give one answer the other way around. C# needs an enumeration implementation like Java has. Java's enumerations rock!
Let me add anonymous overrides to this list also. Sorry to go off topic, but C# needs the ability to anonymously override methods. I have been switching back and forth between Java and C#, and I have to say for unit testing legacy code, there is nothing better than anonymous class overriding.

I would need function pointers of some sort. The ability to use delegates in C# is so useful. There are so many times in Java where I want to create a map of delegates or function pointers as the solution, but I can't. I know you can simulate a similar thing in Java, but having the abstraction as part of the language is a huge plus!

Momentum. I have done a lot of development on both platforms. I'm enjoying the .NET side more because of the way the C# language is evolving. Java's evolution seems to be more a reaction to C# than an actual vision. So I think the best thing for Java to do is ignore .NET and create something new of its own.

Another one I would like is some equivalent to LINQ. I noticed how much I actually depend on the ability to use LINQ when I tried to do a top coder competition and realized they only support .NET 2.0. Once you get used to using LINQ to solve problem and make it part of your regular programming vocabulary it is very difficult to not see problems in that light. It is akin to using generics and then not being able to use generic.

I think, choice between Java and C# is not a question of language features, but a question of platform and ecosystem choice.
So, I doubt that any new syntactic sugar in Java or C# can lead to a significant amount of switchers between the platforms.
After all, JVM world has Scala and many language-sensitive developers are using it in some way.

I think, you should consider swithcing this holywar from "Java vs C#" to "JVM vs CLR", because JVM is (in the last years — mostly) not only Java, but also Scala, Groovy, Clojure, JRuby, Jython, and dozen of JVM-languages.

Properties!
Anonymous objects are nice too

Continuations, like Scala (on top of the rest) would be good too, for agents development.

Support to run over CLR (and vice versa perhaps for JVM) without IKVM and other such layers.

Let's be clear that we need to distinguish between Java and the JVM. I actually switched from C# to Java, but I admit it was not because of Java's amazing language features! In my very humble opinion, C# is the better language, and CLR is the perhaps a more elegant VM. However, even with Mono, you're not writing applications that run everywhere!
I think the greatest argument for Java is the amazing community it has. This is where the cutting edge technology is being developed, not at Sun (now Oracle). The Java community has consistently been the leader in developing Enterprise technologies. For instance, how long did it take Microsoft to provide a DI Framework? Where's AOP in .NET? When I start a .NET project, my foundation is Spring.NET, a Java port. When I need ORM, it's NHibernate. Need a testing framework? NUnit. I realize there are other OSS projects for the .NET platform, but their numbers and support from Microsoft are laughable compared to the Java community.

on the other side, has .net got enterprise open projects like Terracotta (semi commerical), Infinispan, Compass ? no. ncache (commerical), lucene.net are far behind them. Especially Terracotta is unique, it can improve some of your app x100, it's simply perfect and free (partitioning is commerical). If we implement a high load app in both .net with anything and java with terracotta + hibernate + terracotta-hibernate-integration, java app will probably far more performant than .net one. Ther're some ports to .net like nhibernate, log4net, lucene.net, but all of them are trying to catch java versions. And entity framework is a disaster, they have to start with nhibernate as the base or get some lessons from them.
.net is only working on windows (mono is far from enterprise, there isn't any enterprises using it), how much money does myspace.com spent for their 4000 windows web server licences ? 1 million ?
You can't install a simple plugin to VS (and can't do some other things) if don't buy professional edition,
Some windows instance types in amazon web services are nearly x2 price of the linux ones.
if you look at ohloh.net open source java project counts (with language comparison tools), you'll see that java has x5 more volume than c#.
also Java has %20 share on worldwide while c# has %4.x (source:tiobe.com)
Look at the top web sites; only microsoft and myspace are using .net. google, amazon, ebay, linkedin, alibaba, twitter (switched to scala from rails)... many of them are using java and many others are using php, ruby (facebook, yahoo,..)
As a language Java is far behind c#, but Scala (runs on jvm) is as good as c# and it's performance is nearly same as java and also it can use all jdk and other java code as his library.
I'm not saying java is better, but I'm saying java is as valuable as .net, too.

A native 'decimal' type for Java replacing the BigDecimal class would be nice. But Java thread-safe collections are nice.
Perhaps the question is not so much what Java 7 needs to persuade developers to use it, but more a case of what makes developers want to move from Enterprise/server-side java language to a different C# desktop Windows-only oriented world?
For most developers, the language isn't difficult to pick up be it Java or C#. I develop in Java, but Linq didn't take long to understand and use.
I think the choice of Java or C# depends on what motivates you personally -perhaps money? in which case either language will do whether they have certain features or not.
Ste

They should start by fixing the Calendar/Date related classes, even that seems too much to ask.

A simple way to map values in your model to the UI (like bind in Java/FX)

I think it depends on bussiness decisions, not the languages themselves.
But I really really really love C# lambdas and curry :D :D
http://mikeomatic.net/?p=82

a map({codeblock}) which runs over anything iterable would be nice. And filter too. And being able to return multiple values easily from a method.
(a,b,c) = getThreeValues();
(would assign the individual variables a, b and c).
Actually I just think they should have Haskell as a supported scripting language on the JVM :D

linq, lambda, anonymous types

I don't see any point in "luring" anyone anywhere. They solve different problems and you should use whichever one suits you.
Java has less "Language" and less structures to trip up new people, it's platform independent and it doesn't change too fast allowing old code to stick around for a LONG time (Good for some large companies).
C# has tight desktop integration and a slew of nice features that make it more fun to program. It has .net integration. It has pointers, closures, etc which make it harder for n00bs (a valid language target, hence Basic) but more fun for experienced programmers--I haven't convinced myself that these features make you more productive, but in some situations they can make your code a lot nicer! Also if you need pointers, you need pointers.
I don't see a whole lot of overlap in target audiences. Why change a language to attract programmers when it's healthier for the entire industry to have two healthy languages each targeted at solving different problems attracting different developers?

Considering moving to .NET from java [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am a 4th year computer science student, at university alot of my projects were Java based so I am pretty used to the language, platform and apis. However for a long time, I have been reading alot regarding the .net platform improvements and it's large career opportunities (at least in my country). Now I am considering shifting to the microsoft world. I have several questions:
Would it be severe to shift to .NET platform, as when I start my career I will be lacking the "4 years of java experiance" to a "1 year of c#/.net experience"?
How harsh transaction from java world to .net world would be ?
It feels like the future of Sun (and Java as a result) seems a bit blurry, can it be an issue on the long run ?
EDIT:
Sorry for the edit, I want to add that I am more into the telecommunication field (even tho I have no internship/job experience in this field yet). Plus indeed java is not my only language. I am really used to Python, LISP, Javascript,Php and some other markup languages.
Thanks

It will certainly be a shift, largely in terms of learning the .NET framework when you're used to the Java APIs. A lot of the concepts are the same, but it's a case of learning where to find things. You shouldn't expect to effectively have 4 years of C#/.NET experience - but you'll have 4 years of general software development, which is certainly important in and of itself.
Moving from C# to Java isn't too bad, although generics are very different in C#. You'll find there are a lot of features in recent versions of C# which aren't in Java, and it's worth getting to know them to use the language to its best advantage.
Personally I find C# to be a much more elegant and powerful language than Java - and certainly one which has evolved a lot more rapidly. I use both on a regular basis, but my heart is with C#... and that's having come from a Java background like yourself. I certainly don't regret "moving" from Java to C#, particularly as it isn't so much a "move" as just adding an extra string to your bow. It's not like you're giving up your Java experience to learn .NET.
Having said all this, I don't think you need to worry about Java disappearing any time soon. I think it's reasonable to have concerns over the glacial rate of progress of the core API and language (although 3rd party libraries and indeed languages are moving rather faster) but I'm sure companies will be actively developing new products in Java for quite a few years to come.

If you don't want to become the next cobol developer, get used to changing languages. Java and C# will be around for a couple of years, and so will the underlying platforms. But things will change, so better to get used to it.
You have exactly 0 years of experience. Anything done in school or university doesn't count. The reason is: the requirements are completely different. The school stuff might be way more difficult from a CS point of view, but it has fixed, rather clear requirements, and you don't have to support it for 10 years. So again get used to it: It was hopefully a fun time, but it does not count as experience.
C# was in the beginning almost a copy of Java. Now those guys have a lot of interesting features, that java is lacking. But still it should be easy to learn one, when you know the other.
For a job: It is irrelevant how many jobs there are. You only want one anyway right? So you should check what kind of job you are interested in? Web, Mobile, Embedded, Rich Client, Big Servers.
So what is the real advice? Go, find an employer NOW. Tell them you'd like to work in [whenever you are done] and you'd like them to tell you what you should learn in the mean time.

Personally I don't think Java is going away anytime soon, so IMHO Java is just as good a career move as .NET if not better. In any case, I would say that both options will give you plenty of job opportunities.
The languages are pretty similar so you'll most likely find the transition easy, but obviously you need to familiarize yourself with various libraries and frameworks as well (depending on what type of applications you'll focus on).
A lot of what you know from the Java world is really OO, patterns and so forth and that will apply equally well in the .NET world.

I work for a .NET shop, and I can say that as a hiring manager/interviewer, I don't think of a lack of .NET experience from a recent college grad to be a problem -- very few colleges and universities use Microsoft tools, and as other posters have said, the platforms are conceptually similar. What I expect from a recent college grad is energy, enthusiasm, and a solid grasp of CS fundamentals.
That said, I also don't consider a four year degree to be "4 years of java experience" -- student projects are nice on the resume, and are good to talk about in interviews, but unless you have been doing a lot of coding for hire on the side, one year of "real world" experience (where your job is to write software) teaches more about work ethic and delivery than 4 or more years in college.

It depends a bit on what type of personality you have and on what level you understand java. Allot of concepts are the same between the two platforms only with different implementation details, syntax, names etc... on one level I find .net easier since you often deal with all Microsoft products which tend to align with each other pretty well as where in the java space I've had to spent time figuring out how to get product A by supplier X to work together with product B by supplier Y. So if you have more then what I would call a "literal" understanding of java the move should be very easy.
I think you should be able to find jobs in both platforms just as easily imho
If perhaps this move is also being fuelled by eagerness to learn new things then I would advice you to go for something different like a dynamic or functional language.
There are a couple of books which focus on moving from java to c# (I haven't read them so I can not advice on one) but those should really get you up to speed in a matter of hours/days.

I wouldn't bother with learning C# for career purposes. And I say this as a happily employed C# programmer. :-) Oh, I suppose an explanation is in order...
It's much more valuable to know diverse languages. When I'm hiring for a position that's going to be writing C#, I'd much rather hire somebody with lots of Java experience and also some Scheme and Erlang (and no C# at all), than somebody with just Java and C#.
C# really seems to combine two things: the static typing and syntax from the Java world, and a handful of additional features and syntax from the functional world. If you know Java, Lisp, Python, and Javascript, then you can learn C# -- or pretty much anything else -- in almost no time at all. (You won't land an architect position, but you won't be getting that right out of school, anyway.)
The only trick is finding an employer enlightened enough to realize this, and not simply one that feeds resumes through a pattern matcher. But simply putting "Lisp" on your resume is often enough to turn the right heads.

java and .net are both fine i guess.
as long as you want to keep portability to linux, mac os or any other system, you might keep on java. if you want .net-applications for other platforms, you would need to rely on Mono, which is for sure a great project but in my opinion not yet stable enough for production.
if you want to stay on microsoft-world, i consider C# as one of the best development tool i've ever seen. indeed the visual studio, which provides many important coding features really makes the work easy.
they're both approximately the same from the learning aspect. java lacks operator overloading which is an important point in my eyes. .net might lack other features java is better at... and generally i guess in most of the applications, .net is faster than java.
hope this helped a bit
regards

If you write in C#, you will find a lot of similarities to the Java language, and the CLR shares many concepts with the Java runtime, too.
You could as well write both. For exercise i created a chat-program in C# and the server for it in Java and had a lot of fun doing that. You could concentrate on .NET and occasionally use Java. Nothing wrong with that, anyway, more important than being used to a language is the concepts you learn over the years, such as design patterns, best practices and algorithms. Those will help you to understand any new framework or library much quicker as you recognize the patterns and purpose behind it.

I agree with most of the advice others have already given. Both platforms are here to stay and both should provide decent career opportunities.
Just a word of caution though. You write "at least in my country" regarding .Net opportunities. I think you also need to consider "at least in my country" when deciding how large the career impact will be in the short term.
I have worked extensively in both the USA and Germany. My experience has been that, in the USA people are hired more for demonstrated ability than for resume points, but in Germany the situation was reversed. You will have to weigh the short-term impact in your country, unless you want to post which country that is and hopefully someone on SO has experience with that country.

Your Java experience and concepts will come in handy when transitioning to C# and they're not too different (to a certain extent, of course). I won't go into much detail about that aspect of your question since others have made good comments.
What I wanted to add is that although employers may not consider school experience to be equivalent to real world experience, don't let that stop you from referencing them on your resume. Be prepared to talk about them during the interview, as well as any side projects or interests you have. These are good for the "tell me about your favorite project?" and "what did you like most about that project?" type of questions. Be enthusiastic to learn and show a willingness to improve your skills. You can also show that you find certain aspects of C# appealing (perhaps contrast to Java) and that you're confident you'll be able to pick things up quickly and apply yourself.

Job experience is vastly different from the experience you get as a student.
Personally I think you should learn as much as you can while studying - this DEFINTIIVELY includes exotic languages - and only knowing one language, makes you a one-trick pony.
So, get your teachers to teach you exotic stuff. Like functional languages using pattern matching, logical languages for a vastly different approach to evaluating lots of possibilities, assembly language for doing the actual bit stuff, and all these other mind blowing things that people do for FUN and LEARNING :)

Ever done a total rewrite of a large C++ application in C#? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know Joel says to never do it, and I agree with this in most cases. I do think there are cases where it is justified.
We have a large C++ application (around 250,000 total lines of code) that uses a MFC front end and a Windows service as the core components. We are thinking about moving the project to C#.
The reasons we are thinking about rewriting are:
Faster development time
Use of WCF and other .NET built-in features
More consistent operation on various
systems
Easier 64 bit support
Many nice .NET libraries and
components out there
Has anyone done a rewrite like this? Was it successful?
EDIT:
The project is almost 10 years old now, and we are getting to the point that adding new features we want would be writing significant functionality that .NET already has built-in.

Have you thought about instead of re writing from scratch you should start to separate out the GUI and back end layer if it is not already, then you can start to write pieces of it in C#.
the 250,000 lines were not written overnight they contains hundreds of thousands of man years of effort, so nobody sane enough would suggest to rewrite it all from scratch all at once.
The best approach if you guys are intend on doing it is piece by piece. otherwise ask for several years of development effort from your management while no new features are implemented in your existing product (basically stagnating in front of competition)

My company actually did that. We had a C++ code base of roughly that size, and everybody (programmers, management, customers) more or less agreed that it wasn't the best piece of software. We wanted some features that would have been extremely hard to implement in the old code base, so we decided (after many discussions and test projects) to rewrite it in .NET. We reused the code that was modular enough using C++/CLI (about 20% of it - mostly performance-critical number-crunching stuff that should have been written in C++ anyway), but the rest was re-written from scratch. It took about 2 man-years, but that number really depends a lot on the kind of application, the size of your team and on your programmers, of course. I would consider the whole thing a success: We were able to re-architect the whole system to enable new features that would have been near-impossible with the old code base. We also could avoid problems we often had in the old software by re-designing around them. Also, the new system is much more flexible and modular in the places where we learned that flexibility was needed. (Actually I'm sometimes surprised at how easily new features can be incorporated into the new system even though we never though of them when we designed it.)
So in a nutshell: For a medium-sized project (100k-500kloc) a rewrite is an option, but you should definitely be aware of the price and risk your taking. I would only do it if the old codebase is really low-quality and resists refactoring.
Also, there's two mistakes you shouldn't do:
Hire a new .NET programmer and let him/her do the rewrite - someone new can help, but most of the work and especially the design has to be done by developers who have enough experience with the old code, so they have a solid understanding of the requirements. Otherwise, you'll just repeat your old mistakes (plus a couple of new ones) in a different language.
Let a C++ programmer do the rewrite as their first C# project. That's a recipe for disaster, for obvious reasons. When you tackle a project of that size, you must have a solid understanding of the framework you're using.
(I think these two mistakes might reasons why so many rewrites fail.)

Its been tried before, not only C++ => C#, but VB6 => VB.NET, C++ => Java and any other old => new that you can think of. it never really worked. I think that because ppl don't consider that transformation for what it really is (a total rewrite) they tend to take it lightly.
The migration story from C++ => .NET should be thru CLI, carefully deciding what managed and whats remains unmanaged and s-l-o-w-l-y "fixing" piece by piece.

Expression Blend was originally an MFC app. The current version uses WPF for the UI but the engine is still all native. I saw a great talk by principal architect Henry Sowizral about a year ago where he described the process of the migration. Make the engine UI agnostic and you will be able to support whatever the latest UI technology is. The Expression team at one point had what he referred to as the hydra-headed version. Two front-end UIs running simultaneously with one underlying engine - in this way they could see where behavior had unintentionally deviated from the previous version. Since the UI subscribed to events and notifications, changes made in a WPF toolwindow were reflected in the old MFC toolwindow.
EDIT: Looks like some powerpoints are available here or as html here.

I've been through a project that did exactly what you're describing with approximately the same size codebase. Initially, I was completely onboard with the rewrite. It ended up taking 3+ years and nearly turned into a death march. In general, I now agree far more with the incrementalists.
Based on our experience, though, I will say that such a rewrite (especially if you're able to reuse some C++ business logic code in .NET), is not as technically dangerous as it may seem. However, it can be very socially dangerous!
First, you have to make sure that everyone fully understands that what you are undertaking initially is a "rewrite" (or "remake") not an upgrade or "reimagining." The 1998 Psycho was a shot-for-shot remake of the 1960 original. The 2003 Battlestar Galactica was a reimagining of the 1978 original. See the difference?
In our case, the initial plan was to recreate the existing product in .NET. That would not have been technically daunting, since we understood the original well. However, in practice, the urge to add and fix and improve just a few things proved irresistible, and ultimately added 2-3 years to the timeline.
Second, you have to make sure that everyone from the execs to sales staff to the end users is ok with your current product remaining unchanged during the development of the remake. If your market is moving is such a way that you won't be able to sustain your business during that period, then don't do it.
So the main obstacles for us turned out to be social, rather than technical. Users and business interests became very frustrated with the lack of visible progress. Everyone felt compelled to push for their own pet improvements and features, too, so our final product bore only a superficial resemblance to the original. It was definitely a reimagining rather than a remake.
In the end it seems to have turned out ok for us, but it was a real grind, and not something we'd choose to do again. We burned through a lot of goodwill and patience (both internal and external), which could've largely been avoided with an incremental approach.

C++ won't automatically translate to C# (not so you'd want to maintain it, anyway), and you're talking about using different frameworks.
That means you're doing a total rewrite of 250K lines of code. This is effectively the same as a new 250K-line project, except that you've got the requirements nicely spec'd out to start with. Well, not "nicely"; there's doubtless some difficult-to-understand code in there, some likely because of important issues that made elegance difficult, and the overall structure will be somewhat obscured.
That's a very large project. At the end, what you'll have is code that does the same thing, likely with more bugs, probably fairly badly structured (although you can refactor that over time), with more potential for future development. It won't have any of the new features people have been asking for during the project (unless you like living dangerously).
I'm not saying not to do it. I'm saying that you should know what you're proposing, what the cost will be, and what the benefits would be. In most cases, this adds up to "Don't do that!"

I did something similar. Part of my job involves developing & supporting some software called ContractEdge. It was originally developed in Visual C++ 6 by a team in India. Then I took over the development role after it was basically done in 2004. Later on, when Windows Vista was made available as a Beta I discovered that ContractEdge would crash in Vista. The same thing happened in the release candidate.
So I was faced with a decision. Either hunt for the problem in tens of thousands of lines of mostly unfamiliar code, or take the opportunity to rewrite it in .NET. Well, I rewrote it in VB.NET 2.0 in about 2 months. I approached it as a total rewrite, essentially scrapping everything and I simply focused on duplicating the functionality with a different language. As it turns out I only had to write about 1/10th the number of lines of code as the original. Then we held a one month long beta program to iron out any remaining bugs. Immediately after that we launched it and it's been a big success ever since, with fewer problems than the C++ version it replaced.
In our particular scenario I think the rewrite worked out well. The decision was made easier based on the fact that nobody on our team was as familiar with C++ as they were with .NET. So from that perspective, maintainability is now far easier. Nowadays I do think C++ is too low-level of a language for most business software. You really can get a lot more done in .NET with less code. I wrote about this subject on my blog.

Total rewrite for the sake of rewrite? I would not recommend it.

In addition to other responses, I would not take "faster development time" for granted. Sure, for most "business" data-centric applications it will probably be the case, but there are many areas where .NET will not bring in significant productivity increases, plus you need to take the learning curve into account.

We've done a big C++ >> C# migration as we move to .NET. It's a quite tough project. Management would hardly bite the funding for it, so you have to go for a compromise. Best approach is to leave the innermost (or lowest) layers in C++ and cover the upper part with C#, with better APIs designed with newer concepts like readability and API-usability in mind, safe-guarded with unit tests and advanced tools like FxCop. These are obviously great wins.
It also helps you layer your components a bit better as it forces certain cuts. The end product is not nice as you might end up copying a lot of code in C++ because years and years of coding contains many bug fixes and many undocumented and hard-to-understand optimizations. Add to that all the pointer tricks you could do in C (our code has evolved from C into C++ over time). As you stabilize you find yourself more and more reading the C++ code and moving it into the C# - as opposed to 'cleaner design' goals you had in mind in the beginning.
Then you find out that interop performance sucks. That may call for a second rewrite - maybe use unsafe C# code now. Grrr!
If all the team members come from C++, the new code is also look like a C++ design. Try to go for a mix of C# and C++ developers in the team, so you can get a more .NET-alike API at the end.
After a while, the project may lose interest and mgmt may not fund the entire re-write so you end up getting a C#-sugarcoated C++ code, and you may still have unicode/64-bit issues unresolved. It really calls for a very very careful planning.

I was involved in a very similar size project. It was necessary to rewrite the GUI front end because of new hardware and new requirements. We decided to port this to .NET using C++/CLI. We were able to reuse more then halve of the code and porting it work quite well.
We were able to take advantage of .NET where it made the most sense. This made major parts of the code much cleaner. We found the book "Pro Visual C++/CLI and the .NET 2.0 platform" by Stephen R. G. Fraser very helpful.

Have you considered a port to C++.NET? It might be less painful.

I'm currently rewriting a rather large web application.
One thing to remember is that when converting from one language to another especially something like C++ to .Net is that you may end up with less, and probably cleaner, code due either due to language advances or framework code.
That's one advantage for future maintainability, even aside from the opportunity to re-architect the less robust aspects of the old application.

Some additional comments.
Depending on the lifespan of your application you may be forced to rewrite it in a modern language since I suspect that C++ developers will become increasingly hard to find.
Just moving the app to a new language will not reap that great rewards. You'll probably want to do a redesign of the app as well! Do not underestimate the effort required to do this. I would guess the effort for a redesign + rewrite could be as much as 50% of the effort for the original implementation. (Of course, 50% is a totally unscientific guess).
It's way to easy fool yourself into thinking "Well, C# and WPF are just so much more productive that rewriting this mess would be a piece of cake!"

Interestingly most of the answers from people who have done this seem positive. The most important thing IMO is to have good unit tests so that you can be sure your rewrite does what you want it to do (which may not be exactly the same as what the old code did).