Live data from Hacker News

What can you confidently guarantee about your software?

queue.acm.org

61–70 of 71 posts

Re: What can you confidently guarantee about your software?

#61
post #45

Earlier quoted context omitted.

> I would think the cost multiplier in those cases is much lower for an LLM as compared to a human that doesn't have an inherit understanding and needs to give it thought. Wouldn't you? No. I don't see why proving would require less relative effort for an LLM. In fact, years ago, long before LLMs, I wrote about why it is relatively easy to write sort-of-correct software yet hard to write provably correct software, an…

Every time you compile a statically-typed programming language you are using formal verification, so we have all kinds of industrial scale examples. The reports suggest that outputting tokens for these languages is as easy for LLMs as Javascript. And actually, I would suggest that the reports indicate that LLMs find it easier to output tokens for those languages than Javascript. LLMs are laughably bad at writing Java…

> Every time you compile a statically-typed programming language you are using formal verification

Yeah, this is not what we're talking about here. We're talking about proving properties with deep alternative quantifiers.

> That isn't just hard. Proving software correct in complete generally is impossible. There are all kinds of practical and fundamental constraints that leave it to be impossible. Verification is only useful when you are acting within the scope of a compressed specification of a system's behaviour.

Nobody said anything about complete generality. We're talking about the practice of applying formal methods. It's not writing in Rust, and it's not a general program verifier, but a practice that's applied in some parts of the industry and not others, as the article says.

Put another way, the question is: for those programs and those properties that humans are able to prove with proof assistants, how expensive is it for LLMs to do that work.

Re: What can you confidently guarantee about your software?

#62

Earlier quoted context omitted.

> It's already useful for many software platforms. It's useful for databases, where reliability is essential. It's useful for parsers, particularly when you expect the end user to be attempting to send you hostile code. > But e-commerce apps? So the e-commerce app doesn't use a DB? And the e-commerce app receives zero user input that needs to be parser so doesn't use any parser either? If you say its useful for, for…

Read carefully. There's a big difference between developing a database and developing an app that uses a database. If you're developing a database, you should use property-based tests to ensure that your database behaves as expected (ACID reliability, etc.). If you can formally verify parts of your database, you won't have to fuzz it, because it will have been proven correct. But if you're developing a CRUD app that…

> But if you're developing a CRUD app that uses a database, there may be no properties of your app at all that are worth fuzzing.

Surely we have seen enough SQL injection issues over the years to know that, where "uses a database" means using SQL, fuzzing (or formal verification) is a necessity? That only scratches the surface of where fuzzing and property-based testing can be applicable to CRUD apps.

> Effect-free logic is likely to be ~1% of your code base, or less.

Excellent news. Side effects are where property-based testing finds its maximum return on investment. Mutations in any kind of complex system are especially hard to reason about and are easy to get wrong. Property-based testing is great at uncovering the edge cases you failed to consider.

> This is why we keep talking past each other

You keep talking past each other because "CRUD app" or "e-commerce app" is too nebulous. Concretely define exactly what this CRUD app is and then we can all meaningfully zero in on where property-based testing and fuzzing may or may not be useful. As long as you leave everyone to imagine what their own pet CRUD app looks like, you will never find a a shared understanding in which to discuss it.

Re: What can you confidently guarantee about your software?

#64
post #25

Earlier quoted context omitted.

Nitpick: You don't necessarily need any specification at all in order to reap benefits. Formal verification languages come with a lot of conditions that your program must fulfill in order to be accepted: Every loop terminates, every object you want to read/write is non-null, every list or array access is in bounds, etc. For example, if you load an arbitrary C program into Frama-C, you'll have tons of properties to pr…

> "No crashes/panics/uncaught exceptions" should be worth it. Surprisingly, no. Property-based testing and formal validation make it easy to spend tons of time and money "preventing" bugs that would never have occurred in production, especially uncaught exceptions. There is code where strong guarantees can be worth it, (databases, platforms/operating systems, parsers accepting hostile input) but it's not most applica…

One problem with the "won't happen in production" argument is that humans are demonstrably bad at predicting "won't happen in production" situations.

Re: What can you confidently guarantee about your software?

#67

Earlier quoted context omitted.

If you are willing to relax the restrictions, and you probably should, model checking is probably worth its weight in gold for these scenarios. You won’t get proofs but you will spell out your logic in a formal language[0] and each run of the checker will exhaustively check your invariants[1]. [0] Useful because often you will learn something you hadn’t considered. [1] A proof will guarantee your statements hold over…

I’ve recently started using PBT at work and it has been more than worth it, and I want to try Model checking next.

PBT is great and often good enough.

I use model checking mostly in the design phase of a project.

Some much bigger projects at MS and Amazon use it continuously throughout their process.

Re: What can you confidently guarantee about your software?

#68
post #47
post #6

Earlier quoted context omitted.

So much this. I actually did take a formal verification course in college. Our final project was to use the techniques we'd been learning to verify some classic critical-section locking algorithm. I chose to verify an implementation of Lamport's bakery algorithm[0] in C (this was the 90s -- a lot of code was still being written in C). The problem is that Lamport's algorithm makes an assumption that the "ticket number…

You shouldn't have been able to formally verify the algorithm fails to protect the critical section. Wrapping ticket numbers can lead to starvation (literally, if we follow the baker analogy), but the algorithm protects the critical section so long as thread IDs are unique. The sort of environments in which this is a problem would be extremely uncommon. For a start, you need continuous contention. If you ever get a b…

I'm quite certain I formally verified that two processes were both able to get into the critical section WITH THE ALGORITHM I WAS VERIFYING, but this was 35 years ago, so details are fuzzy.

Remember that this is long before Wikipedia and even before Google, so I have no idea where I'd have gotten the alleged Baker's algorithm from.

Also you're right that this isn't much of an issue in practice, but that's not what formal verification is about, now is it? :)

Post reply on HN