The same arguments could have been used when scipy was starting up: * Why did folks build scipy when there was PDL? Just to avoid a few sigils? * Why build scipy when R had been released just before? * Why didn't they just support matlab/octave? (scipy and matlab are so close in syntax anyway) * If syntactical differences are not enough to justify a new scientific library, why not just stick to Fortran, or C/C++? One can argue that an enormous amount of time has been wasted on writing python wrappers. For what? Just to save a few keystrokes? However, most would agree that the world is a much better place now that scipy and related tools are in it.

Some arguments: * Ruby is expressive and flexible in ways that python is not. For example, Rubyvis is flexible enough (or similar enough to javascript at least) to essentially accept protovis (javascript) code directly. I don't think python can do this. * Ruby uses blocks/enumerators instead of 'for' loops. How much programming involves enumeration of one kind or another? * len(array) vs. array.length

Coding is not just getting the computer to do what you want, it is also how you think about it and the form that it takes. 'len(array)' vs. 'array.length' may not matter to most, but it matters to some of us.

The great news is that we can still use scipy when we need to. I'm betting there is room for both projects, especially considering how small sciruby is at the moment.

Ocaml and clojure are great, but have a steeper learning curve; getting non-programming scientists to contribute is far easier in a language like ruby or python.

A beginning-programmer scientist who wants to start writing code to solve problems currently has to 1) code in python or 2) learn ruby and python/scipy or matlab or R in order to do some scientific computing. SciRuby means (eventually) that for most things, novices only have to learn ruby. It is hard to overstate the importance to new programmers of being able to use just one language (at least to start with).

If you like python over ruby, this is easy. If you like ruby over python, it gets old piping all your data over to a python script to use the basic features of scipy.

SciPy is not currently starting up. There were other open-source alternatives to Matlab in 1995, but certainly none with the scope and community of SciPy in 2011. That full-spectrum alternative is not Octave, not now or then. R is a very nice statistics dsl with prevalence in publications and thus a trove of code (arguments much weaker at that time) - but there is no PyMol or MayaVi in R for good reasons.

For the record, NumPy predates PDL by a smidge, and the existence of PDL is more of an argument against SciRuby, considering the cultural similarity and continued strength of BioPerl. As for C/C++/Fortran wrapping - there's a bit more to it than syntax efficiency, plus wrapping is often semi-automatic and leverages multi-language, science-ambivalent toolkits (ie SWIG or SIP). However, one nice consequence is the fact that via buffer wrapping, the NumPy array has become an efficient common currency for a huge number of legacy libraries.

IMHO, the advantages you have cited pale in comparison with the task of reimplementing 15 years worth of work for what is essentially unity gain in code style (+/- 2% depending on your flavor preference). Regarding that code style, you may be missing the forest for the trees: the inflexibility of Python is a small price to pay for community cohesiveness, and the resulting multiplier effect is non-trivial. Put another way, the time I've spent attempting to read Perl code-golf leaves me very leery of Ruby.

My basic argument though is not that Python is superior or coexistence impossible, it's that every person-year spent reinventing a mature system that is far beyond 'good enough' is a person-year that could be spent advancing the state of the art in scientific computing by building on Theano or improving SAGE - or preferably, doing real science.

Re-implementing is much easier than implementing. Scipy source code is all available, right? Besides, we aren't trying to duplicate the entire scipy stack and ecosystem. We are just trying to make it easier to do common scientific computing in Ruby. Also, trying to do it in new ways.

You seem to be saying that ruby is python, just with perl's inconsistency and unreadableness. The syntax differences between python and ruby (more than 2% IMHO) amount to very large differences in code organization. The ruby community places a high premium on brevity and clarity, and ruby's flexible syntax facilitates this. Part of the reason monolithic code bases are more rare in ruby is because we tend to do more with less code. We are talking about two very different forests.

We weren't going to be working on Theano or SAGE anyway, just doing basic science computation to solve real problems in our fields. That's really the problem, we find ourselves quite productive doing science in ruby at the moment, despite its relative immaturity in this area. It's hard not to imagine what we could do with a few more foundational tools. It really is a small cost to enable us to be able to do science in ruby. Plus, building scientific computing libraries is good fun. Every community should have the chance. As Abe Lincoln suggested, 'Let not him who is houseless pull down the house of another; but let him labor diligently and build one for himself.'

Is it so terrible to want to do science in the language you most enjoy and are most comfortable with? To continue with the maladroit quoting of Abe Lincoln, "it's best to not swap horses when crossing streams."

I made the point further down, but will restate it: if ruby hadn't persisted in existing (the nerve!), would django exist today? I find it hard to believe that this is a zero-sum game, and I wish python and scipy every success. Perhaps the most valuable scipy contribution we could make will come by making sciruby something worth borrowing ideas from?