7 ms·

"proving code correct has been a research topic at some point." It has been an area of active research for 40 years. But almost all the research returned the

"proving code correct has been a research topic at some point." It has been an area of active research for 40 years. But almost all the research returned the null result, meaning that the program proving didn't improve code quality (basically it didn't work). Yet somehow a group of programmers, usually fresh out of academia falls for program proving each generation. Strong types do really help but you need a good compiler which is sometimes lacking in the real work cough Scala cough. The problem with strong types and program proving is that the juice just isn't worth the squeeze meaning the extra time taken doesn't result in reduced debugging time or improved code quality. I don't think that changes with LLMs. It just exposes the flaws more quickly.

em-bee 3mo ago
what i expect to change with LLMs is the benefit you get from automated testing. which is really what LLMs need. tools that tell you something is wrong may not speed up a human developer, but they will allow LLMs to make corrections by itself until the warnings go away. so while it may not be worth it to a human developer, it may well be worth it for an LLM.
pmontra 3mo ago
The issue with formal proofs is that we might end up with correct code that does the wrong thing. I mean, something that the market doesn't care about. At the same time a buggy set of PHP scripts does what people care about and captures the market. Think about 20+ years ago and you find a lot of examples.
- psd1 3mo ago
  https://xkcd.com/224/ https://xkcd.com/224/ lol Zuckerberg became rich on php, which grinds my gears almost as much as the genocide thing. In fairness, my peers at $corp used to ship while I was sad-Wojciech "no you can't create tech debt". The universe is cruel to people who care.
  - martl475 3mo ago
    Friend of mine said "Infuriatingly many people got rich with horribly bad software." (Sounds better in German)
  - lancepioch 3mo ago
    If that grinds your gears, then also take a look at Pieter Levels
  - landdate 3mo ago
    php is a great language. there is a reason why the majority of the web runs on it.
    - psd1 3mo ago
      There's a reason why littering is the most common crime - it doesn't require intelligence or planning, and whatever you are holding can instantly become trash.
      - em-bee 3mo ago
        that's a bit harsh.
        psd1 3mo ago
        Php does not distinguish between arrays and hashmaps, which means that an empty dict serialises to json as `[ ]`. You can configure it to serialise to `{ }` instead, but that's a global setting. No, i don't think I'm being harsh.
      - landdate 3mo ago
        if you were to ask people to rate crimes on morality i would presume littering would rank among the least immoral. your point makes no sense. yes, if i had to pick one crime for someone to commit i might pick littering and many people think the same thing because littering is one of the most common crimes. same thing is true for web development with php. you absolute moron you don't even understand what you are saying just making random points that have a midwit cleverness, but when thought over by any respectable mind easily prove to be nonsense. ---- how could somebody like you think they deserve life enough to conjure up a breath let alone a word. It's a shame, and one you are too ignorant be aware of.
- frumplestlatz 3mo ago
  Well, sure — and the issue with tests is we might end up with well-tested code that does the wrong thing.
frumplestlatz 3mo ago
That's literally the opposite of reality; the research and adoption have consistently produced code of extremely high quality, at great cost. The problem has always been: - It's extremely labour-intensive, and even small changes to the code can require an enormous amount of new proof work. - The skills required to formally verify software are very different from the skills required to write it, and the set of people capable of doing so is much smaller. - Code has to be written with verification in mind, against a specification that expresses invariants that can actually be verified, and that is coherent enough that you can derive useful high-level properties of the system from it. You needed two teams — verification and development. Verification would always be behind the development team, while also having to feed requirements and design changes back to the developers. Everything slowed to a crawl. AI changes this. A coherent, verifiable, useful specification isn't easy to write — but it's far easier to write than the software itself, and AI can do most of that work: both drafting the spec and proving that it's consistent and that the high-level properties you actually care about follow from it. More importantly, a high-level spec is far easier to read and reason about than the reams of code required to actually implement something. Which means: - AI does the grunt work of writing and proving the spec; humans only have to carefully review that high-level artifact. - AI writes code it must also prove conforms to the spec, so humans can be assured it's correct without babysitting the AI. - Changes are driven top-down: evolve the spec first, then have the AI fix the implementation and re-prove conformance. Our (very, very large) company is rapidly going all-in on formal verification across projects we never would have dreamed of verifying before; the velocity hit and the man-hour cost were only worth paying for truly critical infrastructure.
- doug_durham 3mo ago
  I’m sure in certain domains this makes sense. However, English is a poor language for doing reasoning in. More and more I’m relying on the code itself as the documentation. One of the superpowers of LLMs is reading code. and turning it into readable English. I don’t keep the English prose around. I delete it. In your example, I don’t see having two sets of artifacts. I see working with an LLM to generate a code base, which is the specification. You still need to have sets of requirements that list the invariants and other parameters. But the process becomes generating the code, and then having the LLM read the code to see if it meets the requirements and invariants.
GregDavidson 3mo ago
I've been successfully practicing programming with proof of correctness since the 1970s. The confusion I see with most people failing at this is that they're trying to write code first and then prove it correct. The idea promoted by Dijkstra, Hoare, et al is to write the code and the proof together, with each of these aspects of the task supporting the other. The result is (in my experience) a better program developed as quickly (even when not counting on vastly decreased debugging time) as pure coding. Similarly with strong lexical typing: One does not try to create a typing model for a hunk of arbitrary code. Instead, one develops the type model along with the code, with each of those aspects supporting the other. Putting it all together: Coding, Typing (and other Constraining) and Proving are done together, with each of these activities supporting the others. It does take time to learn such a methodology. And it takes extra understanding to maintain types, constraints and proofs as the program evolves, i.e. "maintenance".
- hollerith 3mo ago
  Can you show us a proof of correctness you've written?

em-bee 3mo ago

what i expect to change with LLMs is the benefit you get from automated testing. which is really what LLMs need. tools that tell you something is wrong may not speed up a human developer, but they will allow LLMs to make corrections by itself until the warnings go away. so while it may not be worth it to a human developer, it may well be worth it for an LLM.

pmontra 3mo ago

The issue with formal proofs is that we might end up with correct code that does the wrong thing. I mean, something that the market doesn't care about. At the same time a buggy set of PHP scripts does what people care about and captures the market. Think about 20+ years ago and you find a lot of examples.

psd1 3mo ago
https://xkcd.com/224/ https://xkcd.com/224/ lol Zuckerberg became rich on php, which grinds my gears almost as much as the genocide thing. In fairness, my peers at $corp used to ship while I was sad-Wojciech "no you can't create tech debt". The universe is cruel to people who care.
- martl475 3mo ago
  Friend of mine said "Infuriatingly many people got rich with horribly bad software." (Sounds better in German)
- lancepioch 3mo ago
  If that grinds your gears, then also take a look at Pieter Levels
- landdate 3mo ago
  php is a great language. there is a reason why the majority of the web runs on it.
  - psd1 3mo ago
    There's a reason why littering is the most common crime - it doesn't require intelligence or planning, and whatever you are holding can instantly become trash.
    - em-bee 3mo ago
      that's a bit harsh.
      - psd1 3mo ago
        Php does not distinguish between arrays and hashmaps, which means that an empty dict serialises to json as `[ ]`. You can configure it to serialise to `{ }` instead, but that's a global setting. No, i don't think I'm being harsh.
    - landdate 3mo ago
      if you were to ask people to rate crimes on morality i would presume littering would rank among the least immoral. your point makes no sense. yes, if i had to pick one crime for someone to commit i might pick littering and many people think the same thing because littering is one of the most common crimes. same thing is true for web development with php. you absolute moron you don't even understand what you are saying just making random points that have a midwit cleverness, but when thought over by any respectable mind easily prove to be nonsense. ---- how could somebody like you think they deserve life enough to conjure up a breath let alone a word. It's a shame, and one you are too ignorant be aware of.
frumplestlatz 3mo ago
Well, sure — and the issue with tests is we might end up with well-tested code that does the wrong thing.

frumplestlatz 3mo ago

That's literally the opposite of reality; the research and adoption have consistently produced code of extremely high quality, at great cost. The problem has always been: - It's extremely labour-intensive, and even small changes to the code can require an enormous amount of new proof work. - The skills required to formally verify software are very different from the skills required to write it, and the set of people capable of doing so is much smaller. - Code has to be written with verification in mind, against a specification that expresses invariants that can actually be verified, and that is coherent enough that you can derive useful high-level properties of the system from it. You needed two teams — verification and development. Verification would always be behind the development team, while also having to feed requirements and design changes back to the developers. Everything slowed to a crawl. AI changes this. A coherent, verifiable, useful specification isn't easy to write — but it's far easier to write than the software itself, and AI can do most of that work: both drafting the spec and proving that it's consistent and that the high-level properties you actually care about follow from it. More importantly, a high-level spec is far easier to read and reason about than the reams of code required to actually implement something. Which means: - AI does the grunt work of writing and proving the spec; humans only have to carefully review that high-level artifact. - AI writes code it must also prove conforms to the spec, so humans can be assured it's correct without babysitting the AI. - Changes are driven top-down: evolve the spec first, then have the AI fix the implementation and re-prove conformance. Our (very, very large) company is rapidly going all-in on formal verification across projects we never would have dreamed of verifying before; the velocity hit and the man-hour cost were only worth paying for truly critical infrastructure.

doug_durham 3mo ago
I’m sure in certain domains this makes sense. However, English is a poor language for doing reasoning in. More and more I’m relying on the code itself as the documentation. One of the superpowers of LLMs is reading code. and turning it into readable English. I don’t keep the English prose around. I delete it. In your example, I don’t see having two sets of artifacts. I see working with an LLM to generate a code base, which is the specification. You still need to have sets of requirements that list the invariants and other parameters. But the process becomes generating the code, and then having the LLM read the code to see if it meets the requirements and invariants.

GregDavidson 3mo ago

I've been successfully practicing programming with proof of correctness since the 1970s. The confusion I see with most people failing at this is that they're trying to write code first and then prove it correct. The idea promoted by Dijkstra, Hoare, et al is to write the code and the proof together, with each of these aspects of the task supporting the other. The result is (in my experience) a better program developed as quickly (even when not counting on vastly decreased debugging time) as pure coding. Similarly with strong lexical typing: One does not try to create a typing model for a hunk of arbitrary code. Instead, one develops the type model along with the code, with each of those aspects supporting the other. Putting it all together: Coding, Typing (and other Constraining) and Proving are done together, with each of these activities supporting the others. It does take time to learn such a methodology. And it takes extra understanding to maintain types, constraints and proofs as the program evolves, i.e. "maintenance".

hollerith 3mo ago
Can you show us a proof of correctness you've written?