You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Ruby interface for Interactive Brokers TWS available
- Thread starter Raul641
- Start date
panzerman: palinuro nailed it. All of the IB libraries (C, Java, Python, Ruby) are exactly the same set of functionality, just made available in a different language. So in that sense, a trader who is not also a developer will not care which language their software uses; they care about the features that software provides. The developers who write that software, on the other hand, will. The IB-Ruby project is not aimed at traders, it's aimed at programmers. It's a low-level building block of a trading system that allows other programmers to write software meant for traders. It's not intended for the end trader itself.
palinuro: It's great that you're using Ruby. Would you consider working with the public IB-Ruby project on the IB interface portion? All bugs are shallow to many eyes.
xiaohu: I have not tried to use JRuby with the Java library, but it seems like it should probably work.
palinuro: It's great that you're using Ruby. Would you consider working with the public IB-Ruby project on the IB interface portion? All bugs are shallow to many eyes.
xiaohu: I have not tried to use JRuby with the Java library, but it seems like it should probably work.
xiaohu: As I said, I have not tried JRuby or any of the other Ruby-Java bridges with the IB-Java library, so I do not know what the performance implications would be, or even whether it would work at all. Maybe someone who has tried it can tell us how it went.
By writing the API in native Ruby code rather than simply bridging to the Java library, one can (hopefully) achieve an implementation that feels like Ruby code and uses Ruby's idiomatic programming conventions, rather than simply acting as a wrapper around the Java code. While such a wrapper may work, it would still require extra work to coerce it into Rubylike forms - and if you're not going to use Rubylike forms, why use Ruby at all? You may as well program in Java in that case.
Writing a library to implement the TWS socket API in another language is, apart from anything else, also an excellent way to learn the API.
Ideally, I'd use a C language library designed to use Ruby idioms and to be called from Ruby, which would probably be faster than either IB-Ruby or JRuby with the Java library. Such a library does not exist yet, but a native Ruby library will serve as an excellent prototype for such a C library. Once it is written, the critical sections can be profiled and then reimplemented in C optimized for the local platform.
Like I said earlier, the best tool for you to use is the one that lets you get your job done, and that will differ according to the particular person and job involved. IB-Ruby is not a solution for every problem, nor is it necessarily the best solution for any particular problem. It's just another tool that I'm making available to the world in the hope that someone will find it useful.
By writing the API in native Ruby code rather than simply bridging to the Java library, one can (hopefully) achieve an implementation that feels like Ruby code and uses Ruby's idiomatic programming conventions, rather than simply acting as a wrapper around the Java code. While such a wrapper may work, it would still require extra work to coerce it into Rubylike forms - and if you're not going to use Rubylike forms, why use Ruby at all? You may as well program in Java in that case.
Writing a library to implement the TWS socket API in another language is, apart from anything else, also an excellent way to learn the API.
Ideally, I'd use a C language library designed to use Ruby idioms and to be called from Ruby, which would probably be faster than either IB-Ruby or JRuby with the Java library. Such a library does not exist yet, but a native Ruby library will serve as an excellent prototype for such a C library. Once it is written, the critical sections can be profiled and then reimplemented in C optimized for the local platform.
Like I said earlier, the best tool for you to use is the one that lets you get your job done, and that will differ according to the particular person and job involved. IB-Ruby is not a solution for every problem, nor is it necessarily the best solution for any particular problem. It's just another tool that I'm making available to the world in the hope that someone will find it useful.
Quote from Raul641:
The IB-Ruby project is not aimed at traders, it's aimed at programmers.
Exactly. It's fine to try and build up geek points and get some experience in Ruby development with this project, but I would urge most traders to bypass this as just a curiosity for now.
If you really wanted to be helpful to the end user, you would work on extending the existing Java API (if IB would allow it.)
Quote from Raul641:
panzerman: The project was never presented as useful for end users or traders. Reread the original post -- it makes it very clear that this is still under development and not ready for prime time.
It's a great programming exercise for you, but it probably never will be useful for traders, because it doesn't add any additional functionality that isn't already available in the Java interface. In fact as others have pointed out, it may be slower
Quote from panzerman:
In fact as others have pointed out, it may be slower
For certain types of trading systems, real-time speed is not an issue. I have used Ruby before in trading systems. I do not use Ruby for real-time speed. I use Ruby for speed of development. It has saved me hours of coding time.
Some of you are missing the point. It's not about you and how fast you can develop software. It's about the end user and what problems you are solving or new functionality you are providing them. This project doesn't seem to do either.
Therefore, other than a way to gain programming experince in Ruby, I don't see the point. There are untold gigabytes of code that have been written and then abandoned because there was no compeling need for it. Where is the need for a Ruby interface for TWS?
Therefore, other than a way to gain programming experince in Ruby, I don't see the point. There are untold gigabytes of code that have been written and then abandoned because there was no compeling need for it. Where is the need for a Ruby interface for TWS?
Quote from panzerman:
Some of you are missing the point.
It's possible that you are the one missing the point. You seem to admit as much:
I don't see the point.
I can't see the point of needlessly attacking someone who has provided an opportunity for Ruby programmers to develop solutions for TWS that they might not have been able to do hitherto. Why is that a bad thing?