hansvm

Assuming the ink is free, you use some sort of scheme to take advantage of the full printable ascii character set, and you don't bother presenting key values (if necessary, you could print a key offset at the top-left of each page), just the table outputs, I'm getting a break-even point at each character being around 0.2 square nanometers.

The more obvious answer is that they get different marketing signals from the two companies' offerings and want both.

Both. The hypothesis with Eytzinger is that you're doing vanilla binary search on a data structure where each hop is one operation. It doesn't, by itself, do anything to optimize around particular hot leaves, so assuming you aren't doing a weighted rebalance operation before construction it additionally assumes access patterns are somewhat uniform. That's the algorithm and input pattern whose cachability we're trying to optimize.

Imagine, e.g., doing a b-tree lookup on a binary Eytzinger layout. You would always grab more cache lines than optimal. Even more obviously, consider an inorder traversal. The properties of an algorithm and data structure depend properly on both components.

My holdings aren't even locked up, and I'm still not allowed to short my employer -- true as a matter of policy which could get me fired, and true from a US legal perspective most of the time given my role.

My hunch is the HN formatter swallowed the double asterisk typical of python exponents.

While we're being pedantic, 2^30 is 28 in normal programming languages ;)

> LLM-as-a-Judge

Empirically, many problems look like they're easier to check than they are to solve. This seems like a reasonable way to bootstrap a little extra performance, with prior art in well-known DeepMind experiments. It's unclear if it works recursively (I imagine not), but the core idea is solid.

I thought about proposing that idea myself and decided against it. Consumer behavior is a bit hard to predict, and it's a little unclear to me how well "just works" will sell. I like to believe that's viable, but I don't really know.

This might sound like a rant, but it's more an attempt to outline the breadth of the problem by way of many examples. Software quality sucks right now, enough so that I plan my life around it. Payment processing is regularly broken? I'll maintain a couple cards from different providers. Login systems are always broken? If you require a login then I'm going to weigh the quality of your service against not just its physical dollar cost but also the amount of my time you're about to waste if I sign up. Etc.

Enterprise broke something and has been unable to text or email me receipts and reservation information for months. No trouble; I'll look up my information manually on their site when I want to modify a reservation. Great, I've found that information, surely I can modify it? Nope; that's broken too, and it asks me to call and doesn't provide the number I should call. So...I'll look up their customer support number, surely that isn't broken? Nope, somebody deployed a version of the site where I physically see the handlebars and variable name which should have referenced the phone number rather than its actual value, and they seemingly didn't notice or weren't able to roll back the change for at least a day.

And that's not to pick on them (especially because they're otherwise a good company IME), but to highlight a series of technical fuckups which never would have flown in past years, and they're not alone. My HSA just made it impossible to log in without buying a new phone, every single time I've tried to set up automatic payments for Visa they've had a different bug on their website preventing that, WalMart supposedly allows buying things for people in other states (I was buying my sister tires), but some broken AI will reverse the transaction hours later. eBay and Visa are even better on that front; their customer support seemingly aren't able to override the broken fraud-detection AI, so there are some Visa purchases I can't make, and every time I log in to eBay my account credentials are forcibly reset a day later.

Beyond the straight, obvious incompetence manifest in 3+ major bugs in nearly every website or service I interact with, there are also stranger bugs (no "strangest" bugs in recent memory). One of my coworkers has a reliable network blip every 20s (my memory is fuzzy, it might have been 10s or 15s when I timed it, but it's incredibly consistent), only hitting their outbound traffic, and it's at or upstream of the modem. One site I visit has some sort of broken filtering from my mobile carrier, but only for their login page, so I need to use a VPN to log in, but then the rest of the site has VPN detection, so I need to leave the VPN to access the rest. A little while ago, I stopped being able to accept calls while my wireless hotspot is active. Slack automatically moved precisely one of my DMs from the section I had assigned to it to a different section. Discord and Target both had an automatic retry on a failed telemetry implementation without backoff which caused you to immediately violate their rate limit by just visiting the site.

And so on. Major companies are writing broken software, missing the bugs in review, missing them in testing, don't have monitoring or alerting on core metrics to be able to roll back when their deploys suck (or just can't roll back), usually have no way to contact them to inform them of the mistake, and sometimes choose not to fix bugs as big as "many of our customers can't pay us" in days, sometimes ever.

> Even though the text we're reading is Claude talking to us as well :)

I'm not getting that vibe from this one; I'd bet money on it at least being substantially human edited. What are the tells you're seeing?

If I buy one thing and get a worse alternative, I usually call that a scam. $30k for a car, and it feels the need to summarize my location patterns and sell that to adtech agencies without bothering to even notify me? That's a scam. $X for a code generation tool, and it feels the need to ship all my passwords and other sensitive information to a known user-hostile entity? Also a scam. The fact that I can ~clip the antenna~ sandbox the malicious code doesn't make it not a scam; it might be a practical stopgap, but the offenders still basically got away with it.

> the next update

That's a major problem in its own right. Yes, not updating an XP SP1 RCE immediately is dangerous, but in the last couple decades I've seen far more damage inflicted from automatic updates than what I think the lack of them would have caused.

Downloading the SSN/tax/etc data from the entire US wasn't bad either.

Rust was ~70% of my last job, and the other Rust engineers there were very competent -- large volumes of high-quality, high-impact code. In my rust community interactions at the time, also interactions with my colleagues, I definitely noticed some unsavory trends. An example pattern is:

me> This [API | language feature | whatever] seems harder to use than it should be.

them> No, it's actually not.

me> Here's irrefutable proof.

them> Well at least you have memory safety.

me> But...you can have memory safety without this thing being a dumpster fire. Wouldn't that be better?

them> <no concessions, Rust is perfect>

After a few conversations like that, I've literally had those same otherwise high-caliber engineers spend days wrestling with the "easy" thing we were quibbling about. I'm sure it's not intentional, but it comes across as religious gaslighting.

And maybe I just interacted with the wrong people at the wrong point in Rust's lifecycle and the community is mostly very positive. I see enough people with experiences like mine though that I'm not willing to believe it's a truly miniscule fraction of the language's discourse.

Engineers are pretty jaded about plans expressed by authority, especially when there are obvious pressures opposing those plans. Yearly planning doesn't matter when a reorg will change the trajectory by Q3. Sprint planning doesn't matter when you know a fire will hit before then and you won't be given enough time budget to fix it well enough for that not to happen again next sprint. Project planning doesn't matter when the whole point is masturbatory spreadsheet production before you've actually taken a dive into the hairier details and figured out what's possible and what's necessary. That barely working demo strapped on top of a non-existent backend they swore would never become production? Congratulations, you have two weeks to build the next fake demo on top of it, but the base has to actually work now.

Maybe Jared just broadcasted uncertainty and was wrong, but given his position he's not being given the normal grace you might extend to an engineer you trust.

Every time I've rewritten a major project I've made it smaller and faster while fixing all the major bugs and most of the minor ones. My current team has had similar experiences. I'd be curious to see what a Zig -> Zig rewrite of the same magnitude would have done for quality.

Not just beeping. I had a rental Nissan recently violently pull me straight off the road when it couldn't read the lines very well in a thick fog. Apparently you can disable that deep in some settings menu through some magic button presses divorced from the main settings menus, but it was frightening. For most manufacturers, almost none of this tech is good enough to even make optional and non-default, much less legislatively mandated, and that supposes I trust you not to sell my daily mood or whatever bullshit to data brokers.

I remember an engineer I talked to recently saying that OSM didn't have sufficiently up-to-date data for their routing use case -- new roads, closed roads, traffic data, etc. Is that the case?

Potentially lots of money, potentially none, but they should be honest about the capabilities and lifetimes of their products and not make that profit through bait-and-switch and other lies.

And owe them royalties for infringement on the name "Verizon."

I've found my calling. Is this "Tim" role open now that he's left?

Interesting. I can barely stay awake in typical commercial planes, and I always attributed it to the lower partial oxygen pressure.

That makes sense to me. There's a causal link between ambient air CO2 levels and cognitive changes, but the air in front of your face, which you breathe, doesn't play a role...

A lack of direct study might make "in front of your face" numbers harder to interpret in absolutes, but relatively speaking I do think that's the number which matters more. Whole-room analysis is just a proxy for the air in front of your face.

For complicated problems, you can't just write the language spec. You need to iteratively develop it, which itself requires some intermediate state/language describing what you know so far. That intermediate state being the end programming language in consideration isn't mandatory per se, but iteratively refining, replacing, and reworking solutions using code as a drafting board is very common in the industry. That's doubly true for languages, where the social pressures in how it "feels" or is actually used are paramount. If you move away from iterative coding drafts, you still need some sort of interactive product to work on to actually develop the spec.

Plus, current-gen agents/LLMs can't implement a non-trivial language spec without significant hand-holding.

It makes more sense when you view sandboxing as enabling project correctness in the presence of skilled, fallible maintainers rather than preventing explicit attacks. Solutions for the former do a lot to thwart attacks from the latter, but attack prevention (especially with the form of "just another sandbox") is unlikely to help with the former.

Sure, it's changing, and I use AI a ton. The second I ask it (where "it" is a smattering of all the SOTA models and harnesses) to do something as simple as design a server capable of doing <moderately simple task> when any concurrent data structures are involved and the single-server load is in the 100k QPS range, even with extremely thorough plans of how concurrency needs to be managed, it doesn't matter how little code is actually needed or how easy it would be for my juniors to bang out the problem, especially with a little AI boost, AI just can't keep up by itself yet. It can sometimes spit out something close, but only with major correctness issues.

I'm not trying to be argumentative; You posed an idea, and it looked wrong in an important way, so I added my observations. I'd love if you could share the model/harness/workflow you use that makes you so confident in this tooling, because I don't want to be left behind.

And who can't code its way out of a wet paper bag on hard problems. It's more productive for the day-to-day BS, which is convenient because it creates more day-to-day BS you need to handle, but that isn't the reason I hire a staff engineer.

Whatever we're moving toward, I currently can't let any SOTA model + harness operate on more than ~10k changed SLOC at once, and even then only with very careful prompting I thoroughly understand, only on the simplest of problems, and only if I pause it at key points to correct some sort of nonsense thinking and put in a significant cleanup pass and am still willing to tolerate some bullshit. Tooling is impressive for sure, but it's not magic.

You could even just have straight proportional voting if you wanted, and that's be better than the current system. You got 3 votes? Great, you have a 3/100M chance to win.

*hundreds to thousands of billions

And that mistruth appears in delightfully insidious ways, like seemingly well-meaning comments opening up about "half" the job being lying when the point is to shift the Overton window away from the actual numbers, whatever they might be.

(obviously not serious, but it's fun to probe what we can actually reason about when every message might be adversarial)