Hacker News Reader

Comment by d_sem | Hacker News Reader

This resonates. Tips on how to build this skill?

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.

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

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.

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

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

With my solution, you don't need to adapt... that's the whole point. There is no inversion.

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.

> you immediatelly see

But that's simply not true at all.

Let's start with token by token:

  items

You have no clue what type of data ends up in `items`, or that something should end up in `items` at all. This is obvious.

  items =

You have no clue what type of data ends up in `items`. You just know now, that something will end up there.

  items = [

You only know that a list will be in `items`. Not what will be in the list.

  items = [ this

You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`.

  items = [ this for

You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`.

  items = [ this for iterator

You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`. You cannot have, or you break the right to left propagation with nested cases, against what you have with this simple example of yours.

  items = [ this for iterator ]

This is the only time when you know what type is `items` or `this`.

Also `this` is a useless identifier, if you cannot transform or filter in your list comprehension. I don't like mine either that it contains pointless words...

Don't get me wrong, your example is clearly a right to left data flow. Which is not inherently bad, because `items` and `this` are new identifiers, which won't figure out by IDEs, so it doesn't matter.

Also, in my example of Python code (not my version of it, but the valid Python code), there is no need to have `if` at all to break intellisense, or break either left to right or right to left data flow several times inside the list comprehension.

If you named your variables properly and your editor supported type hints, you'd have none of these issues: I used generic names for demonstration.

Compare it to

  family_adults = [ person for person in family_members if person.age >= 18 ]

Code should be as readable as possible by default: I'd argue you do not even need types in code with good naming, though they do prove their worth in codebases being evolved for a long time and many people.

Put yourself in a position where it is your problem/responsibility, where you cannot depend on another to do it for you. You'll be learning every day.

If your hair is on fire, you don't ask how hot.

No who you replied to, but practice. Deliberate practice; not just writing the same apps over and over, but instead challenging yourself with new projects. Build things from scratch, from documentation or standards alone. Force yourself to understand all the little details for one specific problem.

Reply on news.ycombinator.com