617 karma · joined October 21, 2016
This is also comparable to self-driving car: Waymo's system has achieve the level of "less error than human on average" long time ago, but they are still only doing slow expansion. Why? Because when AI is involved, human naturally expect them to be almost 100% correct, not just barely better than human, otherwise why bother use AI (and all the troubles to legalize for AI) in the first place? So in this case, I guess the police just blindly trust the AI being 99.99% correct.
2) How likely would a bomb's name really be "BOMB" vs anything else? If the latter is any higher, wouldn't it be reasonable to always turn around whenever the any other name shows up? In that case, all Bluetooth devices should be strictly banned in the cabin. But TSA is not doing that (not yet).
C++ is a mess in that it has too much historic baggage while trying to adapt to a fiercely changing landscape. Like the article says, it has to make drastic changes to keep up, but such changes will probably kill 80% of its target audiences. I think putting C++ in maintenance mode and keep it as a "legacy" language is the way to go. It is time to either switch to Rust, or pick one of its successor languages and put effort into it.
1. Snake case to camelCase. Even without AI we can already complete these tasks easily. VSCode itself has command of "Transform to Camel Case" for selection. It is nice the AI can figure out which text to transform based on context, but not too impressive. I could select one ":, use "Select All Occurrences", press left, then ctrl+shift+left to select all the keys.
2. Generate boilerplate from documentation. Boilerplate are tedious, but not really time-consuming. How many of you spend 90% of time writing boilerplate instead of the core logic of the project? If a language/framework (Java used to be, not sure about now) requires me to spend that much time on boilerplate, that's a language to be ditched/fixed.
3. Turn problem description into a block of concurrency code. Unlike the boilerplate, these code are more complicated. If I already know the area, I don't need AI's help to begin with. If I don't know, how can I trust the generated code to be correct? It could miss a corner case that my question didn't specify, which I don't yet know existing myself. In the end, I still need to spend time learning Python concurrency, then I'll be writing the same code myself in no time.
In summary, my experience about AI is that if the question is easy (e.g. easy to find exactly same question in StackOverflow), their answer is highly accurate. But if it is a unique question, their accuracy drops quickly. But it is the latter case where we spend most of the time on.
Like the author says, if the screen is too bright for you, lower the brightness, or use night light mode. You can change your environment. You can't change how your eyes/brain function.
I don't understand this. Do people not use lamp or light source in their house? Are people living like cavemen? Otherwise, how is it that much difference between day and night+lamp?
If it is sleep time, there is already blue light filter most OS supports nowadays. No need to ask each app to support a separate color scheme.
I think Mozilla is at the point where they realize it is no longer beneficial to continue the race against advertisers. It is time to collaborate. This way both users, advertisers, and maybe Mozilla themselves can all benefit from stepping back one foot.
I personally support this move. Morally speaking, content creators I consume deserve income from my visit, as long as my privacy is preserved. Seems a good compromise if it works.
gxhash
| 4 > 8300.74
| 8 > 16684.68
| 16 > 33121.69
| 32 > 38146.97
| 64 > 57805.72
| 128 > 49712.76
| 256 > 69277.29
| 512 > 88315.11
| 1024 > 97135.29
| 2048 > 98200.60
| 4096 > 104709.01
| 8192 > 108988.86
| 16384 > 110630.70
| 32768 > 111406.96
xxhash (twox_hash)
| 4 > 1291.20
| 8 > 2579.19
| 16 > 6029.70
| 32 > 10281.18
| 64 > 15950.47
| 128 > 22031.84
| 256 > 17929.12
| 512 > 20728.87
| 1024 > 21683.24
| 2048 > 21679.94
| 4096 > 21732.89
| 8192 > 21748.57
| 16384 > 21534.84
| 32768 > 21703.27
xxhash (xxhash-rust)
| 4 > 1968.26
| 8 > 3946.71
| 16 > 8030.94
| 32 > 13099.80
| 64 > 19073.49
| 128 > 23469.46
| 256 > 22909.73
| 512 > 33117.15
| 1024 > 42467.53
| 2048 > 54638.44
| 4096 > 63193.78
| 8192 > 68677.38
| 16384 > 71658.92
| 32768 > 71421.18I just tried and all I need to provide is the email ID and passkey. You need to use the "Try another way" option.
If implemented correctly user shouldn't even need to provide the user ID at all.
I have a table with sticky head. Then I decide to add a memory feature, where if user scrolls the table body, and leaves the page, I'd save the index of the first visible row, and restore the scroll position when user comes back. I noticed that every time the restored position is always about one row too downward. For instance, when I want to restore to row 5, it restores to row 6 plus a few pixels. Turns out, once I turned the thead semi-transparent, I can see row 5 was indeed at the top of the table, but the thead just overlaps on top and making it look like row 6 is the first visible row.
I told myself, no problem, I just modify the scroll position to be aware of the thead's height. It worked fine at first, but from time to from it'd still be off a few pixels. Turns out, because the table is huge, I'm doing lazy loading upon the scroll event. And because I'm using the default automatic table layout (instead of the fixed layout), sometimes certain head cell becomes too narrow and word wraps, thus increases the whole head's height. The final solution is to create a ResizeObserver[1] on the thead element and dynamically adjust the scroll position if its height changes.
[1] https://developer.mozilla.org/en-US/docs/Web/API/ResizeObser...