Separating behavior and mutations is a counter-intuitive, old, and powerful way to structure software where verification is as easy as possible for humans.

Behavior of software is the observable properties we care about in a system. When I click this button, it shows me a notification. When I send a payment, the warehouse fulfills the order unless the payment isn’t successful. Mutations are what happens as a result of software exhibiting behavior. Light enters your eyes after the notification pops up. You are given an ice cream cone paid for by the salary you received after the business received money from a customers’ order (ah, the complexities of modern finance). The warehouse pulls a pallet off a rack, packs an order, and puts it into the mail to ultimately reach a customer. Mutations are the thing we care about, but software only captures behavior. Mutations are simple, concrete, and easy for people to understand. Behavior in complicated software is often completely unintelligible or, at best, requires a small army of super smart people to make sense of what it’s currently doing and how to make it do new behaviors without causing undesirable mutations. Separation of behavior and mutations is counter-intuitive. Once you start structuring software this way, understanding, trust, and confidence naturally follow. This is more important now than it ever was before, because ordinary people who don’t have strong coding skills are building more software for smaller groups of users.

Mutation/Behavior Separation is also an old idea. The real name for a construct which separates mutations and behavior in computation is a monad. Use this term if you want to scare normal people away as fast as possible. Oh, crap, did I only hold back on the FP bro language until paragraph 3? Anyway, I only say this because new things are scary and Mutz is for skeptics by skeptics. If functor sounds like language whose suitability in a work setting isn’t immediately clear to you, that’s fine. Mutz isn’t intended for functional programming superfans. However, it recycles good, old ideas, clear, and well-documented ideas from the functional programming world. We do this confident that we’re armed with the knowledge around why these ideas haven’t taken the programming world by storm thus far, and why it might in this AI coding area.

Last but not least, Mutation/Behavior Separation is a powerful way to structure software to maximize the ease of verifiability for humans. This is because behavior can be exercised without mutations. You can write a program which reads, writes, and searches files; and then you can try out that program with fake mutations and zero risk. You can create, save, and continuously check that scenarios play out the same way over time. Once programs get complicated, you can make very sweeping declarations about the properties of that complex system. For example, consider a web app which has users and user-data. The app stores user-data in a folder for each user. A property of this system is that when processing a request for user X, the app will never read or write to the user-data folder for any user other than user X. Property adherence can then be assessed across all the scenarios you have.