Sounds like you want your strategies to talk to each other? Still not really clear on what you're looking for, but we probably don't have it at the moment. If you can provide a clear example, I can look at putting in a feature request for it.
You obviously have a strong opinion on Java, so maybe MotiveWave isn't for you. With regards to your comment about fancy chart patterns and complex wave counts, we are not just an Elliott Wave software. We are a full featured trading platform. You can choose an edition without the EW features and use whatever trading tools you like to use. If you need more time after our 14 day free trial, we have leases on our Professional and Ultimate Editions. We will put up to 6 months' worth of lease payments towards an upgrade to a lifetime license, so you only need to pay the remaining difference. If you want to start cheap, we have editions starting at $99 for a lifetime license. For trading functionality, that starts at $295 for a lifetime license. We also put the cost of a lower edition towards an upgrade to a higher edition, so again, you only pay the remaining difference. Lots of options.
I don't know how MotiveWave is designed but I assume it is an event based architecture. I have used another product where strategies can be grouped together and you can attach a RiskControl script to the work space. When backtesting the group of strategies, the risk control script OnOrderPlaced event is fired for every order placed by every strategy. Within the risk control script, I have access to all strategies and all of their open trades and account equity/available cash. Within the script I can cancel the order or let it proceed. This is a very important feature because I might be trading dozens of correlated strategies and I have max exposure logic which will cancel orders when exceeded.
MotiveWave is not script-based as you're describing. So, currently you would not be able to do that in MotiveWave.
It's not that complicated. The strategies don't have to talk to each but position sizing has to be universal across all strategies in a separate function, so risk is assessed across strategies and not per strategy.
I know this is a legendary topic necro but I feel like I can contribute something meaningful to this. I am a software engineer professionally and have spent most of my adult life as one. There really isn't one answer. Aside from the below I'd like to recommend reading basically anything Ernie Chan writes. He has a very unique perspective on the industry and has many great suggestions on how to develop in his books. There are some general considerations for language choice. I will try to build a flow chart here: 1. How familiar are you with development? If you are not familiar with any form of general purpose language or you didn't take a college-level math class (using MATLAB or less commonly R) you would be best served by learning a platform specific language. Think ThinkScript, NinjaTrader's scripting, EasyLanguage, etc. These are designed to be picked up quickly. Alternatives to these are basically limited to Excel and Excel formulas. Excel VBA is a derivative of Visual Basic which would imply some familiarity with programming in a general purpose language. The entire finance industry is built on Excel sheets. Every financial engineering course I took was in Excel, except for one where I wrote some code in R. If you fit into these stage go no farther. The languages described in the above paragraph will be your domain. 2. What stage are you at in the development process? 2a. Research R, MATLAB, Python. MATLAB was the original realm of basically all of scientific programming. R has made dramatic jumps (especially with the inclusion of the optional Intel Math Kernel) and is sufficient for all but the most strenuous forms of trading. If you are familiar with 0-indexed languages you will find it difficult to navigate both MATLAB and R. In that case, I would suggest Python. Matplotlib is incredible. The primary draw to R and MATLAB is most complicated quantitative math has been implemented for you. For example, MLE variants of GARCH, ARIMA+GARCH, etc. Your goal here is rapid turn around. Speed doesn't matter. Research platforms (MATLAB, R) are the winners of this realm, followed by interpreted languages (Python has been adopted by the scientific computing community recently). 2b. Out of Research You can stick with the language you picked in (2a) for backtesting. Execution however will need to be addressed via the below. This comes with additional considerations: 2ba. What does my broker/execution provider offer? If you are operating on a pure FIX basis your choices are almost limitless. If you can write a FIX protocol library (or better yet find one!) you can use the language. Some brokers offer libraries to their platform. Some are REST-based. REST-based are limitless as well - though some languages are easier to work with REST than others. 2bb. What am I trying to accomplish? If you are using highly optimized and very expensive algorithms you are limited to C#, Java, C++, or MATLAB. R is currently not prepared for this type of execution. Before you say "of course I need quick execution" because you will, you probably don't. If you're not making markets or trading in the sub-minute market your requirements for speed don't even matter. You are best suited for whatever you are most comfortable with. At the point you worry about clock-cycle consumption you can pay someone to rewrite your platform. For reference I was storing nearly 2 million options chain records into a database per day before I had to deeply optimize both the queries I was using and the code I wrote to send the data off to the database. If you are just trading the standard bars (1m to 1M) you can use whatever you want. I prefer Java or C++. It comes to preference of their model of language. Both of these languages have a near unlimited supply of talent. Java's JVM takes some warming up to work right, and C++ takes some compiler voodoo to make lightning fast. It's personal choice. My opinion? If you don't have a preference go with Java. You will be hard-pressed to need something better and well written JVM-aware code is very, very fast. Appendix: Why not Python for everything? Python as a language is flawed in a number of ways not worth going into in this topic. Python has excellent C bindings making it possible to increase it's speed considerably. Python's Global Interpreter Lock gimps the language in a way that makes it useless outside of research. Why not OCaml/F#? Functional programming is great if you get it. You are, however, limiting yourself in terms of available talent and support. I love functional programming. I tend to stray away from it because it is not optimal for my use case. Why not Haskell? Haskell is a great research language. It is awful in practice. The only people who like it are type theory purists who shun every other form of programing and make fun of you from their ivory tower of excellence. Haskell programmers fall into the realm of researchers rather than engineers. I'll let you piece together the difference.
Outside of latency-sensitive stuff (i.e. anything where you're counting mikes becomes c++ territory), most places roll an interpreted language for both production and research. These days it's usually python, but still have legacy code (e.g. myself I have code in perl, R, python and a fair bit of VBA). The reality is that most of production code is not the code that sends orders, but rather a variety of micro-servers, converters, fitters, reports, alerts etc. Python is perfect for that and I honestly can't think of any other language that does everything just as well.
I agree with you primarily that Python has become the glue language PERL (ahem...perl) once was. Combine this with the relatively easy to understand syntax and it's no wonder trader-turned-developer types have flocked to it. It however has a number of faults I feel limit it's utility: 1. It is generally slow. Most people don't understand the C bindings well enough to implement a faster solution using them. The average code written and deployed is actually very slow. 2. Enforced tabs This is a pet peeve of me. Deeply nested functions you find in mathematically intense functions greatly over-run the 120 column limit most companies enforce for readability. This creates a mess of attempting to split something like a function that calculates the MLE of a GARCH function into a bunch of smaller functions just for readability. 3. Threading is garbage Global interpreter lock basically makes this point undebatable. Any sufficiently complicated task is either offloaded to the underlying C bindings or succumbs to absolute garbage execution. 4. Difference between declaration and use of a variable is ambiguous 5. A lack of static typing prevents verification of expected behaviors. In math functions this is very important to me. 6. Aspects of functional programming useful for mathematics such as numerical methods are bolted-on and thus poorly written The itertools library is an atrocious compromise given to you by the benevolent dictator who is an outspoken critic of functional paradigms. 7. As a professional developer the module system makes me want to bang my head against a desk The only module system worse in my opinion is Rust. 8. Object orientation is an afterthought 9. Having a "Benevolent Dictator for Life" greatly reduces the ability of the language to be flexible to industry needs. I think Python became popular because it was adopted fully and wholeheartedly by Google and crammed down everyone's throat. You have basically no choice if you want to use well maintained libraries for machine learning and scientific computing. That is, unless you can afford MATLAB. As a result it's popularity has greatly accelerated on the back of Google support. To me, it is far from ideal. It, to me, is the same as Javascript. It was adopted by a bunch of big names and thus gained incredible (unwarranted) popularity. However, to bring it full circle. For the average discretionary trader it is fine. I have built most of my models in C++ and I generally intend to keep them there. Professionally, I work in Java. Both are excellent languages - however I can understand the aversion to them given the (as you specified) affinity for Python in industry.
Yes, for average and beyond, discretionary and systematic I personally run a book that's just shy of 500 and I use python for almost everything (with some vestiges of older languages, Excel. Obviously, the DMA engine is written in C++ but all of the non-RT stuff is in python. In this business, choosing a technology platform is like choosing a wife. Ideally, you'd like one that's a swimsuit model but who'd gladly cook, clean and have sex nightly. In real life you have to settle for something more realistic.
Hmm...So what was the financial industry doing before Microsoft existed? What were financial engineering students doing before MS? I thought FORTRAN was the original realm of all scientific programming. Man, these modern systems and languages. Way too much to follow.