Looks like we have different definitions of "system" programming :)
System programming is creating software that is a platform for some other software. Databases, trading platforms or application servers are those kinds of things.
But if we take your very narrow definition that system programming is only programming inside of an operating system, then there is almost none system programming being done in C++ and almost all of it is exclusively being done in pure C. There is not a single C++ line in Linux/Unix/MacOS X kernels nor their device drivers. C++ is used to implement some bloated userland stuff like KDE.
a guy that worked in a company providing a HFT platform.
Last I checked, Java was utterly useless in the HFT domain (not even because of GC, wasteful indirection, or its usual bloat, but simply because it uses JIT compilation).
rapidcoder wrote:
We are using Azul Zing... Java."
Looking at Azul's web page where some numbers are present ( http://www.azulsystems.com/products/zing/low-latency-java-applications ) that solution is still hopeless for serious HFT, although I can certainly see the allure for less demanding algotraders, quants and cheap new firms who can't pay a C++ developer.
There is not a single C++ line in Linux/Unix/MacOS X kernels nor their device drivers.
Apple wrote:
Language Choice
Apple considered several programming languages for the I/O Kit and chose a restricted subset of C++.
C++ was chosen for several reasons. The C++ compiler is mature and the language provides support for system programming. In addition, there is already a large community of Macintosh (and BSD) developers with C++ experience.
The restricted subset disallows certain features of C++, including
* Exceptions
* Multiple inheritance
* Templates
* Runtime type information (RTTI)—the I/O Kit uses its own implementation of a runtime typing system
These features were dropped because they were deemed unsuitable for use within a multithreaded kernel. If you feel you need these features, you should reconsider your design. You should be able to write any driver you require using I/O Kit with these restrictions in place.
Yikes.... Seems like I touched a nerve here, I was literally luaghing when I saw Fredbill30s posts and then... RAPIDCODER, roflmao.
Oh well.
Thanks for the wealth of Information.
As for what kind of programming:
I'm going to go on a limb and conclude that system programming implies programming OS features.
No, I am not doing system programming right now. Mabey in the future when I'm a bit more enlightened in more areas, but certainly not right now. I just want a good head start on my Degree, and wanted some advice from the pros (I can tell the pro posts from the... er.. "i know all, but am not entirely right" posts...) seeing as I have not the expertise to make this decision completely alone.
@ darkestfright: You have to be inclusive of the non-pageable drivers when making standards like these. Templates cause a larger than would otherwise be necessary function lookup table. They also aren't necessary when you're restricting the datatypes that are to be used to begin with.
If you really say what is better to learn C++ or Java. I would recommend you learn Java in your College and C++ on your Spare Time and they are almost so similar, you can easily understand that.
Of course this gives you higher Rates of Employment chances.
The restricted subset disallows certain features of C++, including
* Exceptions
* Multiple inheritance
* Templates
* Runtime type information (RTTI)
So basically it is C with classes, not C++. Eliminating templates means eliminating STL. Eliminating exceptions means basically returning error codes everywhere. This doesn't feel much different than coding just plain C.
Last I checked, Java was utterly useless in the HFT domain
Perhaps you are right, but that doesn't change the fact that many HFT companies *are* using Java and are not doing any worse than companies using C++. The guy I talked to was not the only one that I know of who's working for a Java based HFT company.
I honestly think that they're both fantastic. I know for a fact that Java is used often with databases, but not always. I've spoke with 2 professionals who handle databases. One with about 10 years of experience, the other 14. The younger one used mostly SQL and Java. He said he didn't have to worry to much about speed, so he didn't bother with other languages often. The other however, has to make his databases very fast. He doesn't use Java or C# often because they aren't fast enough. He doesn't accuse them of being slow, just simply not fast enough. He sometimes doesn't even settle for c/c++, but Assembler. So I guess that adds on to use what you need to depending on the situation.
For most programmers their C++ code or C code with optimizations will be much more efficient then anything they could program in ASM manually.
In my opinion ASM might be useful to learn for debugging purposes, or if you are planning on doing some very low level stuff with hardware like boot processes and maybe some other cases. Other then that it is a waste of time generally.
The other however, has to make his databases very fast. He doesn't use Java or C# often because they aren't fast enough.
That's funny, because databases are mostly about I/O and concurrency, which means by using C or C++ or assembly you don't win *anything*, and you make lots of things much harder to yourself.
It's not like I said he codes half of it in Assembly. He does what parts he feels is necessary, which isn't much. He uses Java and C# too if the situation permits it. He simply can't always use it though, because as of now C/C++ is faster at run-time if you know what you're doing. Note I said
if you know what you're doing.
He has a lot of experience under his belt in several languages, Assembly is one them.