Building better software through mathematics (And no, I don't mean formal verification) Greg Brockman Stripe CTO // @thegdb

Mathematical problem-solving techniques are dual to software engineering techniques. ! Proof by example to follow.

Mathematical low road Define “determinant” as a formula of various pieces of a matrix. ! Use symbolic manipulation to prove a bunch of interesting properties. ! It’s exhausting, but it works.

Translated to engineering… Just bang code into your editor. ! Easy to produce but hard to maintain or extend. ! This is what programming is for many people.

Translated to code… my_hand = ["2C", "2D", ...].shuffle your_hand = ... ! while true my_card = my_hand.shift your_card = your_hand.shift ! compare = compare_cards(my_card, your_card) if compare > 0 ...

Mathematical middle road Define “determinant” as a function with a few specific properties. ! Oh hey, it’s easy to show existence and uniqueness. Use these properties to easily derive a formula. ! It’s a clever way to solve the problem at hand.

Translated to engineering… Decompose your program into modules. ! The implementation of those modules should follow naturally from their interface. ! If it’s hard to implement any one piece, you haven’t decomposed enough.

Translated to code… class Card; ...; end class Hand; ...; end ! class War def initialize @my_hand = Hand.new @your_hand = Hand.new end ! def start my_card = @my_hand.draw your_card = @your_hand.draw if my_card.beats(your_card) ...

Mathematical high road Build the theory of exterior product space. Determinant is a special case of this general theory. ! All our desired properties are obvious. ! This is the “Ender’s Game” approach to problem solving.

Translated to engineering… Break a system into fundamental units, and design very general abstractions around them. ! This is really, really hard. ! When you get it right, everything else becomes easy. When you get it wrong, you never ship.

Translated to code… class War < AbstractCardGame players 2 loss_condition {my_hand.length == 0} victory_condition {your_hand.length == 0} on_win “add_card_to_deck” end

Mathematics is just software with a more expressive, more performant programming language.

Software does have its advantages though…

Mathematics: Software engineering:

Can we apply learnings from mathematics (which has had thousands of years to mature) to build better software?

Yes. (Ok, it’s not really fair to answer my own rhetorical questions.)

Elegance through least action Mathematical elegance comes from a stubborn unwillingness to do unnecessary work — refusing to accept anything but the simplest, most compact solution. ! In software, choose the design that requires to unnecessary work for your user. Example:

Understand how your abstractions are implemented To use a theorem, you need to understand its proof. ! In software, if you don’t understand how the abstractions you use are built, you won’t understand the resulting system.

Design software down but build software up The concept of “brute force” as a shortcut is well-understood in math. You’ll generally brute force by hand. ! In software, your CPU can instead do the brute force. Take advantage of this to get software built faster.

Greg Brockman Stripe CTO // @thegdb