So, this is a good start. Turns out we're already two minutes past time. Awesome! And I have a lot to cover. So my name is Ernie Miller. I work for a company called CareZone. They're based out of Seattle. I'm based out of Louisville.  Truth is, I got into programming because I liked video games. I started programming at the age of six. So naturally I decided I want to make video games. I'm going to major in computer science. Anyone else out there who did the computer science thing? Great. Good for you. That's very cool. I ended up taking a somewhat different route to a career in programming. So I dropped out of college to go full-time in my tech support job at an ISP. My intention was to work my way up from there. See, I had heard there was going to be an opening in the systems administration department, and I wanted one of those jobs, so I figured I could probably start getting to write code from there. And so I landed that sysadmin job, and as you might imagine, I started out writing Perl, which was quite popular with the sysadmins in that day. This is, by the way, a real program that actually runs and prints the text of 99 bottles of beer. So I wrote other languages in the meantime, but when I found Ruby, it was natural for me. It really felt like a natural transition, and especially since people had started to hear about this Rails thing, and Rails was becoming really popular, I thought I can finally pretend to be a respectable programmer now and write some web applications.  And while we're talking truth here, to be honest, this isn't even the talk that I wanted to give to you today. That talk started life about a year ago when a friend of mine named Terrence asked me to submit a talk to Keep Ruby Weird. So I voiced my concerns, as I thought I had a right to do, about preparation time and all of that, and he responded, what I can only assume is the conference organizer equivalent of a used car salesman's, let's take the car for a test drive, there's no obligation. So Terrence knew exactly the kind of talk that I wanted to give, and he knew I found the whole idea pretty scary. I had opened my mouth a few years ago, or I guess a couple years ago at this point at RailsConf, about this idea that I had to build a choose your own adventure game. Basically it was a talk slash game kind of hybrid where the audience was going to be able to vote on which way the talk would go. And so I knew that if I mentioned this to somebody, I was going to be screwed, that I was actually going to have to do this talk. The problem was I actually had no idea how I was going to build this thing. I had spent most of my programming career writing web applications, and this thing was more like a game or really a multiplayer network driven game than a presentation application, but it didn't really matter because I hadn't written either of those things before. So I gave in and I wrote a proposal, but I put this giant caveat in the middle of it thinking I might get out of it. Unfortunately they accepted it anyway. So before I accepted the invitation, I spent some time hacking together this amazing incredible tech demo that you see before you right now using Elixir, Phoenix, and React at the time. I wanted to make sure I could get a presenter, a desktop client, and a mobile client all working at the same time, and obviously as you can see here it had a long way to go, but what I was able to hack together in that weekend felt almost too easy. I often tell people that the right technology feels like a cheat code. You can judge a technology by the things that it makes feel like cheating. That's another way of putting it. And I figured at that point, well obviously I've chosen the right technology, but in the back of my mind I'm sitting here thinking maybe I'm really cheating, like maybe I just haven't run into where this is all going to break and I'll find out later, because it couldn't possibly be this straightforward. Anyway, so I had about eight weeks to try to turn my simple tech demo into a full fledged presentation application.  And I also had to build way more slides than I normally would build for a presentation because of the choose your own adventure nature of it. And this was all for a talk of a type I had never written before using a tool chain that was now only barely existed. It also had to keep running under the load of a room full of people who I knew were going to try to break it. So not a big deal at all. Just kidding, it was a really, really, really big deal, very big deal. I was stressed out beyond all belief. And I felt like if this didn't work out, I will have lied to my friends. But to be fair, as a software developer, I'm pretty used to lying. It's sort of our business. And before you say, well, there has to be an intention. It's not like I intend to lie. I'm fully aware that if it's going to be a lie, it's got to have some intent behind it. And you don't intend when you estimate to lie to anyone. But let's just talk about that for a second and really think through. Let's assume the best case scenario here. You pick some work off of a queue. You start working on it. And once you've gotten into a bit, somebody comes by and says, well, how long do you think it's going to take? Now, you might have some general idea because you've started working on it at this point. But you can't really say for sure. And more often than not, someone's asking you to give them that estimate. They're asking you how long it's going to take before you even dug into the work to understand what's involved. And so you basically make something up. Now, you might have even learned it's best to pad things a bit because you know someone's going to hold you to this estimate that you just gave. And you want to make sure you deliver, under promise over deliver, right? And maybe you're sitting here saying, well, not my shop. We're enlightened. We're agile. We don't estimate in units of time. We use points. Points. I love stock photography. So the idea with points is you're not estimating in time. You're estimating in difficulty as it compares to some other thing that you might be estimating. And everyone just agrees to pretend that you're not really thinking about how long it's going to take you as an individual to implement this when you give them that value. Now, when you estimate, even if you're intentionally not intentionally misleading somebody about how long it's going to take or how hard it's going to be, you are lying.   And I hope it's not a surprise to anyone in this room that you actually don't have that superpower. You can't predict the future. We're going to come back to that in a bit, but for now I'd like to move on to something different. So Git commit histories are another area where we kind of play fast and loose with the truth. So what's Git? Well, it's a distributed version control system. But what's a version control system? Well, it's a tool primarily concerned with keeping track of history. You know that record of all the stuff that's happened, the immutable list of events that have occurred up to this point. So if you're setting out to change the past, then you're probably going to fall into one of two buckets.  And you're subservient to the will of the machines. And you're working to ensure humanity's demise, whether you're doing it because of choice or because your programming is irrelevant at that point. Now, from the point of view of the altered timeline, it's impossible to know history's been changed. And so let alone the motives for changing it, or whether or not they were for good or evil, that's just gone. It's not there. Now, maybe you think this is an unfair analogy. So let's look at it another way. Do you know how Git is implemented? It uses what's called a hash tree, sometimes called a merkle tree. I'm not a CS grad, obviously, so I had to look that up. According to Wikipedia, hash trees are for verification of data shared between multiple computers. And more importantly than that, they're specifically created to ensure no one is lying. So we've got this incredibly powerful tool built on algorithms designed to ensure consistency and to make sure nobody's lying. And what is the very first thing that we do with this tool? We lie to it. We lie to it a whole lot, actually. And look, I mean, I understand there are absolutely tons of Git workflows that can work well. And there are plenty of situations in which these commands are reasonable or even advisable. But lots of them are just plain abusive.  I agree. I'm a huge fan of commit logs that tell a story. It's just that I prefer that story being nonfiction. It's valuable to know how things became the way they were. It's also sometimes unflattering or confusing. But I'd rather know what we tried that didn't work so that we can learn from history the next time something comes around. Look at it this way. Every time you have to force push to a remote with Git, Git is actually trying to tell you, hey, you're lying to me. And you're saying, I know. It's OK. Don't worry about it. It's for your own good. I hope you're really, really sure of that. So maybe we can be forgiven for lying so freely. I mean, we're surrounded by lies. And every abstraction is a lie if it's an abstraction at all. The entire point of an abstraction is to make something seem simpler than it really is underneath the covers. So as an industry, we've built this really impressive tower of abstractions, or if you'll allow me, a tower of lies. And we do our daily work atop this tower. Every story in this tower is a story that someone thought was worth telling for our own good based on their opinions. And you might guess, especially if you know me, I have opinions about some of those lies. Actually, scratch that, I actually have feelings about some of those lies. But because feelings are hard, I want to talk to you first about something simpler. Let's talk about science instead for a second. Specifically, easier than feelings, quantum mechanics. Let's talk about quantum mechanics for a second. Anyone know what this equation is in the room? Hey, there's some hands. Awesome. So for those of us who, like me, didn't immediately recognize this formula, let's start with something simpler. Anybody know what this is? This is a pebble. I would also allow a very small rock. Yes, that's true. So if you drop this pebble into a still pool of water, you're going to get little waves or ripples like this. And if you drop two pebbles next to each other, you're going to get two sets of waves. And those ripples are going to make kind of a pattern that you see here where they intersect. So way back in 1678, this guy named Christiane Halkins. It's hard to pronounce these foreign names, you just bear with me. He was telling people that they thought light was a wave just like those ripples. And he published this idea way back in 1690 in something he called his Treatise on Light. But waves, we know, needed to be in something or on something. So what was light really going to be a wave in exactly? He made up a hypothetical substance called the luminiferous ether. And yes, luminiferous ether wouldn't make a great name for a rock band. So the problem for Halkins was this. This guy was kind of popular back in the day. Maybe you've heard of him, he's kind of a big deal. And Newton also wrote his own treatise on light. And he claimed light was a particle. And since Newton was a bigger deal, nobody really paid much attention to Halkins at all. But there were some people that thought Newton was wrong. And Thomas Young was one of those guys. And in the beginning of the 1800s, he delivered a series of lectures to the Royal Society outlining a wave theory of light and adding to it a new fundamental concept which was called the Principle of Interference. Well, this is a sketch that he drew. You might notice it looks a lot like the ripples that we saw earlier in the way that they created that pattern. If you had two slits on there, the left and right, A and B, in a wall, and then you created ripples on the other side of those slits, then when they went through the openings, they would produce this pattern. And he called them interference patterns. And if light was a wave, he predicted then that we should be able to see something like that if we shone light through two holes the same way that we made ripples in water. And in 1803, he performed that exact experiment. We now call it double slit experiment. And he saw exactly what he predicted. He saw an interference pattern. And the really cool thing about his experiments were that they were super easy to reproduce, like anybody could do it. But even a century after their origin, Newton's particle theories had so much inertia, so much momentum, and prestige that Young's findings didn't draw much interest at all. And some were even ridiculing him. Like, how could you possibly be right? Like, you're going against what Newton says, and Newton's awesome, he's like a rock star. And it's funny, scientists can be pretty petty when someone has the quote unquote wrong opinion, not at all like programmers. So in part, he had a lot of trouble sort of getting traction with his ideas because he was busy going out and doing actual real world demonstrations of how they obviously worked. So by 1817 though, there were enough experiments from other people who weren't young, who weren't being ridiculed that corroborated Young's theories that they'd gained critical mass, and Newton's particle theory was thrown out for a while. Classical wave theory was what went on to allow the invention of radio and radar, among other things, but it still failed to explain certain things. Among those things, the ozone layer, which protects us from short wavelength ultraviolet light. And yet, if waves pass into or out of a medium, they return to their original frequency, their original wavelength, once they come back into the atmosphere. So if light was a wave, it would pass through the ozone layer, and then it would return back to its short wavelength, and it would fry us all and kill us, so that couldn't quite work. So to understand why this works, we actually have to take just a tiny step back to a couple of millennia ago. This cheery guy here is a democratist, and he's also known as the laughing philosopher. He's usually the guy that gets credited with developing the philosophical theory of the atom or atomism in the fifth century BC. So he said that the universe was made of tiny, indivisible, indestructible particles that he called atoms after the Greek word for indivisible, atomos. Philosophical atoms now supposedly came in an infinite variety of shapes and colors, so they could be combined in different ways to make all the things that exist. Now this idea survived for millennia, and in fact, when chemists and natural philosophers in more modern times discovered something, tiny particles that were apparently indivisible, the natural name for them was atoms. The idea had survived all this time. But it turns out that atoms don't actually come in infinite varieties, at least not as far as we know, and in fact, there are so few, relatively speaking, that it was straightforward to create a table of all the ones that were discovered, and even to predict the kinds that we hadn't discovered yet. And we call that the periodic table of the elements. Now the other difference between atoms, as we understand them in their philosophical counterparts, is that it turns out atoms aren't indivisible. They're made up of even smaller parts. At the end of the 19th century, a guy by the name of JJ Thompson, who was a physicist at Cambridge University, was conducting experiments with a cathode ray tube. Now during the course of these experiments, he discovered that cathode rays were actually streams of negatively charged particles that he estimated were about 1,000 times smaller than a single atom of hydrogen. In other words, he discovered what we now know as the electron. And he went on to propose that these atoms that we thought were indivisible were in fact divisible, and that electrons were the building blocks of the atom. So we call these tiny particles like electrons elementary particles. And the electron was the very first elementary particle we discovered, but it wasn't gonna be the last. And this is all well and good and kind of interesting, at least to me. Hopefully you're sticking with me so far. But how does it actually relate to the discussion that we were supposed to have? And wasn't this thing gonna be about quantum mechanics? Or wait, no, that wasn't even right either. It was supposed to be about lies, I think was the talk title, right? So in 1900, a theoretical physicist named Max Plunk suggested that radiation is quantized or can be only exist in discrete amounts. So you can have like one quanta of radiation. You could have two quanta, but not one and a half quanta of radiation. That's not a thing, right? So most scientists didn't take him seriously, but this guy did. And in 1905, Albert Einstein suggested that electromagnetic waves of which light is just one could only exist as discrete or physical wave packets. He called those wave packets, and in at least one such case, the light quantum. Now, Einstein was very careful to avoid calling these wave packets particles, but still, I bet Isaac Newton would have felt pretty smug if he'd still been around. Now, the existence of these light quanta's, which we'd later come to call photons, they would be confirmed 17 years later by a physicist named Arthur Compton. He performed an experiment that showed that x-rays could be scattered by electrons. And so we knew electrons were particles, so if we could scatter x-rays with particles, then it's like colliding two balls into each other, right? If they affect each other, they must both be particles. But wait, we already established that light behaves like a wave, so which one is it? So when we shine a light through two slits, like that double slit experiment earlier, we see the interference pattern we would expect if light is a wave. But if light's a particle, and we know it is, thanks to Einstein and Compton, then we should also be able to send just a single photon through those holes. Now, this thing here, this thing is a photomultiplier tube. And it's a device that's so sensitive that it can detect the impact of a single photon. Now, if we put it in an extremely dark place and we shine an extremely faint light through those same two slits, we can tune things until the photomultiplier tube is only picking up a single photon at a time. And then we can check to see where those photons landed. And as the photons are fired through the slits, they appear to be a pretty much random distribution. But if you track them over a long enough period of time, something really cool happens. Even though the photons are arriving one at a time, the same interference pattern that we saw earlier appears. Now, how is that even possible? What's the photon interfering with or being interfered with? The answer lies in something called wave functions. Now, these are basically the heart of quantum mechanics. A wave function tells us the probability that a particle is going to be observed in a given position, in a given time. And we don't actually know what these are waves of or waves in, I only hope they're halfway as cool as luminiferous ether whenever we do figure out what it is. So, Ernar Heisenberg and Niels Bohr, they were physicists that actually pioneered quantum mechanics at the University of Copenhagen in the 1920s, and they had an interpretation of quantum mechanics that seemed to work called the Copenhagen interpretation today. It says that the wave function doesn't actually have a physical nature at all, and it's comprised of pure possibility. And so, a particle that traverses the double slit experiment exists only as a wave of possible locations that encompasses all the possible paths that it could take. And it's only when we actually detect or observe the particle that its location and the path that it took to get there is decided. We call this wave function collapse. That's what occurs when you detect it. Now, prior to the collapse, it's meaningless to try to say anything meaningful about the particle because it's as though the universe is allowing all of these possibilities to simultaneously exist. We call this state a superposition. And it holds off on choosing until the very last instant when we measure it. Not only that, but those different possible paths, the different realities that are all existing, they interact with each other in such a way that the interactions increase or decrease the chance that the next particle is going to land in a particular place. And that's that interaction. We see an individual particle eventually creating this full-on interference pattern. And that pattern is real, even if the vast majority of the paths that could have been taken involved in producing the pattern never happened. So in the Copenhagen interpretation, the final choice of the experiments of the universe is random within the constraints of these functions. But the theory of quantum mechanics, this does produce accurate predictions of reality and is consistent with the Copenhagen interpretation, but there are lots of other interpretations on one other we're gonna talk about today. And this one seems to work too. So if you're still with me so far, take a deep breath, we're getting close to wrapping up all of this science stuff and getting to the feelings, as it is a Ruby conference after all. But it's gonna get a little bit weirder before we finish. So this is Erwin Schrodinger. He was an Austrian physicist, you've probably heard of him. So remember this thing? This thing is known as the Schrodinger equation. And it's a partial differential equation that describes how the quantum state of a system changes with time. Now he formulated it in 1925 and it won in the 1933 Nobel Prize. In the 1930s, he was following the writing and experiments of Albert Einstein, Boris Podolski and Nathan Rosen, three researchers that had some real issues with the strange nature of quantum superpositions. And specifically they had some real issues with the idea of wave function collapse that was proposed by the Copenhagen interpretation. So they described this thought experiment which became known as the EPR paradox and they published a paper in 1935. The short version of it is that if any particle's position is unknown until its measure, suppose for a second that two particles interacted with one another in some way and you knew the nature of the interaction, then in theory you could predict the position or the second measurement of a particle if you knew the measurement of the first one. So this concept was gonna later be called quantum entanglement and they claimed that the outcome of a measurement can be predicted then if that's the case, there's something else at play here, there's something, some real world thing, an element of reality that must describe it because you can't predict the unpredictable. So they said in short that the Copenhagen interpretation was correct but could not possibly be complete. Schrodinger agreed and over the course of extended correspondence with Einstein about the EPR paradox, he came up with the thought experiment you probably know him for today. Now I'm gonna ask you to forgive, I'm gonna ask you to forgive this particular illustration, this is not an accurate illustration of the Schrodinger's cat experiment but it's not as morbid. So Schrodinger proposed a scenario with a cat in a lock box and it had a tiny bit of radioactive substance in it. It also had a Geiger counter and a mechanism that was hooked up to the Geiger counter so that if there was a single atom of radiation detected by the Geiger counter, it would smash a small flask of poison and it would kill the cat. You can see why the cat looks so annoyed now. This is, I'd be annoyed too. So according to him, the Copenhagen interpretation implies that until we make this observation, the cat remains in both an alive and dead state until the state's observed. Well, you might, I promised someone I wasn't gonna laugh at this slide but it's my favorite slide. Okay. So Schrodinger wasn't actually promoting the idea of alive and dead cats as a real possibility. He was doing this to show how absurd the notion was. It just didn't make any sense and that was the existing view of quantum mechanics and it's like something's gotta change. So years later in Dublin in 1952, he gave a lecture during which he was warning the audience that what he's about to describe might seem lunatic. It was when his equations seemed to be describing several different histories, they aren't alternatives but are all actually happening simultaneously and this was really the earliest known reference to what later came to be called the Many Worlds Interpretation of Quantum Mechanics. Now, the Many Worlds Interpretation was gonna be more formalized by Hugh Everett in 1957 and he called the relative state formulation, he gave it that name. Relative state formulation sounds scientific. I think Many Worlds is better because I watch lots of sci-fi, so whatever. But the claim is that it isn't just tiny particles that have a wave function but everything, everything that exists has a wave function of possibilities and Everett's thesis introduction read and it's kind of dense so I'm just gonna, I'm just gonna read it for a second. Since the universal validity of the state function description is asserted, one can regard the state functions themselves as the fundamental entities and one can even consider the state function of the entire universe and in this sense, the theory can be called the theory of the universal wave function since all of physics is presumed to follow from this function alone. That's very dense but in an early draft of his doctoral dissertation, he explained in a way that makes a little more sense. As an analogy, one can imagine an intelligent amoeba with a very good memory as time progresses that amoeba is constantly splitting each time the resulting amoebas having the same memories as the parent or amoeba hence does not have a lifeline but a life tree. Now, this is an excerpt from a letter that Einstein wrote to Schrodinger over 15 years after they started corresponding. Einstein never really stopped being frustrated with this ad hoc nature of wave function collapse that the Copenhagen interpretation proposed. It felt like a cop-out. I mean, it surely did to Everett as well. His relative state formulation seems to suggest that the more real thing is the state functions themselves and then all of physics emerges from those state functions. So those functions that we can't see that we just, they're just math, those are the more real thing. And so it's still impossible to deny the usefulness of the Copenhagen interpretation or if you'll allow me to call it the Copenhagen abstraction in making sense of things. Reality or truth then becomes a question of perspective. How much reality is enough? All right, deep breath. We got through the quantum mechanics stuff. Congratulations. You all now know much more quantum mechanics than you did walking into the room, hopefully.  Taking individually, estimates are wildly, wildly inaccurate. We don't know how accurate our estimations are gonna be in advance and we have no way of knowing for sure how long it'll take until the deed is done when we deliver the finished work. But the funny thing is estimates tend to be wrong in ways that offset one another. They're easy things that turn out to be hard, hard things that turn out to be easy and there ends up being a pattern emerges that you can start to base larger scale predictions on. So you end up with this paradoxical result that estimates can work really well so long as we can all agree to accept that ad hoc principle that they don't actually work at all. Or maybe things are more like they are with Git. Maybe there's some objective notion of truth, but that truth like the biggest Git repository you've ever seen branches off into an infinite number of directions and the state that we observe is just the head of our current branch. Is it any wonder then that there are intelligent people asking the question of whether or not we are actually living in a simulation? And it's not just one isolated individual either. There are all kinds of voices asking this question and some seriously smart people think it's almost a certainty. Others say it's completely ridiculous. It's disturbing to some and it's easy to dismiss this stuff as the stuff of science fiction or completely irrelevant since we can't yet figure out any way to prove or disprove it anyway. But let's not forget that fifth century BC Greek philosophers had very limited powers to observe and yet somehow managed to come up with the idea of the atom, which panned out to be pretty true. So how many of you seen the matrix? There are actually some hands that did not go up, but I am fairly sure that 17 years is way past the statute of limitations for spoilers. Feel free to plug your ears if you disagree. So central to the plot of the matrix is the idea that most of us are living in a simulation called the matrix while our real bodies are hooked up to machines generating power for artificially intelligent machine life. So some humans have been unplugged and they can enter and leave the matrix at will fighting against those machines in a real world that by the way is hellish by comparison. So I wanna show you one of the most memorable clips from that movie for me. Cypher, the guy on the left there, he's been unplugged for nine years and he's meeting with an agent of the machines. Just want you to watch this for a sec. Do we have a deal, Mr. Reagan? You know, I know this steak doesn't exist. I know that when I put it in my mouth, the matrix is telling my brain that it is juicy and delicious. After nine years, you know what I realize? Ignorance is bliss. So to be clear, the situation in the matrix is not quite the one that's posed in the simulation hypotheses. And that's what actually to me anyway makes it especially interesting. In the simulation hypothesis, there's not a real version of you at all. Or depending on our perspective, the simulated version of you is the real one. But what Cypher is asking for is fundamentally different. He knows the version of him that exists in the matrix isn't the real one. And he says, ignorance is bliss. He wants a deal that will plug him back in and make him forget it's not real. He wants to make the simulated reality his reality again. That brings us back around to the point of abstraction. Okay, all that out of the way. Let's talk about those feelings I mentioned. It's been said that science is the search for truth. And lots of you said that you had computer science degrees. Do you spend a lot of time searching for truth? And looking for code examples on Stack Overflow does not count, by the way. You might say, well, it's really an applied science or I'm a software engineer. It's an engineering discipline. And that's fair. I mean, there are very good cases to be made for applying engineering principles to software development. But then we're not really, we're just going from searching for truth to applying truth, which is different, but still not what I think we do most of the time. For some reason, we shy away from labeling ourselves as artists. But I feel that we spend a lot more time being artists than we spend being engineers or we spend being scientists. And there shouldn't be any shame in that. Now, artists move beyond searching for truth or applying truth, they actually express truth. And in some might even go so far as to say they create new truths. And that's what we actually try to do with abstractions. Now, I still believe that abstractions are by their very nature lies. But when we work with code, don't we strive to create things that feel somehow true, that feel consistent? And how do we do this as artists? Well, first thing that we do is we try to aid the suspension of disbelief. Performance artists do this all the time. So the lie is for your own good. It's something that's gonna give you some enjoyment or reduce your suffering in some way. When a magician pulls a rabbit out of a hat, you don't have to really believe he has magical powers.  And this just needs to go so far as to enable enjoyment. It's that informal contract between the audience and the performer. The audience should be left wondering, how do they do that? And it does absolutely no one any good if having seen a magic act, we're so convinced magic is real that we go home and try to saw our partner in half, for instance. And also it's the context in which an abstraction is framed and from where we perceive it. That influences just how truthful it's gonna feel. For instance, if I show you this code, you don't assume if I create an instance of person with the name Ernie Miller, I've created a copy of myself. The object represents just a small shallow sort of slice of what I am, specifically my name. I can count on you as programmers to share that context. Earlier this year, I gave that presentation that I talked about at the beginning. I gave it at Ruby on Ales in Bend, Oregon, and those organizers, they actually had a surprise, they gave to all the speakers. And this is the one that I got. It's me with my cat Esther. Now when I say this is me, you understand this is an artist's interpretation of me portraying what they think I look like. That's one part of me. I didn't have to tell you that. And this is me too. Again, you make the leap that this is me when I was younger and also that I was a huge dork. You're right on both counts. If you know me from Twitter and somebody says Ernie Miller to you, this might be how you picture me. But is it me? No, it's still just a photograph. It's an abstraction that represents me. But even when we go back to the painting, the portrait, that distinction seems almost silly, right? That's because of a shared understanding, a shared context that we have about pictures that's been ingrained over the course of millennia from the very first cave painting. It's sort of elemental. And we're able to build on top of that a shared understanding to express or create things that feel true. So once we believed water, fire, earth and air were the elements and everything was made from them. Now we know about atomic theory and the elements in the periodic table, but we also know that those don't exist without even something more elemental, the elementary particles. But given how useful it is, even on its own, the periodic table's not going anywhere. The jumping complexity between the elements and elementary particles, remember by the way, that we still don't actually understand how these particles work. The periodic table's still really useful as an abstraction. So how does any abstraction achieve that feeling of being true? What does it really take? How does it become elemental? It does so by being pervasive, persistent and practical. So elemental abstractions are everywhere and they have been for a long time. They might be made of more elementary things, but they're useful on their own and even without understanding what's underneath. Modern web applications like the ones you're probably building, they're compounds really of four elements, HTML, CSS, JavaScript and state. You could be forgiven for swapping state to SQL or something like that, but really it encompasses whatever gives the actions in your application some impact on the system. And there was a long time during which I had these sort of partially formed feelings about certain abstractions that I struggled to explain. As developers we tend to talk about things like leaky abstractions or violations of the principle of least astonishment. But those words are just proxies for what we're really feeling, which in the first case are a suspension of disbelief. So disbelief has been broken because we were forced to understand how things worked under the hood. And in the second we already had some context for how things worked and the abstraction broke that reasonable expectation that we had based on that context. And that's when it actually dawned on me. There was a reason I had such strong feelings about these abstractions. I was a naive young Rails developer and I was attracted to shiny things like we all were when we were naive young Rails developers. They lured me in with promises of a better world. They told me they were gonna lie to me for my own good and make things better. But it turns out that road could only end in heartbreak because they were lying to replace something elemental. Who knows what that logo is? How many of you are familiar with Hamel? How many of you like Hamel? I'm sorry. So when Hamel came along I took one look and I was like, yes please. It looks so, I mean look at it. Look how clean it looks. So elegant. But while Hamel will generate valid HTML, valid HTML is not valid Hamel. You can't try it. Try funneling it through and see what happens. And it was the same thing with SAS whenever SAS was first coming out. It looks so pretty. It's got variables and nesting and mixins and those are all things that I had longed for for ages in CSS that I mean I was like sign me up. But once again valid CSS is not valid SAS. Forget you ever knew CSS. What about CoffeeScript? Any fans of CoffeeScript? A few, a few. Look how pretty it is.  And this if I squinted it almost looked like Ruby. And I love Ruby. So you're probably seeing a pattern. All of these things attempt to stand in for something that we can't escape. When we debug our applications in the browser there's still HTML, CSS and JavaScript. There's no amount of source mapping that's gonna change the reality that lives underneath. So we've got these abstractions that stand in for something elemental but they ask us to forget what we already knew even though the browser's not gonna forget it. And there's gotta be a better option. I personally think a better abstraction to replace HTML is just embedded Ruby. It gets it right. A plain old HTML file is still perfectly valid if incredibly boring embedded Ruby. You only really trigger the Ruby interpretation whenever you ask for it with special tags that aren't HTML tags and that part's important. We're extending, not modifying. SCSS gives you all the good stuff in SAS as a superset of CSS. And the same thing with ES6 or 2015 or whatever the heck they're calling it this month. It extends what you already know to be true. So it feels natural. But that's only three of the elements, what about state? So back to the beginning. You may remember I was mildly stressed out by having agreed to do a talk in eight weeks. And I didn't have a working application. I had punted on a lot of things for that proof of concept. Stuff like loading actually a real slide deck and I was just hard coding slides in there. It was horrible being able to actually have some speaker notes actually rendering attractive slides as you might remember, they weren't terribly pretty before and they had to be written and marked down. And so that being said, the application continued to be a breeze to build. I got the basic presenter UI laid out, complete with slide preview notes, connection info. I got slide loading and voting functionality built out. Then I got it rendering properly on a number of browsers. And to tell the truth, actually the hardest thing about this application was getting the CSS to play nicely. The fact that you probably can't tell the difference between those two screenshots is a testament to how stubborn I was actually. Then as I started building the talk, I'm like, ah, it would be nice to reuse this voting thing to like vote in just general like bar charts sort of polls instead of branching votes. And it would turn out to be something I could do like in a couple of hours. And oh, maybe images should have captions. Okay, I can add that, that'd be fine. And oh, when I use images, I need to find a way to include attribution because it turns out people like to be attributed for their work. And I like to use quote slides and that would be great if that just worked. And then I'm building part of the talk that discuss distractions and I'm thinking about how distracting chat applications can be and everybody's already connected to the server so why not just make a slide that's literally a standalone chat application so that everybody in the conference can actually talk and be distracted during that part of the talk. I was later told by someone who attended the talk that this was the most beautifully over-engineered talk they'd ever seen. I took this as a compliment because it was a pleasure to build, so why not? I'm not overstating when I say that I had more fun, more joy building this application than anything that I'd built in the past. For the most part, I didn't feel like it was even building a web application. It was just like building an application and it felt like using an application. And I think because I managed to avoid dealing with all the pain that was caused by one lie that we've been living for so long, we started to think it's true. You can totally fake this, but building a stateful application on the back of a stateless protocol is kind of weird. And we've spent decades figuring out better ways to fake it, but the fact is traditional server-rendered web applications are a huge hack. I'm surprised they work at all, actually. And I mentioned before that I had been into programming through systems administration. As a system man, I'd SSH into a server. I was starting processes that forked other processes. I had like Exynet D was managing processes. It was all processes and never, not once, while I was in an active SSH session, did I have to stop and like resend some credentials manually to tell the SSH server, hey, this is me. Like I'm still me, which in HTTP we do all the time with cookies and session storage and all kinds of things. Did any of that sound familiar? So the elemental abstraction for state is a process. And I think this is a big part of why we generally say that threading is so hard. As though Erlang and by extension Elixir had said, you know what, we can't really get away from dealing with processes. So let's just call it what it is and try to make it as lightweight and honest as possible. And that's like serious judo move right there. And I think that's why I found this application such a joy to build. There's something truly special about an honest abstraction. Pretty much everything in the app came down to processes and messages. And from the moment the React application had connected the Phoenix web socket, it was just another process and system as far as we were concerned, communicating via socket. Socket processes there on the left, the user, they knew whenever the person connected, whether they were a presenter or an attendee, gave them the right rights. And really everything even in the React side was just messages. They were actions dispatched, but they were messages vice versa and whatever they would, they'd get translated back and forth through the web socket. And since the UI was just the result of a function applied to the current state of the application, everything just was very consistent. It felt really honest. And that's what I really love about Ruby right now is that we're planning to bring some of those capabilities to Ruby. Guilds, at least as they've been described so far, and I checked with Koichi to make sure this slide was not inaccurate. They almost feel like many processes that have their own sort of state within the Ruby process. So where things need to happen in parallel, we can wrap them in a guild. When they don't, when the guild just needs access to object state, those objects can just live in that guild and you get away from all that extra ceremony. So we kind of get the best of both worlds. Let's ignore for a second how we're gonna split out those user socket processes. I think we've still got plenty of time to figure that one out, but I'm just happy we're gonna have some new tools that will help us tell more helpful lies. Because that's what a good abstraction does. It helps us suspend disbelief. It helps us treat a lie as something true. And I don't want you to miss the really important bit here. The real power of an abstraction lies in its ability to affect perspective. It lies in its ability to free our minds to think about something else. We can consider new possibilities. Every day, every line of code you write has the opportunity to create this kind of perspective shift for the people who use it. So make your lies great ones and may your users always feel that ignorance is bliss. Thanks.