 Yeah, so what we're gonna talk about is kind of how to discuss static and dynamic languages, how to convince people, your coworkers or your friends, why you should use a functional language, why you should use, you know, Haskell or Clojure or whatever, and how to do this in a way. And this is really kind of drawing on my experiences of working at a company that was exclusively a Java and C shop and bringing in eventually, growing up to the point where now we have a large Clojure development team, and later on brought in Scala. And so, you know, so this is sort of how, based on my experiences of doing that and kind of how to communicate this in a way that doesn't turn people against you very quickly. So before we get started, I want to tell you a little about who I am. My first kind of real work with functional languages came about four years ago when I started working on a project called Piplin, which was a way to compile Clojure to FPGAs. Now, Clojure, or sorry, FPGAs are sort of a type of, I like to think of them as silicon stem cells because what they allow you to do is it's like a chip that if you want it to be a CPU, then you can make it a CPU. And if you want it to be a GPU, then you can just program it and it's a GPU now. Or if you want it to do something weird and custom, maybe custom network processor, then that's also possible. And so I thought these were really cool, but I didn't like the languages that you programmed them in and I was like, man, it'd be really cool if I could use like a functional language and like have types to verify it anyway. So more recently, what I've been doing is kind of leading the efforts at Two Sigma to sort of rebuild our compute infrastructure. Two Sigma is a quantitative finance company in New York. And so in doing this, it's been a lot of Clojure and a lot of Mesos. Also we're hiring, if you want to talk to me afterwards. And so this is what I've been doing more recently professionally. But what I really enjoy doing for fun is like it's a cold night because I live in New York, it's always cold there. And so you just go to the couch, get a nice glass of scotch, maybe a paper on distributed consensus, maybe Paxos or viewstamped replication, and just read it. That's pretty fun. So I want to kind of set the tone. This talk, it's about how to choose a programming language, both for you to make that decision, but even more importantly, it's how you can discuss that choice of programming language with others. And it's about how types affect that choice. Now, finally, I'd like to outrage you all equally today. So be prepared, this is going to hurt cuz it always does. So first, let's talk about when to use a dynamic language. So who's visited a website today? All right, so I don't actually think this is really worth discussing that much because JavaScript was the correct language to use in all cases. Like it's on our phones, it's on our computers. That's it, we're done. All right, now maybe not. So let's talk about JSON. Now, JSON is, I'm sort of gonna use it as a stand in or a proxy for dynamic languages and JavaScript in particular because I don't really want to go into the function part of it, but really kind of just stick to the data side of it. And what JSON is, it's the greatest data interchange format. It's so much better than CSV or then a binary file that doesn't have any type or information on how to decode it. It's a lot better than Word docs, I don't know. Now, you might argue, hey, look, David, JSON, it's not the greatest. How can you say it's the greatest? Well, no good talk, no talk is complete without a dictionary definition. So the key is, what does it mean to be great? It's eminence, maybe less so quality in JSON's case. But look, JSON's great, right? It's well specified. For instance, when we have a JSON thing, we say look, we want to iterate over our JSON object. Well, of course, this is a map and so maps don't care about the order of keys in them, right? It doesn't matter what order I added elements to my map. No, it does, sometimes, unless you're in a functional language in which it doesn't. In which case you're gonna have a lot of trouble being compatible with other languages, okay. So maybe JSON's not really well specified, but it's got a rich representation. I mean, we remember before JSON when we wanted to send data and you get some unstructured text, you try to parse it, you hope for the best, JSON's got maps, it's got lists, it's got numbers and strings, that's pretty crazy. I mean, we can express anything, we can express some things and other things we can kind of have very inconsistent, like dates, you know? I mean, there's only four ways to specify dates in JSON, if you're on .NET. At the time, this question was asked, so, but you know, look, so maybe it's not, I mean, it's rich, but it's not maybe rich in the absolute sense, but look, at least it's really efficient. Surely we wouldn't be using this as this transport protocol for the web. You know, well, apparently Google suggests if you search for JSON efficiency, they actually recommend you use BSON instead. It's not a really strong endorsement of JSON's performance. But you know, so really, so why is it so popular then? The key is network effects. And what I mean by this is, if we have a bunch of people participating in sort of the social graph of programming languages, building web services, building applications in libraries, then if there's n people, there's n squared possible connections between those people. Which means that the more people start using something, the number of connections, the number of possibilities increases quadratically. And so, because JSON is popular, it's popular. And it continues to feed its popularity, which makes it more popular. And this is really important, the best solution doesn't always win, but there's other social effects at play. So, why is it so popular? Well, I mean, we'd hope that JSON being the JavaScript object notation is easy to use in JavaScript, lo and behold it is. It's also easy to use in Python. You just import JSON, say JSON.loads. At this point, you're probably thinking, look, David, you're cheating. Python is known for being terse and batteries included. Like, what about the worst language in Java? And actually, I didn't know it was possible to be this brief in Java, right? There's no factory. I was, I was, so, all right, so, you know, maybe, so this kind of contributes, right? They put some focus into the API, into the user experience. And that, you know, it's not, yeah. So, look, it's really easy to use, right? It's compatible with everything. And the fact that it's schema-less, it makes it really easy to parse, easy to deal with in our applications. We don't have to worry about unspecified or unanticipated input, because we can ignore it. And that's what a lot of people do anyway in their day-to-day interactions. So, you know, it's reasonable. Now, what I want to argue, though, is that even though it's schema-less, it doesn't actually, it's not actually completely typeless. And now this diagram, we're going to, I want to kind of break it down. And what it's about is, is how JSON really encodes a hidden type system. Now, this diagram comes from a blog post about how V8 compiles JavaScript objects to be efficient in memory. But I think that there's really something deep here that I kind of want to go over. So, we look at some JavaScript, and this is the code. And, you know, we have a constructor function to make a new point object. And then we're going to make, like, a p, which is a point. We're going to make q, which is a point. We'll assign a property to q to make it, like, a new kind of point, a 3D point. And we're going to go through it in the order of the comments. So, we're going to first look at point zero, then one, two, and three. And we're going to look at the state of the types in the JavaScript program at each of those points. Now, look at point p for a second. It's a pair of 11 and 22. This is what we really want our memory to look like in the end. We want just to have 11 and 22 to be next to each other in memory, because, like, that's what we wanted. We don't want all this crazy dynamic stuff. And so, how are we going to do this, given this code? Well, let's start by seeing what happens when we call new, but we haven't started to run the constructor. So, that's point zero. And so, if we look at point zero, we say, what's the type? Well, the type is the empty type. It's a table which lays out the object, has keys, has the offsets in the actual array that's going to contain the data, but there are no keys. And so, we just have this empty table. So, that's cool, I guess. I mean, that reminds me of something like unit, maybe, or object, or things like that. Now, we're going to execute point one. And so, I'll let you think first, what do you think the layout table would look like after we execute point one? Literally a second. So, in fact, the layout table has x is at offset zero, because this is also, we're programmers. That means we're lazy and bad at our jobs. And so, what do we do? We're just like, man, I need to add something to this. I'm just putting it in the next place I can find. It just looks like this is the first slot in the array. The first slot everywhere. It's easy. And we look and we say, look, actually, that point one type, our goal representation and memory is, in fact, an instance of the point one type. This is kind of like virtual classes in C++, or kind of like interfaces. We're sort of, there's this hierarchy that's being created. Now, the JavaScript developer who chooses not to be enlightened doesn't realize they're creating an implicit type hierarchy. But in fact, they are. And this is kind of how it's going. So we'll keep going. We'll execute the point two line where we assign the second property. Of course, we expect the layout table. We say, OK, well, we have a new thing. Why? We're going to put that at the next available offset in the array because we're lazy. That's what we do. It's also faster, whatever. And still, the underlying representation, what we want it to look like, that's what we got. And that's what the type is describing. So I want to go back to this diagram and show you a little bit more about this class flow. So on the upper left of the diagram, we have the code. That's boring. Then on the bottom left in the yellow, is it yellow on the screen? Yeah. We have the target memory layouts of the P and the Q objects. And then on the right in the blue, we have the hidden class hierarchy. Now the hidden class hierarchy, we start at the very top. That's this empty kind of object, unit type thingy. And then as we go down, we keep adding more fields. And so we've actually created this type hierarchy flowing through these hidden classes on the right hand side in blue. And this is really interesting to me because it's like, look, I thought I was using a dynamic language that had no types, no safety at all, but apparently there's something going on here. So what does point three do now? We'll sign point three, we have a new layout table, and we have a new property array, which is in fact the point three property array. Now the interesting thing here is point three, as I've kind of been harping about these hidden classes in the way that they evolve, point three still looks like the way the type looked at point one or point two time. So if we had some code that was expecting what a point looks like at the comment in our code where it said point two, that is the two element point, the point three still meets that contract. It's kind of interesting. And so even though we use JavaScript, we got this type hierarchy. Now you might say, look, nobody cares because maybe most people don't care, but if you actually wanted to write high performance JavaScript, which hopefully you do considering you have to run it on my mobile phone and I don't have the greatest battery life, you need to understand what this does and how it works because if you wanted to try to write JavaScript code that was going to execute efficiently on some device, then you need to understand what the compiler is going to generate. To understand what the compiler is going to generate, you have to understand the implicit types that you're writing anyway. And so even if you're writing in a dynamic language, you couldn't get away from it. You actually had to use types and so that happened. And so there's something here. Maybe JavaScript, I mean, I was kind of teasing about it, but there's actually something kind of interesting, a few interesting things about it. So at the end of 2013, PayPal wrote this breathless blog post about how Node.js completely revolutionized everything. Now they moved away from Java because that's a boring enterprise language. It has no business in a financial transaction processing company. And they started using Node and they got faster execution. They really cut down the bugs because the double equals, triple equals thing is not confusing to anyone. And so, but here's the thing, like they actually did make it faster. They actually did have fewer bugs. And why is that? Well, it's not about the language, okay? The programming language just matters in a vacuum. You can't try to make an argument about how this language is objectively better than that language. It's about the engineers. It's about how they relate to the machine and how happy they are when they're writing this language because that leads them to have passion. And if they're passionate, then they're gonna care and they're gonna care to make the project succeed. And so, when you're thinking about framing these talks about which language to use, don't try to frame it in terms of objective betterness. Try to frame it in terms of passion building. So I'll take another example, which is GitHub. GitHub a couple of years ago was valued at three quarters of a billion dollars. That's a lot of money. They also store all the source code for all the companies. That's pretty important. So obviously it's probably written in like Haskell because they can't afford to make mistakes because it's like the economic cost and the business risk is way too high. Yeah, but it's not. It's written in Ruby and Erlang. So you might think like, oh God, I really need to move to GitLab immediately. But those are also written in Ruby and Erlang. Now you say, look, what's the problem with Ruby? It's like, it's such a great language. It's got functional stuff, object oriented stuff and it's a great language. Well, the problem with Ruby to some people is monkey patching. Monkey patching is this really powerful tool where what you do is crazy things where you're like, oh man, this Rails framework, I don't wanna fork it. I just wanna change the code in it and then let Rails just keep upgrading versions and I'll assume that they didn't change their code even though the version number changed and this is all gonna be fine. And so you say it's all fine. So I did this as an experiment. So I opened up IRB. This is the interactive Ruby interpreter. And so I was like, so I take the string hello and I say toString. And of course the toString of a string is the string, hopefully, or not. So I then said, I wonder what would happen if I changed it to the toString of string was something different. And so then I tried it. And you know what, it works. I mean, for someone, maybe not for the libraries I'm using. And so look, so now you're laughing or you're like, this is stupid, why would you do this? You're just like, this is like taking a loaded gun and pointing it at yourself. Just don't monkey patch in this way, do other things. Or use Haskell because it's safe. Now you say, now you're thinking, or some of you are thinking, there's no way you can't monkey patch in Haskell because it's statically typed, it's checked. It's all good. But you know, we can do this thing which is we can add new instances, type class. We can do some clever things with the way that we import stuff and the way we rename things. And what we can end up with is some code which although the compiler understands is different, we can create the textual content of the source code file. That's the part where the human has to look at it and not make mistakes. We can make that super confusing and completely obliterate all the benefits that we got from the static type checker. So what are we talking about here with this monkey patching and type classes and extensibility? Well, what we're really talking about is this thing called the expression problem. Now the expression problem is typically thought of in static compiled languages. And the goal is that we have data and we have functionality. And we want to tie data to functionality through specific implementations. So for example, we have lists on the left side and we have operations we could do to lists on the top. And so maybe we want to say add a new type of list. In which case, we put the new class here, we fill in some or all of the columns and then great, now we have a new type of list. Or maybe we want to add a new operation to a list. So we add a new column and then we add that operation to all the new rows. Now this is something you can do in Haskell. This is something you can do in Clojure. This is also something you can do in Ruby. But Ruby never had static types. It wasn't even compiled. Did we solve the expression problem? I'll leave that for you to answer to yourself personally. I feel like at this point it's arguing technicalities that when it comes to the expressivity of the language, we have similar levels of expressivity. So make sure that you choose arguments that you can actually back up when somebody chooses to be obtuse to you. So now let's talk about how to advocate for languages effectively. So I'm gonna just kind of joke about the strictest type of static type languages. Pretend I'm arguing for, I don't know, like Agda. Like we should really write all of our software in Agda, it's gonna be great. And here's the argument. Look, the world's a really scary place. We've got hackers, they're gonna hack us. Types mean that we don't have memory problems. Hackers attack memory problems. It makes a lot of sense. But we got metasploit. And then it's like, oh shoot, right. Although my application was written in Agda, it turns out that I was using nginx, and nginx has a pre-bundled exploit so that any random high schooler can download it on the internet. And they're just like, oh, what if I type metasploit your company? And then metasploit, for those of you who don't know, sorry NSA, it's this open source tool you can download that has all sorts of hacking attack payloads. You just point it to the server and it figures out how to exploit it for you. And all the hackers use it for their security researchers, use it for exchanging their security research code in kind of a common framework. So here's the point. Programming language choice isn't actually protecting us against hackers. It's not really protecting us against metasploit. So what are we considering then if it's not about real safety from the hardcore safety sense? Maybe it's an ethical question. It's not so much that we really believe we're totally protected, but it's that we need to be responsible. And so the aforementioned JavaScript developers, they're unethical and they should have their licenses revoked. Or we could license them first and then we could revoke their licenses. So, all right. So there's a guy named Paul Snively. Paul Snively is really respected in the Scala community. He blogs a lot about type systems and he spoke at Strange Loop in 2012 and in 2014. The first time he spoke at Strange Loop was this talk called Types versus Tests in Epic Battle. And he and another person, they basically got on stage and it was basically it was WWF for programmers. So it was a prescripted battle of whether you could write the program with a typed language or a test-driven development faster and with fewer bugs. And obviously Types one, because both of the developers prefer typed languages. But I mean, it's really entertaining. Yeah, it was WWF, right? It's just like, this is just, I mean, sorry, if you didn't realize that that was like all staged wrestling, it was, is kind of predetermined. Okay, so now the second talk is a talk that I've spoken to Paul about. And the thing is that what I'm going to tell you about is something that he also knows that he shouldn't have said it this way. He's already come to the same conclusion that I'm going to point out. So that's my pre disclaimer. So the second talk was called Types Systems, the good, the bad and the ugly. Now in this talk, he said some things about people. And so I'm going to show you a sample audience reaction. So this is not the kind of tweet that you want to be coming from your kind of reason, the persuasive discussion about typed languages. Now the other thing to kind of understand is that in context, Rich Hickey, the creator of Clojure and Joe Armstrong, the creator of Erlang were sitting in the audience and they were listening to this. And they're like, oh, hmm, you know, and they were kind of displeased after the talk. They were in the hallway talking. I joined their conversation. It's actually sort of out of that conversation about kind of how do you actually discuss typed versus untyped, static versus dynamic, different classes of languages. How do you have these discussions in a way that doesn't just piss people off? And so, you know, like definitely credit words do. Had Paul Snifely not said this, I would not give this talk. However, it's not really about that anymore. So look, so maybe it's not about the ethics of typed systems. It's really, it turns out that as programmers, we're very emotional beings. And so this is about the emotions of typed systems. And you know what, I just can't believe you. I refuse to believe that my beloved language, like you're telling me that Clojure isn't the best language for command line tools. Well, I mean, I don't see how we can continue being friends. So I live in Brooklyn. Brooklyn has a lot of hipsters. And we don't have all of them, but we have a bunch. And so the thing about it is, you know, I've gone to bars with friends and I'm not really much of a beer drinker. I go for like the Blue Moon or something. And then they go, they're like, oh, oh, you don't prefer the double hopped, ultra dark IPAs, how quaint. Don't be that person when you're talking about languages and types, you know. Being a snob just makes you seem condescending and it turns off your listener from being even willing to hear what you're saying. So you really have to be careful not to stone snobby when you're talking about your obvious, I know functional languages are superior. That doesn't mean that your audience will know that when you're having this conversation next time. All right, so given this, like, what can we really use to drive our decisions and what can we really use to drive our conversations? Business needs, profit, that was a joke, by the way. I mean, I'm also serious in that like actually, you know, remember, like, why are we even paid? Right, it's to sell stuff. Ultimately, we have companies, the companies sell things and the companies give us money so they can sell more things. So, you know, in some sense though, you really should remember like, the business needs are important. And so we're gonna talk sort of about how we can frame using typed languages, using functional languages in the context of business needs in a way that you can be successful with non-technical management and with, you know, technical peers who perhaps aren't on the FP bandwagon yet. So look, here's the plan that the engineer comes up with. The engineer is like, all right, look, we're gonna use more types. Those types are gonna remove the bugs and that's gonna deliver value to the company. That value means we make more money. It's gonna be great. And so the engineer says this to the project manager and the project manager's like, okay, that's an interesting plan, but guess what? We're gonna ship it now. We're gonna open a call center. They just remove the minimum wage laws in country X, like, done. This is gonna be great. The minimum wage call center is going to resolve database inconsistencies manually. Don't even worry about race conditions or transactions anymore. Like, we have someone to do that, okay? And we pay them 50 cents an hour. Now this is kind of terrible, but it's also true. Like, I'm sure that everyone at some point has either worked on or used an application that had this very model. I mean, I have anecdotes from friends of mine where they were working, say, on retail applications and they're like, oh, well, like, they wanna be able to, the customers wanna call in and, you know, I don't know, they wanna, like, change their order. And they're like, well, we should add a way for the call center up to change the order. And they're like, no, don't worry about it. Just make a new order, make an old order. Oh, and they're like, what about transactions? What if the item goes out of stock? Eh, it's a few customers, you know. So now, so the project manager's like, okay, great. We shipped it now, this is gonna be good. They go to the executive and let the executive, we have this great new plan. And the executive says, guess what? I was looking at the balance sheet and the engineers get paid the most, so let's fix this. We'll just fire the engineers, leave the product to kind of, kind of, wither. But it doesn't matter because our customers don't even have a choice. It's like what the federal government might do. So, but look, you know, really, this too is delivering more value to the people who are the real value stakeholders. And so the moral is that we're totally screwed and there's no way we can ever get anybody to use anything good because they'll probably just fire us. Um. But. But types are really great. And this isn't exactly true. And so what I wanna do is I wanna make a distinction because there's a really important distinction. I keep saying types and everyone in the audience knows exactly what I mean. But when you go back to work and you say to your coworkers, you're like, man, we gotta use a typed language. They're gonna say, we are, it's Java. And so then what I would say is, well, the question is who is your type system for? Now there's two things your type system could be for. It could be for the computer. That's things like Java, C, C++, go. These are the languages where the type system's purpose is to let the compiler generate better code. That's the only reason there was a type system. And that's why take Java and Java collections and Java generics, those aren't even in the actual output of the compiler because it doesn't care. Because that was something for people and we didn't care about people. The goal was how do we make containers for objects and everything's an object, done. And so this is one type of language, right? It's oriented for the machine, making it go faster, making the compiler have some insights. Then there's human typed languages. And the human typed language, that's something like OCaml or Haskell, these are languages where the type system is there to help you find problems with your logic and with your reasoning and help show you where you have flaws and inconsistencies in your thought process so that the computer can actually help you do your job. It's crazy. So this is the argument that I heard so many times. But Java helps me reduce bugs. I use collections, I put types on the collections, it's amazing. I have never tried to get a foo out of the collection and then called it as if it was a bar and it got all messed up, it doesn't happen anymore. But here's the thing. Does the type system, does it prove the global properties of your system? And does it guarantee zero run time errors? The fact that in Java you can say throw new run time exception kind of eliminates the notion of the Java's type system is really that powerful. And so this is something to consider, is who are you talking to? A lot of these developers, and by these developers I just mean developers who aren't here. A lot of developers, they haven't used these computer typed languages. They've only had human typed ones. So if you say let's use a typed language, they're not gonna understand what you're saying. You're not even, you're both saying types, but I say types and mean Haskell and you say types and mean Java or C. If you've ever dealt with C arithmetic and what number type comes out of doing operators, it's always int. It's very confusing. So first you have to create the distinction and you have to really make sure that the audience that you're talking to uses the same terminology with the same like backing dictionary. So all right, so when should we use typed languages? Well, there's a bunch of times when we really have an excellent way to kind of get these into the system. And these are those times. If you're building databases, aerospace, transportation systems, nuclear power reactors, planes, these things are critical. And the reason I call them all critical and you can take your own business problems and kind of map them into this critical domain. And the way you can do that is by saying, what is the impact of an issue? Well, the impact of an issue in these cases is a big problem. If you lose customers, that's a big problem, right? We don't wanna be like, oh right, GitHub went down for six months and so now they don't have any more customers. That would be a big problem. So when engineering their system, they have to make sure that that is not one of the things that could happen. And if you can kind of create an argument for why are types going to help prevent this from happening, that's a real compelling case to get a typed language, to get a functional language into the projects and into the company. Going out, running out of customers, that leads to bankruptcy. This is another thing. This is a thing even a completely non-technical manager or executive will understand. Well, some of them, the ones that don't have golden parachutes. But a lot of them, most of them will get it. The bankruptcy is bad. And again, depending on the industry and the person, you know, there was recently an Airbus crash that happened because of bad software development checks where some things about contractors using languages and integrating components properly and the plane crashed. That's really bad. People could die. And most people, they understand that in questions of life or death, that type systems are a good choice. Now, this might seem hyperbolic, but sometimes hyperbole is the only way to really get your point across. So, all right, so how do we trust our software then? Because there's many ways we could trust our software. Well, one thing we can do is we can do a design review. Before we get started, we can just make sure, is the thing that we're thinking about doing, does it even make sense? Is it even going, is it out of any potential to work? Can we identify flaws in the project prior to starting? The second thing we can do is we can do code review. This is kind of, as we're going along, we're evaluating the software that our peers are writing and through peer review identifying potential problems, heading them off. Hopefully, we're all doing these things, we're all doing unit testing, integration testing, and I don't need to explain what those are, I hope. Then there's static analysis. And in static analysis, I'm kind of lumping together here, both things like type systems like you get from a human type language, and also things like co-varity and find bugs. These are, co-varity is a kind of a C and Java identifying potential problems in the source code before you ship the application, or find bugs as identifying potential problems in the byte code of a Java application, trying to prevent you from doing that. And then lastly, and kind of the 200 pound gorilla hammer is theorem proving. This is where you say, well, look, languages are nice and all, but I want to use a separate language to explain what I think my program does and then have some other researchers tool analyze my specification of the program to make sure that it's consistent and sound and has whatever property it is that I want it to have. That's an interesting question. It doesn't need to be, but in practice, the theorem provers that are sufficiently powerful to prove theorems tend not to have good enough performance for, because also generally when you want to prove the theorem, you also, it's because the application is some kind of criticality aspect. And so, you know, it's unlike, today there are, at least I'm not aware of, language of systems that have undergone, you know, the years of consistent use where I would trust the theorem prover and its output. And I'll talk about one theorem prover in particular that's really cool in a little bit, that is like, it's really cool. I don't want to spoil it. So, I want to talk about these last two things, because these two things, to me at least, they're spiritually they're connected with typed functional programming, you know, and they're both about saying, look, we're not going to run your program to see if it works, we're going to look at your program to see if it works. So I'm going to talk about static analysis and really specifically about types in the form of anecdotes. So the first anecdote I have is about a friend of mine named Matt. Matt builds spaceships or satellites really. And Matt frequently says he's a terrible programmer. He's like, man, I really suck. All I do is program in CN Haskell for these aerospace like satellite things, but like I'm really bad and that's why I write Haskell. It's cause I'm like such a bad developer. It's like only Haskell is the only thing I can do. Like I tried using Python, but I'm way too bad for Python. So, you know, I was, I'm like listening to him. I'm like, what is this guy saying? This does not reconcile at all with my understanding of the difficulty of the languages and the problem domain that he's working in. And here's the thing, Matt's a great programmer. And the reason that he uses Haskell is that he knows that for his business, it's life or death for his company because he works at a small startup, you know, they raised, I don't know, I'll make it a million dollars in funding and it cost, you know, $900,000 to launch a satellite. So they only get one shot. And then if that succeeds, then they can get more money. But if it doesn't succeed, like who would give the money to the company that like blows up satellites for bad software? It's not like, honestly, we're perfectly good at that without paying for it. So, and then the other thing is that even for his C code, he used static analyzers and would kind of reimplement it in Haskell in order to try to prove semantics of the C code that he was writing. Now, you know, I'm sorry if any of you are like really hoping to do kind of, you know, professional aerospace programming, but generally the radiation hardened computers we send into space aren't fast enough to run very much. So you kind of stuck with oftentimes these really awful low level languages that don't have any safety. But you know, here's the thing. In this problem domain, this is the perfect domain to use static analysis tools to use steadily typed languages, it's great. Now, I wanna talk a little bit about what I do at work. What I do is it's big distributed systems stuff. Now the thing about distributed systems is they have very different properties. You can swap in components. You can do rolling updates. You can do rolling rollbacks. You can do hot fixes. If any kind of API is broken for a while, it's only broken for a while because we can fix it because we have networks and like upload new code. It's pretty cool. Now there is a caveat, which is the data layer bugs. Those are catastrophic. Once you get bad data into the database, it's extremely hard to get it out or usually you just don't bother because it's easier to kind of write checks to sanitize the database before you present it to the user. So the thing is that when you look at the distributed systems that I work on, there's not that many types through most of the kind of high level worker code and that stuff. Where the types start showing up is as you get closer and closer to the data layer, we validate more and more. And as you get closer and closer to the user layer where the user interacts with it, we validate more and more. Because at some point there's kind of this idea of like trust and cost of a mistake, right? If the user types in some bad data and it says okay and it was wrong, and the thing that they did actually didn't work and the okay was a lie, then the user says okay, your system always lies to me. It happened once, therefore it always lies. And it's never worked and I can't possibly use it ever again. And same with the database, like if your database kind of has bad data in it, that's a huge problem. Now there's a third domain here that's kind of interesting, which is FPGAs, these silicon stem cells I was talking about earlier. These chips that you can make them become any chip you want. Now the problem with FPGAs is that you don't really compile stuff to them. You use simulated annealing optimization systems that take like six hours to try to figure out how the hell to map the text that you wrote onto like a physical piece of hardware that has ridiculous like, literally quantum physics constraints about how you can build the damn thing. Okay, so as a result of this, this is a great domain for the use of types and formal methods and these kinds of things. And so tons of verification tools and simulation, this is kind of par for the course with FPGA development. If you're not using these things in your FPGA developer, you're not an FPGA developer, like it's just not possible. So there's been a lot of work actually here. If you're interested in kind of a different type of domain where types are necessary, it's not always just the criticality of it, but it's the developer productivity. In this case, we have things like BlueSpec, which used to be Haskell on FPGAs, but then turned into this horrible bastard child of system verilog, which is the worst programming language. Maybe mumps might be worse, but it's pretty bad, okay? So BlueSpec, that was like one project from MIT. There's Clash, which is another Haskell on FPGAs, but much more like Haskell and less like that other thing. And that came from the University of Twent, I hope I said that right. There's Piplin, which is the project that I wrote, the compiled closure to FPGAs. Now you might be thinking, maybe you saw some of the closure talks today and you're like, wait a second, closure doesn't have types. And you're saying types, types, types. What's up? Well, part of what Piplin did was it made sort of another simplified type system that could particularly deal with the idiosyncrasies of FPGAs and map those into a type-checkable domain. And then there's Chisel, which is Scala on FPGAs and that was a project on a Berkeley. So the thing is that the context, the requirements, the decisions, all these things are feeding into each other. How long does it take to develop? How long does it take to test? How can we deploy? When can we deploy? What's the impact of breaking our system? These are leverage points that when you're trying to sell the use of a typed language or a functional language, you can use these leverage points in order to make the case for why you should use a language rather than just it's better or it's more fun. Actually, it's more fun as a good one, as I was saying earlier, but it's better as not a good one. All right, so I just want to kind of, in the final section, I'll make the case for why types are absolutely the best. All right, now, this is actually definitely not what you should do. I know people, I'm sure, have done this at various times and this is not going to work. So you say, types are theorems about what the function does. Yeah, some of you know where I'm going with this. And programs are proofs and this is called the Curry-Howard correspondence. So now the person you just said this to, this is their reaction. They say, theorems and proofs. Yeah. You can't use the word theorem just ever. Just never use that word when discussing or proof. Never use either of those when discussing types. Well, maybe proof, but don't say theorem. Nobody likes that. Or the people you need to say that to are not the people who will be receptive to that word. So look, then the other question is look, why would we use types when we could use TLA plus? Cause we just said types are theorems and they're improving. TLA plus is this, it's a really interesting way to specify the behavior of sort of time-oriented systems and potentially distributed systems in order to verify their properties and verify that the algorithms that we're using actually do what we think they do. Now, what I'm sure your logic is is like, well, I'm saying we should use Haskell rather than re-encoding our program in TLA plus cause it's way easier to use Haskell than it is to use formal methods. So here's the thing. Adrian Cockroft is an engineer at Amazon and he tweeted this a while back which is that at AWS, they're SREs, they learn plus cal to work on their TLA plus applications in just a few weeks. TLA plus is not an esoteric research tool. It's being used in production at companies. Now, with no offense meant to SREs or you might call them sysadmins or other things like that, generally the sysadmins skill set is different than the developer skills set in that they have to learn more about how to actually operate the reality of the machine where the developer is like, we like to stay up in our little ivory cloud towers of like, I have types and I have maps and maps are great and I don't need to worry about how much memory is on the machine. But it turns out you can't just allocate infinite memory even if that's the model our language is exposed. So in spite of this, SREs typically, they're not doing full-time software development, right? They're doing a mixture of work and at AWS, they successfully get SREs to learn how to use a formal verification tool for the systems that they're working on. This is not an esoteric thing. This is not way out there, right? This is something that you can teach to someone who has had no exposure to it and actually get up and running and actually see real success with the project. Cause usually S3 doesn't lose data. So that's pretty, you know, a testament I suppose to S3, SREs plus Cal, they're all good. So, you know, the thing you might think to yourselves, look, types are integrated, you know, they're part of the language. And when I want to use, I want to make sure that my language is, my program is still type checkable. I just press build, you know, I don't have to wait for a long time. I don't have to wait to like, you know, run integration test and find out runtime exception gets thrown deep in some method somewhere. And so as a result of this, it feels like less commitment, right? Cause our build system, we don't have to make some special build system that first verifies and then checks and maybe make sure that the verification and the actual program are being kept in sync. We don't have to worry about it. And you know, here's kind of an analogy that I like to think about this. Look, some people drive. Apparently a lot of people do, but in New York we don't. But in most of the rest of the country, it seems like people drive. And so they have like car keys and they put a little pocket knife in their car keys cause they're like, man, you know what? I might get a loose thread. I need to like cut it off. Maybe like I need like a screwdriver at some point. You know, it seems useful. It seems useful to have this. But now if you were a person that's like, man, yeah, you know, I might need to cut off a loose thread and you know, maybe screw something in or something. But you know what, you know what though? Like this pocket knife is a little flimsy thing. Like I'm going to duct tape a bowing knife to my leg. Like this is going to be great. Like I'll just, I'll just attach, I'll just wear these on my belt at all times because you know, it's similar to like putting my keys in my pocket. I mean, sort of. Now you laugh and you think, hi, yeah, what a crazy image. Like someone just carrying a giant knife around in their pocket all the time. But think about this. You had car keys. That means you have a car. That means you have a trunk. You could just throw the more useful tools into the trunk and leave them there and then go get them when you need them. You know, it's not necessarily that the commitment and the trade-off isn't always what it first looks like, right? So we literally have like, you know, moving object carrier with us. So all right, in case you zoned out or you rage quit or you're just like, man, what was going on? Here's the key points that I want you to keep in mind. The human factor is arguably the most important thing and is a great way, especially when talking to management, to be like, look, the reason we gotta use this is because it's really popular. It can be easier to hire. We're having, you know, like our developers, they don't seem that happy recently. Like that project's really slogging. Like this is going to like breathe new life and passion into everyone. It's going to really rally the troops. And so this is like a great way to make the argument for why to use types, why to use functional programming. Don't be a beer snob. Haskell is a great language, okay? Facebook is a multi-billion dollar company and they use PHP. So from the measure of how valuable is the, is the sort of the software, you know, the language honestly doesn't actually have that much impact on the value of the software. There's other factors. So don't be a snob when you're trying to talk about these things. What you should talk about is the cost of failure, right? Can we redeploy? It's going to be tough to make a new call to like say we need all this extra hardening of the system. Are we going to go bankrupt? That's a lot easier to say that we should harden the system a little bit more. So, you know, and the last thing I want to say is remember that formal methods, they shouldn't be relegated to research labs. They're starting to see use. They're pretty hard to advocate for, but I mean people are actually using them in production, in the wild, and in, you know, business use cases that don't have any kind of academic tie-in. And so the thing to remember is that there's a spectrum. There's a lot of choices. Dogmatism isn't really going to get you anywhere. That's just another way to be a beer snob. Thanks.