If you know C++ you can pretty much figure out any language that you might encounter. It's much easier to go from C++ to Java and etc. than it is to go the other way.
The two most useful classes that I had were an operating systems course and algorithms.
Good luck in your studies.
Graham
I work as a software engineer for a company that manufactures an FDA approved medical device. We are ISO certified as well (for design and manufacturing). There are no restrictions on using open source software for FDA medically approved devices. We use Linux on our embedded single board computers, several of the boost libraries, and many more open source libraries. If you have restrictions using open source in your workplace it is most likely because your ISO certified design process limits open source use. The design process is defined by your company and certfied by TUV auditors for ISO compliance. The actual ISO 9001 documents that specify what is required for an ISO certified medical company is actually very light. Oftentimes companies make additional restrictions upon themselves for their ISO certified design process (usually some dipstick with an MBA and no engineering sense whatsoever, but doesn't realize it). For example, if someone (let's assume the dipstick MBA) at your company stated in your design process (prior to the initial ISO certification) that open source code cannot be used and the ISO auditors certified your design process with that exclusion, then your company is bound to that limitation (even though the FDA or ISO standards don't limit open source use). Bummer eh? Good luck. It's a shame you have to deal with those restrictions.
This is another fine example of an article, by a member of the Java community, which attempts to wrestle the Java language from its stereotype of being used in mostly CPU idle applications.
The whole notion of moving completely towards interpreted language applications is laughable. Java has its place and uses; web applications, gui interfaces, and anything else that's sits idle 99% of the time.
The argument that processors are fast enough to run all applications written entirely in an interpreted language follows the comment, "Who needs more that 640k of memory?"
That's easy to answer, everybody that likes to push the performance envelope, write a deterministic application, benchmark their system to death, or tweak a system to the hilt for sh*ts and giggles. There are a lot of folks in this category.
Embedded application engineers relying on deterministic behavior would be foolish to get in bed with Java. Sure Java can make it last longer, but we want a quickie this time. Sorry, no time for foreplay. Trying to get something to happen every 5 microseconds, such as a good portion of modern medical equipment, would be tough with Java garbage collection and etc. looming nearby. Have fun sorting that out. Sure it can be turned off but there are numerous Java related barriers preventing high performance deterministic behavior.
Found a bug in the JVM? Ugh, try debugging that or worse try to get Sun to do it without a truckload full of cash.
Writing a cutting edge game? Could you imagine a project manager asking engineers, how can we make this Java coded game run faster without impacting the schedule much? Oh..Oh..Oh...me! I can answer that! Try C/C++ with inline assembly where needed and throw out the Java code. He'd pass out.
The Java versus C++ battles are as contrived as they can get. Why does the Java community pick on GCC and a limited set of code examples? Then they use Sun's flagship Java implementation against an open source compiler. That's like pitting Pee-Wee Herman against Mike Tyson. The simple reason is Java can't hang with a reasonably complex high performance application written in C/C++.
A better route than trying to push Java bloat on the rest of the developer community would be to deep six Java all together and push for a standard C++ threading model (boost threads), network interfaces (many already exist), a windowing framework (give us something better than the FLTK), and etc. With these tools in hand code written in C++ can be compiled for a wide variety of platforms more easily. We get the speed, flexibility, multi-platform usage with the same code base, and most importantly we can say bye-bye to Java.
Slashdot Mirror
If you know C++ you can pretty much figure out any language that you might encounter. It's much easier to go from C++ to Java and etc. than it is to go the other way. The two most useful classes that I had were an operating systems course and algorithms. Good luck in your studies. Graham
I work as a software engineer for a company that manufactures an FDA approved medical device. We are ISO certified as well (for design and manufacturing). There are no restrictions on using open source software for FDA medically approved devices. We use Linux on our embedded single board computers, several of the boost libraries, and many more open source libraries. If you have restrictions using open source in your workplace it is most likely because your ISO certified design process limits open source use. The design process is defined by your company and certfied by TUV auditors for ISO compliance. The actual ISO 9001 documents that specify what is required for an ISO certified medical company is actually very light. Oftentimes companies make additional restrictions upon themselves for their ISO certified design process (usually some dipstick with an MBA and no engineering sense whatsoever, but doesn't realize it). For example, if someone (let's assume the dipstick MBA) at your company stated in your design process (prior to the initial ISO certification) that open source code cannot be used and the ISO auditors certified your design process with that exclusion, then your company is bound to that limitation (even though the FDA or ISO standards don't limit open source use). Bummer eh? Good luck. It's a shame you have to deal with those restrictions.
This is another fine example of an article, by a member of the Java community, which attempts to wrestle the Java language from its stereotype of being used in mostly CPU idle applications. The whole notion of moving completely towards interpreted language applications is laughable. Java has its place and uses; web applications, gui interfaces, and anything else that's sits idle 99% of the time. The argument that processors are fast enough to run all applications written entirely in an interpreted language follows the comment, "Who needs more that 640k of memory?" That's easy to answer, everybody that likes to push the performance envelope, write a deterministic application, benchmark their system to death, or tweak a system to the hilt for sh*ts and giggles. There are a lot of folks in this category. Embedded application engineers relying on deterministic behavior would be foolish to get in bed with Java. Sure Java can make it last longer, but we want a quickie this time. Sorry, no time for foreplay. Trying to get something to happen every 5 microseconds, such as a good portion of modern medical equipment, would be tough with Java garbage collection and etc. looming nearby. Have fun sorting that out. Sure it can be turned off but there are numerous Java related barriers preventing high performance deterministic behavior. Found a bug in the JVM? Ugh, try debugging that or worse try to get Sun to do it without a truckload full of cash. Writing a cutting edge game? Could you imagine a project manager asking engineers, how can we make this Java coded game run faster without impacting the schedule much? Oh..Oh..Oh...me! I can answer that! Try C/C++ with inline assembly where needed and throw out the Java code. He'd pass out. The Java versus C++ battles are as contrived as they can get. Why does the Java community pick on GCC and a limited set of code examples? Then they use Sun's flagship Java implementation against an open source compiler. That's like pitting Pee-Wee Herman against Mike Tyson. The simple reason is Java can't hang with a reasonably complex high performance application written in C/C++. A better route than trying to push Java bloat on the rest of the developer community would be to deep six Java all together and push for a standard C++ threading model (boost threads), network interfaces (many already exist), a windowing framework (give us something better than the FLTK), and etc. With these tools in hand code written in C++ can be compiled for a wide variety of platforms more easily. We get the speed, flexibility, multi-platform usage with the same code base, and most importantly we can say bye-bye to Java.