Its more the matter of using the right tool for the right job. Ruby is faster than what it was in 2007 and u can make it faster. There is no dispute that c++ is the standard, but its really only a necessity when doing HFF. Ruby is not a toy language, u can create a lot more in Ruby than in c++ and in quicker time. Ruby metaprogramming takes it to a whole new level. Also look at how java is starting to creep into HFF, surprising, but has time roles things change. I wouldnt mind also using LISP to code a strategy.
Ruby programming
- Thread starter Nashequilibrium
- Start date
Its more the matter of using the right tool for the right job. Ruby is faster than what it was in 2007 and u can make it faster. There is no dispute that c++ is the standard, but its really only a necessity when doing HFF. Ruby is not a toy language, u can create a lot more in Ruby than in c++ and in quicker time. Ruby metaprogramming takes it to a whole new level. Also look at how java is starting to creep into HFF, surprising, but has time roles things change. I wouldnt mind also using LISP to code a strategy.
http://shootout.alioth.debian.org/fastest-programming-language.php
Ruby 1.9 = 58.5x C++
Just go with Common Lisp if you want that type of expressiveness (SBCL is free, Allegro is the best commercial implementation), at least you'll stay within an order of magnitude. Otherwise write your base in C++ and hook in LuaJIT, you'll still smoke Ruby.
I program in all: C++, Java, Ruby, and firmly believe that each of them has their own niche, although, at this point the only thing that C++ is better at than Java is writing drivers for operating systems and supporting legacy systems that beg to be rewritten in a modern language (some 80-s era dinosaurs or people who don't want to learn new technologies will disagree of course, but evolution will take care of them eventually
Anyway, even if Ruby is 58.5 x slower than C++ - It can cost 100x as much time/money to write certain types of programs in C++ than Ruby, and even after that - support (bug fixing etc..) will be more expensive. In this age of super-cheap hardware it only makes economic sense to use a tool that provides faster time to market opportunity.
That said, Ruby's (as well as other dynamically typed languages) strength is development of quick and dirty apps and web sites, when your program grows beyond a few thousand lines of code - maintenance and new development will become a nightmare. You can't develop robust large scale or real-time software without static typing.
How many times are you rewriting your trading platform? This isn't a web 2.0 development forum, even if latency didn't matter, how many extra racks are you going to lease at the exchange just to run Ruby and be competitive (not that I think you can do it)?
And I highly doubt that you are using C++ in such a manner that requires its efficiency. Unless you are doing high frequency trading, the language choice really doesn't matter. Latency always trumps anyway (I/O is always your bound, not CPU at this point). Just write code in whatever language you can be the most productive in.
Personally, I love prototyping in ruby, but I prefer the type safety of statically typed languages. I have even started the transition to Haskell for the guarantees of pure functional languages.
You don't know me, I do colo, and my OMS is in Java and I will have to spend a significant amount of time rewriting it. Had I used Ruby I would have been screwed a long time ago. I dunno why you are projecting yourself onto me.
And perhaps you do indeed colocate, and for you, speed and efficiency is an issue because your strategies rely on it. In that case, C, C++, or Java (Server) may be the appropriate solutions for you. But I still stand by my belief that for most people, disk and network I/O are bigger bottlenecks then CPU usage. Plus, if I am really concerned about Ruby speed issues, I can use Rubinius (which runs on the LLVM) or JRuby, which runs on the JVM.
Personally, I have strategies that have trades that last for several days. Speed and efficiency are not necessary for these platforms.
Just because Ruby doesn't work for you doesn't mean it can't work for other people.
Programming languages are like tools. Better, they are like spoken languages -- each with its own expressive ability. You choose the tool necessary for the job. For you, it may be C++. For me, in rapid prototyping, it is Ruby or Matlab.
So tell me what does Ruby give you? How many statistical packages or data feed adapters are available? Had you told me R or Matlab right away, I could see it, but using Ruby you have to reinvent the wheel in almost every aspect. At least in python you can leverage scipy/numpy. Then again I don't know how you trade, but I prefer not having to implement entire statistical suites.
Rubinious and JRuby are still orders of magnitude from Java performance. Same can be said for all the new backends for Python.
At one point I was dead set on using a combination of Franz Allegro Common Lisp (3x C++ performance) and Haskell for "productivity" reasons, but I personally spent way more time tinkering with bullshit than getting to where I wanted to be. I just don't buy the productivity argument since we're not constantly pumping out new platforms.
It's easy enough to embed LuaJIT into a C++ infrastructure and get quick prototyping and performance. That's just my 2 cents. If you're happy with Ruby than more power to you. If you're doing swing trades with manual order execution just about anything will do I suppose.
There are plenty of available packages for scientific computing in Ruby. The ones that spring to mind are the gsl bindings (ruby-gsl), statistics2, R bindings (ruby-rmathlib or rsruby), LAPACK bindings, libsvm bindings (RubySVM), etc...
Let me give you an example of how I used Ruby lately: I had about 20 years worth of historical fundamental company information on 300+ companies. It was pretty much quarterly information. First, I needed to parse all the files that the data was in and load it into a database. The ActiveRecord library made this easy -- and migrations made database maintenance even easier. Then, I had to run some analysis on the data -- analysis that would take a long time no matter what language you were using. But using Amazon's EC2 platform and distributed Ruby (DRb), I was able to quickly analyze the data by making the process parallel.
Could I have done this all in C++ or Java? I am sure I could have. But I bet that I would have had to have written a lot more code to get the task done. To me, I was willing to waste the extra CPU cycles for the sake of programmer ease...
Again, this is MY experience. I find Ruby useful. I also find it to be a pleasure to program in. Each tool in its place, as I continue to say. There is more than one way to skin the cat -- and LuaJIT is a very valid option. I just happen to find that Ruby works for me.