The reason is, they like ruby so much that they want to use it for number crunching too, and not to have to use a less appealing language. They want to build an ecosystem so other people can join and contribute and grow together and maybe outgrow python. They want ruby to win so much that they are willing to work on duplicating a framework existing somwhere else.
That's why I'm trying to use Ruby where possible, even at the cost of a small productivity hit. The benefits of others being able to read my code far outweigh the few extra minutes it takes for me to do something (and in many cases, the sheer brevity of Ruby as a language means it's faster, simply because it's less typing).
I'd love to see SciRuby become a more useful project, and I'd love to contribute. Unfortunately, they don't make it especially easy to get involved -- the mailing list points people to the roadmap, but it's not at the level of detail where someone could jump in (and the component gems don't seem much better), so it's a bit hard to know where help would actually be useful.
1. Because of its consistent object oriented design and because everything returns a value, chaining is natural in Ruby.
2. Avoid index errors and for loops with powerful block Enumerators.
3. Scientific data and services are moving to the web, and Ruby is a great web language (although it is incorrect to call it 'just' a web language).
4. The Ruby community is highly innovative and dynamic, so we can collectively generate solutions quickly.
(see the interview for more explanation) Some of these points are more vision than reality at this point, but we think ruby has great potential as a science language. The other reason this makes sense is that folks are already doing science in ruby (and have been for some time) and many tools already exist--we are building on a good foundation and just hoping to extend it to make things better/simpler.
2. Python has list comprehension, iterators, and generators, which also allow you to loop without for loops or explicit indexing
3. Python also has lots of web frameworks/libraries.
4. Are you saying the Python community is not (as) innovative?
I'm not saying this project is completely without merit. I know that many people prefer Ruby's syntax and preferences to those of Python. But I think it is disingenuous (and somewhat insulting to Python developers) to claim that this project has any potential benefit beyond allowing Rubyists to do scientific computation in their preferred language.
However, due to the special nature of python's builtin datatypes (str, list, int, float, tuple, dict, etc.), you will not be able to use chained_class on those classes.
This helps to make my point about ruby's object model. Of course, ruby takes a speed hit for it, but it is more consistent in this regard.1. (reply) I know it is possible, however, in practice it is easier and done more often in ruby. The idea permeates ruby thinking much more than in python. Even 'if' statements return a value, and rubyists often use that.
2. (reply) yeah, list comprehensions are cool, wish ruby had 'em. The original point was more directed to R and matlab code. Still, the way in which enumeration is done in ruby looks and feels quite different than python, even if the same effect is achieved. [1,2,3].each_cons(2).map {|x| x + 3}
3. (reply) True, but if ruby hadn't persisted alongside python, would django exist? sciruby may do things differently than scipy, and that just might make python/scipy better down the road.
4. (reply) To be clear, I have the utmost respect for the python community. How about saying that they innovate in different ways? Python's emphasis on having one preferable way of doing things tends to yield well engineered systems, and innovation occurs easily in layers as a result. Because of ruby's flexibility, Rubyists are more prone to rebuild core functionality in different ways. Depending on how much you care about syntax, that's either a colossal waste of time or quite useful.
Finally, if you don't care about the syntax of scientific computation, then yes, this only allows rubyists to do computation in ruby. But, despite their many similarities, ruby and python are fundamentally different in several ways. To suggest that we might be able to do scientific computing in somewhat new and interesting ways is not meant to be insulting to python developers, and we make the claim with the deepest sincerity, and humility. Like python, ruby possesses unique strengths, and we hope to bring these to bear on scientific computing as best we are able.