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.
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").
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.
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.
It's not new information that people can learn/practice in their sleep. This is already known and well documented. The interesting question is: what conditions increase the chance practicing in ones sleep? What are the mechanisms?
I suspect the commenter above is reflecting on 2026 USA and not 1850 USA. The past tense nature of your comment if part of the concern highlights a common recognition that there is limited evidence the country is currently capable of building.
The geographic and demographic orders of magnitude when comparing these two places makes it difficult to extrapolate applicability of best practices. Who's to say the Swiss model scales? Article doesn't convincingly address this.
For context:
41 US States are geographically larger than Switzerland. It's most comparable state in area is West Virginia. West Virginia is .064% of the national area.
Some fun distance contexts. Driving end to end in Switzerland is comparable in distance to:
Driving from Pittsburgh to Philadelphia, Detroit to Chicago, or New York City to Washington DC.
Extrapolating with this method, large cities should be as well equipped as Switzerland.
Los Angeles has 10x the population density of Switzerland and around the same population density in urban area. Same for Washington dc, San Francisco...
It doesn't have to be an all-or-nothing. Distance between cities may be large, but the order of magnitude is closer when comparing within cities.
Yeah but like 10x the population, 10x the GDP, etc.
You're saying they laid down rail in the US from end to end during wild West times but modern infrastructure can't be built to the same scale even with mechanisation?
Lmao sounds like the UK. It does make sense tho, the world is now filled with middlemen and getting any job done costs 10x because of parasites.
And also a time when people were laying down ties with their hands and a hammer.
This isn’t a labor issue it’s purely political. Some people get rich from the status quo and bribe politicians to prevent competition. America is increasingly corrupt, particularly since citizens united and accelerating under the current admin
This is the same American-branded copium we see during discussions of socialized healthcare, which every other first-world country on the planet seems to manage. China has 10G and 50G home fiber. Zurich is larger geographically than Manhattan, while having much lower population density.
Unfortunately, problems like socialized healthcare are just far too complicated for contemporary America to solve. We used to be able to tackle big problems, but unless you're looking for ways to dodge taxes or rip people off, we're just not equipped for complex problem solving anymore.
Fine, 99% of China "landmass" does not have 50G. 100% of the US does not have 10G. The fact that in NYC, the richest city in the history of cities, most buildings still only have access to cable from a single provider is absolutely ridiculous. Urban centers is what is worth comparison here, and the US falls massively behind.
Very untrue. There are several providers in the US which offer 10Gbit services. Many more offer 2-5Gbit services pretty broadly. I've got friends in Kansas City with 40Gbit residential service. Sonic also offers 10Gbit in California.
Not all landmass because most of Tibet/Xinjiang empty, but ~100% wireless coverage east of Heihe–Tengchong line where ~95% of population are. Including Tibet/Xinjiang remote areas, ~95%+ of administered population areas down to village level where poor farmers have access to 5g AND fiber hookup option by now.
Building infra and networking gear is cheap in society that knows how to build and carriers are required to install in administered villages even if it's not profitable. Fiber adoption rate actually higher among rice farmers because they get subsidies, 1Gbps gigabyte fiber for cost of 200 Mbps in city and because bunch of villages got hooked up in last 10 years - they skipped straight to fiber which was bundled with road/power buildout.
Meanwhile US so dysfunctional / can't brute force rural fiber, need to literally invent SpaceX to plug gap. Which TBH is good copium.
More likely the cultural practice was not passed down after the massive change in food preservation about 125 years ago. In the United States, fermentation was a universally practiced method for the pickling of vegetables. This practice has been so reduced that the word "pickle" now only refers to cucumber preservation.
I don’t agree that the word “pickle” has been reduced like you claim. Used as a noun, it is only applied to pickled cucumbers. But it’s used as a verb is still very common and the average person understands that many things can be pickled.
Although if you were to ask them to guess at the etymology, you probably would get a lot of disappointing answers.
I think the big difference is sauerkraut is pickled in brine, resulting in fermentation. Whereas all the pickles I grew up with in the UK were pickled in vinegar, which doesn't produce fermentation. Pickled onions, eggs and beetroot come to mind
And yet an accessible ecosystem of 3rd party non-emacs tooling has not been developed.
I would pay big bucks for an obsidian-styled org-mode clone that had a no-frills GUI interface. I find org-modes task tracking, calendar, and agenda views top tier.
For what it's worth, there is this vscode extension https://github.com/realDestroyer/org-vscode/ which is pretty neat and can do org-mode task tracking, calendar and agenda view--and HTML preview.
I worked for a few years in an large org which utilized perl for build scripts, testing automation, and a few other things. I would summarize the half decade Perl learning curve as initial bewilderment, intermediate cult like praise, to advance level disillusionment.
There was something about scaling usage in large teams that felt awkward and high friction.
