There's a quote from a PyCon 2011 talk that goes:

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?

  • 2
    I'd suggest that although they are both dynamic languages, Python and Ruby are quite different. More different than similar. Mar 7, 2012 at 13:40
  • 20
    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.
    – wkl
    Mar 7, 2012 at 13:44
  • 4
    People interested in this question me also be interested in checking out the Computational Science stack exchange site.
    – Mark Booth
    Mar 8, 2012 at 18:59
  • 2
    "readability counts"
    – jsbueno
    Sep 25, 2013 at 4:10
  • 1
    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. Oct 15, 2013 at 21:23

10 Answers 10


I'll expand on my comment.

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

Here's an article written for the Astronomical Data Analysis Software and Systems, written in 2000, suggesting Python as a language for scientific computing.

The article has this quote about Python:

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

  • SAGE - Math package with first public release in early 2005

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.

ipython was first released in the early 2000s, and has had many features added to it that make it very nice for scientific computing, like integrated matplotlib graphing and being able to manage computational clusters.

From above article:

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.

Good list of scientific and numeric packages for Python.

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.

  • 8
    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. Mar 7, 2012 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.
    – wkl
    Mar 7, 2012 at 20:44
  • 3
    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 Nov 15, 2012 at 18:51
  • Preferential Attachment Processes explains an awful lot about what languages are used. It's Zipfian! See The Zipf Myatery "PAP" is explained at 12:50 into it.
    – radarbob
    Jul 20, 2016 at 14:34

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.

  • 4
    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 Dec 7, 2012 at 22:45
  • 4
    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 Vit
    Dec 8, 2012 at 8:28
  • 11
    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. Oct 15, 2013 at 21:29
  • 2
    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.
    – mc0e
    Oct 18, 2013 at 13:45
  • @AndrewVit: Not necessarily. TIMTOWTDI works great if you have one developer, or if you have a small, tightly integrated team of developers. But as soon as you have people who have never met working on the same code, you're going to start asking yourself "Oh, why would they do it that way?" Or, alternatively, you'll write a style guide to force everyone to do it the same way, and then you're not doing TIMTOWTDI any more.
    – Kevin
    Dec 10, 2018 at 5:03

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.

  • 22
    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.
    – sepp2k
    Mar 7, 2012 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.
    – Cyclops
    Mar 7, 2012 at 15:54
  • 7
    @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.
    – sepp2k
    Mar 7, 2012 at 15:57
  • 5
    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? Mar 7, 2012 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. Mar 7, 2012 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. May 9, 2014 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. May 9, 2014 at 16:09

This is a great discussion here, I think posts here really answered why python is more popular in the scientific community. However, there are some the counter arguments for ruby sciences:

  • ruby can be more intuitively coded than python (DSL etc): given the right packages used:

    check bioruby: http://bioruby.org/ a sequence reserve can be simply: s.reverse etc. if you use databases: ruby database binding API is arguably better than python.

  • ruby allows higher level of abstractions at the same time of being terse.

  • better package management system: ruby gems are so easier compared to: setuptools, pip etc

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.


After using python for data analysis for a while (coming from experiences working with ruby, lua, and R), the numpy package (and many related scientific libraries) makes it 'possible' to run fast computation ( speed similar to C, as numpy is written/integrated with C codes) with the ease of programming in python.

Numpy has existed for a while, the availability of it helped many other related scientific packages to be built, such as scipy, pandas ... etc. There great tools make python a great ecosystem for scientific computing, whereas in Ruby, similar faster matrix calculation library is just being developed (NMtrix: https://github.com/SciRuby/nmatrix). This huge timing difference make python the obvious choice for scientific computing.

  • 5
    "in the end, python is like everybody's language", you'll need to provide a source to back this up.
    – Walter
    Dec 7, 2012 at 20:55

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.


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

  • 2
    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.
    – Brian
    Oct 15, 2013 at 21:23
  • @Brian, agreed. Oct 16, 2013 at 2:52
  • @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. Oct 16, 2013 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. Oct 16, 2013 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.


I think one of the main reasons Python became so popular for data science was because of amount of time/effort (i.e., money) we could save in order to extend our scripts for real solution (e.g., software system). With Python, we could more easily build a system solution based on the code we have written for data science.

I have experiences with searching for an interpreter language with this feature about 15 years ago. At the time, Python was chosen to be the one, not because it's the perfect language for data science, but because it was a rare OOP language with fast/portable interpreter that was also extensible to interface with other languages such as C/C++/Java. Unlike nowadays, those were great but rare features for directly building solutions from the base code already implemented for data science.

Time might be another critical factor for making a data-science language. 15 years ago, we found there were already basic packages such as numeric and scipy for numerical computation in Python, but we didn't even know existence of Ruby as a programming language. As of late 2018, I could find several projects using Ruby for data science. Maybe 10 years later, one might ask why Ruby is so popular for AI.

Not the answer you're looking for? Browse other questions tagged or ask your own question.