Hacker News Reader

Comment by mbell | Hacker News Reader

It's been tried before. mum, Numerical Ruby and SciRuby were all attempts.

The fundamental issue I believe they all had is lack of community. There is a quite large community of folks using Python for scientific computing. Many are not professional developers but rather scientists / engineers who aren't as open to jumping around to different languages as a developer would be.

These issues combined with the fact that Ruby is mostly pigeon-holed as a web only language would make replicating the community that the NumPy/SciPy/matplotlib stack enjoys almost impossible.

It also doesn't help that such capability have to be implemented as C extensions due to performance requirements. This greatly limits the number of developers that would/could work on such a project.

View on HN

SciRuby "were?" We rebooted the project a few months ago. Making some progress. sciruby-dev at googlegroups dot com, and #sciruby on IRC.

These kinds of projects can take years to take hold; you can't expect people to just all switch right away. Blog posts like this just need to be commented on with a link to those libraries. Eventually some big lecture, class or project will use one of those libraries and a whole new group of people will supplement the community. This doesn't just go for Ruby, it applies to any language

Ruby performance in general is getting much better and when C extensions are necessary (as they often are in any high level language) libraries like ruby-ffi have taken a lot of the pain out of that process.

There's more inertia here than you may be thinking. See this recent HN headliner about the difficulty of getting the NumPy/SciPy community to merely move from CPython to PyPy: http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-p...

If that's a challenge, good luck getting a lot of NotProgrammers to move to a completely different language.

Besides, if I may be blunt, who in Rubyland cares if these guys are on Python? By and large, these people are on an island. They are optimizing for things you pretty much don't care about, for programming styles you're not using, for libraries you've barely heard of. Trying to entice them off of Python onto Ruby is a waste of time for everybody. The Ruby community would at best get nothing, at worst net pain of supporting a lot of newbies, and the scientists would incur the horrifying overhead of a language shift for the closest thing to a sidegrade available in the set of the top 20-ish language. If they were going to do that they probably shouldn't be going for Ruby, they should probably be going for Haskell or OCaml, both languages for which I could outline actual advantages to the scientists for the pain of the switch (though probably not enough to justify the switch).

You make good points, they're not blunt. I've just read the same basic blog post many times complaining that there's no SciPy in Ruby. Again, I'm not in the sciences so I'm out of my element talking about it. I'm just trying to make the simple point that there does seem to be people out there wanting science libraries for Ruby

>It also doesn't help that such capability have to be implemented as C extensions due to performance requirements.

If you think the NumPy and SciPy stacks are pure python, you'll probably be surprised to find a lot of C and fortran sitting under the hood.

I know they are not written in Python, that comment wasn't meant to be a knock on Ruby's performance in any way. Its simply the case that writing a highly performant vectorized computation library in a language that doesn't allow direct memory manipulation is a non-starter.

Reply on news.ycombinator.com