Is there a specific reason to store the key + value as an `uint64_t` instead of just using a struct like this?
struct slot {
uint32_t key;
uint32_t value;
}
Readit Newsjudofyr commented on My favourite small hash table corsix.org/content/my-fav... · Posted by u/speckx
judofyr commented on Over fifty new hallucinations in ICLR 2026 submissions gptzero.me/news/iclr-2026... · Posted by u/puttycat
> And yet, we’re not supposed to criticize the tool or its makers?
Exactly, they're not forcing anyone to use these things, but sometimes others (their managers/bosses) forced them to. Yet it's their responsibility for choosing the right tool for the right problem, like any other professional.
If a carpenter shows up to put a roof yet their hammer or nail-gun can't actually put in nails, who'd you blame; the tool, the toolmaker or the carpenter?
> If a carpenter shows up to put a roof yet their hammer or nail-gun can't actually put in nails, who'd you blame; the tool, the toolmaker or the carpenter?
I would be unhappy with the carpenter, yes. But if the toolmaker was constantly over-promising (lying?), lobbying with governments, pushing their tools into the hands of carpenters, never taking responsibility, then I would also criticize the toolmaker. It’s also a toolmaker’s responsibility to be honest about what the tool should be used for.
I think it’s a bit too simplistic to say «AI is not the problem» with the current state of the industry.
judofyr commented on Over fifty new hallucinations in ICLR 2026 submissions gptzero.me/news/iclr-2026... · Posted by u/puttycat
Regardless, if a carpenter is not validating their work before selling it, it's the same as if a researcher doesn't validate their citations before publishing. Neither of them have any excuses, and one isn't harder to detect than the other. It's just straight up laziness regardless.
I think this is a bit unfair. The carpenters are (1) living in world where there’s an extreme focus on delivering as quicklyas possible, (2) being presented with a tool which is promised by prominent figures to be amazing, and (3) the tool is given at a low cost due to being subsidized.
And yet, we’re not supposed to criticize the tool or its makers? Clearly there’s more problems in this world than «lazy carpenters»?
I’m sorry, but this is such a terribly unscientific approach. You want to make a case for your hypothesis? Follow a structured approach with real arguments.
Saying «I know that correlation doesn’t imply causation», but then only demonstrating correlation isn’t really bringing this discourse any further.
You are right on return (use next in a block), but break uses block scope.
Maybe I explained it a bit imprecise. I was trying to explain the following behavior:
def foo
p 1
yield
p 2
end
foo { break }
Coming from a language with functions as first class objects, blocks felt a bit limited to me, because it feels as if you almost have functions but not really, and they get inputted by a back door. Used for example to:
let isLarge = a => a>100;
numbers.filter(isLarge)
Blocks let you do the same but without extracting the body as cleanly. Maybe it’s a chronological issue, where Ruby was born at a time when the above wasn’t commonplace?
>When you write 5.times { puts “Hello” }, you don’t think “I’m calling the times method and passing it a block.” You think “I’m doing something 5 times.”
I’m of two minds about this.
On the one hand, I do agree that aesthetically Ruby looks very clean and pleasing. On the other, I always feel like the mental model I have about a language is usually “dirtied” to improve syntax.
The value 5 having a method, and that method being an iterator for its value, is kinda weird in any design sense and doesn’t seem to fix any architectural order you might expect, it’s just there because the “hack” results in pretty text when used.
These magical tricks are everywhere in the language with missing_method and the like, and I guess there’s a divide between programmers’ minds when some go “oh that’s nice” and don’t care how the magic is done, and others are naturally irked by the “clever twists”.
Blocks are fundamentally different from functions due to the control flow: `return` inside a block will return the outer method, not the block. `break` stops the whole method that was invoked.
This adds some complexity in the language, but it means that it’s far more expressive. In Ruby you can with nothing but Array#each write idiomatic code which reads very similar to other traditional languages with loops and statements.
judofyr commented on Strong Eventual Consistency – The Big Idea Behind CRDTs lewiscampbell.tech/blog/2... · Posted by u/tempodox
> This has massive implications. SEC means low latency, because nodes don't need to coordinate to handle reads and writes. It means incredible fault tolerance - every single node in the system bar one could simultaneously crash, and reads and writes could still happen normally. And it means nodes still function properly if they're offline or split from the network for arbitrary time periods.
Well, this all depends on the definition of «function properly». Convergence ensures that everyone observed the same state, not that it’s a useful state. For instance, The Imploding Hashmap is a very easy CRDT to implement. The rule is that when there’s concurrent changes to the same key, the final value becomes null. This gives Strong Eventual Consistency, but isn’t really a very useful data structure. All the data would just disappear!
So yes, CRDT is a massively useful property which we should strive for, but it’s not going to magically solve all the end-user problems.
judofyr commented on macOS dotfiles should not go in –/Library/Application Support becca.ooo/blog/macos-dotf... · Posted by u/zdw
None of the tools the author mentions as following XDG, actually follow XDG. No default tools shipped with macOS place files under .config or anything like that. There is a bunch of dotfile vomit in $HOME and that's it. Every tool that uses .config is one you manually install from an external source.
The XDG spec is to coordinate the userspace of Linux software, meaning both CLI apps and windowed apps. Linux needs things called standards because Linus has not bothered to write them down himself, so there is no equivalent of Microsoft telling you data goes in AppData and Apple telling you data goes in Library. Identifying it as a standard for CLI tools across OSes is just wrong.
When CLI tools do this on macOS, it is not because anyone thought 'this is a standard for macOS', it is because they thought 'with -target darwin I don't get any compilation errors. ship it!' and frequently use those locations on Windows too where they don't make any kind of sense at all.
The standardized location is Library. If you do not expect it, that is on you; you should expect it, as it is the standardized location. It is only just now that people are starting to catch up with it, instead of blind ports with absolute minimum macOS-specific code, because of libraries like `dirs` which make it easy.
> The standardized location is Library.
Except for Zsh (~/.zshrc), SSH (~/.ssh/config), Vim (~/.vimrc), Curl (~/.curlrc), Git (~/.gitconfig). Apple could have chosen to patch these and move the configuration files into ~/Library if they really wanted.
I suspect that this is an instance where “the scientific consensus” is wrong because to suggest contrary to that is wrongthink and enough to have one ostracized not only from science, but also society as a whole. I would love to be wrong, so if someone could explain this to me, I’d be very receptive to an explanation of why this logic is wrong:
First, let’s substitute emotionally charged terms for more neutral terms; e.g. imagine rather than discussing intelligence and race, we are discussing something else highly heritable and some other method of grouping genetically similar individuals, e.g. height and family. The analogous claim would therefore be that “although height differences have a large hereditary component, it does not follow that disparities in height between families have a genetic basis.” This seems very clearly false to me. It is in the realm of “I cannot fathom how an intelligent person could disagree with this” territory for me. If variable A has a causative correlation with variable B and two groups score similarly with respect to variable A, then they are probably similar with respect to variable B. Of course there are other variables, such as nutrition, sleep, and what have you, but that does not eliminate a correlation. In fact, for something which is “highly heritable” it seems to me that genetics would necessarily be the predominant factor.
It’s a really unfortunate conclusion, so again, I’d love to be wrong, but I cannot wrap my head around how it can be.
> Suggest contrary to that is wrongthink and enough to have one ostracized not only from science, but also society as a whole.
There's many scientists who have published the "contrary". They were not ostracized from science or from society as a whole. These saw next to none negative impact to their position while they were alive. Other scientists have published rebuttals and later some of the originals articles have been retracted.
J. Philippe Rushton: 250 published articles, 6 books, the most famous university professor in Canada. Retractions of this work came 8 years after his death.
Arthur Jensen: Wrote a controversial paper in 1969. Ended up publishing 400 articles. Remained a professor for his full life.
Hans Eysenck: The most cited living psychologist in peer-reviewed scientific journal literature. It took more than 20 years before any of his papers were retracted.
There's a lot of published articles about the "contrary view" that you can read. You can also read the rebuttals by the current scientific consensus (cited above).
> The analogous claim would therefore be that “although height differences have a large hereditary component, it does not follow that disparities in height between families have a genetic basis.” This seems very clearly false to me.
But this is not an analogous claim since you're talking about disparities between families. The analogous claim would be: "although height differences have a large hereditary component, it does not follow that disparities in height between groups have a genetic basis".
A very simple example for height[1]: The Japanese grew 10 cm taller from mid-20th century to early 2000s. Originally people thought that the shortness of the Japanese was related to their genetics, but this rapid growth (which also correlates with their improved economy) suggests that the group difference between Japanese and other groups was not related to the genetic component of height variance.
[1]: Secular Changes in Relative Height of Children in Japan, South Korea and Taiwan: Is “Genetics” the Key Determinant? https://biomedgrid.com/pdf/AJBSR.MS.ID.000857.pdf
You're shredding your credibility for nothing. You can instead just acknowledge Fil-C provides memory safety only for code correctly synchronized under the C memory model. That's still plenty useful and nobody will think less of you for it. They'll think more, honestly.