https://www.hillelwayne.com/tags/formal-methods/ Recent content in Formal Methods on Hillel Wayne Hugo -- gohugo.io en-us Mon, 17 Jun 2024 00:00:00 +0000 https://www.hillelwayne.com/post/composing-tla/ Mon, 17 Jun 2024 00:00:00 +0000 https://www.hillelwayne.com/post/composing-tla/ Last year a client asked me to solve a problem: they wanted to be able to compose two large TLA+ specs as part of a larger system. Normally you’re not supposed to do this and instead write one large spec with both systems hardcoded in, but these specs were enormous and had many internal invariants of their own. They needed a way to develop the two specs independently and then integrate them with minimal overhead. https://www.hillelwayne.com/post/alloy-facts/ Wed, 10 Apr 2024 00:00:00 +0000 https://www.hillelwayne.com/post/alloy-facts/ I’ve recently done a lot of work in Alloy and it’s got me thinking about a common specification pitfall. Everything in the main post applies to all formal specifications, everything in dropdowns is for experienced Alloy users. Consider a simple model of a dependency tree. We have a set of top-level dependencies for our program, which have their own dependencies, etc. We can model it this way in Alloy: https://www.hillelwayne.com/post/world-vs-machine/ Thu, 04 Jan 2024 00:00:00 +0000 https://www.hillelwayne.com/post/world-vs-machine/ This is just a way of thinking about formal specification that I find really useful. The terms originally come from Michael Jackson’s Software Requirements and Specifications. In specification, the machine is the part of the system you have direct control over and the world is all the parts that you don’t. Take a simple transfer spec: ---- MODULE transfer ---- EXTENDS TLC, Integers CONSTANTS People, Money, NumTransfers (* --algorithm transfer variables acct \in [People -> Money]; define \* Invariant NoOverdrafts == \A p \in People: acct[p] >= 0 end define; process cheque \in 1. https://www.hillelwayne.com/post/lpl/ Wed, 16 Nov 2022 00:00:00 +0000 https://www.hillelwayne.com/post/lpl/ img {border-style: groove;} Someone recently told me a project isn’t real until you do a retrospective, so I think it’s time to do one for Let’s Prove Leftpad. Short explanation: it’s a repository of proofs of leftpad, in different proof systems. Long explanation: the rest of this post. Background I’m into formal methods, the discipline of proving software correct. Consider the following contrived code: def add(x: int, y: int): int { if(x == 12976 && y == 14867) { return x - y; } return x + y; } This typechecks, and any black-box unit test would find that add(x, y) == x + y. https://www.hillelwayne.com/post/safety-and-liveness/ Tue, 06 Sep 2022 00:00:00 +0000 https://www.hillelwayne.com/post/safety-and-liveness/ img {border-style: groove; border-width: 1px; padding: 5px; } Sounds like I should write a post on safety and liveness! First, some definitions. A system is anything that has changing state. This is an incredibly broad definition that covers a wide variety of situations, like: Two threads in a thread scheduler Five servers behind a load balancer A reader and writer communicating on a FIFO queue A business workflow being manually followed A person waiting for the bus Etc. https://www.hillelwayne.com/post/refinement/ Tue, 13 Jul 2021 00:00:00 +0000 https://www.hillelwayne.com/post/refinement/ When teaching formal methods, I often get asked how we can connect the specifications we write to the code we produce. One way we do this is with refinement. All examples are in TLA+.1 Imagine we’re designing a multithreaded counter. We don’t know how we’re going to implement it yet, so we start by specifying the abstract behavior.2 ---- MODULE abstract ---- EXTENDS Integers, Sequences VARIABLES pc, counter vars == <<pc, counter>> \* Two threads Threads == 1. https://www.hillelwayne.com/post/spec-composition/ Sun, 18 Apr 2021 00:00:00 +0000 https://www.hillelwayne.com/post/spec-composition/ Recently my friend Lars Hupel and I had a discussion on why formal methods don’t compose well. You can read the conversation here. We focused mostly on composing formally-verified code. I want to talk a little more about the difficulties in composing specifications. This is half because it’s difficult for interesting reasons and half because it’s a common question from beginners. Beginners to formal specification expect specifications should be organized like programs: multiple independent modules that interact through public interfaces, where the modules don’t know about each others’ private implementations. https://www.hillelwayne.com/post/action-properties/ Thu, 25 Feb 2021 00:00:00 +0000 https://www.hillelwayne.com/post/action-properties/ There’s not a whole lot on TLA+ technique out there: all the resources are either introductions or case studies. Good for people starting out, bad for people past that. I think we need to write more intermediate-level stuff, what Ben Kuhn calls Blub studies. Here’s an attempt at that. Most TLA+ properties are invariants, properties that must be true for every state in the behavior. If we have a simple counter: https://www.hillelwayne.com/post/queueing-prism/ Mon, 02 Nov 2020 00:00:00 +0000 https://www.hillelwayne.com/post/queueing-prism/ For latency, anyway. A common architecture pattern is the “task queue”: tasks enter an ordered queue, workers pop tasks and process them. This pattern is used everywhere from distributed systems to thread pools. It applies just as well to human systems, like waiting in line at a supermarket or a bank. Task queues are popular because they are simple, easy to understand, and scale well. There are two primary performance metrics for a task queue. https://www.hillelwayne.com/post/flossing/ Wed, 28 Oct 2020 00:00:00 +0000 https://www.hillelwayne.com/post/flossing/ My work brings me though a lot of software correctness techniques, things like type theory, test-driven development (TDD), and formal methods. The surrounding communities all have the same problem: they can’t get people using these techniques. They all ask “Don’t people care about correct software?” To which the insiders usually answer “programmers don’t care about correctness, they just care about shoveling out garbage to make money!” I’ve heard this from every single community I’ve explored, many of which are in direct conflict with each other. https://www.hillelwayne.com/post/tla-golang/ Fri, 25 Sep 2020 00:00:00 +0000 https://www.hillelwayne.com/post/tla-golang/ My job these days is teaching TLA+ and formal methods: specifying designs to find bugs in them. But just knowing the syntax isn’t enough to write specs, and it helps to have examples to draw from. I recently read Chris Siebenmann’s Even in Go, concurrency is still not easy and thought it would make a good case study for writing a spec. In it, he gives an example of Go code which deadlocks: https://www.hillelwayne.com/post/decision-table-patterns/ Wed, 09 Sep 2020 00:00:00 +0000 https://www.hillelwayne.com/post/decision-table-patterns/ Decision tables are easy, simple, and powerful. You can teach them in five minutes and write one in half that time. You can look at a table and understand what it’s saying, see if it matches your problem, and check for design flaws. So it’s kinda weird that there’s basically nothing about them online. I wrote an introduction a while back, but I want something a little more formal. So this post will reintroduce the core ideas in a more formal way and then talk about some of the techniques you can apply to make better tables. https://www.hillelwayne.com/post/fairness/ Fri, 03 Jul 2020 00:00:00 +0000 https://www.hillelwayne.com/post/fairness/ I’m in the process of revising some of my workshops. I realized that one particular important aspect of TLA+, fairness, is something that I’ve struggled to explain well. Then again, everybody struggles to explain it well! It’s also a great example of how messy concurrent systems can get, so I figured it would make a good post for the blog. Stuttering Take the following spec of a clock. I used TLA+ but it should mostly be clear from context: https://www.hillelwayne.com/post/alloydocs/ Mon, 13 Apr 2020 00:00:00 +0000 https://www.hillelwayne.com/post/alloydocs/ tl;dr: online Alloy reference here. If you’ve read this blog at all you probably know I’m a big fan of Alloy. It’s a simple, powerful formal method whose entire syntax fits in just two pages. You can learn it in a day and be productive in two. And it can be used to model everything from package management to database migrations to authorization systems. Two years ago I was invited to the Workshop on the Future of Alloy. https://www.hillelwayne.com/post/feature-interaction/ Wed, 05 Feb 2020 00:00:00 +0000 https://www.hillelwayne.com/post/feature-interaction/ In most testing frameworks, you’re expected to write a lot of low-level tests and few high-level tests. The reasoning is that end-to-end tests are slow and expensive and only cover a tiny amount of the program’s state space. It’s better to focus on testing all the parts in isolation versus testing that they all work together. In practice, global correctness does not follow from local correctness. It’s possible for every part to be individually rock-solid but the system to be broken as a whole. https://www.hillelwayne.com/post/business-case-formal-methods/ Wed, 22 Jan 2020 00:00:00 +0000 https://www.hillelwayne.com/post/business-case-formal-methods/ This is an “intro packet” you can use to argue for the benefits of formal methods (FM) to your boss. It’s a short explanation, a list of benefits and case studies, and a demo. Everything’s in TLA+, but the arguments apply equally well to Alloy, B, statecharts, etc. Adapt the material to your specific needs. Quick notational note: I’m leaving out the code verification side of formal methods, mostly because design verification is a much easier sell. https://www.hillelwayne.com/post/hyperproperties/ Mon, 13 Jan 2020 00:00:00 +0000 https://www.hillelwayne.com/post/hyperproperties/ When we design programs, we usually look for two kinds of properties: that “bad things” never happen and that “good things” are guaranteed to happen. These are called safety and liveness properties, respectively. These are properties that we want to hold true for every possible program behavior. “We always complete every request” is a liveness property. If our system has it, every program trace will complete every request. If it doesn’t hold, I can give you a example behavior where the server never responds. https://www.hillelwayne.com/post/formally-modeling-migrations/ Wed, 09 Oct 2019 00:00:00 +0000 https://www.hillelwayne.com/post/formally-modeling-migrations/ Most of my formal methods examples deal with concurrency, because time is evil and I hate it. While FM is very effective for that, it gives people a limited sense of how flexible these tools are. One of the most common questions I get from people is Formal methods looks really useful for distributed systems, but I’m not making a distributed system. Is FM still useful for me? https://www.hillelwayne.com/post/prism/ Mon, 17 Jun 2019 00:00:00 +0000 https://www.hillelwayne.com/post/prism/ In my job I dig up a lot of obscure techniques. Some of them are broadly useful: formal specification, design-by-contract, etc. These I specialize in. Some of them are useful, but for a smaller group of programmers. That’s stuff like metamorphic testing, theorem proving, constraint solving. These I write articles about. Then there’s the stuff where I have no idea how to make it useful. Either they’re so incredibly specialist or they could be useful if it weren’t for some deep problems. https://www.hillelwayne.com/post/adversaries/ Sun, 05 May 2019 00:00:00 +0000 https://www.hillelwayne.com/post/adversaries/ A common question I get about specs is how to model bad actors. Usually this is one of two contexts: The spec involves several interacting agents sharing a protocol, but some of the nodes are faulty or malicious: they will intentionally try to subvert the system. The spec involves an agent subject to outside forces, like someone can throw a rock at your sensor. These “open world” situations are a great place to use formal methods. https://www.hillelwayne.com/post/using-formal-methods/ Mon, 11 Mar 2019 00:00:00 +0000 https://www.hillelwayne.com/post/using-formal-methods/ A few people have told me that they’ve enjoyed learning formal methods but aren’t sure how to actually use it. They’re mostly doing short sprints at work and aren’t building new systems from scratch. This tells me there’s some confusion about what makes specifications useful, and that we need a resource on applying them in practice. This is a short guide to using specifications at work in a way that’s accessible to beginners, applicable in many contexts, and provides solid business value. https://www.hillelwayne.com/post/why-dont-people-use-formal-methods/ Mon, 21 Jan 2019 00:00:00 +0000 https://www.hillelwayne.com/post/why-dont-people-use-formal-methods/ I saw this question on the Software Engineering Stack Exchange: What are the barriers that prevent widespread adoption of formal methods? The question was closed as opinion-based, and most of the answers were things like “its too expensive!!!” or “website isn’t airplane!!!” These are sorta kinda true but don’t explain very much. I wrote this to provide a larger historical picture of formal methods, why they’re actually so unused, and what we’re doing to make them used. https://www.hillelwayne.com/post/tla-messages/ Wed, 31 Oct 2018 00:00:00 +0000 https://www.hillelwayne.com/post/tla-messages/ I recently did a corporate TLA+ workshop and some people asked what TLA+ specs look like in practice. If you looked at the most common public examples, you’d probably come away thinking that people only used it for critical consensus algorithms. This is a problem for two reasons: first, it makes it harder to learn TLA+, as there aren’t simpler examples to experiment with. Second, it makes it hard for people to see how TLA+ is useful for them. https://www.hillelwayne.com/post/practical-tla/ Thu, 18 Oct 2018 00:00:00 +0000 https://www.hillelwayne.com/post/practical-tla/ I am delighted to announce that my book, Practical TLA+, is now available! When I stumbled into TLA+ in 2016 I had no idea it would so define my passions, my values, and my career. I definitely didn’t think I’d be writing a book. But 11 months and 220 pages later, here we are! This is the largest project I’ve ever done and I’m incredibly excited to share it with you all. https://www.hillelwayne.com/post/augmenting-agile/ Mon, 30 Jul 2018 00:00:00 +0000 https://www.hillelwayne.com/post/augmenting-agile/ I really like the c2 wiki as a historical artifact: a lot of big names in Agile and Extreme Programming argued with each other there.1 One thing they did was the Extreme Programming Challenge, where people tried to test the limits of these approaches. They’d find edge problems (designing databases, remote teams, etc) and see if Agile/XP still worked in that context. In almost every case they quickly decided that yes, it works just fine. https://www.hillelwayne.com/formally-specifying-uis/ Mon, 11 Jun 2018 00:00:00 +0000 https://www.hillelwayne.com/formally-specifying-uis/ Good UI is necessary to making correct software. If people have trouble using the product, they’re more likely to do the wrong thing. Personally, though, I can’t stand UI work. I don’t think it’s “beneath me” or anything, it just doesn’t quite mesh with my brain. Visuals and interfaces give me anxiety. Mad respect for the people who can handle it. I love formal methods. Recently my friend Kevin Lynagh released Sketch. https://www.hillelwayne.com/post/raw-materials/ Sun, 27 May 2018 00:00:00 +0000 https://www.hillelwayne.com/post/raw-materials/ This is an excerpt from Michael Jackson (not the singer)’s book Software Requirements and Specifications, in his discussion of “Raw Materials”. It’s worth letting stand on its own. First, make a list of all the languages you use in all your development activities. Be honest: don’t list all of the languages you have ever heard of; include only languages you have used for real work at least once… Now, ask yourself which of the languages on your list you would choose to say these things, and how easily you could say them: https://www.hillelwayne.com/post/theorem-prover-showdown/ Wed, 25 Apr 2018 00:00:00 +0000 https://www.hillelwayne.com/post/theorem-prover-showdown/ Functional programming and immutability are hot right now. On one hand, this is pretty great as there’s lots of nice things about functional programming. On the other hand, people get a little overzealous and start claiming that imperative code is unnatural or that purity is always preferable to mutation. I think that the appropriate paradigm is heavily dependent on context, but a lot of people speak in universals. I keep hearing that it’s easier to analyze pure functional code than mutable imperative code. https://www.hillelwayne.com/post/nix/ Fri, 16 Mar 2018 00:00:00 +0000 https://www.hillelwayne.com/post/nix/ This post was commissioned by Graham Christensen as part of the Great Slate fundraiser. Thank you! I wanted to help out the Great Slate fundraiser and donated two technical essays of the purchaser’s choice. Graham bought one and asked for Something that has to do with Nix or NixOS This was a bit of a challenge, given that I didn’t even know what Nix was. I had never used it and still haven’t, nor can I use it for the near future, because my only computer right now is a Windows box. https://www.hillelwayne.com/alloy-randomizer/ Mon, 15 Jan 2018 00:00:00 +0000 https://www.hillelwayne.com/alloy-randomizer/ One of my vices is watching Link to the Past Randomizer games. This gist is it’s a regular Zelda game except all of the items in chests are randomized. A chest that normally has bombs might have a critical item, while the chest that’s supposed to have the moon pearl might only have 10 rupees. People use randomizers to run races, since you can’t just memorize the “correct” path through the game. https://www.hillelwayne.com/post/modeling-deployments/ Tue, 30 May 2017 11:48:17 -0500 https://www.hillelwayne.com/post/modeling-deployments/ I’m working on some examples for my TLA+ guide and realized this one would be a good introduction to specification in general, so I simplified it a little to make it more accessible. Enjoy! The problem Deploying code to a set of servers is tricky. You can turn them off, migrate the code, and turn them back on, but that’ll piss off the customers. You could also update them live, but different servers update are different rates and customers could get inconsistent results.