Language of the future

Discussion in 'App Development' started by leveragize, Oct 14, 2011.

Which language is the future?

  1. Java

    12 vote(s)
    19.0%
  2. Scala

    5 vote(s)
    7.9%
  3. C#

    23 vote(s)
    36.5%
  4. F#

    9 vote(s)
    14.3%
  5. C++

    12 vote(s)
    19.0%
  6. OCaml

    2 vote(s)
    3.2%
  1. Div_Arb

    Div_Arb

    I didn't see Cantonese or Mandarin as one of the options.
     
    #11     Oct 25, 2011
  2. Because we will all speak LISP or FORTH, depending on how much you like (or dislike) parentheses. :)
     
    #12     Oct 25, 2011
  3. Mr_You

    Mr_You

    What languages are the most popular trading platforms using:

    Java or C#.
     
    #13     Oct 25, 2011
  4. IIRC many retail platforms (NinjaTrader, OpenQuant) use C#. Some open source platforms use Java.
     
    #14     Oct 25, 2011
  5. 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#
     
    #15     Oct 25, 2011
  6. 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.
     
    #16     Oct 26, 2011
  7. jprad

    jprad

    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.
     
    #17     Oct 26, 2011
  8. 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
     
    #18     Oct 26, 2011
  9. I pretty much agree, but it sounds to me like you half-admit that Python compilers ARE slow by today's standards. Still, I'll put up a fence with a sign that says "Depends what you need it for", and in that sense we agree.
     
    #19     Oct 27, 2011
  10. 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? :/
     
    #20     Oct 27, 2011