Come on, we all know a language and its library ecosystem go hand in hand. Trying to separate them from the standpoint of adoption is pointless. TFA comes to its conclusion by looking at libraries. In your hypothetical where Perl or Ruby take Python's place, that would manifest as Perl or Ruby having better data science libraries. The causality would probably be just as cyclical as it is for any "best language/library for task X" question.

This. Most schools are moving away from C or Java being their primary language. Most comp sci professors acknowledge the usefulness of a scripting language and so when they need to pick one, they pick one they have the most familiarity with. Due to numpy and scipy this tends to be Python over Ruby.

Also many things about python that I don't like such as `len` being a function rather than a method on a list are very trivial when coming from a language like C which has hordes of tiny inconsistencies.

The whitespace thing in python is pretty gimmicky but does also hold a certain amount of pedantic appeal.

The Python design FAQ explains why Len is a built-in function instead of a method. Guido wanted a guarantee that whenever he called it, it'd return a whole number. As just another method, you might find a new type that defines a length in fractional terms, which would break any code wanting to use that as a list index, etc.

But that would be on your for misusing the length method. All the built-in and popular libraries would still define length properly.

Perhaps, but "your" mistake might impede the popularity of the language. A wide range of well-designed community libraries are a major reason to choose Python.

Take a look at the design rationale for the new __matmul__ magic method. It's not for the standard library, it's for the community.

The need to do that reveals a couple of weaknesses (or more charitably, tradeoffs) of Python: lack of type constraints, and (related) lack of well-defined, invariant interfaces on objects.

Trade-offs indeed. Magic methods indicate the use of interfaces defined by traits rather than formal types. Duck Typing. It's flexible.

But you can also see that Guido has been into types lately. He's been pushing the development of mypy and the new optional type system.

Ruby is just used rarely outside RoR, realistically speaking.

Actually, you should qualify that a bit more. Ruby is rarely used outside of Ruby on Rails in North America. In Japan, it is widely used and Ruby on Rails is fair less common.

What were Ruby used for in japan?

Ruby is a very versatile language in its own right. While the other poster is correct that it is used for anything that perl and python are used for it's also taking a large chunk from the Java and C# crowd in Japan. Everything from server side applications to command line tools and even GUI based desktop applications can be written in Ruby. Using FFI I have made some quite amazing applications with Ruby.

Rails is amazing and I personally love it. But it's not the only thing Ruby is good for.

Probably anything that Perl and Python are used for.

Well, true, you have a point. Ruby is rarely used outside of Rails. Which is a shame, really.

Go to Japan.

Whitespace is no issue with a good editor (Sublime, vim, emacs...).

I dislike the many inconsistencies in Python. You mentioned one. Others: sort vs sorted (destructive vs non destructive). Also: not being able to chain methods because many don't return a value. (Scheme, Elixir or even Ruby are imho much more elegant.)

But all in all Python is a very useful programming language with a rich eco system.

The Python design FAQ explains that .append and .sort return None to remind you they are mutation methods. I find this more elegant than Ruby, etc., where many things look like pure functions but aren't.

https://docs.python.org/2/faq/design.html#why-doesn-t-list-s...

I know the reasons why and how mutating methods work in Python.

Nevertheless I find this here much more elegant:

data.sort.tail.first # or this data.append(7).append(3)

More elegant than this:

sorted(data)[1:][0]

data.append(7) # and then

data.append(3)

I love method chaining in Elixir or Javascript. In Python I have to create temp variables here and there to capture / further process intermediate results.

Having said that: Python has it's strengths. I use it more than any other programming language.

I understand the preference and the difficulty created by methods and operators that are essentially statements instead of expressions. However, when making that criticism we should also acknowledge the benefit of requiring or encouraging multiple lines for those actions.

    if (x=42) {}

Has burned many people. Append having a useful return is comparable, though probably not as much of a trap.

> sorted(data)[1:][0]

I don't want to get into the weeds, but shouldn't that just be

    sorted(data)[1]

Or if you like unpacking for clarity

    first, second = sorted(data)[:2]

?

> Had Perl or Ruby been the premier language to use for DS/ML, they would be growing instead of Python.

Well Perl was the premiere data science language for a while. Python made inroads and eventually took over. I think you're mostly right through, it's just a matter of other factors affecting the communities at the time causing Perl to not grow nearly as quick as Python, and Python getting a good numeric library. Had Perl not lost a lot of community in the early 2000's, it might have retained this area.

Perl just lost the plot. I think BioPerl was ahead of the game before the Python scientific libraries stole the show so they only have themselves to blame. Perl's successor Ruby seems to be headed in the same direction by failing to diversify which is a shame because Ruby is much better language than Python.

You still have to explain why python is the premier language for that.

Libraries. And to build them you need certain language features. 2 big ones: complex numbers and operator overloading. The lack of these meant that everyone doing simulation and data analysis skipped Java altogether.

The reason C is so popular is because it's the scripting language of Unix. C++ is the scripting language of Windows. Objective-C, Macs and iOS.

Well, Python is the scripting language of a ton of useful libraries which are relevant to a lot of very interesting fields.

R sits in a similar spot, but Python is a better, friendlier language, which means actual programmers are more apt to recommend it as an offhand solution to a simple problem someone who isn't seen as a programmer is having: "Oh, that's easy. Just copy and paste this Python code, and maybe hack at it until it does something." You can get scientists programming with recommendations like that.

"It's psuedo-code that works"

This. I took the habit of writing very Python-like pseudocode while taking lecture notes, and having it run almost verbatim at home was a blast.

Honestly if other languages had the ability to use words like and, or, not, foreach <thing> in <thing> it would make learning to code that much more accessible. Even a language like C could do this. I understand that obviously you're not going to change something like a bit-wise (>>/<<) operator into something that flat says what it does (drop bit right/left), and I appreciate a good use of a ternary operator, you'd think it would be fairly trivial to de-codify some of the more basic operations.

Python has super-easy bindings to C too, that's another reason it's popular in scientific computing

And because it has bindings to C, it has bindings to a lot of other languages traditionally compiled to machine language, such as Fortran and C++, making SciPy possible, because that optionally depends on LAPACK, which is written in Fortran.

https://www.scipy.org/scipylib/building/linux.html

Of course, the people who just install and run SciPy don't need to know that, but the fact Python has a nice C FFI means it can run literally decades' worth of software across a fair number of languages.

I'd be using lua if it had python's library breadth. Or maybe julia. Not python.