ablob

Most knowledge about human computer interfaces was obtained through metrics. Groupings, menu bars, corner buttons, context menu orderings, and other things didn't just spawn into existence. There was a time where human pattern recognition and physiology was an active consideration for user interfaces. One of the reasons mouse input became popular is precisely because interfaces were created to be easy to use with it.

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.

The existence and growth of the codeberg project does, however.

You're right it doesn't. At least not completely. I was thinking about precision (i.e.: if the test is positive, what are the odds that its prediction is true). It turns out, that accuracy is not defined as "true positive / (true pos. + true neg.)", but "correct predictions / all predictions". The whole point of OP's statement: "It's kind o remarkable how even a 99.9% accurate heuristic is insufficient at scale.", which you actually support with your example.

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

There are implications by linguistics. If you learn a language you also passively obtain insight into cultural norms and expectations. Moreover, Learning a language is much easier if you're friends with natives and converse with them on a semi-regular basis. Being able to speak the language also means that there doesn't need to be a separate support structure for you, as you will be able to use the ones provided to everyone else.

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.

The mentioned accuracy in the comment you are replying to already encapsulates the relation of true positives to false positives.

There is no progress without possible failure in medicine. Each treatment starts with assumptions and you can only go so far until you start testing on actual people. Until we understand the mechanisms completely there is no way around that.

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.

What exactly do you mean by "solved NP-hardness"?

I wonder if it will feel significant. I can't remember being limited by the controller battery. The runtime on a single charge is probably still going to be measured in weeks, and at that scale I feel like it doesn't really matter.

Douglas afaik. Boeing moved HQ and quite a few engineering practices were abandoned.

I wonder by which metric you measure these scripts. Clearly it can't be on pronounciation or information density. If "amount of letters" is your pick, then Latin might be "objectively" the best system - you'd just be using a very bad metric.

If you're going to unify all the worlds language into one script, then you'd better pick a good measure for that. If everyone on the world learns it, then it doesn't matter if there are 50 or even 100 different characters.You will have to capture _all_ of the nuances of the languages without blowing them out of proportion in size. Good luck with that.

You may not be able to mix encodings, but mixing languages has always been possible. If you used a French encoding you would be able to write in English, but not the other way around. I'd wager there are similar cases for cyrillic text. What Unicode gave us is its universality (heh). You don't have to carefully select an encoding able to represent the languages you wish to use anymore.

> Many users of CJK language would argue that CJK unification was a mistake.

Luckily it's not a decision without turning back. In most relevant contexts you should know the input language and can select a Font specifically using said variations. Of course this information will not be present in plain text, but if it turns out to become an issue I'd wager, since language codes do exist, that a control code-point for language selection can be added to the specification. There's already so many special cases in Unicode that it shouldn't be a huge issue (apart from backwards-incompatibility that would lead to tofu instead of no rendered glyph).

afaik this is a non-issue with modern text rendering engines. Modern font files include rulesets to determine the forms and shaping engines apply these rules to eventually reach the desired "shape" (i.e. order, position and which glyphs to render). For example, if you use HarfBuzz it should be able to calculate the Glyphs and offsets you need for a properly set script.

I personally spent way to much time trying to understand it, but at least according to this video (https://www.youtube.com/watch?v=VaA0v0V4RsU) it really is not that difficult if you leave out all the font-selection and emoji shenanigans.

I think at least FreeType (glyph rendering) and HarfBuzz (text shaping) make it needlessly complex through their documentation. It is extensive in describing what the parts do, but the only way to figure out what you need is by fiddling around. As soon as you want to do more complex stuff you're on your own. Especially figuring out which parts you don't need is annoying.

The lovecraftian horror of pdf mostly comes into play through the sheer amount of software that supply almost correct pdf. It's not enough to be able to read pdf anymore, you also have to be able to deal with software that emits subtly wrong documents.

I'd like to add that there is almost no way of "running away" from it. If I search for anything on the internet I am almost guaranteed to be handed pages and pages of AI generated content. In lieu of that I found that directly prompting for an answer tends to yield better results nowadays. Not because it's good per-se, but because having control over the prompt beats having little to no control over it though search by proxy.

It saddens me to see that high quality content is drowned in this sea of garbage to the point of being almost impossible to find.

I personally stumble upon many topics where I only care about the what. In that case all the theory is just a distraction I'm just wading through to get to the point. If it's optional, then looking into the how and why is certainly nice, but it should be part of an appendix or a commentary and not interspersed within the proof unless an uncommented version exists.

I feel like keeping the amount of molecules the same within the simulation needs to be justified. How would it look like if the average amount of molecule was the same across a um?

Isn't this just an issue with rsync? (or rather your ancient version of it) I think you'd run into the same issues when using an IPv4 address port combination. It was rsync's choice to use colon as an indicator in lieu of IPv6's existence. You'd be complaining all the same for other separator choices if rsync just happened to pick the same one.

Nonetheless I do agree that the choice of colons isn't great due to how it ambiguates their meaning.

Two fields should be fine, actually. The way caches are organized you are very unlikely to thrash with the lookups (due to n-way associativity) while only keeping relevant data in the cache at the same time. You still have roughly the following layout (in the cache), where A is the field and V is valid:

  | A1 A2 A3 A4 | A5 A6 A7 A8 | ...
  | V1 V2 V3 V4 | V5 V6 V7 V8 | ...

The former access pattern still yields a clean cache layout where no unnecessary data is loaded (which is the most costly operation here by far) as opposed to

  | A1 V1 B1 C1 | ... | A2 V2 B2 C2  | ...

In the general case there will exist a number of fields for which SOA layout will be worse if all are accessed close to each other, but for just a validity indicator this should not be the case. I think your statement is not wrong, but also not 100% correct.

This is on par to linear search being faster than binary search for small n. As soon as caches and branch prediction chime in many rules of thumb just change. Most importantly, however, is that a distinction between small and large n basically _needs_ to happen at that point.

According to the thread rsync broke for incremental backups and increases the cpu load heavily. The whole thread only started because people noticed regressions and were wondering what happened.

Since I quite a few users are using distros that won't update for a while it gets even better: this trend may continue and as soon as the update actually happens we'll be so far down the road that it will be too late to take a step back and reconsider due to the delayed feedback. This is pretty much about the few people _already_ having issues with it.

That being said, if the creator wants to use AI to work on the project they are free to do so. I just hope nothing of value is lost because of it.

P.S.: If you stop writing by hand and start delegating - to AI or other people - something has changed. There shouldn't be any discussion about it. Delegation is different than writing it yourself.

If we're talking two's complement it's not undefined that is right. Having to emit checks though, that is where I beg to differ. A check is only useful if you want to actually change the behavior when it happens, otherwise it is useless. Furthermore, it might be "essentially free" from a branch prediction point, but low and behold caches exist. You would pollute both the instruction cache with those instructions _and_ the branch prediction cache. From this it doesn't follow at all, that there is no cost.

In the end small things do add up, and if you're adding many little things "because it doesn't cost much nowadays" you will end up with slow software and not have one specific bottleneck to look at. I do agree that having the option for checked operations is nice (see C#), but I have needed this behavior (branching on overflow) exactly once so far.

Somehow I highly doubt that a small game company is going to run a "huge network of interconnected cloud services". I've also yet to find a small game company running their own big online multiplayer game.

http3 operates on a different OSI layer

I just feel like "you can do this with Kubernetes" is a slippery slope. "You can do X with Y, so use Y" is a great way to add a dependency, especially if it is "community vetted" already. Sometimes simple is better - you don't need to add anything that implements some of you logic as a dependency to stay DRY or whatever you want to call it.

It really feels like we are drowning in self-imposed tech debt and keep adding layers to try and hold it for just a while longer. Now that being said, there is no reason not to add Kubernetes once a sufficient overlap is achieved.

afaik, you always have to break open abstractions for more performance. If you ignore cache-levels in your program you're gonna have a bad time - and depending on the system the layout (and with it how you should use it) is different. The same is true for how machines are interconnected. Depending on the wiring you have different throughput-values when sharing data between nodes. The whole area screams "not universal" to me.

So what would be such an HPC language that you're so fond of? A quick web search reveals only languages that use C++/CUDA code as a back end (python), are new and experimental (Julia) or FORTRAN. For what you're talking about none seem all to good, so you've peaked my curiosity.

C++ by comparison doesn't stand in your way too much either. I feel like the biggest gripe Rust has is what happens when you do have to go unsafe. That seems to be a strong point of contention for many folks. Maybe all the reasons that lead people to use unsafe rust go away or the attitude about it shifts in some manner.

For me Rust turned out to be less interesting after I saw the whole ceremony about typing. The amount of things I had to grasp just to get a glimpse into what a library does felt much more involved than any of the things I did with C++. The whole annotation-ting feels much less necessary and more like a proper opt-in there.

Anything that increases the entry time by a second or more is a pretty good way to make me (and probably others) just not bother with opening the website.

I think his point is that "form follows function". If you know what kind of semantics you're going to have, you can use that to construct a syntax that lends itself to using it properly.

I guess "back in the day" you had to be able to write an efficient parser, as no parser generators existed. If you couldn't implement whatever you wanted due to memory shortage at the parser level, then obviously it's gonna be a huge topic. Even now I believe it is good to know about this - if only to avoid pitfalls in your own grammar.

I repeatedly skip parts that are not important to me when reading books like this. I grabbed a book about embedded design and skipped about half of it, which was bus protocols, as I knew I wouldn't need it. There is no need to read the dragon book from front to back.

  > But there's a reason most modern resources skip over all of that and just make the reader write a recursive descent parser.

Unless the reason is explicitly stated there is no way to verify it's any good. There's a reason people use AI to write do their homework - it just doesn't mean it's a good one. I can think of plenty arguments for why you wouldn't look into the pros and cons of different parsing strategies in an introduction to compilers, "everyone is(or isn't) doing it" does not belong to them. In the end, it has to be written down somewhere, and if no other book is doing it for whatever reason, then the dragon book it shall be. You can always recommend skipping that part if someone asks about what book to use.