3 ms·

Fail, and try to understand why. Don't be quick with the answer. Sometimes it takes years. But it's crucial to want to improve, and recognize when the answer is

by ruszki 5mo ago

Fail, and try to understand why. Don't be quick with the answer. Sometimes it takes years. But it's crucial to want to improve, and recognize when the answer is in front of you. Read why programming languages have the structures what they have. Challenge them. They are full with mistakes. One infamous example is the "final" keyword in Java. Or for example, Python's list comprehension. There are better solutions to these. Be annoyed by them, and search for solutions. Read also about why these mistakes were made. Figure out your own version which doesn't have any of the known mistakes and problems. The same with "principles" or rule of thumbs. Read about the reasons, and break them when the reasons cannot be applied. And use a ton of programming languages and frameworks. And not just Hello World levels, but really dig deep them for months. Reach their limits, and ask the question, why those limits are there. As you encounter more and more, you will be able to reach those limits quicker and quicker. One very good language for this, I think, is TypeScript. Compared to most other languages its type inference is magic. Ask why. The good thing of it is that its documentation contains why other languages cannot do the same. Its inference routinely breaks with edge cases, and they are well documented. Also Effective C++ and Effective Modern C++ were my eye openers more than a decade ago for me. I can recommend them for these purposes. They definitely helped me to loose my "junior" flavor. They explain quite well the reasons as far as I remember.

necovek 5mo ago
I am curious about that nit on list comprehensions in Python: what do you mean, why are they a "mistake" of language design?
- ruszki 5mo ago
  So when they designed it, it wasn’t that bad for simple cases. However, with more complex nested lists, there isn’t a clear data flow, it jumps from one place to another. Especially the first term is problematic. It’s not beneficial at all for the modern IDE based development. So at the end, this is a better list comprehension in this sense: `[state_dict.values() for mat to mat2 for row for p to p/2]` Or similar, where data flow is 1->2->f(2)->3->4->f(4). Where right now it is this lovely mess with one more repeating term: `[p / 2 for mat in state_dict.values() for row in (mat 2) for p in row]` Where the flow is f(4)->2->1->3->f(2)->4->3 This is not just a Python list comprehension problem obviously. The simple for… in… has a similar problem. It’s only better, because the first term `p/2` is at the end.
  - zahlman 5mo ago
    I'm struggling to even understand what you have in mind, because HN doesn't do Markdown formatting and asterisks are interpreted for emphasis across lines. But I've never really thought there was a problem with the syntax. To me it reads naturally, left to right: "A list ([) of the results from calculating whatever, (for) each of the (name) values that are (in) the (names) container". With multiple clauses, they're in the same order as the corresponding imperative code, which also makes sense. (Perhaps if "for" were spelled "where", it might not...)
    - ruszki 5mo ago
      You can create a natural sentence for every permutation. There is an asterisk between mat and 2. mat asterisk 2. f(2) is a multiplication of mat.
  - necovek 5mo ago
    You seem to be complaining more about for working on iterators/generators like range() and not on comprehensions themselves. List comprehensions are inverted (syntax-wise) compared to regular program flow, but that is pretty easy to learn and adapt to (and is, imo, much better than "a = b if x else c").
    - ruszki 5mo ago
      With my solution, you don't need to adapt... that's the whole point. There is no inversion.
      - necovek 5mo ago
        It is focused on communication flow for small data-only loops: it is much easier to reason about items = [ this for iterator ] because you immediatelly see what type of data ends up in `items`. Syntax inversion overhead is very much paid for with this benefit IMO. Again the bigger problem is the 'if', including in comprehensions.
        5mo ago

by ruszki 5mo ago

necovek 5mo ago

I am curious about that nit on list comprehensions in Python: what do you mean, why are they a "mistake" of language design?

ruszki 5mo ago
So when they designed it, it wasn’t that bad for simple cases. However, with more complex nested lists, there isn’t a clear data flow, it jumps from one place to another. Especially the first term is problematic. It’s not beneficial at all for the modern IDE based development. So at the end, this is a better list comprehension in this sense: `[state_dict.values() for mat to mat2 for row for p to p/2]` Or similar, where data flow is 1->2->f(2)->3->4->f(4). Where right now it is this lovely mess with one more repeating term: `[p / 2 for mat in state_dict.values() for row in (mat 2) for p in row]` Where the flow is f(4)->2->1->3->f(2)->4->3 This is not just a Python list comprehension problem obviously. The simple for… in… has a similar problem. It’s only better, because the first term `p/2` is at the end.
- zahlman 5mo ago
  I'm struggling to even understand what you have in mind, because HN doesn't do Markdown formatting and asterisks are interpreted for emphasis across lines. But I've never really thought there was a problem with the syntax. To me it reads naturally, left to right: "A list ([) of the results from calculating whatever, (for) each of the (name) values that are (in) the (names) container". With multiple clauses, they're in the same order as the corresponding imperative code, which also makes sense. (Perhaps if "for" were spelled "where", it might not...)
  - ruszki 5mo ago
    You can create a natural sentence for every permutation. There is an asterisk between mat and 2. mat asterisk 2. f(2) is a multiplication of mat.
- necovek 5mo ago
  You seem to be complaining more about for working on iterators/generators like range() and not on comprehensions themselves. List comprehensions are inverted (syntax-wise) compared to regular program flow, but that is pretty easy to learn and adapt to (and is, imo, much better than "a = b if x else c").
  - ruszki 5mo ago
    With my solution, you don't need to adapt... that's the whole point. There is no inversion.
    - necovek 5mo ago
      It is focused on communication flow for small data-only loops: it is much easier to reason about items = [ this for iterator ] because you immediatelly see what type of data ends up in `items`. Syntax inversion overhead is very much paid for with this benefit IMO. Again the bigger problem is the 'if', including in comprehensions.
      - 5mo ago