hiimkeks

What would also lessen the confusion would be people putting in the effort to read a little further than the headline before coming up with a hot take.

Ex falso quodlibet.

(note that your comment uses present tense)

My guess is if you pronouce this "nool" it sounds similar to "bool", and it's a slice of the name "Bernoulli" because the models generate Bernoulli distributions

It's Dragostea Din Tei all over again

[always_has_been.jpg]

Before 2004 Germany had a %vol limit for selling alcohol to 16 year olds. In 2004 they changed the law such that it is not based on percentage, but whether it contains distilled alcohol to prevent under 18 year olds from drinking sweet alcopops, which apparently was a big thing back then.

Just today I had Sonnet 5 generate this (asking about always-on display in the iPhone e-versions):

> This mirrors how Apple has always segmented Pro vs. non-Pro iPhones: base models got LTPS panels while Pro models got LTPO, and only with the mainline iPhone 17/17 Plus did that gap close the standard versions previously lacked the smoother 120Hz ProMotion technology and the always-on display feature, unlike the Pro models — the 17e is the one model line still using the older, cheaper panel.

(emphasis mine)

I mean, I can guess what it is trying to say, but who RL'd this nonsense?

Can you remind me what RFC number the Protocol of the Elders of Zion was again?

Git is over 20 years old at this point. If somebody is in their 60s now, they were in their 40s when it came out. This is not about age. They must have slept on it for a long time.

Nobody expects an engineer to be a git expert, but if a senior software engineer has heard of git only yesterday or don't have a vague concept of how DVCSs like hg or git work (DAG of commits), then something has gone very wrong.

Maybe there are use cases where SVN is superior (I can't come up with any but they may exist), and maybe engineers in that industry really are so specialized that they never get around to working on anything else!

But maybe it's because nobody else is willing to hire them.

I love this! The docs are really good and I am looking forward to playing with this.

I think I disagree a little bit about the value of type and lifetime annotations, I think if I used this, I would put a lot of [sig ..] into my code.

I think having a similar syntax for lifetimes would be valuable so I as a developer can make sure that some value is not 'static (or has the lifetime of some other object that lives as long as my program). Basically I want to ensure that my values are actually dropped at some point.

One thing the docs could be more explicit about is where this runs. I saw that it has a Wasm backend, but can I also compile this to native code? Do the effects require some runtime (and I don't mean something like the JRE, more like what Go has)? Maybe I missed this, though.

Anyway, I hope I get to play with this soon!

What I think you are saying is that computing the hash needs to process the entire string, and the length of that string roughly corresponds to log n, therefore it's O(log n). Not sure I am entirely convinced by that reasoning, but let's roll with it for now.

Because if you apply it to binary search, you need to compare the strings at every step, and by that logic, each of these operations is O(log n), which means your binary search is now O(log^2 n).

I guess the crux is that we are still comparing apples to oranges (or multiplication operations to comparison operations), and at the end what probably makes hashing faster is that we are not branching.

Still I don't think it makes sense to think of both hash tables and binary search as O(log n).

Parent is using normal words to say they have no idea what communism is

Status is yellow now, actions hang for me. Same like more or less any Thursday.

We definitely would need centuries for this, because Moore's law has been dead for a while, while the number of possible programs grows exponentially in it's length.

But I hope we have more efficient ways to do this in a century.