cespare

This defeatism is unhelpful. I'll not simply surrender the country that I love, thanks.

The parent is wondering about parking in the bay, before the robot picks it up.

> We didn't write this parser by hand because, at least pre-AI-coding, parsers were extremely difficult to maintain. Writing one without AI would have taken months [...]

> Instead, we use ANTLR, a state-of-the-art, open source parser generator.

I don't agree with this (pre-AI-coding) take. Hand-rolled parsers are much easier to write well and maintain than people think. They also tend to be much faster and produce much better errors than parser generators. I guess if the language you're trying to parse is, say, C++, then you're going to have a miserable time (probably no matter what). But an SQL parser is very doable. (I say this as the author and maintainer of an in-house SQL dialect thingy at work.)

What makes building and maintaining a hand-written parser such a tractable task is:

- The code size can be large, but you can start with a core of a few well-chosen abstractions and then you add lots of parsing code for various language constructs but it's all kind of orthogonal and doesn't add compounding complexity as you go. - It's just about the most testable kind of code there is. You can cover all the various corner cases with tests and really lock in the behavior so that you can very confidently make changes. One approach I like is to make zillions of tiny test files in the target language accompanied by some golden representation of the AST.

And of course, as the author found out, these properties make writing a parser a really good task for AI coding, too. These tools are very, very good at generating a bunch of new code based on existing abstractions and covering it with lots of test cases.

So I agree with where they ended up, just not where they started :)

I live a couple of blocks away from this Kirkland roundabout and I drive through it very often -- almost every time I go anywhere. Overall, I like it. My average traversal through the roundabout, for just about any source/destination, seems a bit faster than the pre-roundabout infrastructure and much faster than the temporary so-many-stoplights configuration they had for the past year or two.

AFAICT this is not talking about Glasswing stuff. They are saying that they were sent a demonstration of Fable 5 being used/abused in some specific way that led to the "discovery" of some minor, already-known vuln, and that other models can find it too. IOW, they're claiming that the USG's complaint is baseless and dumb.

Skirt too short, in other words?

I'm going to place the blame on the party committing the crimes, not the person exercising free expression.

Personally, I like configuration languages that don't let you "go nuts" in the first place.

It is 1995. You get an unsolicited email with a dubious business offer. Upon reflection, you decide it's not worth consideration and delete it. No need to wonder how it was sent to you; that doesn't need to influence the way you handle it.

No. We need spam filters for this stuff. If it isn't obvious to you yet, it will be soon. (Or else you're one of the spammers.)

I really identify with this way of thinking. One domain where it is especially helpful is writing concurrent code. For example, if you have a data structure that uses a mutex, what are the invariants that you are preserving across the critical sections? Or when you're writing a lock-free algorithm, where a proof seems nearly required to have any hope of being correct.

I guess to me it seems like common sense that a system that has substantially fewer crashes also has substantially fewer deaths. Maybe we can't make definitive statements about the expected number of deaths yet, but I think the most reasonable best guess with the information we have is that waymo deaths will be much lower.

The alternative requires a scenario where waymo is especially likely to get into fatal accidents while being very good at avoiding non-fatal ones, right? Seems far-fetched.