 These are my slides. I came here a long way from Berlin. That is, if you want to walk there from here, that is a two and a half month walk. And why I'm mentioning this is because apparently there is a theme here. Who was here for last year's conference? And last year, the keynote speaker, Chad, was also from Berlin. This is a photo of us, obviously, in Berlin hanging out on a camel. That's what we do in Berlin. So next year, your keynote speaker will probably come from Berlin, too, I guess. It's just a given. Anyhow, I think we're already behind in time, so let's get started with the talk. I'm not actually really going to talk about Sinatra. In case you didn't notice, that's what I'm the maintainer of. I'm going to talk about abstraction. And I'm going to talk about abstraction on quite an abstract level. But I'm also going to talk about color. I'm going to talk about magenta. Not magento, not magneto, magenta, or anything from the purple violet spectrum. This talk is very, very meta. And I like to open with a quote that is my motivation, why I want to talk about abstraction from Douglas Adams, who says that anything that's in the world when you're born is just normal. Anything that's invented between your 15 and 35 is interesting and new and shiny. And anything that's invented after this is against the natural order of things. And I want to talk about computer science and color perception. And this talk might be kind of confusing because I'm jumping back and forth between things. So I thought, I'm just going to start with a conclusion. Usually you put the conclusion at the end. I just put it at the start of the talk, just to be sure what I'm talking about. I think that abstraction happens in our minds. Abstractions shape how we perceive things. Changing abstractions is a basic principle of innovation and progress. Abstraction, I think, is the basis of computer science. Would you agree with this? Is this some nodding or head shaking? I actually think abstraction is the basis of science. And science rocks. Without abstraction in computer science, we would always be talking about transistors. Actually, that's already an abstraction over how electrons move in medium. But without abstractions, when I write my web app, obviously, in Sinatra, I would just be thinking about the transistors I need to survey HTTP response. But instead, we can write code like this without having to worry about the hardware it's actually running on, speaking of electrons. So this is an atom with electrons. And the lowest energy that an electron can have and its current state is called the ground state. And when the electron or the atom has a higher energy than its lowest energy, it's set to be in an excited state. And because these states of the electrons occur only on distinct levels, they are set to be quantitized. And that's what we call quantum mechanics. And so these electrons are excited, which means they are flying on a higher level farther away from the core. And then at one point, they just jump towards the ground level, releasing a photon. And then that is what we generally refer to as light. Well, actually, only a fraction of that is what we refer to as light, because that is the visible spectrum. That is the light that we can see. And the frequency here depends on how far the electrons jump. So therefore, we see different colors for different frequency within the visible spectrum. And humans have their vision works by a principle that's called trichromacy. That means the retina in our eyes contains two types of photoreceptors, rods and cones. And the rods are the more numerous, and they're more sensitive, but they're not sensitive to color. And the cones, of which we only have 6 to 7 million, compared to 120 million rods, they're sensitive to color, and they're more concentrated in the center of the retina, called macula. And there we have three different types, generally. We have cones that are more responsive. So this is the frequency, and this is the sensitivity of the different types of cones to light at that frequency. So we have cones that are more responsive to blue. So we will, if there's light of that particular frequency, then the blue cones will have a very strong sensation, whereas all the other cones will have a very weak sensation. And the same happens on the other end of the spectrum, where our red cones will have some sensation, but our blue cones won't have any sensation at all. And you might notice I'm jumping a lot. This is intentional, and I hope it will all make sense in the end. So patterns and algorithms. There was a very interesting book that I already recommended to someone yesterday or two days ago. Came out in 1977, called the Pattern Language, by Christopher Alexander and others. And it's the second book in a three-book series, the first book being the Timeless Way of Building, and the third book being the Oregon Experiment. And in this book, Alexander argues that to be able to talk about architecture in general and starting from interior design to building your house to designing a city, you need to have a common language to refer to the patterns you're using, the style you're using for building, the principles you're using for building. And this was so influential that it inspired software developers to try to apply the same principle to software. What came out of this is a book called Design Patterns, by what's usually referred to as the Gang of Four. Came out in 1994, and that's where we get principles like singleton classes, fly whites, and so on. And a lot of things we use today to communicate about software comes from this book. And there's also a nice quote by Christopher Alexander, the architect, who then wrote the foreword for one of the authors. No, actually not. For Richard Gabriel's book, Patterns of Software, which came out two years later. In that book, he says, I would hope to see examples of programs which make you gasp because of their beauty. Perhaps, too, a knowledge more widespread in our culture so that people outside the field, lay people like me, could also begin to grasp the beauty of programs. And I think for that, we need abstract concepts like those patterns to reason about software, to reason about what is beautiful software. We need concepts like algorithms, which is a word used by programmers, if they don't want to explain what they did. So who can tell me what algorithm this is? All quiet? Yes, it's a sort algorithm, but quicksort, yes. Feel free to just yell at me. I'm probably not taking questions, so just yell things. This is quicksort. And this has nothing to do with what does actually the program do that's using quicksort. It's just an abstract algorithm. So let's talk about those cones. These dots represent the cones. And where they are on the slide represents their sensation or their excitement. And I simplified here, pretending that they're very distinct for certain frequencies. So imagine those are your cones. You don't see anything right now. They don't have any sensation. It's dark out. And then there comes red light. And your red cone feels the sensation. And your brain says, yes, this is red, I notice. Or green light. And your green cone feels the sensation. Same for blue. Now there are more frequencies than just red, green, and blue. So when you see yellow light, both your red cone and your green cone will feel a sensation. And your brain will then know that the frequency has to be somewhere in between those two frequencies. So it will show you yellow. But what happens if you feel a sensation in both the red cone and the blue cone but not in the green cone? In that case, your brain would assume that the frequency or by the logic with frequencies being in between the cones that feel the sensation, it should probably assume that it's in between red and blue and right in between red and blue is green. But it can't be green because otherwise you would feel a sensation in your green cone. So at that point, you could argue your brain makes up a new color outside the spectrum. That is magenta. While what actually happens at that point is you see light that is a mix of two different frequencies, red and blue. Our brain just cannot tell the difference. So it's magenta real. And you actually see this when you write CSS. This is the CSS hash code for the color magenta. And you see it has all the red light, all the blue light, none of the green light. And this representation is an abstraction over how we represent color on our monitors. Our monitors aren't actually able to produce all the colors. They just have red, green, and blue dots. Three of them make a pixel. And you might argue that for some, this is a leaky abstraction. I'm going to go into this into detail later. But an interesting thing that comes from that is if you take color pictures, some cameras take separate pictures for contrast and then red, green, and blue. And an example for this is satellites. So Google Maps takes pictures in that way. And if you have a fast-moving object, you will see the different colors on this photo. So in the world of computer science, there are different kinds of abstractions. The first one, I'm going to take a historical look. The first one that really came up historically after we had the abstraction of software to begin with is data abstraction. So the first book I read when I was a kid on programming, the first chapter was about picking your right data types, your data structures. It's your data structure determines if your program is a good program or bad program. If it will perform well, it won't perform well. So this book was arguing that before you write any code, sit down and think about the data structures you're going to use. And who here does that? Raise your hands. Who here does that? OK, maybe I should talk to you guys later because I don't do that. And in 1967, there was a paper arguing that you shouldn't do that. It's called Dataless Programming that basically how people, how I just explained it, how people write software right now, is they think about the data types, they pick them, and then they write the code accordingly. And that might get you into trouble when you later on realize you need a different data structure, so you basically need to rewrite your program. And it argues that we should have programming languages and use them in a way that they allow us to write our code independently of the data structures we will be using, which today is a thing I would argue most people do, and we refer to this as our business logic versus our persistence layer or memory management, et cetera. Space. Space is big. You just won't believe how vastly mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemists, but that's just peanuts to space. Who here is fascinated with space? OK, it's more people than thinking about their data types, I like it, but that data structures. So there's a lot of space out there, but in index space, there are also some interesting things, like planets and stars. And apparently, we're all supposed to be made out of star stuff, or today, sometimes, it's referred to as star dust. Well, actually, as a side note, I like to geek out on things. If you ignore all the space between the atoms that we have in our body and just count the atoms, we're actually just 38% star stuff because the rest is hydrogen. Hydrogen is the base state, the atom that has not been created by fusion, so it's not actually made out of a star factory. At this point, you may say, wait, wait, what? Are we still talking about abstraction? Yes. At least, I think so, maybe. Because I'm talking about the periodic table. So the interesting thing is, in the beginning, I talked about the electrons jumping towards the core and then releasing photons. And how they jump depends on how the light they emit depends on how far the electrons jump, and that depends on how many quantum states an atom has. And that relates to how many protons an atom has. And as you know, the numbers in the periodic table correspond to the numbers of protons they have. So from the light that atoms emit when you make them glow, you can tell what kind of atoms they are. So you get emission lines. And do you know what the emission spectrum and the emission spectrum of iron and a cat have in common? They're both felines. Anybody know? Could be a dead joke, I guess. So this is very, very useful for determining what's in a star, because stars do fusion and they have glowing atoms. And then we see the light. And then we just need to measure the wavelength. And then we get those nice diagrams. This one's actually better. That shows the different stages stars go through. So you can determine their content. And combined with their size, you can then determine how old those stars are. There's a problem here. You can't really use a normal camera for this, because a normal camera doesn't store the wavelength. It just stores the value for red, green, and blue, because that is how we see it. So that would be a leaky abstraction at that point. That doesn't allow us to use normal cameras. If you want to know how you actually do it, come to me later. That would be too much for this talk. So besides state abstraction, there's control abstraction. And this is something we take for granted today. But those were groundbreaking ideas at the time. The first idea for control abstraction were subroutines. It's a piece of code you can put somewhere else, and then you can jump to it, and then it jumps back. This also later on brought with it reusability. And a lot of public debate. So in 1968, Dijkstra published his famous letter. It was not a paper, it was a letter. Go-to statement, considered harmful. And then in 1973 came another paper, or this time a real paper by James H. Morris Jr. called Projection and Programming Language, in which he argues that the ability of programming language to isolate program in modules is vital. In that paper, he also argues that you should be enforcing this isolation. And he then goes on about protection mechanisms and how you can sign or encrypt data structures so that other parts of the code don't meddle with it. Which I do think today is no longer really necessary because we have the conception of public APIs and data you're supposed to manipulate and data you're not supposed to touch. But the important thing that came out of this paper is that you should be able to reason about modules and isolation. And this then, for me, lies the founding stone for things, the foundation for things like test-driven development and libraries, reusable code in general. Other things that came out of the 70s were ideas like global state, global variables, that those are a thing you should avoid whenever possible. So I said humans have trichromacy. But there is also a condition called tetrachromacy, where you have four different cones. And typical beings that have four different cones are zebra finches and goldfishes. So they have four different cones are sensible to four different wavelengths. The last one is in gray. It probably isn't gray for them. But we can't actually tell what color it is. Well, it would be ultraviolet, but what color is ultraviolet? And this allows them to see millions of more colors. So you could argue that our screens are not really made for zebra finches and goldfishes because pictures in red, green, and blue do not fully represent the world they see. But what do we care? We're not making video games for zebra finches yet. So it turns out this is a condition that is also relevant in humans. This paper specifies a method to figuring out how many different cones you have. And if you look into it, there is a wide range of statements of how many people are affected by this. There's a genetic mutation where you have more than three cones. And depending on the source you read, it's anywhere between 2% and 3% of all women. That paper in particular says it's 12% of all women. Statistically, it could be 50% of all women. But why women? Well, so our cones come from a gene on the X chromosome, or actually two, OPN, 1MW, and W2. So that can give you three different color cones. So if you only have one X chromosome and one Y chromosome, you can have up to three different color codes. But if you happen to have two X chromosomes, you can, in theory, have up to six different color codes. But those are mostly dysfunctional. There are actually a few confirmed cases. I've found at least six different cases, of which two are 100% confirmed, with the method described in the paper to have true tetrachromic vision. And the first truly confirmed case was in 2012. And as I said, they see 99 to 100 million more colors than we do. And this phenomenon was actually known before, because this also happens in new world monkeys, where the male monkeys usually only have two different color cones, and then the female monkeys have three different color cones. Interestingly, there's actually an artist from San Diego. She has tetrachromacy, and she is painting the world the way she sees it. I don't think you can really tell with the light, but there is a lot of pink going in there. And the interesting thing is they don't just see more colors from the spectrum. If you imagine to have four different color cones, there's also more colors that are not on the spectrum that your brain needs to make up. There is not just the one where you just have the outliers, but there are all kinds of combinations. And you could argue that for them having RGB as our generally accepted color representation is a leaky abstraction. So object-oriented programming. Who knows who this guy is? Yeah, come on. Any guesses? Santa Claus? It's Ellen Kay. So when I first saw this picture, or when I first used this picture in the slide, the Sean Cripps Holding Things meme was very popular. Has anyone seen that? No, me. Am I the only one? So Sean Cripps is a developer, and he's holding things. So I did the Ellen Kay Holding Things. And then at the time, someone took a picture of me while I was talking about this and created Ellen Kay Holding Me. So this is Ellen Kay. Who has heard of Ellen Kay? He's generally referred to as the inventor of object-oriented programming. And many more things, actually, also the inventor of the laptop computer, graphical user interfaces, and so on. Obviously, he didn't do it alone. He worked at Xerox Park at the time. And he worked with another guy called Dan Ingalls. And one day at Xerox Park, they got a visitor. And Dan showed him around. And the visitor was this guy. Who knows who that is? Yay, raise your hands or whatever. You're very quiet as an audience. Yes, this is Steve Klamnik. No, Steve Jobs. And there's this famous quote about his visit where Dan showed him around saying that they showed him three revolutionary things. And he didn't see the first one, which was object-oriented programming. He also didn't see the second one, which was networking. They had all the computers there in one network, which was revolutionary at the time, because of the third thing they showed him, graphical user interface. This is the graphical user interface they showed him. And it was a major influence on macOS. This particular graphical user interface is Smalltalk 80, which is both a programming language and an environment to program it in. Today, one of the successors of Smalltalk 80 is Squeak. And this is what it looks like today. And this was one of the very first fully object-oriented languages, where a lot of the ideas of how object orientation works comes from. And when I talk to people about object orientation, so two days ago, I was told that JavaScript is not object-oriented because it doesn't have classes. So you could make a point that JavaScript is not object-oriented, but it has nothing to do with classes, because object orientation has nothing to do with classes. Ellen Kay says that object orientation is message-passing, hiding of state process, and extremely binding of all things. So you could argue that object orientation is what you get if you combine data abstraction, control abstraction. So why are those cones dysfunctional? This is my own ideas of why they are dysfunctional from reading different papers and resources. I think it's because we don't see colors with our eyes. We see colors with our brain. I mean, think about it. Our brain, it just colors. Like the light coming out there is red and blue, yet this looks somewhat white to me. And that's because my brain tells me it's white, not because it is white. Moreover, I think that we don't see colors that we don't have an abstract concept for. And there's actually something that's called the Sapphire Wharf hypothesis, or linguistic relativity, which says that the structure of a language affects the way in which its speakers perceive the world. And there's a strong version which says that it determines how we perceive the world, and a weak version says that it influences how we see the world. And think about it. How many colors are in a rainbow? Any guesses? 5, 7, 10? It's 10? 7? Wrong. Millions. Those are fine gradients. There is no border between one color and the other. Yet we see, I see distinct colors. That is because I train my brain to see those distinct colors. I've trained my brain to teleport green and blue. Interestingly, when we learn to speak, the color perception of our brain switches from the left brain side to the right brain side. And that's because the part of the brain that is used for color perception before we are able to speak is then used for language. That to me also means that there is a certain link between language and color. The thing I love most about programming is that we make the rules. And some rules enable good programs. There's a single responsibility principle. You heard of this? No, yes, yes. There's a list curve substitution principle. Can anyone, has anyone heard of this? List curve substitution principle. Can you define it? No, that's wrong. He says you should. So what he's trying to say, I think, is that if you write code for a class that should work with a certain class, then you should be able to substitute that object of that class with an object of a subclass of that class. Is that what you're trying to say? That is wrong. Because when list curve formulated this principle in 1994, not even calling it list curve substitution principle, she didn't really know about classes. It's about types. So it's almost correct, but instead of class and subclass, it should be type and subtype. There's a law of demeter. They're solid, which is actually multiple principles. Does anyone know which sub-principles these are? Yes. Gold star. And then the principle, I don't know if this is really a principle, but something that I myself think it's don't abstract too much too early. I once in a while get a pull request for Sinatra replacing those one line methods with code to generate those one line methods. It's then only two lines shorter and harder to read, in my opinion. And strong external abstractions allow weak internal abstractions. What I mean by that is imagine distributed applications. So we at Travis CI, we are a fully distributed application. And the best thing if you start having small apps and only really do one thing and have a well defined, say, interface API over HTTP, is in that small app, you can use whatever technology you want. You can write the crappiest code ever because if there's a problem with it, you can probably rewrite it in a day or two. So is magenta a color? Yes, no? Any takers? What will you say? Yes, yes, yes? Yes. So those are all the colors that or these are the colors we generally see. And only the colors on the outermost line are colors with a single frequency. And then here's cut off. So this is all where green is missing. And all that in there I would refer to as colors. So yes. So I need to hurry a bit. Inheritance. We just talked about this. Inheritance is used for multiple things. It's used for type hierarchy. And my sound is off. It's used for type hierarchy and implementation sharing. Those are two different things. Yeah, just give me that. Hello. Hello. So inheritance classes are used for type hierarchies and for implementation sharing. And this gets even more complex with mixins. And I think both use cases are valid, but we really need to think about when to use inheritance. And I think people should, especially in Ruby, rely more on composition because mixing type hierarchy and the implementation sharing can be very hard. And you can even have type hierarchies without inheritance, for instance, with that typing. So are we doing it right? I think that's something we should really think about. And as I said, classes are not necessarily object-oriented programming. So color and abstractions. And this is where we come to why I keep talking about color in this talk. So there's this theory of language evolution with how we perceive colors. And this particular book is very much debated because not because so everyone agrees in linguistics that the further we go in civilization from hunter-gatherers to farming and so on, the more colors we learn. The thing that's controversial is the order in which we learn colors. So many languages, especially in their early stages, do not have separate terms for green and blue, which makes it really hard to tell apart green and blue. So these are the civilization stages in the book and which color terms civilizations have at one point. And there's the Himba tribe in Namibia, which is well known for putting clay in their hair. And they have different vocabulary for colors than we have at different lines. So especially green and blue are all over the place, or what we would refer to as green and blue. I think, at least in Hindi, it's very similar to English, where the borders are. But in their language, not at all. So they did a test with them, where they showed them two different pictures. This is the first one, and they were supposed to show which square has a different color. And it's blurred out. But can you spot which square has a different color? So there are like 12 squares here. Yeah, that one. That one's blue, and the rest is green. So they sit there for quite a long time staring at it. And after a few minutes, they can point at the square. However, shown this picture, they instantly see the square that has a different color. But it's even hard to see on my screen here, but it's that one. And I know that because I watched a video of them pointing at the square. They see it instantly. Abstraction is also a security issue. Most attacks rely on switching abstraction levels when the people building the system didn't expect it. And you might be switching down like in a Heartbleed attack, where you switch down to the implementation level, conceptually SSL will secure, but this implementation was lacking a check, so Heartbleed. Or you could switch a level up, where you, for instance, just rely on people reusing their passwords for all the services. And then you can just log into their iCloud account and steal all their private photos. Or even go to social engineering. Someone was adding fake entries for the US Secret Service and the FBI on Google Maps right next to where the actual FBI and Secret Service was with a fake phone number. And then he was proxying the phone call to the FBI. So people called the FBI complaining about a potential terrorist attack. They were actually calling that guy. He was recording the whole thing. And no one knew. Abstractions are just everywhere. But abstractions only exist in our mind. Business logic is not something the computer actually knows about. The computer only has transistors. Business logic exists in our minds. Object oriented programming exists in our minds. Colors, UI elements, countries. And this doesn't mean they don't exist or are bad. But they only exist as concepts in our minds. Conclusion. Abstraction happens in our minds. All abstractions. Abstractions shape how we perceive things. Changing abstractions is the basic principle of innovation and progress. Thank you. And may the force be with you.