Yes, the diagram just shows the ASCII table for the old teletype 6-bit code (and 5-bit code before), with the two most significant bits spread over 4 columns to show the extension that happened while going 5→6→7 bits. It makes obvious what was very simple bit operations on very limited hardware 70–100 years ago.
(I assume everybody knows that on mechanical typewriters and teletypes the "shift" key physically shifted the caret position upwards, so that a different glyph would be printed when hit by a typebar.)
"No signaling" would be: "I dress like I always do since forever." Any reference to opinions of others would mean that the person cares for them, even in the form of "I don't care", and thus the dress is also a signal to them.
At least for me, the signal I'm sending is "I care more about how comfortable I am in my clothes than I do about what other people are inferring about them". The point isn't that people aren't receiving some sort of signal about me based on that, it's that the signal that they might receive is entirely irrelevant to my motivations. That itself might be a signal, but it's incidental to the actual choice I'm making, which is entirely personal.
I'd say, not "people in general" but people form other socioeconomic strata. This guy is not talking like us, suspicious. He talks in an elaborate and thought-through manner, not simply, so, he's not candid, double suspicious!
Imho, there is an easy way to turn this around. Ask: "What is your range for the role?" Then it becomes easy to say: "Fine, I'm comfortable with this range", or maybe "Oh, I'm afraid I can't afford this".
Once you're at the offer stage, you can bargain about specifics.
This is not very different from collecting visual cues. You can notice a delivery van arriving. You can see the driver's face, same with passers-by. The biggest difference is that a camera needs to be more conspicuous, while a BT receiver can be invisible and undetectable. Much cheaper, too.
I have an ESP32 Cam in front of me right now. I think I paid maybe 8 bucks for it. If I wanted to, I could very easily hide the tiny camera in my front door, and use it to both collect bluetooth and wifi metadata (including MAC addresses) and correlate images/faces to MAC addresses when people pass by close enough so that I can identify them later from longer range wifi/ble detections.
(I actually do plan to install this at my front door, but aimed mainly to detect when a deliver/parcel in on my doorstep, and I don't (yet?) plan on sniffing bluetooth/wifi with it)
If you don't "know about them from another source" you can't effectively find/access the information and you might not even know that there is something you really should know about.
The service bridged the gap by providing a feed about what is potentially relevant for you depending on your filters etc.
This mean with the change:
- a lot of research/statistics are impossible to do/create
- journalists are prone to only learning about potentially very relevant cases happening, when it's they are already over and no one was there to cover it
I kept digging and reached the service https://www.courtserve.net. Seems like a windows application (old school one) that receives the data, but I need more time to explore there. They've been working with MoJ for 20 years (their claim).
Initially I thought they have people at the courts live reporting but that's a bit of a stretch...
It very possible to make lightning-fast React web UIs. DOM sucks, but modern computers are insanely fast, and browsers, insanely optimized. It is also very possible to make sluggish-feeling Qt or Swing applications; I've seen a number.
It mostly takes some thinking about immediate reaction, about "negligibly short" operations introducing non-negligible, noticeable delays. Anything not related to rendering should be made async, and even that should be made as fast as possible. This is to say nothing of avoiding reflows, repeated redraws, etc.
In short, sloppy GUI code feels sluggish, no matter what tools you use.
> but modern computers are insanely fast, and browsers, insanely optimized
I think these facts have been used as excuses to shit up the app layer with slow mal-optimized js code.
An example of a recent high performance app is figma, which blows normal js only apps out of the water. And it does so by using c++ wasm/webGPU for its more domanding parts, which is most of it
I think we have to let go of the "just get more ram" approach and start optimizing webapp code like figma does
> I think we have to let go of the "just get more ram" approach and start optimizing webapp code like figma does
I think you're underselling how much work went into making Figma that way. You're talking about a completely different realm of optimization that most companies won't spend money doing, and most web programmers won't know how to do.
As long as there's no incentive to do otherwise, companies will slap together whatever they can and ship as many features as possible.
For most apps React is never going to be an issue when it comes to performance, unless you use it wrong or you use it for something that is not standard, like rendering fractals.
It makes sense to analyse performance if your website is meant to reach absolutely everyone, like old smartphones.
There's the issue that a single-page app can be bloated from the start, but that's also in the using it wrong category
> modern computers are insanely fast, and browsers, insanely optimized.
You made the reverse point: If you need modern hardware to run a react app with the same performance as a svelte/vue/solid app on low-hardware, something is fundamentally wrong.
> Anything not related to rendering should be made async,
The thing with DOM interaction is that if you try to make it synchronous then it gets really fucking slow (reflow and friends). So you want it linearized for sanity reasons, but probably not sync.
This is the first sane comment in this entire comment section. So much nonsense in here, but I guess I should expect that when JavaScript is in the post title.
(I assume everybody knows that on mechanical typewriters and teletypes the "shift" key physically shifted the caret position upwards, so that a different glyph would be printed when hit by a typebar.)
reply