Language of the future
- Thread starter leveragize
- Start date
Because we will all speak LISP or FORTH, depending on how much you like (or dislike) parentheses.
IIRC many retail platforms (NinjaTrader, OpenQuant) use C#. Some open source platforms use Java.
Thinkorswim and eSignal use Javascript syntax with their own interpreter.
Metatrader 4 (most common platform in Forex) uses a Javascript-like coding language called MQL4
Metatrader 5 uses a new language based off C#
Hehe, this thread is interesting, and a bit silly. I've been programming for about 6 years full time. A good coder knows all the languages fairly well. In the end there is no single language that is the future, it's what you need it for. C++ can access the lowest level in general and is good if you need memory management, thread and CPU cycle management all done by yourself and optimized. For further optimizations you'd go into ASM, but I think only realtime 3D applications need that. For all intents and purposes, the managed .Net platform is ideal for automated trading development. Most systems do not require huge amount of optimizing in terms of CPU and memory, unless you're working on a microsecond HFT that is.
Asking what language is the future without stating in regard to what is like asking which tool is the best? The screwdriver, the hammer or maybe some clamps?
Languages work on different platforms which have different capabilities and so when performance is an issue, I'd say C++. For most automated trading systems it's probably C#, or any other .Net language like VB or F# since the final interpreted code is almost exactly the same regardless of how you type it as long as it's .Net.
lol uhm... no.
Python compilers are always much slower than the average language, it lacks features and low level control. Source libraries, really? Hmm, didn't see that many compared to say c++. Then again, i'm not sure what we're talking about here.
Asking what language is the future without stating in regard to what is like asking which tool is the best? The screwdriver, the hammer or maybe some clamps?
Languages work on different platforms which have different capabilities and so when performance is an issue, I'd say C++. For most automated trading systems it's probably C#, or any other .Net language like VB or F# since the final interpreted code is almost exactly the same regardless of how you type it as long as it's .Net.
lol uhm... no.
Python compilers are always much slower than the average language, it lacks features and low level control. Source libraries, really? Hmm, didn't see that many compared to say c++. Then again, i'm not sure what we're talking about here.
You were doing pretty good up until that observation.
Yeah, Python and the like can be accused of that. But, so could C++ back when Stroustrup first created it. Anyone around long enough remembers running your code through cfront, the first C++ compiler.
It wasn't fast or complete, but it worked. There were hardly any libraries available either back in the 80's.
What Python can do that Java, C++ and C# can't do too well is rapid prototyping. Other languages can do that even better.
For some things those languages shouldn't even be considered, like when you have a fairly complex conversion task that you're only going to do once. Perl is perfect in those situations, it's quick, dirty and has a ton of libraries.
I was really trying to figure out which language features people care about in trading. I want to hear your opinions regarding:
1. memory management (GC vs unmanaged)
2. concurrency model
3. static typing vs duck typing (or better yet, type inference)
4. object-oriented programming vs functional programming
1. memory management (GC vs unmanaged)
2. concurrency model
3. static typing vs duck typing (or better yet, type inference)
4. object-oriented programming vs functional programming
1. Depends on how fast you need the memory access, and the amount of memory you will need. HFTs need it fast and in huge amounts, so it's very important. MFTs need less speed but if they monitor huge amounts of pairs per machine, may need better memory management. Single-stock scalping systems don't care about it.
2. Mostly depends on how many pairs you're watching. Most strategies will work OK without extremely optimized parallel execution. It usually pays of to have one machine do each pair if synclocking data would become an issue anyway (and thus slow it down).
3. Quite important in all cases.
4. There are people who don't use OO? Really? :/