...not to mention there are still plenty of bugs and data type/memory management is awfully inefficient....
If this were its only problem, then it is no big deal to get a gc (garbage collector) for C/C++. If memory allocation was inneficient, it would again be trivial to get a high speed allocator "drop in" replacement for malloc/new. There are even product that do both at once.
no multithreading capabilities.
This is a bigger issue, and an extremly difficult one to get correct. For example, if I were building this system, I would write so that it was not only multi-threaded, but distributable as well.
if i were him i would stop trying to "fix it" and start rewriting from scratch, but like in trading, some people refuse to recognize they are wrong, cut your losses short and move on. too much ego.
Yes - this shows your real understanding of programming technique. But IMHO, shows a lack of experience in writting complex systems. In almost every software engineering project that I was involved in, we often wrote a system that we knew we were throwing away to learn what the difficulties were. In addition, something that took great pains to do in one language, became "obsolete" as other languages, or tools, became available. The best engineers understand that all programs are special purpose languages for the domain they are "modeling." First they learn the "language" of the domain by building a prototype, then they build the special purpose language that would have made the prototype in a 1/25 the number of lines of code. The special purpose language would be designed to also be reflective (in the way that java or C# are) so that anything not handled by the language would be easily implemented (btw, this is why systems like TradeStation suck - they are not reflective.) The ability to adapt to new instruments/datafeeds, etc is also critical, as a six month advantage in coming up to speed to trade a brand new instrument can mean millions or tens of millions of dollars in profit. If you just wrote something that dealt with the domain as it exists now, this would take months to adapt. If you wrote a specialized language that you then used to write the program in, it would take a fraction of the time. The best programmers are the language designer/writers.
Given todays languages (without the luxury or skill to implement the special purpose language) there is no question in my mind that the best compromise in to write these sorts of tools a hybrid environment of programming languages. For example, I would use assembler of the most time critical parts. I would use C++ for the low level stuff that could not be done in a higher level language, but did not need the absolute speed of assembler, but could benefit from the portabilty of C++. Finally, for all non time critical and high level stuff, Java, (or C# as the compiler as it matures and if it only needed to run on Windows) would be my choice.
The poster above that suggested Matlab as the orinating language is not differentiating between the "Model" and the "View." Systems like Matlab are great for writing the view, but are not expressive enough to write the model (hence his suggestion that you interface with a C/C++ program.) It is imperative that the "simulartor" be written in such a way as to be able to accept multiple views, or my prefered term, metaphors. I know that there are many people that are very comfortable with Excel - why alienate them?
Finally, to the orignal poster - I would use your system if you designed it in one way - make it reflective. That alienates languages like C/++ and leaves Java (and possibly C#) to implement it in. If this was not an option, then make it open source so that, if I needed to implement something, I could do it with enough sweat.
nitro
.