aunderscored

Agreed, trusting a single human is fine, but there are weird extra tertiary effects as soon as you mention your looking at some metric. Especially if you're above someone in a hierarchy. They may subconsciously try to game it as well.

Yes, whatever you want to optimise is a good way to phrase this. However, it'd not just what you want to optimise, you will get side on effects. Even when things seem reasonable, longer term things come out. I don't have a good solution for this. But training people to target one (or even a few) things is incredibly difficult.

I also question the trust aspect. Part of this (which can also be gamed of course) is the level of trust you have that a team is doing their best to work towards some goal. More metrics indicate lower trust in some ways.

I think specifically this (metrics vs judgement), gaming happens in both, but metrics lead to much more wild problems if gamed, because they have a much harder "you said do this more so I did" backstop than "well this seemed to be what you wanted".

Thinking about it a bit more, if you make the argument that human judgement here is itself a compound metric of many different inputs, this semi resolves itself. But we still have the problem that the metric has no backing that can be handed around other than "seems good to me", which changes for many people.

This isn't "don't measure things" it's, "understand that when you measure something, it often turns into a goal. This can have unexpected consequences".

Even with human judgement this happens. Yhrtr are jokes about payment by line of code that have existed for decades.

The main thing is we need to measure secondary things. User satisfaction, defect rate, bugfix rate, etc (and this isn't to say that those are good measures that work everywhere. They may or may not.)

At the end of the day, the challenge is to think, and not assume they a number means what you think it means, or more or fewer of something will always be good.

Except that now there's yet another standard, which nothing but this thing speaks. TS6 is very well used at the moment as everything in the Charybdis line speaks it, etc.

Interesting. Why not use an open link network? These will result in around the same state. Spam _will_ be an issue here, in general. And with a different backend you're going to struggle to use preexisting tooling to handle it.

Using & channels is fun, I'd be interested to see how many bots and clients fall over dead when faced with that particular bit of IRC history.

I feel like this is one of the most damaging parts of the slop problem. Occasionally the slopisms fit into real writing. Sometimes people do just write like this, and we are losing a sense of reality because we keep being tripped up by this nagging little voice

How does that differ from this where you need to keep track of state and the whole change in the stack?

This one definitely does not feel like AI to me. I could be wrong. But it has too much warmth.

The problem is this reduces usability for others. Yes, there are many local to a country sites, but there are also large scale global ones. In both cases, you're not really gaining anything other than some clever autocomplete that could be far more precise if the site offered the correct fields so that whatever autocomplete tooling I use can put the data in for me.

The page itself specifically says "and country", however that too doesn't work. Other non us countries may have the same postal codes, or in my case mine is 4 digits, and I had to figure out that "oh, this is us only and it doesn't work at all for me", which was just entirely a waste of time.

RFC language is expmicltly defined in 2119[0]. Any other interpretation is incorrect.

[0] https://www.rfc-editor.org/rfc/rfc2119

IRC still exists at a semi large scale. If you're looking to return

If you're interested, fstrings are faster because they directly become bytecode at compile time rather than being a function call at runtime

Just like the event

This looks really cute. I wonder if it'd help with reviews when people have strange PR's

Working on some tailored to my needs tax reporting software. I submit claims to my workplace in batches under a number of different categories. Using this as an excuse to get better at some bits of SQL, leaning Textual as well, which I'm hoping to use in other things. Other than that I'm cooking a few IRC bots that I swap to when the other code becomes a bit too boring

Agreed! Sorry my read was for apps. You can use --user with pip to install into the user site rather than the system site, however it still causes overlap which can be problematic

pipx solves this perfectly.

There are already some bits of this with specific bytecode and the upcoming jit, it's not using annotations at all though

Without significant language changes, this is not possible. While your code may be typed as an int, I can simply redefine what int means. I can also modify the code in your method.

Have you considered fixup commits? On shared branches they work very well. Either autosquash before pushing, or as part of your final PR prep

Watched this on a whim in December. It was a fantastic movie and I recommend it to anyone

Indeed! It's delightful like all of bash. I've used them in a few places but I try not to

Not only do they exist, but they have some fantastic foot guns! https://mywiki.wooledge.org/BashPitfalls#A.5B.5B_-v_hash.5B....

If you always allow a company to say "wait no don't" with issues, it gives them a tool to quiet problems without solving them. Responsible disclosure is a tool , and part of that tool is the understanding that this will be public

Saw this in person, awesome look at street lamp control and then walking that all the way up to "oops we figured out a way to attack the European power grid"

It's the same amount of terrifying as a regular deploy, you need to ensure that you limit access as needed

It does, which is why this is more easily done by importing exact bits or using a single file

Every JSON API under the sun disagrees, but I do agree in principle. People very much like using HTTP as a JSON (or XML) transfer protocol

Indeed. That is particularly good at violating the principle of least astonishment

Disagree. Annoyingly there is a reasonable case for 200 but with an error, if http is your transport but not your application, then 200 says "yes, the message was transfered and understood correctly, here is your response" which may be an error response from the application