Hacker News Reader

Comment by bookmark1231 | Hacker News Reader

I concede about multi line lambdas but far too many languages take a “syntax is bikeshedding and unimportant” approach to language design. New languages are still using “&&” and “||” as if it’s 1975 and syntax highlighting doesn’t exist. Looking at C++, Rust and even Zig code is unnecessarily complicated for someone who isn’t intimately familiar with the syntax meanwhile for the most part anyone can understand Python syntax (well, at least Python syntax that doesn’t abuse decorators and obscure dunder overloads)

View on HN

I personally find && and || easier to read than "and" and "or" because instead of using words to separate words, it's symbols separating words. Sure syntax highlighting helps, but I don't think there's an objective choice here

> New languages are still using “&&” and “||” as if it’s 1975

Because it's consistent and people don't want to relearn minor details each time they switch. And Python has a lot of those little differences. Though the "and" and "or" keywords are among the few things I actually like.

> meanwhile for the most part anyone can understand Python syntax

What matters more to me is how the syntax works in the long term. I have no trouble reading and writing a lot of Rust code, but even after years with Python I still can't remember the difference between "[-1:]", "[1:]", "[:1]" etc for slicing lists/strings. Recursive list comprehensions with their lack of parentheses are unreadable to me to this day (e.g.: `[item for sublist in list_of_lists for item in sublist]`). Python is very easy and quick to pick up, really productive for prototyping, but I don't consider its syntax to be its big advantage.

the lady doth protest a bit too much me thinks

> Recursive list comprehensions with their lack of parentheses are unreadable to me to this day (e.g.: `[item for sublist in list_of_lists for item in sublist]`)

1. there's no recursion here

2. it's literally just a double nested loop flattened (i.e. exactly matching the semantics) to be on the same line instead of indented and on two lines:

  [item for sublist in list_of_lists for item in sublist]

is the same as

  for sublist in list_of_lists:
    for item in sublist:
      item

like why would you need parens when you know the for starts the next nested loop.

> why would you need parens when you know the for starts the next nested loop

Well that's the thing, I don't know the "for" starts the next nested loop because there's no indicator for that, and aside from that it's harder to see it at a glance. Nested loops have a colon, line break and deeper indentation inbetween, here you get nothing.

To me it feels like it breaks Python's own rules: the language omits curly braces for scopes but ensures readability with colon & indentation. But here the chained list comprehension nests two loops without any visible scope boundaries.

Perhaps it's just me and others can read it just fine, but that's my two cents on it.

> Well that's the thing, I don't know the "for" starts the next nested loop because there's no indicator for that

`for` is a keyword in the language - you know that the `for` starts the next loop by the same reason you know `for` starts any loop.

The remainder of your complaint makes zero sense. You expect us to sympathize with an archetype (you) that is familiar enough with the language to know what a `for` loop is (basically week 1) but not familiar enough to spot the keyword. This is an archetype with zero instantiations (ie I'm calling bs on even you personally experiencing this problem).

Readability is about more than knowing keywords, if you can't even agree with that and the syntax consistency issue I don't have much more to say.

> Readability is about more than knowing keywords

the goal posts have been moved; your comment:

> I don't know the "for" starts the next nested loop because there's no indicator for that

my point: there is no other role that the sequence of characters `for` can play in python (because it's a keyword) so you have all indication that you need.

The issues I raised were pretty concrete, and not merely "this symbol is better than that symbol"

Reply on news.ycombinator.com