00:00:02

Alright, uh, 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 wrote, I learned a language called closure and it changed my life. It was probably one of most difficult things I've learned professionally, but has also been one of the most rewarding. It brought the joy 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 in, by me has been my experience for nearly 30 years. Other famous French philosopher, cloud levy Strauss would save certain tools. Is it good to think with, and for reasons that I will try to explain the next five minutes, I believe functional programming and things like immutability are truly better tools to think with and has really taught me how to vent myself from constantly sabotaging my code, which I've been doing for decades.

00:00:55

Uh, I'm going to make the astonishing claim that these things have eliminate 90% of the errors I used to make. So, uh, 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, uh, most mainstream languages, uh, supported, only passing things by value. Um, so which meant that if you pass the variable to a function and you changed it within the function, um, you know, you would only change your local copy. So often this means that you'd have to return the new state. And if it was just, if this was a structure or a large object means you would have to do a lot of copying and pasting, this is tedious error prone and very time-consuming.

00:01:42

I often find myself complaining about this, uh, wishing there were a better way, and it turns out to, you could do this by, uh, eliminate this by using pointers, but actually pointers are now considered so dangerous few languages besides C, C plus plus, and assembly, even let you do it because it is that dangerous. In 1995, I got introduced to a huge innovation programming languages that was called passing values by reference to showed up in Cecil plus Java modular three, uh, which allowed you to change the value that was passed you as a parameter. Uh, and it would change, uh, the, the reference that you passed it in from the color. And this seemed really great. I loved it because it's such a time-saver because it lets you write less code. Um, but three years ago I changed my mind. So closure is one of the categories of languages called functional programming, Haskell F sharp.

00:02:30

Uh, they're all part of these, uh, have the same sensibility. They don't let you change. Variables functions need to be pure. Um, 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. Certainly not. Uh, even reading from disk is not allowed because, uh, it's not always the same. And so this is one of the biggest aha moments of a program for me because it taught me how terrifying program passing variables reference should be. Because when you see this, what you should 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.

00:03:16

When anyone can change your internal state, you may have heard of Heisenberg's 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 most difficult problems in distributed systems. I'm fixing my coffee cup and I can't get it to, I can't figure out how to get it to fill up again. Right? So, uh, and I, 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, uh, he wrote castles and Stein, 3d tomb, uh, quake. He wrote, he gave this amazing, uh, keynote at the quake con conference in 2013 saying a large fraction of the flaws in software development are due to programmers, not fully understanding all the possible states or code may execute in an a multithreaded environment.

00:04:01

The lack of understanding and the resulting problems are greatly amplified to the point of panic if you're actually paying attention. Um, and so the point here is that in the real world, it's not just your coffee cup, you're 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, uh, truly taught me. They have a belief that uncontrolled state mutation is that the very limits of what humans can reasonably understand and to be able to test and run in production. And so, uh, programming languages, I pioneered functional programming techniques.

00:04:50

This has Haskell OCaml closure, Scala, Erline elemental elixir of reason. And Mel, uh, 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? If you can't change containers, uh, you know, if you really want to make a change at persists, you have to make a new container. Uh, Kubernetes uses this concept, not in the small, but in the large for systems of systems. Uh, if you see Apache Kafka, chances are they're using it for an immutable data model, uh, 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. Um, and so just, uh, talking with, so I'm going to introduce the next speaker, which is Scott havens. Um, and we were, as we were talking for the slide, he said, everyone knows now, as a doctor, doctor said, his go-to statements are considered harmful to program flow.

00:05:42

And it is, uh, he said that it is without a doubt that uncontrolled state mutation will surely within our generation be considered the next go-to. Uh, 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@jet.com and Walmart labs, his remit was to rebuild 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 power 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's now senior director, head of supply chain technologies at Moda operandi and 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 the program, but can be applied at the most vast scales, such as Walmart enterprise with that Scott havens.