Bryan Cantrill

And there isn't some like runtime edge condition I need to consider.

So it's like, eh, go for it.

Uh, so I just be in, in some cases, like it's going to be, you know, depending on the context, you know, I think that, uh,

And I think that may be true in many JavaScript contexts, and that's why in the cases where people are writing front-end code and they have additional rigor they want to apply, they're using TypeScript or more robust languages.

Yeah.

I think you're right that, you know, the reason why I don't care about the quality of my blog is, like,

Yeah, that's not a foundation on which I'm going to build decades worth of technical innovation.

That's like one and done.

And I think there's lots of software that kind of fits that model.

And I think that's where you kind of get the slopware pejorative term.

But for some of this code, it's sort of fine.

If you're building something that is a one-off, it is associated with some...

time and place and whatever, fine, like whatever, I don't know.

And yeah, there's going to be a lot more of it and that's frustrating.

But on the other hand, for the stuff that is foundational, that has always been rigorous and the rigor is increasing, this becomes a lever by which the rigor continues to increase.

Yeah.

But is that, is that always been the case for the kinds of code that we care about rain that like,

Uh, you know, one of the things that's beautiful about oxide is we go to a demo day where, you know, we show off, you know, rain, you show off this 30,000 line change or whatever, or I show off like this library that compares one thing to another thing.

And it's like, people are hooting and hollering as opposed to, um, you know, systems demos are traditionally seen as boring.

And the thing that's whizzy is when, you know, you can demo something cool and graphical and whatever.