Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SciRuby

sciruby.com

Post reply on HN
Print view View original

41–50 of 63 posts

Re: SciRuby

#41

Post by bugsbunnyak »

Why?

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).

If I need a real change, I'll use Ocaml or Clojure, and gain speed from the change.

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.

Are there any other, better reasons to want to build an ecosystem from scratch?

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

Re: SciRuby

#42

Post by muuh-gnu »

hogu wrote: post #25

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

You could have asked this question anybody who tried to write SciPy or NumPy before they existed: "if you're doing science, why would you want to use python over fortran?" Or, befor ROR existed, "if you're doing web development, why would you want to use ruby over java/perl?". Your question is basically asking why anybody would ever try something outside of an established ecosystem.

The reason is, they like ruby so much that they want to use it for number crunching too, and not to have to use a less appealing language. They want to build an ecosystem so other people can join and contribute and grow together and maybe outgrow python. They want ruby to win so much that they are willing to work on duplicating a framework existing somwhere else.

Re: SciRuby

#43

Post by jtprince »

hogu wrote: post #25

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

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/

Re: SciRuby

#44

Post by jtprince »

epistasis wrote: post #8

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. 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 g…

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.

Re: SciRuby

#45

Post by jtprince »

lrfunk wrote: post #18
jcarden wrote: post #2

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

> This is very much needed. Why? (just curious) SciPy is mature, popular, and has already been heavily peer-reviewed. Then there are R an Matlab and ... What does SciRuby bring to the table that makes it stand out from the rest?

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/

Re: SciRuby

#48

Post by mhartl »

mohawkjohn wrote: post #35
gphil wrote: post #26

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?

Could you go into more detail? Since we haven't released yet, we might still switch. But I haven't heard a lot of compelling reasons for doing BSD instead.

The resurrection of SciRuby is great news, but the use of the GPL was one of the first things I noticed, and I strongly recommend using a more permissive license. The MIT license would be a good choice. In addition to avoiding the fears associated with the viral nature of the GPL, using the MIT license would be more in line with the culture of the Ruby community. Most Ruby software I know of (though not, strangely enough, Ruby itself) is MIT-licensed, and people will be more comfortable with SciRuby if it conforms to this expectation.

Re: SciRuby

#49

Post by zhemao »

timwang wrote: post #46

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

It's the same. The Ruby 1.9.x (YARV) interpreter uses a GIL as well, although like Python, there's a way for C extensions to release the GIL.

Re: SciRuby

#50

Post by tel »

pwang wrote: post #30
tel wrote: post #28

Earlier quoted context omitted.

Matplotlib is ok for a first plot during exploratory analysis, but is a far, far cry from the facilities available in R through base graphics, grid graphics, trellis graphics, or ggplot2. Protovis/d3 take a different approach, also focused on a similar Grammar of Graphics like ggplot but primarily concerned about the tooling, instead of the application. Tooling level libraries are nice because they tend to be flexibl…

Your choice of terms is very interesting! I would say that Protovis and d3 do not take a Grammar of Graphics approach per se; rather, they tackle mostly just the lowest level of the grammar, namely aesthetic composition and some transforms. ggplot is very nice for the kinds of datasets that people use R for, but it's only one part of the story. For large dataset and interactive visualization in Python, take a look at…

You're right to point that out. I abused the term. The real thing I think ggplot and protovis/d3 share, and the fundamental thing that makes them powerful and interesting, is the declarative nature of those DSLs. GoG is quite a bit more on top of declarative syntax, but, while I really enjoy Hadley's work, I don't think it's the end all be all in declarative graphing DSLs.
Post reply on HN