It’s interesting, Ruby can be a bit more performant too. I discovered this when I taught some ML stuff to a ruby group, and converted some Q Learning programs and maze navigating stuff from Python to Ruby, and was surprised to see the Ruby version run around 1.3-1.8x faster depending on what the code was doing. It’s not enough difference to really matter, but it just reinforced my “aww shucks” feeling that Ruby could have served that ecosystem very well.
Ruby has a great liquid hiring pool and can be used to write functional software rapidly. That’s the beauty I see, and it comes at a cost like all languages. There’s nothing especially beautiful about the way that it expresses algorithms; most languages have great aesthetic by leaning into the features and idioms designed into the language. How can a language have aesthetic in a general sense if languages have expressive tradeoff?
Regardless, i’m interested in how the syntax actually supports this. You can build monads in any language to support chaining! I’ve found the block syntax often makes this less readable if you can’t use a method identifier—ruby doesn’t have syntax for anonymous arguments that would allow expressions like `arr.map(someFunc(“arg”, @0))`, so the resulting block is more verbose and distracts. There’s also no currying.
Ruby like syntax, compiled on LLVM so fast
- it looks just easier in python to use c bindings
- python is used in universities, just like java is/was
I think crystal is the better of both, and would be great for this kind of stuff
Python is older than ruby, and matz probably had less ties, and probably uses more JP than guido did Dutch.
So Numeric and then SciPy (2001), numarray (2001), and Numpy (2005) just had a big head start on the other free-software numerical computation libraries, basically because a few early Pythonistas were interested in the field, and it kept accruing more and more powerful stuff: FFTW (1998), SparsePy (1999), the ability to read MATLAB files (1999), matplotlib (2001), IPython (2001), and so on. It got popular enough that dozens of people started contributing code to it, making it grow faster and faster.
At the time, most scientists were still using MATLAB; other alternatives for array-based computing included R, Bell Labs's Lush, and if you were a real masochist, PV-WAVE's IDL. Octave, the free-software MATLAB clone, wasn't yet a reasonable replacement. And all of these languages had the disadvantage that they were sort of trapped in their own little library ecosystems: if you wanted to do Gaussian quadrature or calculate a Kullback-Leibler divergence or plot some data, you were golden, but if you wanted to scrape some data out of some web pages with regular expressions, parse command-line flags, read members of a zip file, or run as a CGI process on a web server, you were shit out of luck. Numpy's syntax for a vector of numbers is pretty shitty compared to Octave or APL, but it's worlds better than R or especially IDL, and most people prefer it to Lush's Lisp syntax, although I have a soft spot for Lush myself. And Python and Numpy have reasonable language semantics too, unlike Octave or R.
(I think Lush may have been a bit late to the free-software party, too, so it wasn't really an option.)
So academia started switching over from MATLAB to Numpy, I think around 2010. The transition isn't over yet; the numerical-methods class I audited last year is still using Octave. R is dominant in statistics and will probably stay that way. But Numpy is pretty broadly adopted.
It basically came down to a head start due to a lot of hard work done in the 1990s that just happened to be done in Python. It's maybe not entirely coincidence that the people whose taste ran to reimplementing Gaussian quadrature were fans of Python and not Perl, Ruby, Lua, or Tcl, but they could have been.