jtprince's comments

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?

And while we're at it, may he forbid the co-existence of emacs, vim, and textmate; java, C++, C#; javascript and dart; KDE, gnome, enlightenment, fluxbox, fvwm, icewm, metacity, compiz, wmii, monad; ubuntu, debian, gentoo, redhat, and arch; bash, csh, and zsh ... nothing good ever comes out of approaching a problem from a new angle.

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.

I'm not arguing that everyone using python for science should come running in hordes to sciruby. What I'm saying is that if you prefer ruby to python that this is helping to make it possible to do a lot of science all in ruby. Also, some of the nuances of ruby could make for some interesting science code.

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.

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.

in addition to jergason's response, sciruby allows/facilitates:

1. better chaining of commands 2. blocks and enumerators 3. integration with rails and other web services 4. a dynamic community

see http://www.floss4science.com/interview-sciruby-team/

It's hard to argue with SciPy's success--it is well engineered, relatively easy to use, highly useful, and well documented. Though SciRuby should be able to do most of what SciPy is capable of, we don't plan on SciRuby being a SciPy rewrite. We all pretty much use matlab, R (and scipy), as well as ruby, so these are all influences.

In addition to the point muuh-gnu makes, we wonder if ruby will be able to add something fresh to scientific computing. In a recent interview[0], I outline some thoughts on this:

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.

[0] http://www.floss4science.com/interview-sciruby-team/

I scanned your project and it looks great. This is one of the major things we are trying to accomplish with SciRuby - simplified access to things like GSL for basic/essential science and stats. Seems like you and Claudio Bustos should get together (Claudio is working on distribution[0] and is very involved in sciruby). We should join forces.

[0] https://github.com/clbustos/distribution