SciRuby

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.

I'll be in touch this week. This could be exciting. More than anything, I think this will give statistics a home on the Web and will give a new face to statistics for non-engineers. Maybe we can do for statistics what Rails did for Web development.

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.

From the website:

    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.

The main reason we initially chose GPL, I think, was because while we had strong respect and appreciation for the MIT-license-like Ruby culture, we were more concerned about the science culture.

In other words, what could we do to provide another arm-twisting mechanism to force publishing authors to release their source code? We wanted to facilitate openness among people who might join the Ruby community by way of SciRuby, as opposed to those who might join the SciRuby community by way of Ruby.

Whether or not we can actually enforce release of source code is an open question. Certainly many journals and funding agencies have enormous problems here.

What about a joint license? For example, is the following practical? "If you publish your work in an academic context, SciRuby is GPLv3 for you. If you do not publish your work in an academic context, SciRuby is MIT."