[zhemao]

1. Everything in Python and every function returns a value, but that method just happens to be None if you don't explicitly return. You could probably pretty trivially implement a class that wraps an object and returns the object itself if one of its methods returns None.

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.

[jtprince]

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.

[zhemao]

As for #1, I've just implemented it. https://github.com/zhemao/chainsmoker

[jtprince]

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.