SciRuby

I'm glad to see this project is coming back.<p>I'm in the middle of writing a Stats library for Ruby[0]. Maybe we can join forces?<p>[0] <a href="https://github.com/davejacobs/stats" rel="nofollow">https://github.com/davejacobs/stats</a>

I noticed this is licensed as GPLv3 as opposed to a BSD license for SciPy. Isn't this going to be a huge barrier to adoption, or am I missing something?

Why?<p>The two technical justifications (objects all the way, and enumeration) in the FLOSS interview [0] are both arguable and not nearly convincing enough to justify further fragmentation of the open-source science ecosystem. If I want cleaner semantics, s/python/ruby is at best moving sideways - for the sake of a few keystrokes? Ruby is slower both in the interpreter itself and in the lack of f2py,Cython,Numexpr,PyCUDA,weave (even Theano sometimes).<p>If I need a real change, I'll use Ocaml or Clojure, and gain speed from the change.<p>It seems like a waste to discard (or attempt to replicate) the 10s-100s of person years represented by SciPy and the ecosystem including f2py, Cython, MayaVi, IPython (not just a REPL), Pandas, Chaco, PyCUDA/OpenCL, and SAGE - to name a few.<p>Are there any other, better reasons to want to build an ecosystem from scratch?<p>[0] <a href="http://www.floss4science.com/interview-sciruby-team/" rel="nofollow">http://www.floss4science.com/interview-sciruby-team/</a>

I hope they don't set up SciPy as the project to emulate and improve upon. Deep knowledge of R, Fortran, and Matlab would better inform this project of what scientists need.<p>SciPy is great, but it's clearly best for programmers that have a slight scientific bent and can't stomach learning the existing scientific tools (which are admittedly a bit difficult to combine with modern software engineering). There are some great ideas in SciPy, but a broader set of influences is essential to making a great scientific toolkit.

This is a sincere question, if you're doing science, why would you want to use ruby over python?

Wow. This is very much needed. That being said, to what end are they going for ?

I'm really glad they're implementing Protovis instead of trying to copy Matlab's plotting facilities like Matplotlib. Matlab plotting is pretty terrible.

Great idea and something that will definitely be highly used (I'm downloading it now!), but I really would be cautious attempting to provide what R provides, 'but better'.<p>R's power comes from the fact that hundreds of scientists have written packages for it when they have a new method - you won't be able to get that overnight. Also, R has strong links with other languages like C.<p>Finally, while I agree that sometimes R's syntax can be slightly obfusicated, I don't really think the examples on their site are fair... You can 'plot(y~x)' guys :p

Interesting stuff, but given the sheer brainmass that SciPy has attracted its going to be hard to draw users away from that crowd. I think the only appeal of this project, at least for the time being, is labs that are already entrenched in Ruby.

hopefully they make the DSL similar to matlab. Having worked in matlab &#38; numpy, I can definitely say that having numpy's syntax semi-close to matlab helped a lot when we do ports. It (porting) happens more often than you'd think.

Looks good. I'm a big fan of narray to get decent performance for array operations, interesting to see how the rewrite of that will perform. Narray is pretty damn close to realtime compared to native ruby implementations.

This is absolutely needed. Glad that the project is come back to life. Big up to the developers.

God forbid you use existing mature tools appropriate to your task.

This is terrific. This is newsworthy. Hope it gets legs.

python's concurrent programming is not that good. how is the situation in ruby?