Gene Kim

All right. To motivate the next talk, I want to tell you just a little bit about something that has influenced me a lot.

About three years ago, I learned a language called Clojure, and it changed my life. It was probably one of the most difficult things I've learned professionally, but it's also been one of the most rewarding. It brought the joy of programming back into my life. For the first time in my career, as I'm nearing 50 years old, I'm finally able to write programs that do what I want them to do, and I'm able to build upon them for years without them falling over like a house of cards, as has been my experience for nearly 30 years.

The famous French philosopher Claude Levi-Strauss would say of certain tools, "Is it good to think with?" And for reasons that I will try to explain in the next five minutes, I believe functional programming and things like immutability are truly better tools to think with, and it has really taught me how to prevent myself from constantly sabotaging my code, which I have been doing for decades.

I'm going to make the astonishing claim that these things have eliminated 90% of the errors I used to make. So I'm going to try to motivate why.

So about a year ago, I found this amazing graphic on Twitter that describes the difference between passing variables by value versus passing variables by reference.

So when I was in graduate school in 1993, most mainstream languages supported only passing things by value, which meant that if you passed a variable to a function and you changed it within the function, you would only change your local copy.

So often this means that you would have to return the new state, and if this was a structure or a large object, it means you would have to do a lot of copying and pasting. This is tedious, error-prone, and very time-consuming. I often found myself complaining about this, wishing there were a better way. And it turns out you could eliminate this by using pointers.

But actually, pointers are now considered so dangerous, few languages besides C, C++, and Assembly even let you do it because it is that dangerous.

In 1995, I got introduced to a huge innovation in programming languages that was called passing values by reference. This showed up in C++, Java, Modula-3, which allowed you to change the value that was passed to you as a parameter, and it would change the reference that you passed it in from the caller. And this seemed really great. I loved it because it was such a time saver, because it lets you write less code.

But three years ago, I changed my mind.

So Clojure is one of a category of languages called functional programming. Haskell, F#, they're all part of these, have the same sensibility. They don't let you change variables. Functions need to be pure.

The functions always return the same output given the same inputs, and there are never any side effects. You're not allowed to change the world around you. Now, you're not allowed to read or write from disk. Even reading from disk is not allowed because it's not always the same.

And so this is one of the biggest aha moments of programming for me, because it taught me how terrifying passing variables by reference should be. Because when you see this, what you really should be seeing is this. It's like, why is my coffee cup changing? Who is messing with my coffee cup, and how do I make them stop?

The point here is that it's very difficult to understand your code and to reason about what is happening when anyone can change your internal state. You may have heard of Heisenbugs, where even the mere act of observation changes the result. And these are the hallmarks of multithreading errors, which is considered to be one of the most difficult problems in distributed systems.

I'm fixing my coffee cup, and I can't figure out how to get it to fill up again, right? And because I need to replicate the problem.

So in the real world, uncontrolled mutation makes things extraordinarily difficult to reason about, because other people can put anything they want in your coffee cup. John Carmack, he wrote Wolfenstein 3D, Doom, Quake. He gave this amazing keynote at the QuakeCon conference in 2013 saying, "A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified to the point of panic if you're actually paying attention."

And so the point here is that in the real world, it's not just your coffee cup. You are operating in a universe of coffee cups, and if you zoom out, there are many, many more coffee cups around that. And if anyone can change your state because they have a reference to it, it becomes almost impossible to reason about.

Under these conditions, it's almost impossible to understand what is actually happening and how to make things truly deterministic. And this is one of the beliefs that functional programming truly taught me: they have a belief that uncontrolled state mutation is at the very limits of what humans can reasonably understand and to be able to test and run in production.

And so programming languages that pioneered functional programming techniques like this are Haskell, OCaml, Clojure, Scala, Erlang, Elm, Agda, ReasonML, is becoming increasingly popular.

And what I find so exciting is that these concepts are now showing up in infrastructure as well. Docker is immutable, right? You can't change containers. If you really want to make a change that persists, you have to make a new container.

Kubernetes uses this concept not in the small, but in the large for systems of systems. If you see Apache Kafka, chances are they're using it for an immutable data model that says you're not allowed to rewrite the past. It turns out version control is immutable, right? You get yelled at if you actually rewrite history.

So I'm going to introduce the next speaker, which is Scott Havens. And as we were talking for this slide, he said, everyone knows now, as Dr. Dijkstra said, go-to statements are considered harmful to program flow. And he said that it is without a doubt that uncontrolled state mutation will surely, within our generation, be considered the next go-to.

So one is for code, one is for data.

So the next speaker is Scott Havens. Until very recently, he was Director of Software Engineering at Jet.com and Walmart Labs. His remit was to rebuild the entire inventory management systems at Walmart, the world's largest company. He earned this right by the amazing work he did building the incredible systems that powered Jet.com, a company that Walmart then acquired. It powered the inventory management systems, order management, transportation, available to promise, available to ship, and tons of other critical processes that must all operate correctly to compete effectively as an online retailer.

He is now Senior Director, Head of Supply Chain Technologies at Moda Operandi, an upscale fashion retailer. And I hope what he presents will blow your mind as it blew my mind, showing that functional programming principles apply not just in the small in a program, but can be applied at the most vast scales, such as Walmart Enterprise. With that, Scott Havens.

Supersonic.