> Scala has a very rich standard library. Python doesn't.

This is not something I could have expected someone to say about Python's standard library…

I know. It's strange to say that. But Scala's library is very very rich.

Another example is that Scala offers a lot of ways to process a list like foldLeft, foldRight, unzip, headOption, lastOption, flatMap, groupBy, and many methods around Map, Set, and etc. Python probably doesn't offer many of these methods.

Of course, this comes with the cost of higher learning curve.

List of standard methods of this kind https://docs.python.org/3/library/itertools.html

Yes, itertools is great. But its stblib is still much lighter than Scala's and Ruby's.

Actually, that seems to be the direction/principle of Python, where it is less inclined to add a helper function.

"It has been discussed ad nauseam on comp.lang.python. People seem to enjoy writing their own versions of flatten more than finding legitimate use cases that don't already have trivial solutions." from https://softwareengineering.stackexchange.com/questions/2542...

Not that this is better or worse. It's just that, on the brevity aspect, Python code is gonna be longer.

I don't see how that example is relevant, because:

(1) It shows Python expresses the concept fairly compactly in the core language without even resorting to stdlib,

(2) It ignores an option (also in the core language) using a ternary and the truthiness of lists: my_list[0] if my_list else None

While what you say is true, my small example shows that the code is longer in Python for solving the same problem, i.e. `my_list[0] if my_list else None` is longer than `my_list.headOption` or `my_list.first`.

And we are talking about the brevity of a language here.

I'm not sure what your example is illustrating. The SO question asks for the idiomatic one-liner to get the first non-null element of a list. The accepted answer does that.

    next(iter(your_list), None)

This is 100% standard library.

Maybe I should have given the comparable example in Ruby, which is `array.first`. Even Scala offers `array.headOption`. Both are more succinct than Python's.

The degree of richness and/or the height of abstraction seem lower in Python. (Not that this is a bad thing. It depends on people's taste, of course.)

Python is indeed very frustrating that way. So many of its limitations and flaws are justified on the basis of clarity and then there are this array of very simple things that can only be expressed in unclear ways which every other language offers a solution for.

A comparable example from JavaScript, there is no library-method for getting the last element of an array, so it gets clumsy: myArray [myArray.length - 1]. A better standard library would provide a method for that: myArray.last(). Or maybe myArray[-1].

That's a great example. And, yes, Javascript has a similar problem.

Sounds like you just don't like Python, but you don't have great reasons for not liking it. The standard library is fantastic in Python. Find better reasons to back up your unfounded dislike.

Saying Ruby/Scala have richer standard lib than Python isn't really a stab at Python.

Like dragonwriter says, it shows that "Python expresses the concept fairly compactly in the core language without even resorting to stdlib".

It depends on your taste whether you like richer stdlib, and I do. But some don't.

We are talking about how short the code can be in this post, and `my_list[0] if my_list else None` (Python) is longer than `my_list.headOption` (Scala) or `my_list.first` (Ruby).

I'd appreciate more if you elaborate why my example isn't a good illustration on the brevity aspect.

I think there are just a lot of people here getting touchy and defensive because other people aren't automatically leaping to false conclusions from this article's data, preferring to imagine that the article validates their personal choice of favourite programming language rather than engage in proper speculation about the quality of the conclusions made within the article.

I would agree that the sample size was small so programmer competency may be a big factor.

The interesting takeaway from this study I think is that it does not show that statically typed (even "pure") functional languages are not obviously better than plain old Python.

The interesting thing is not what this study proves, but what it does not prove.

> The interesting takeaway from this study I think is that it does not show that statically typed (even "pure") functional languages are not obviously better than plain old Python.

Could you elaborate more on this statement? Not a native english speaker here, so I don't quite understand the sentence. Thank you.