Whatever this approaches, it is not a state of software engineering I find desirable.

P.S.: No true Scotsman spotted

It is known that warnings and pop-ups that show up almost all the time yield diminishing returns. I think it was named "normalization of deviation" by some folks in a blog a while ago, and I believe that name fits. If you get warned about missing https all the time, or that something might be dangerous (even though it does precisely what you want it to do), it will loose its effect by the time you actually need it.

You can argue this is malicious compliance, but if you want it to go away it would probably be easier to go for banning tracking and personalized ads altogether. Eliminate the reason for this behavior, so to speak.

  git config core.editor "vim"

I might be misinformed, but I believe that American citizens have a way of forcing specific regulation instead of only forcing it to be considered. That would be something we don't have in the EU. So in the end it might just even out in that regard.

Maybe this sentiment stems from being software engineers, but at least for hardware it becomes abundantly clear that "good enough" is a desirable state unless you want to spend years in development. The only direct comparison I can find in software is computer graphics, where the endeavor often halts as soon as the average person can't perceive a difference anymore.

No one bothered to make any of the other options easier, only the previously simplest option was barred behind trying everything else. This is what over-bureaucratization looks like.

To use a different example: No one wants to switch to public transport (which is already crowded anyway)? No problem, just ban driving unless you can prove that it's orders of magnitude faster and it's not feasible to move your residence. No further preparation is done; no thought goes beyond the horizon. "Eat this rule and deal with it, you don't have to deal with the paperwork if you're willing to spend 2 hours more on commuting". That's the line of thought here. There are no plans to make it actually viable to use the train, the other options are just barred behind this veil of plausible optionality. You can do it, of course. The issue arises from doing this with literally anything you tackle.

You essentially only add rules and special cases without ever consolidating them or even considering possible impact on adjacent topics. Everything grinds to a halt by doing this and nothing ever gets simplified. It is a huge issue on a landscape that favored small businesses (that can't afford divisions dealing with this) when the way the law is written suddenly requires structures only big companies or consultancies can provide. It entombs the market structure and drowns any competition in regulatory capture. We haven't even seen what happens once the markets are dominated by oligopolies and monopolies. By that time the only way to deal with the fall out will be even more rules, as the competitive landscape will already be dead.

I'm not against the goal of this regulation, but the recent way the rules have been made favor a market structure I consider incompatible with the goals of the EU.

  2>&1 >/dev/null cat file

Maybe it's because I don't see how sleep regularity is a factor you can change as willingly as visits to the fridge, or maybe its because I don't see why people wouldn't just eat more before heading to bed.

It could also just be that I find a treatment of symptoms to be less desirable than causes.

How someone interacts with your software is absolutely measurable and the results will vary by how a user is likely to use it in frequency and variety of function. Someone that needs to do something specific with your software every day will interact with it quite differently than someone that just hops onto it every now and then to do a different task each time.

All of this requires actual studies and observation of users over time. Micro benchmarks have no space there. Testing how fast a find and replace is is meaningless. In case of software for writing text you'd test a user actually writing prose, changing font sizes, title colors, and maybe replace a word over the file too. You would have commonly used functions mixed in with less commonly used functions over how the software is used under a specific use case. (For example, writing text, revising text, and polishing a graph representation are different use cases)

This is not easy, which probably why it's not done all too often, but it is also most definitely unlike a micro benchmark (which your link argues against).

All that being said, I don't know of any person strictly pitting mouse against keyboard when testing UI for possible improvements.

All of this brings me to my questions: Why do you reject measuring how good an interface is? Or given your dismay over keyboard based workflows, why do you think they would win most of the time?

I'd wager that if actually tested, in only a few scenarios the keyboard would win, while hybrids (with both mouse and keyboard input) perform best for most people.

> There is an important difference between scenarios where we care about the relative versus absolute frequency of errors.

The context is chat control without probable cause over the whole population of Europe with a low prevalence. My point, and presumably that of OP, is that even a small relative frequency of errors will yield an unsustainably high absolute frequncy of errors.

> This is merely information provided to a human agent.

It will be in theory. In practice the human agent will just forward the decision. A human agent is not sufficient; you need to test only with probable cause for the kind of scenario we're talking about. The exact opposite of "Chat Control 1.0 and 2.0".

P.S.: The comment I originally replied to choose a very convoluted way of saying that the false discovery rate of the test matters for a proper evaluation. Both you and they explain this by throwing numbers without context in combination with slightly inaccurate definitions. I got the definitions mixed up differently, which led to this follow-up.

I'd wager the sum of these things is something one may expect from a permanent resident (i.e.: cultural knowledge, some amount of integration, ability to function without specialized support structures). And it turns out, that language proficiency is a pretty good proxy for measuring that. Just because you don't accept the rationale behind the requirement it does not mean that there is none.

The requirements are not there to verify that you can live somewhere permanently, but if you _may_ live there permanently. Money is not the only dimension your so called "net positive" may be measured in.

Genes are an important part of lifeforms. Of course, you may object to tinkering with them and wait until nature has done the tinkering for you. That will inevitably slow down progress by obtaining information so much slower that countless lives will be miserable due to missing cures and treatments. This is a zone where there is no clear moral answer. The only thing I would say with confidence is that gene editing is very likely the key to a plethora of treatments and preventative measures.

> Will they need to live their whole life for us to confirm the cure worked? People already do that right now without gene editing. A friend of mine is 10 years over the life expectancy of their condition just because their parents decided to have them live their whole life "to confirm the treatment worked". 9 out of 10 people with that condition died by the age of 12 if not within the first year of birth. I'd wager being part of a medical/scientific program to monitor your condition is the least of your concerns at that point.