This sounds more like scrupulosity than a moral framework.

https://en.wikipedia.org/wiki/Scrupulosity

People have always told me I'm too hard on myself.

Then again, I've made mistakes to know I wasn't hard enough on myself.

If you're worried about causing a negative effect on someone and then you do, the solution isn't to not worry about that.

As someone who has been quite hard on myself too:

To err is to be human. If you minimize your life to minimize negative impacts on others, you are hurting yourself (and your friends and family). If you make a mistake, learn from it and try to be better. None of us are born with the skill and knowledge to do the right thing all the time, and sometimes there is no right thing, just different tradeoffs with different costs.

> If you minimize your life to minimize negative impacts on others, you are hurting yourself (and your friends and family).

Mind expanding on that?

I'm not the commenter, but I interpret it as:

The benefit that others get by you reaching your potential is greater than the risk to others of you making space for yourself to reach your potential.

It's talking about Luau (gradually typed, https://luau.org/), not Lua.

Hopefully https://github.com/astral-sh/ty will make the Python typing situation better, but absent that, Python typing is... not great. Honestly even with that it feels subjectively very finicky.

icontract or pycontracts -like DbC Design-by-Contract type and constraint checking at runtime with or as fast as astral-sh/ty would make type annotations useful at runtime

"Support runtime checking" : https://github.com/astral-sh/ty/issues/867 :

> [ typeguard, beartype, trycast; mypyc ]

mypyc/mypyc: Compile type annotated Python to fast C extensions https://github.com/mypyc/mypyc src: https://github.com/python/mypy/tree/master/mypyc .. docs: https://mypyc.readthedocs.io/en/latest/ :

mypyc docs > Using type annotations > Strict runtime type checking: https://mypyc.readthedocs.io/en/latest/using_type_annotation... :

> Mypyc ensures type safety both statically and at runtime. [...] `Any` types and erased types in general can compromise type safety, and this is by design. Inserting strict runtime type checks for all possible values would be too expensive and against the goal of high performance.

Oh my!

beartype docs: https://beartype.readthedocs.io/en/latest/ :

> Welcome to the Bearpedia

trycast: https://github.com/davidfstr/trycast :

  from typing import TypedDict, Literal

I think you vastly overestimate the value that people place on Trump. The GOP would swear in President Vance and count their blessings.

I would not be screaming for blood. It is the world order he wants, and perhaps the only possible lesson in why we shouldn’t give him that world order.

Most polls put it at 30%. (And 30% of those that could vote, didn't—so here we are.)

Of course it supports partial updates. It just requires you to know the difference between a document and a field, and model your data appropriately.

Both are true. Different camps meant that any significant change to the language was scrutinised loudly. If my memory doesn't fail me, the last significant changes from the time Guido was still in charge, and he mostly abandoned the BDFL because of backlash. Since then python has been on a constant "analysis paralysis" state, with only efforts about performance pushing through (no one complains about a faster horse).

> If my memory doesn't fail me, the last significant changes from the time Guido was still in charge, and he mostly abandoned the BDFL because of backlash

I think Guido left the BDFL role in 2018, and we’ve gotten walrus operators, structured matching, and exception groups since then (just off the top of my head). There’s also been significant language/grammar accommodations towards type annotations.

Overall, I’m of the opinion that Python’s language evolution has struck a pretty nice balance — there’s always going to be something new, but I don’t feel like the syntax has stagnated.

The other poster said “The result is that the Python language is pulled in many different directions, and with each release gets increasingly bloated and strays further from its foundations.” Which is directly contradictory to your (more correct) notion that language changes have slowed and only changes with low or no additions of complexity are worked on.

Have you worked on different types of Python projects? (Not in different codebases, different types of codebases)

I don’t have any specific complaints about Python syntax because I can force it to get the job done…but homogeneous, it is not.

The falsehood is the phrase "with each release gets increasingly bloated and strays further from its foundations."

It hasn't had any such language-changing release for at least six years. The implication that this is an ongoing process attributable to newer adopters is simply false. It is a process that has stopped, and when it was happening, it was attributable to longtime Python developers.

Self-hosting a database server is not particularly hard or scary for an engineer.

Hiring and replacing engineers who can and want to manage database servers can be hard or scary for employers.

> Hiring and replacing engineers who can and want to manage database servers can be hard or scary for employers.

I heard there's this magical thing called "money" that is claimed to help with this problem. You offer even half of the AWS markup to your employees and suddenly they like managing database servers. Magic I tell you!

Less than 20% of Americans live in most of the (very large) country. The rest live in cities and suburbs.

And how do you think vehicle ownership compares between those two groups?

In the cities and suburbs—-where the vast majority of trucks are garaged—-they are generally an obnoxious luxury good.

Which is why new pickup truck models are so often not fit-for-purpose as a working truck of any kind. Like an EV F-150.

Those census definitions are not good. I’m sure the place I went to high school is considered “city” by that definition, but the average HN poster would not recognize it as one, and there were lots of farm working trucks around.

It turns out that anecdotes don't constitute data. If the place you went to high school is considered "city" by the census definition, then I guarantee the majority of pickup trucks in the area were obnoxious luxury goods that never hauled a single thing to or from a farm.

And you would be wrong.

A good system, i. e. one that got it right from the start, is one that is cost-effective to change. (“Will” has little to do with it.)

Change in which ways? A system designed to be cost effective to change in any way isn't going to be cost effective to change in a small set of ways.

Answering that question well is what makes the system good!

Wait til you hear about NodeJS not supporting parallel threads until version 12...