How difficult is it to turn a “Java School” programmer into a C or C++ programmer? [closed]

Answer 1

Java programmwer would fit right into a C# house, as well as a C++ developer would.

The cross over into C/C++ would depend on the programmer but I wouldn't count their Java skills for anything other than general programming experience. I would also be surprised if you attracted many such applicants.

Answer 2

It is relatively simple to figure out if a graduate has solid understanding the basics irrespective of their 'language' group. These fundamentals include 1) Data Structures 2) Operating Systems and 3) Algorithms and their Complexity. These are essentially conceptual areas and discussing design or approach towards a particular problem in these can reveal how strong or weak they are. You dont have to make them write code.

I would say that if anyone has a strong base in these fundamentals, and equally importantly has a positive attitude, he can learn any other language.

I always go for these fundamentals and their evaluation - fresh grad or experienced. These are the primary criteria to get someone hired.

Answer 3

I am a java developer myself, but had a C/C++ base in college. And I am GLAD I started with memory management, lists, queues, stacks and most important: pointers. Although I don't use pointers explicitly, I know what's going on in the back of my app, find memory leaks, performance issues, etc.

I think the best solution is not asking Java/C# developers to learn C/C++ (and all the matters that come with these languages) when they go to work, BUT teach them these subjects in college. This would be the best solution.

As it is now, it's like fixing the effects/symptoms, not the actual cause.

Answer 4

It's just another language.

And if you stick with the relatively small subset of pure OOP features, there is really not that much to learn from a Java developers perspective. The only thing you should have to teach them in order for them to be generic OOP programmers is the fact that they have to implement a destructor to take care of their memory.

However, if they should be using the STL, templates, exceptions and the likes, they'll probably need some more guidance.

Answer 5

I have programmed in many languages and find C++ very difficult to figure out and be productive in, compared to other languages that I have used such as Java, C, Python, Fortan, Javascript, ASP and Perl. I would almost say it's in a category of its own. I do NOT believe that competence in one of the languages I just listed (including Java) is a great predictor of how good a C++ programmer a person might be. I think C++ almost requires a different type of thinking, and certainly the ability to hold a huge amount of information in one's head while coding, versus focusing mainly on the business requirements.

I have been trying to become proficient in C++ for years, despite never needing to use it at work (i.e. studying in my own time). It is very tough going and after all this time I am not sure that I would be successful and productive as a C++ programmer. I think I am reasonably competent overall in those other languages.

So, based on my small and clearly biased sample of one person (me!) I would suggest leaning towards developers who have demonstrated a substantial amount of past C++ experience if that is what they are going to be doing at work, day to day. You will need to spend more time finding those candidates but you will have a better chance of success in the long run, I think.

Answer 6

I started with C/C++ and moved to Java.

I'm not sure new grads really know anything--consider them clean-slate for training. You might even be better off with an uneducated hacker.

That said, it's fairly easy for a good engineer to shift back and forth between pointers, memory allocation and the like--but I think it's amazingly difficult to shift from garbage-collected OO back to non-OO.

When you are working with a system with GC, you get much better at thinking about your design at a high level. You can actually code in a way that is much more understandable. You start really having classes that focus on a single responsibility (most classes will be a few screens--most methods will be trivial).

I've never seen good OO C++ code, which is probably good because OO code isn't going to be all that performant and simply has too many small allocations/deallocations, short method calls and other little performance roadblocks to make a C++ programmer happy.

It's kind of like taking your race-car and putting AC, power steering and Power windows on it. Much more usable, but defeats the reason it was chosen in the first place.

By the way, I'd love to actually see some good OO c++ code if anyone has a reference...