At least in our shop (Argonne National Laboratory) we have three
accepted languages for scientific computing. In this order they are
C/C++, Fortran in all its dialects, and Python. You’ll notice the
absolute and total lack of Ruby, Perl, Java.

It was in the more general context of high-performance computing. Granted the quote is only from one shop, but another question about languages for HPC, also lists Python as one to learn (and not Ruby).

Now, I can understand C/C++ and Fortran being used in that problem-space (and Perl/Java not being used). But I'm surprised that there would be a major difference in Python and Ruby use for HPC, given that they are fairly similar. (Note - I'm a fan of Python, but have nothing against Ruby).

Is there some specific reason why the one language took off? Is it about the libraries available? Some specific language features? The community? Or maybe just historical contigency, and it could have gone the other way?

I'd suggest that although they are both dynamic languages, Python and Ruby are quite different. More different than similar.
–
Adam CrosslandMar 7 '12 at 13:40

15

I don't know this is an answer, but - remember that Python had more 'traction' before Ruby took off outside a small community with Rails (circa 2005-2006). Google had been using Python for a while, which raised its profile (early 2000s). Python's syntax is clear and easy to learn and read (and remember this was in the age when Perl was really the only other major option), so I think that really pushed scientific computation toward it. After that, it was probably self-reinforcement, as people created NumPy/SciPy, MatPlotLib, and many other scientific computing packages.
–
birryreeMar 7 '12 at 13:44

To offer some Computational Chemistry perspective, it is trivial to parallelize a calculation with Python, and cheap, too. Perhaps both of these are true in Ruby, as well. I don't know.
–
Jonathan LandrumOct 15 '13 at 21:23

9 Answers
9

I think there are a few factors that influenced the use of Python in scientific computing, though I don't think there are any definitive historical points where you could say, "Yes, that is the reason why Python is used over Ruby/anything else"

Early History

Python and Ruby are of roughly the same age - according to Wikipedia, Python was officially first released in 1991, and Ruby in 1995.

However, Python came to prominence earlier than Ruby did, as Google was already using Python and looking for Python developers at the turn of the millenium. Since it's not like we have a curated history of uses of programming languages and their influences on people who use them, I will theorize that this early adoption of Python by Google was a big motivator for people looking to expand beyond just using Matlab, C++, Fortran, Stata, Mathematica, etc.

Namely, I mean that Google was using Python in a system where they had thousands of machines (think parallelization and scale) and constantly processing many millions of data points (again, scale).

Event Confluence

Scientific computing used to be done on specialty machines like SGIs and Crays (remember them?), and of course FORTRAN was (and still is) widely used due to its relative simplicity and because it could be optimized more easily.

In the last decade or so, commodity hardware (meaning stuff you or I can afford without being millionaires) have taken over in the scientific and massive computing realm. Look at the current top 500 rankings - many of the top ranked 'super computers' in the world are built with normal Intel/AMD hardware.

Python came in at a good time since, again, Google was promoting Python, and Google was using commodity hardware, and they had thousands of machines.

Plus if you dig into some old scientific computing articles, they started to spring up around the 2000-era.

Earlier Support

Python is an interpreted object-oriented programming language that is starting to receive considerable attention in scientific applications (Python, 1999). This is because Python, and scripting languages in general, represent a next logical step for many scientific projects (Dubois 1994). First, Python provides an interpreted programming language that can be viewed as an extension of the simple command languages already used by scientific programs

Second, Python is easily integrated with software written in other languages. As a result, it can serve as both a control language for driving existing programs as well as a glue language for combining different systems together. Finally, Python provides a large collection of third party modules, an established user base, and a variety of documentation in the form of books and online references. For this reason, one might view it as a highly polished and expanded version of what scientists often try to accomplish when writing their own command interpreters.

So you can see that Python had already had traction dating back to the late 90s, due to it being functionally similar to the existing systems at the time, and because it was easy to integrate Python with things like C and the existing programs. Based on the contents of the article, Python was already in scientific use dating back to the 1995-1996 timeframe.

Difference in Popularity Growth

Ruby's popularity exploded alongside the rise of Ruby On Rails, which first came out in 2004. I was in college when I first really heard the buzz about Ruby, and that was around 2005-2006. django for Python was released around the same time frame (July 2005 according to Wiki), but the focus of the Ruby community seemed very heavily centered on promoting its usage in web applications.

Python, on the other hand, already had libraries that fit scientific computing:

NumPy - NumPy officially started in 2005, but the two libraries it was built on were released earlier: Numeric (1995), and Numarray (2001?)

BioPython - biological computing library for python, dates back to 2001, at least

And many more, though I don't know many of their time lines (aside from just browsing their download sites), but Python also has SciPy (built on NumPy, released in 2006), had bindings with R (the statistics language) in the early 2000s, got MatPlotLib, and also got a really powerful shell environment in ipython.

It is also worth noting a number other Python related scientific computing projects. The numeric Python extension adds fast array and matrix manipulation to Python (Dubois 1996), MMTK is Python-based toolkit for molecular modeling (Hinsen 1999), the Biopython project is developing Python-based tools for life-science research (Biopython 1999), and the Visualization Toolkit (VTK) is an advanced visualization package with Python bindings (VTK, 1999). In addition, ongoing projects in the Python community are developing extensions for image processing and plotting. Finally, work presented in (Greenfield, 2000) describes the use of Python in projects at the STScI.

So a lot of it is probably due to the early history, and the relative obscurity of Ruby until the 2000s, whereas Python had gained traction thanks to Google's evangelism.

So if you were evaluating scripting languages in the period from 1995 - 2000, what were you really looking at? There was Perl, which was probably different enough syntactically that people didn't want to use it, and then there was Python, which had a clearer syntax and better readability.

And yes, there is probably a lot of self-reinforcement - Python already has all these great, useful libraries for scientific computing, while Ruby has a minority voice advocating its use in science, and there are some libraries sprouting up, like SciRuby, but Python's tools have matured over the last decade.

Ruby's community at large seems to be much more heavily interested in furthering Ruby as a web language, as that's what really made it well known, whereas Python started off on a different path, and later on became widely used as a web language.

I'd forgotten the bit about c integration. In many cases a scientific calculation is computationally intensive, and being able to write a c routine for just that bit is an important advantage.
–
Spencer RathbunMar 7 '12 at 20:33

1

@SpencerRathbun The article I linked mentions using Python with SWIG to generate wrappers and allow Python to interop with C/C++ code. SWIG didn't get official Ruby support until Ruby 1.6, which was released in 2004. So Python already had a major head start just in mind share and tooling around it fit for allowing people to bolt Python into their existing systems. Not having to ditch all that existing, optimized FORTRAN/C code that was in use was probably the biggest driver.
–
birryreeMar 7 '12 at 20:44

2

In 1991 we were using TCL to hook together numerical libraries as a way of analysing data without having to write masses of C/Fortran. Python came along at just the right time to replace TCL. Ease of interfacing with 'C' (and by F2C with fortran) was the big deal compared to PERL, TCL interface to 'C' was very easy
–
Martin BeckettNov 15 '12 at 18:51

I have used Python extensively for engineering applications and Ruby for web applications.

The problem I see with Ruby as a scientific language is that there are too many syntax options for a given operation.

Python is designed with the following premise "There should be one-- and preferably only one --obvious way to do it". This makes it MUCH easier to read someones code and determine its intent. This is key for peer reviews for engineering, etc.

I like Ruby and it is great for certain tasks, but my Ruby code could be syntactically entirely different than a different programmer's code that does the exact same thing. This causes too much ambiguity in a scientific or engineer environment.

Yes indeed. Ruby is in the TIMTOWTDI tradition, and therefore is just a slightly better Perl. Software is written for programmers. Compilers/interpreters are, in that sense, a secondary audience. Scientists tend to be serious about getting their job done without too much interference from unnecessarily difficult software. QED
–
Dominic CroninDec 7 '12 at 22:45

3

Not sure I follow this argument. If the programmer and not a machine is the primary audience, there are times when wording things differently improves clarity and highlights the intent. Doesn't a more flexible language help understanding by our soft human brains?
–
Andrew VitDec 8 '12 at 8:28

6

But C can look like an explosion at the ASCII Factory, as well. Recall that in C, an array is a skin around pointers. So array[5] can alternatively be written as *(array + 5) which can alternatively be written as *(5 + array) which can alternatively be written as 5[array]. Which is stupid.
–
Jonathan LandrumOct 15 '13 at 21:29

1

I'm a very long term perl programmer, and it remains my favourite language for most purposes. Not sure about mathematics though. I'd disagree with this attitude to the TIMTOWTDI approach. Having many approaches available doesn't mean they are all good of course, but it's important to be able to tailor your expression so that it maps clearly and directly to the idea you are expressing, both to your human and machine audience. Lack of syntactic options doesn't help that.
–
mc0eOct 18 '13 at 13:45

At a guess, a large part of it would be the reliance on matlab by lots of researchers. Python has alternatives, such as sage. Whereas ruby does not, or at least there is no obvious ones.

Secondly, according to the Ruby FAQ, python is both procedural and object oriented, whereas ruby masquerades as a procedural language. If you are writing a small script for math purposes, like what you'd do in matlab, the OO paradigm is a headache. Not only that, but it forces a conceptual jump away from the functional/procedural paradigms that researchers use. Math is not OO. Math is functional, followed by procedural (think logic proofs).

Finally, note that the Ruby FAQ states that ruby is more complex than python. Programming comes second to researchers, not first like us.

I think the OO thing is a bit of a red herring. What does a researcher care whether the expression 1 + 1 sends the message + to the object 1? That does not change the structure of your program in the slightest.
–
sepp2kMar 7 '12 at 14:08

1

@sepp2k, I think Spencer is suggesting that Ruby would require scientists to program differently. I don't know Ruby, but supposing you had to create objects to write a program in Ruby, whereas Python allows procedures - this would add to the mental overhead. Granted not a lot, but to a non-programmer, every bit of extra work would be a reason to use another language.
–
CyclopsMar 7 '12 at 15:54

5

@Cyclops I get what he's suggesting. I'm saying it's wrong. The whole point of the quote about ruby masquerading as a procedural language is that you don't need to structure your program in an object oriented way. If you type in something like "2 + 2", you're creating two Integer objects and calling a method on one (passing the other as an argument). However that doesn't make typing "2 + 2" in ruby take any more effort than typing "2 + 2" in other languages.
–
sepp2kMar 7 '12 at 15:57

3

I'm with sepp2k, I don't buy that argument either. Some languages, like Java, do force the OO paradigm on you - not so with Ruby. What's stopping you from writing a purely procedural or functional program in Ruby?
–
Mike BaranczakMar 7 '12 at 15:59

2

@Cyclops exactly. While Ruby can pretend to be procedural, in a non-trivial context you will run into situations where the OO paradigm makes the language work in a certain way. If you don't understand or ignore that, then either you are unable to do what you want or you end up with a messy hack.
–
Spencer RathbunMar 7 '12 at 16:02

When the BDFL (Guido van Rossum) first wrote Python the goal was that it be as understandable as plain English (DARPA funding proposal) which would eliminate common coding errors.

One issue that is highly visible is the use of indent to delimit blocks. In languages that have explicit complex statement delimiters (e.g. C braces, Pascal BEGIN/END) whitespace would be collapsed to a single space character before feeding the code to the lexer. This would allow great variation in how code is laid out.

For professional programmers this is not an issue because they have trained themselves to deal with it from 30 or more hours a week of practice.

For other professionals where programming is a tool this issue becomes a major problem. This group includes mathematicians, physicists, chemists, engineers, etc.

Since Python reduces errors for non-professional programmers it allows them to think about the problem they are trying to solve and don't have to deal with the mechanics of the language as much.

This is a single example of why it is popular outside the programming profession. There are other examples that can be used to illustrate the same point such as batteries included, The Zen of Python (import this), the use of Monty Python humor, and so forth.

I can't find any reference to a dissertation or doctoral program on Guido's resume or publications list. Do you have a citation for that? This interview just says he was a researcher at CWI.
–
M. DudleyMay 9 '14 at 15:49

I totally messed up on that: I had read that he did is dissertation on it, but did not do the proper research on it. I found my error after I had written this post, but then never made the correction here. Thanks.
–
Lance HelstenMay 9 '14 at 16:09

However, ruby's adoption was/is/will be hindered by its complexity. I am thinking Lisp is a great/powerful language, but why it didn't take off as a general language? the similar situation is here with ruby - it inherits a lot power from lisp, small talk, and perl!: but only a selection of people will actually use it to get the benefits. In the end, it may remain strong in certain niche/special areas (such as the rail in web, puppet in configuration), it is hard for 'non'programmers to fully enjoy it, but it might be programmer's good friend (saw somecomputer scientists enjoy the language: http://www.cleveralgorithms.com/nature-inspired/index.html )

Some most recent update:it seems python is already taking over the landscape. Recently books such as: http://www.amazon.com/Python-Data-Analysis-Wes-McKinney/dp/1449319793
and many other books (data analysis, machine learning etc), are all written with python as the language used. If ruby wants to catch up, it needs some serious efforts. Considering matplotlib in python, it's probably several man years to get it to the state where it is now. Unless some serious efforts put in ruby, it probably can not catch up with the stage of python data analysis/scientific computation in the next 2-3 years.

I've been wondering this same thing. I think it's, as Spencer Rathbun said, because of the procedural aspect of Python. Being a "non-programmer" myself, I find it beautiful the way you can code in Ruby and the Rails framework is excellent for ease of use. However, when coding for scientific purposes (math, biology, etc), you normally think in a "mathematical" language, that is, you don't care about statements like

Person.find_by_name 'Juanito'

but you care more about

A = B*C + D

So I think Ruby is powerful that many of it's features would be unused in a scientific program. It's easier just to think in procedures.

Another thought here is that:
nowadays, probably your language of choice isn't that important,
unless you are developing some really big packages.

For everyday user, maybe we shall just pick the tools we are familiar with and get the research questions answered. To me, python has a strong scientific computation crowd already, using it will make it easier to work with other people. However, personally:

Ruby is more productive as a tool language

R is more productive as a statistical analysis language

LuaJit is the one where performance is important (here we can go to C, C++, Go etc)

Python has better support for N-dimensional arrays with the Numpy package. I haven't seen anything similar for Ruby.

Python seems to be faster in the numerical computing / scientific computing that I have done. I have no proof other than when I have written similar algorithms in Python and Ruby, the Python algorithms ran faster (YMMV).

This doesn't really contribute much to the discussion. The effectiveness of Numpy is already covered (in greater detail) in the accepted answer. Your performance argument remains unconvincing; I don't like relying on anecdotes when discussing historical performance, especially when any such arguments are probably already well-covered with trustworthy (well, more trustworthy than a context-free anecdote) benchmarks.
–
BrianOct 15 '13 at 21:23

@Brian, my specific contribution was the comment on N-dimensional arrays. This is the core of what Numpy is built around, yes, but I didn't see any mention of N-D arrays. This is the core of linear algebra and what Matlab and Numpy does well. Ruby uses arrays like programmers use arrays, not like engineers and scientists use arrays (i.e. matrix). If you think it would help, I'll add a comment about N-D arrays to the accepted answer.
–
Josh PetittOct 16 '13 at 2:55

@Brian, and I still stand by my comment that I haven't seen good N-D array support for Ruby for scientific computing.
–
Josh PetittOct 16 '13 at 2:57

One reason is that Python has good support for using/integrating/calling C/C++ code, whereas to my knowledge Ruby does not offer the same degree of (ease of) integration. This means that you can write the high-performant code components in C/C++, and then use Python (i.e a high-level / easier-on-the-eyes language) to glue the whole thing together. I imagine that this is also one of the reasons for its early institutional adoption by Google.