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. ...My original post asked for specific examples regarding why Java was inappropriate for coding a front-end client. Thus far, I see no answer to this question: I already know the answer and I was just making a point ......

    If you are a commercial entity that needs to distribute client software over more than one platform, and the nature of the application does not really make large resource demands on the vast majority of client computers, then it would be a bad business decision indeed - as well as a bad technical reasoning - to start writing client specific bells and whistles that are really not needed by your users .....

    Now on the server the technical points regarding using interpreted code might change the equation - but very often interpreters, pre-compilers etc are very fast on modern hardware. People often overestimate their needs even on the server ... its common mistake made by software people to make decisions without hard test numbers supporting their design decisions ..... Software vendors love this bad engineering behaviour by the way ....
     
    #31     Nov 2, 2005
  2. .
    Hi Craig,

    You bring up a lot of points. I didn't bother to check, but I can't get away from the idea that you are a 'happy' Java user - many are. True or not, Java's fortunes don't have anything to do with this. I don't even have to bother with either refuting or disproving your points. This all has been done as I pointed out already.
    "Beyond Java", by Bruce Tate at O'Reilly Sept 2005, ISBN 0-596-10094-9. In fact, many highly experienced software engineers state their views in this book. Interestingly, in Chapter 1. "Owls and Ostriches", the first section is titled: "1.1 Ignorance as a Virtue". (I don't want to imply that this applies to most posting here, but it could.)
    Java has known a great defection of top level talent the last 1-2 years. Its reign will probably be over in another 2 years. Don't panic if you are attached too much to it. It's still going to be around as an oldtimer for some time.

    As to the self-styled "professional" posters, styling themselves as fatherly know-all figures using arguments like IB is an amazingly well managed company - let me add, that I don't doubt this - all this has absolutely nothing to do with the argument at hand. There are other amazingly well managed companies in the USA which seem to run in the exact track mapped out by the "Beyond Java" book. (In fact one is the darling of Wall Street and some ET people can't stop posting about how the price of their stock is keeping on shooting up. Some must know better. :D )

    Let me add that I don't see everything 100% as Bruce Tate though. He basically sees Ruby and Python as very similar vehicles pointing the way to the future language-wise. Why? Takes a bid of study but Bruce does a good job on this. He kind of goes for Ruby, me for Python. I will be happy either way. In fact I run Ruby as well simply to keep ready. If I would have to switch one day, it will be far less traumatizing than to move from X to Y. Let me add that Google picked Python as its workhorse quite some time ago.

    Now all the 'Performance' and other lover's arguments in favor of their pets. A lot to be said about this. Roughly: C/C++ 10,000 LOC (lines of code), Java 5,000 LOC, Ruby, Python 2,000 LOC (less depending on how you count). (C# is no more than a kind of a Java clone). This brings out the fact that C/C++, Java etc all belong in the 'High Clutter' category, i.e. a programmer has to peck a lot of redundant characters into his keyboard in order to come up with the same result. As program-bug-devils love complexity, 5 times as much crap can easily result in 25+ times more programmer time to come up with a running solution. Interestingly, studies of programmer productivity regularly done since the assembler stone-age of computing kind of indicate that a programmer's day-output in LOC is amazingly constant. Ruby-Python are reputed to be about 10 times more productive in programmer's time.
    Then there is the crap about 'slowness'. It is not difficult to write a bit of code to show how bad interpreted languages are doing. You can do this for Java as well, btw. All this has nothing to do with the performance of the actual application. You simply never run that kind of dummy proof code in an application. Ruby-Python as programmed by the user is kind of a glue language stiching together library code. In fact this is the case for 99+% in most applications written in any language - some do much better than others though.

    Much more can be said about all this. I kind of did in the past already. Nobody pulled it all nicely together like Bruce. Nobody can afford not to answer these questions: YES or NO.

    One more thing. How do you forecast the future in computing? Look back a bit: Changes always come and when they come, they were not expected by most and surprise many. Bragging about 'great management' and other wailing doesn't help - Didn't lill' BG at one time not manage to even fool those pro-pillars of "well-managing-IBM" fat cats? IBM, DEC, Sun (,M$ :confused: ) have seen many who believed to keep on floating on cloud seven all the way till their pensions. :D

    If you want to survive, be prepared. Don't be an attached cash cow to be milked. That's the essence of the OSS message. I don't want to add anything more about the wisdom/security/stability of W (a.o.) platforms. Make sure you are platform independent, so may you reach retirement age in peace.

    nononsense
     
    #32     Nov 2, 2005
  3. :cool: PyPy :cool:
     
    #33     Nov 2, 2005
  4. Bruce would suggest: "Ruby on Rails".
    nononsense: I dunno :(, but I try not to fall asleep.
     
    #34     Nov 2, 2005
  5. "One more thing. How do you forecast the future in computing? Look back a bit: Changes always come and when they come, they wre not expected and surprise many."

    Well.... If you based the future on current FLOPS/Dollar or some other appropriate measure you would see that there still is a lot of spare capacity...

    The fact of the matter is there is currently a lot of computing power, storage capacity and even network bandwidth available for most commodity applications.

    Software vendors (and bookwriters/consultants) work hard to convince you that only they have the mindshare worthy of attention.

    At the end of the day this stuff is not very complicated and most of the discussions are simply marketing noise designed to part you from your dollars ......
     
    #35     Nov 2, 2005
  6. Right on prt,
    That's about the essence of the fast one BG in his younger days pulled onto IBM.
     
    #36     Nov 2, 2005
  7. About the future of computing:

    I've never been a friend of MSFT. I based my work on Unix/Linux ONLY for years for that reason.

    But one cannot deny that they employ a few great minds now. The platform is very mature.

    Now the point is, even MSFT has acknowledged the time of endless hardware performance increases is over. Just look at the Longhorn Candidates. Without doubt, one of the main design goals was, to make it as efficient as possible regarding memory and CPU useage (except for that Aero thing, of course, I talk about the Kernel).

    That just matches my thinking - full stop.
     
    #37     Nov 2, 2005
  8. nitro

    nitro

    I would say keep the front end as is, but remove the dependency of the API on the front end and allow FIX directly to execution servers over public internet at no extra cost or volume requirements. Lots of brokers do this now.

    To me this is the most glaring problem with IB - no free FIX connection directly to execution servers over public internet.

    Alternatively, implement a local FIX engine into TWS.

    nitro
     
    #38     Nov 2, 2005
  9. Nonon,

    The point is not whether Python or Ruby are better than Java. I can virtually guarantee that IB would not consider either as a platform for TWS. There just aren't enough people with the experience available and rightly or wrongly, management would see this as an unacceptable risk. It might be different in two years time. They also don't have the same corporate backing and support (SUN etc) as Java. Again, rightly or wrongly manangement will see this as a risk and it may well change over time.

    If I was in their position, the first thing I would want to see would be a successfull real time GUI application of the complexity of TWS developed in Python and widely deployed on thousands of machines. I would be particulary interested in support issues. If such exists then lets hear about it.

    For me, the issue boils down to whether TWS and it's API remain reasonably open and cross platform. At this point of time, taking a realistic view, I think it's Java or MS. I'll take Java anyday.

    I'm not offering an opinion on Python as I don't know, but I've read some overblown claims like 5 x productivity gains. The history of computing is littered with claims of this sort that nearly always turn out to be wildly optimistic. And the points in some comparisons I've read, such as syntatically significant indenting replacing braces, weak typing and so on really havn't moved me much. We shall see how things turn out in the next few years.
     
    #39     Nov 2, 2005
  10. You can have FIX over the public internet, but according to IB website, it's not free - $500 setup, and then $100 per month.
     
    #40     Nov 2, 2005