Comment by xelamonster | Hacker News Reader

Comment by xelamonster | Hacker News Reader

Parent Full thread

A lot of your points are valid but I disagree that Python is only popular due to network effects. I think it hit a sweet spot between expressiveness and accessibility that makes it attractive, and your point that popular libraries are often written in other languages to me just highlights another advantage: painless integration. You can get the speed of Rust or C code where it counts without the overhead of needing to write everything in those less approachable languages.

I love how naturally it reads too--all the little details like allowing "is" and "not" in place of symbols add up to make it uniquely easy for my brain to parse. List comprehension in simple cases I find much more readable than equivalent implementations in other languages. Of course it's far from perfect, for example when those comprehensions start to get more complex they quickly become, well, incomprehensible.

The ecosystem is pretty nice too, beyond just being large I find most of the packages I end up with are reliable and configurable enough to support many use cases. In comparison Javascript (an arguably more popular language) is a nightmare of awful syntax and unintuitive restrictions, with a hellscape of an ecosystem where even the most well-regarded frameworks feel half-baked at best.

I agree with all your points, except list comprehensions. I used to like them, but now refer the callback style from Javascript much better.

Cannot auto complete at start:

My auto complete doesn't work at the start of a list expression. In [for obj.abcdef...], what is obj? It cannot know. In a callback, using typescript , it knows: list.forEach((obj) => obj.acdef...): obj is an element of list, which, if typed, we can infer its value.

It's minor but it's not optimal.

confusing multi line comprehensions

I don't know how to format this in HN, but this is pretty weird in multi lines: [obj.y \n for obj in my_list \n if obj.x >3 ]. Something like this reads much better: my List.\nforEach((obj).\nfilter((obj) =>obj.x >3).\nmap((obj) => obj.y))

I'm comparing with Javascript which I don't enjoy much either. But I liked using this style in C#, with the LINQ nodule.

in a strange coincidence, SQL suffers from exactly the same issue due to select being before the from statement. I nevertheless still prefer list comprehensions over doing trivial things with map/reduce simply because it reads like math.

> this is pretty weird in multi lines: [obj.y for obj in my_list if obj.x >3 ]

Yeah, it's a shame that Python doesn't allow us to write this as `[for obj in my_list: if obj.x > 3: obj.y]`

> I don't know how to format this in HN

4 spaces at the beginning of the line make a code block.

    result = [obj.y
      for obj in my_list
      if obj.x > 3]

    result = myList
      .filter((obj) => obj.x > 3)
      .map((obj) => obj.y))

    IEnumerable<float> result =
      from obj in myList
      where obj.x > 3
      select obj.x;

Yeah that makes sense, and I find the map chaining for complex cases much clearer too. I always have to look up how to do a nested list comprehension and I always end up mad about how dumb the syntax for it is when I figure it out. I do very much prefer Rust's use of || instead of the parentheses for arguments though just to differentiate things. And the inconsistency in structure between function declarations and types and function literals in whether you need a colon or a fat arrow or nothing drive me insane in Javascript. I don't hate Python's solution here either, why bother with weird syntax just literally label it lambda.

> You can get the speed of Rust or C code where it counts without the overhead of needing to write everything in those less approachable languages

Only if your problem fits this shape. The language boundary is narrow and if you have an algorithm that crosses the boundary often, it won’t be fast.

Reply on news.ycombinator.com