i know them when seen, but actually it's easier to tell those who aren't http://en.wikipedia.org/wiki/Expert http://en.wikipedia.org/wiki/Expertise
I see we have a language bigot. Programming languages are tools, like anything else. Use the best tool for the job. Why do quants continue to write production systems in C/C++? Because they can guarantee performance. Good luck guaranteeing performance with perl and python. Edit: I'll throw in this also: Another reason C++ is still so prevalent is the huge investment in the form of legacy code. You need experienced C++ talent to port that intellectual property into other languages/frameworks. -segv
Good point.. I'm not a fan of designing complex software in C/C++, but what kind of performance are you guaranteeing ? For realtime number crunching speed is criticial.. but for offline optimization, some of the higher level interpreted lanuages might actually be preferred due to the increased maintainability. I'm working on a hybrid java/realtime platform now where simulation/computation threads are scheduled by the OS using highly optimized generated C code and can be used as plugin modules in online or offline analysis and near-realtime performance is gauranteed with clever use of linux 2.6's threading capabilities.. I've not yet lucked into hard realtime linux because for my purposes it is not necessary, but there are ways to obtain a good balance.
This needs correction. If you are talking abouy scientific calculation, Python gives you access to the most reputable mathematics and statistics libraries, developed over tens of years. A lot is still done in Fortran, both for the C++ as the Pyhon case and requires Fortran runtime libraries. Setting up identical calculations in C++ - identical libraries are used - will result in practically identical execution times as in Python. By far most instructions executed are from identical highly optimized code. Python code comes only in as kind of a glue linking calls to such libraries. The C++ program, if done correctly will perform a tiny bit faster, but at what development cost?
I agree. It should be noted that the inverse is not true. A programmer with experience in only perl/python/java/etc will not be likely pick up C/C++ in a week. Hence the demand for C/C++ experience. Again, I agree with Nitro here. Rapid prototyping in a lightweight language is extremely common, and some people are of the opinion that it is a best practice. -segv
That's obvious, but nitro did not address the Python -> C++ case. This is due to the fact that C++ is a "high clutter" language, difficult to learn and error prone. C++ and especially C are historical monuments. The elegance of Python consits partially in not do away with these but build on C/C++ making access to C tools very easy in places were required. Since my migration of trading programs to Python, I never had to use this, except for occasionally wrapping some existing C code. Making predictions is always tricky but I can see C taking its place next to Assembler: indispensable but known and used by the few. All other programming will be done in Python and Ruby kind languages. Perl is in fact in a class by itself; highly efficient in the hands of adepts, it can hardly be called a language next to Python or Ruby. Java and its clone C# have no future whatsoever as people will become more and more suspicious of proprietary code owners. I can see a move towards 100% OpenSource for basic tools like compilers. This is the way history shows us since C back from around 1975. Did you ever see any serious piece of critical code done in Java or C#?
I am talking about execution time guarantees and resource utilization guarantees. Both are essential in real-time systems. I wholeheartedly advocate using the right language for the task at hand. If the task at hand involves real-time guarantees, C/C++ and assembly are the right tools. If the task at hand involves offline processing, pick the right language for the type of processing you are doing. -segv