Should IB program a non-Java TWS?

Discussion in 'Interactive Brokers' started by local_crusher, Nov 1, 2005.

Would YOU want a non-java TWS?

  1. Yes

    64 vote(s)
    63.4%
  2. No

    37 vote(s)
    36.6%
  1. Simple answer. No. Anybody that builds platform dependent software is a fool - unless they want to be bought by $soft. Unless people are seeing performance degradation there is no reason to write platform dependent super optimized code ...... I would be very surprised if people that use the IB platform encounter performance barriers with the existing software ....
     
    #11     Nov 1, 2005
  2. Hmmm Java has "grave" shortcomings" ? Under which scenario ? Its a decent cross platform environment for general purpose use. Yes there are perhaps better alternatives to using the JVM and Java frameworks- not $softs dot Nut frameworks by the way.

    Which particular areas of Java do you deem inappropriate for general purpose use and which alternative are you using to get around your perceived problem areas in Java ?
     
    #12     Nov 1, 2005
  3. What do you care about java or anything else ? If speed is a real issue, the only thing you need is a direct line between your own trading software and IB's servers.

    Discussing questions of speed on a graphical interface is just a nonsense.

    IB : we need an API not relying on an unreliable piece of graphical software.
     
    #13     Nov 1, 2005
  4. To express my personal thinking:

    I've been a programmer for more than 22 years. I know the "early generation".

    When I wrote code, it was always a figurehead for myself and my mind. It HAD to be as fast and efficient as it could be. No matter if it was some 8Mhz 8086 or a multiprocessor target machine.

    Point is: One of the things in the world I hate most is: Interpreted code. No matter if it's GW-Basic, Java, Python or .Net; No matter if it's JIT-"compiled" - I have one word for it: HORSES**T


    I really did not assume so many of you rely on platform independence for trading front-ends(!), as Win32/64 is nearly standard for that in my opinion.
     
    #14     Nov 1, 2005
  5. alanm

    alanm

    The poll does not ask the same question as the subject. My answer is Yes for the poll, but No for the subject. I'd probably prefer a closer-to-native* TWS, but don't think they should do it.

    crusher said: - May be an increased cost for IB

    Maybe is a grave understatement. It's a huge amount of work, at a time when they have a full plate.

    Personally, I prefer the "feel" and appearance of well-designed apps crafted with the native Windows UI controls to some of the Java/Swing/whatever counterparts**. Platform independence means nothing to me, nor, I suspect, to the vast majority of IB users and volume.

    If they did have to maintain platform independence (or at least Linux/Solaris/Windows/Mac), it would be a huge amount of work to develop natively for each platform without resorting to some sort of plaform-independent library, like Java :)

    Might it be faster? I don't know. Most of TWS seems reasonable in performance for its capability, with the obvious exception of the charts.

    I don't remember if the back-end was ever changed from pre-TWS4 (pre-Java) days. I know there was a long time when you could use the old (non-Java) app as well as TWS4. I seem to remember the back-end was some sort of C/UNIX environment. Maybe one of the IB software folks can comment?


    *"closer-to-native": Almost everything anyone develops sits on top of some kind of framework or other set of libs. MFC, for example, while extremely useful, blurs the line between interpreted and compiled because of how generic some of the classes are, and how "interpretive" of runtime-specified params the underlying code has to be. Not that I don't use it alot, but you have to be careful in places where performance matters.

    **A good example is the TWS grid. When you attempt to re-size a column by dragging the border, if the adjacent column responds to a click event (like the "Last Change/%" column), after dragging in that direction by a few pixels, the column stops resizing, and the clickable column gets a click event (and does whatever it's supposed to do with it). I'm under the impression that this is not fixable by the application programmer (at least not without some sort of hack).
     
    #15     Nov 1, 2005
  6. Not being totally tech savvy yet... I just still want to know why ATS traders are required to API through the bloated TWS anyway?

    And what's so difficult with coding the API and/or TWS in C ... or C/C++.

    I try to avoid java. I really don't understand how it is still considered a "standard". My accounts of using any java sw, is it's lacking quality.

    It's seems to me that Java is becoming less and less common.

    Maybe one of these days IB will here the cry from their active clientele.
     
    #16     Nov 1, 2005
  7. def

    def Sponsor

    the back end is not written in java.

    this is a silly question. all i know that from my desk in HK it takes less than 20 milliseconds for my order to reach the HKFE upon the click of the mouse or entering a hotkey. However, as you probably know, it takes a person a couple hundred milliseconds to react to the brain telling the finger to click the button.
     
    #17     Nov 1, 2005
  8. Sam123

    Sam123 Guest

    Well, since IB is offering an API, they should pay attention to the platforms their customers are using. If most of them are using Windows, then they should be developing tools for the .NET framework by now, which offers the power of Java, C++, and Basic to the layman.
     
    #18     Nov 1, 2005
  9. Did they suggest it was? I thought they claimed it was written in Atari Basic, the old 8k cart.
     
    #19     Nov 1, 2005
  10. cmaxb

    cmaxb

    What I wish they would change:

    The C++ API is windows only. Come on, there must be way to make that platform independent. MyTrack could do it. I don't want to have to use Java if I choose Linux.
     
    #20     Nov 1, 2005