4 ms·

One factor on why Python only saves 20%. Scala has a very rich standard library. Python doesn't. An example is: https://stackoverflow.com/questions/363944/pyth

• saagarjha 7y ago
  > 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…
  • tanin 7y ago
    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.
    • xenator 7y ago
      List of standard methods of this kind https://docs.python.org/3/library/itertools.html https://docs.python.org/3/library/itertools.html
      • tanin 7y ago
        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/254279/why-doesnt-python-have-a-flatten-function-for-lists 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.
• ibejoeb 7y ago
  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.
  • tanin 7y ago
    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.)
    • zmmmmm 7y ago
      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.
    • galaxyLogic 7y ago
      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].
      • tanin 7y ago
        That's a great example. And, yes, Javascript has a similar problem.
• vesche 7y ago
  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.
  • tanin 7y ago
    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.
    • zapzupnz 7y ago
      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.
      • galaxyLogic 7y ago
        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.
        • tanin 7y ago
          > 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.
• dragonwriter 7y ago
  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
  • tanin 7y ago
    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.