No I would not reach quite that conclusion I would say "Python saved 20% code lines over Scala!".

The results say something about the greatness of Scala, not of statically typed languages in general. The other ones did not do quite as good as Scala.

From what little Scala I've read it looks very terse indeed. That can be a benefit but at the same time makes it harder to understand code written in it, in my opinion.

I think most people would consider 20% basically within the margin of error induced by stylistic and other non-meaningful differences.

For example, it's not completely clear from the post but it seems like the 0.5x figure is from wc -l, which means Python wins a line every time there is a conditional or loop just because it doesn't need a closing brace. That alone might eat up a lot of the 20%, but you would be hard pressed to say that is a meaningful difference.

My surprise from this study was simply that dynamic languages are clearly not much worse than the best-of-breed statically typed languages. Maybe 20% is within the margin or error, but you definitely can't take that as any evidence that Scala is "better" than Python.

The reason I think this is "big big news" is I thought the general consensus had already been reached in academia if not the programming community that "statically typed functional languages are much better". There's little or no evidence of that in the results of this study.

I don't know where you get that. This is about code base size. Dynamically typed languages have always had fewer LOC than statically typed languages.

If there's a surprise, it's that Scala is able to snuggle up to Python so nicely, while being one of most strongly typed languages.

It is actually nearly a 30% reduction with respect to the Scala line count.

More to the point: while the numbers nominally show differences in languages, everyone with programming experience recognizes that unmeasured and uncontrolled human factors probably had a big part in the outcome.

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