|
No. Your risk is greater than your reward.
Java and C++ are two separate beasts. Java to C#, sure.
|
|
|
|
|
Yes, no, maybe so.
It depends 100% on the person. I have worked in C & C++; sometimes in well managed frameworks and sometimes working barebone. I have worked in VB, C# and Java, and not worried at all about it. Hell, I started in COBOL and have done too much Scripting to be good for any one.
Anyone can switch, the question to ask is do they have the desire to switch?
veni bibi saltavi
|
|
|
|
|
Nagy Vilmos wrote: Anyone can switch, the question to ask is do they have the desire to switch?
That's plain wrong.
As everybody knows, Java developers hate switch .
|
|
|
|
|
In case you didn't know, Javians lurve to switch , if you want to select a group who are different go slap the VB boyz.
veni bibi saltavi
|
|
|
|
|
No.
There are exceptions of course.
No, really, there aren't exceptions.
|
|
|
|
|
I say, Java to C# would have been a 100% yes (maybe 110%) but Java and C++ (as you're mentioning embedded programming) are entirely different. Java (as OriginalGriff has mentioned above) works on a framework, known as Java Virtual Machine, which executes the bytecode of Java by Just-in-time compilation process. C++ on the other hand has to be compiled to the metal and thus, every processor architecture needs to be sure of, x86 or x64 and other bla bla.
I would have asked that person whether he knows some about Java ME. Java SE and Java EE are all high-level frameworks and they run on JVM (you know), where as Java ME (although not a low-level but) has a few low-level stuff and needs to be memory-efficient, the SDK is also built for micro devices and would allow you to learn a few things I have personally enjoyed this, it is used for programming embedded devices or other micro controllers.
If the developer is eager, (as OG mentioned) hire him, give him a test time. Allow him to learn the frameworks and language (C++ and Java are differnet languages in their structure also!). Indeed if this was for me (and the offer was worth investing my time for), I would have learnt C++ and embedded device programming in a matter of 2-3 weeks.
Programming is fun!
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
If they are straight out of university, they are largely stuck with what the university teaches: Java in this case. That doesn't mean they CAN'T learn, it means they were taught Java.
So... can they make the jump? Depends on the person. Bring them in, give them a chance. Realize they have a steep learning curve and don't let them make production changes. Mentor them, code-review them, but allow them to learn.
|
|
|
|
|
|
Sorry but no, unless he has some side projects with C or C++ on Arduino.
|
|
|
|
|
That's for sure, if he/she only program in Java, then it would have a hard time with C++, but if he can learn another language and use several ones besides Java, hire him/her.
|
|
|
|
|
It will get hard, because Embedded C is pure C and a lot of bitshifting and memory access. And the Java is high end server stuff. If the guy is smart and willing he can and will learn it, but he will need its time and a lot of passion. But it will take time and maybe the guy isnt satisfied and leaves after some months.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I'm going to argue the other direction. A bit over a year ago I was drafted for an internal PIC32 embedded project despite my professional career having been in .net and other high level languages; with C++ being something I did and forgot over a decade ago in school.
It was a major shift; but I didn't have any major trouble picking it up. I only had two majorish problems that would've been managable if I'd had more than a month or two for a crash project. The first was the slow deployment process horking up a lot of my (especially early) time estimates. (The amount of time I spent coding was in line with what I was expecting; but the difference between being able to click run and stopping at a breakpoint a few seconds later and having to spend several minutes programming multiple chips first slowed everything down a lot.) The other was a combination of my not knowing how to read board schematics/translate data sheets into reality (and for most of the time not even having a viewer for the format the schematics were made in); and limited information flow with the person who designed boards and wrote the lowest level code about how the low level bits he was writing were intended to be used and where IO pin multiplexing meant that I couldn't use X and Y at the same time even if I wanted to.
I'd talk to the kid and make sure he understands what he's getting into. If he's expecting to have a bunch of huge libraries and to never worry about memory use I'd be worried; but as long as he understands what he's getting into and appears able to learn I don't think it should be a major concern. It's not like a kid right out of school is going to be able to work in whatever they thought they were learning without a non-trivial amount of ramp time after all.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I'll agree with the others who say it depends. I got a BSEE back in 1994. The place I was working at the time was a C/Assembly shop doing embedded programming. Our program at my school had 1 semester of 6502 Assembly, and a semester of FORTRAN. No requirement for C. I learned how to do C on the fly, and actually got to the point where I could write faster, smaller, and more efficient C code than most of my colleagues' assembly code. I was writing ISRs using C when that was frowned upon. I did that because it was easier to debug, and then just tuned the C to output the assembly I wanted.
We had a mix of people. Some were EEs like me, some had CS degrees. We basically split the work up so that the EEs were doing the board level stuff, and the CS people were doing the application level stuff. This was layered so that we could do a lot of the application level stuff on the PC first and debugged there.
The personality of the person I think has a lot more to do with how good or bad they are as a developer. One of the best developers I have worked with didn't even have an associates degree in anything, just a high school diploma. One of the worst ones I worked with had a masters degree in EE.
I'd say to talk to the person yourself, and you can tell if they are someone who likes to learn or not.
|
|
|
|
|
You guys are great. I was going to post this over in the Java forum, but the first 12 posts were clearly homework related.
I do agree that SOME people could make the jump. It's funny, one of my programming questions to candidates is: What's the largest unsigned value you can put in a byte? I'll usually clarify it by saying, "You know, 8 bits...". If they have a clue they know I'm setting a trap . So we agree that the largest value is 255. Good. Now, what's the largest value you can put in a word - 16 bits? And if they have no concept, they'll say ... 510.
Anyway, I like the idea to try them out, sort of a no-fault clause.
I truly appreciate all of the feedback.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
size of a word in c is processor dependant. if the size of a word is 32 bits the largest value would be 0xFFFFFFFF. If it is 64bit it would be 0xFFFFFFFFFFFFFFFF... at least if the word was unsigned... else the largest value would we 0x7FFFFFFF and 0x7FFFFFFFFFFFFFFF.
Can I get the job?
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
lol, I disagree. You CS types f'd it all up. point taken, but to avoid confusion, we now have word, long word, long long word, etc.
but specifically I would even mention the # of bits I was talking about, just to see if they have a clue for binary. I want to know what they see in their head mentally. Interestingly, if you put that you know C, you better know something about this... otherwise you lost me. Have had people with MS in computer science.
fwiw, the company I consult for is actively hiring embedded or close to embedded. If you like or think you like the Atlanta area, contact me off line.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Yes, no, perhaps ...
It largely depends on the person. I used to work with a developer who could switch (self-taught) to almost any language and be quite proficient and knowledgable within weeks. I have also worked with people who could not program their way out of a wet paper bag. So you need to look much more closely at the person, and their skill and ability, not just what they have worked on in the past. Face to face interviews can usually weed out the ones who think they can blag it*.
*Although TBH, that's what I got away with for much of my career.
|
|
|
|
|
This is true.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Biggest concern: Java has memory management. C and C++ do not, you do that on your own. If the Java developer has never had to be concerned with memory management they will create a program that will leak memory and program will run for some time then it will fail, especially in embedded world. I came from assembly, C / C++. Then I learned Java and thought, wow that is nice, memory is managed for me. Going from Java to system level programming language like C will be a big learning curve.
|
|
|
|
|
Most likely NO!
And not because of not be able to program, but because he will soon be fed up with how hard some things must be done with c++.
For example, we had to do a C++ embedded project after more than 10 years of C#/.NET; after a thorough analyses of the c++ project and how it was supposed to be implemented, I ended up implementing first a full garbage collector.
Even the most careful programmer that comes from a garbage collected environment, that never in his life used a delete obj; statement will forget to free the memory even months after the start with c++.
|
|
|
|
|
|
Fresh out of college is tough. His/her depth is probably not nearly what they believe it to be.
If they really want to learn C/C++ and you have a run at them about embedded. Then maybe.
You could make it happen. But this would be a heavily mentored situation.
I would make them read a boat load of code, learn to build and test the systems you are working on.
They would have to read the libraries you leverage, and build a spreadsheet of .o file sizes, and impact on the executable sizes.
Then, they would be on small bug fix tasks (identify, verify, repair, review). The review is a review of their entire thought process, and a code review. Preferably DAILY of all code they propose to change. Until they are writing better code. Then they can start with small changes/enhancements, but I would review EVERY line of code for many many weeks.
If they are off by 10 degrees and you are not reviewing. In 9 months, they are going to be breaking everything. If you can keep them to 1 degree off, and constantly monitor, you should both be happy.
The great part of this, is that SOMETIMES when you go through this with management, they realize why it costs more to hire the people with the right skills up front.
But I don't mind investing in good people. Doing this has led to near lifetime relationships with these guys for me. They appreciate getting up to speed at an accelerated rate.
HTH
|
|
|
|
|
It's not just about language - does the candidate have an appropriate knowledge of and inclination towards low-level programming, as you're likely to see in small embedded systems? Bits, bytes, addresses, malloc and free ... Realising there's no garbage collector to handle memory for them - maybe no heap allocation at all! Tight timing requirements, low latency responses... All of that is kind of non-Java... Just saying...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I'm inclined to also say no, but really what that means in this case is that their resume would not be at the top of the stack.
If they've only ever done Java, then I would expect a serious deficiency in their knowledge of memory management/garbage collection, since they're used to having that handled by the VM. Java also doesn't have pointers, so expect that to be another pain point.
That said, my company does hire a lot of kids fresh out of school. We start them with a 3 month paid internship (roughly $10/hour). If they're able to get up to speed in that time (and we have enough work), we offer them a full position. So far it's worked out pretty well. Out of 20-25 interns over that last 4 years there's only been one that we had to let go due to incompetence. The rest we either hired, or they got positions at other companies in our industry.
|
|
|
|
|
If it's a guy straight out of college, then he probably can't write in C++ OR Java, but just thinks very highly of himself. It's not like he's disabled or anything. If you have time to train him up, Java isn't unrecoverably dissimilar to C++. But it will be slow going for about two years until he has basic mastery of C++. He could be productive sooner if the project is not too demanding. (Without meaning to be insulting, if EEs do the coding now, it's probably not too demanding). But he won't be able to just sit down and start cranking out code the first day. You said you were agile, and hinted that to you agile means cronically in a rush. Retreading an enterprise java guy doesn't seem like what you want to do in a rush.
The mindset for embedded C++ is all about optimization and performance, templates and inlining and profiling. The mindset for enterprise Java is all about memorizing design patterns and writing elaborate factory methods. Learning the difference in syntax is easy. Unlearning the enterprise mindset and acquiring the embedded mindset is probably harder.
|
|
|
|
|