• Josep M. "Txus" Bach

    Programming the future

    >> Alex: Okay, next up, we're very glad to welcome a Barceloean residing here in Berlin, he has many talents, among them is running Baruco, the Barcelona Ruby conference, he's a language geek, he loves Clojure, he also loves Ruby. >> I do, still. >> And he has this remarkable ability to predict the future, sore something like that, he will explain everything now, so thank you very much for being here today, honor have you, pass it over to you (Applause) >> Thank you. So, can you hear me? >> No. Okay. >> You hear me now? >> Yeah. >> Okay, so, Alex got just one thing wrong, and that is that I'm not Barcelona, actually. Those who think ‑‑ who know me, they don't, so you're in for a great surprise. So, this year, 2037 I was born in this year. In the ‑‑ in the United States of China. And, I miss my country, I really do. Germany is pretty okay, though. And 2064, I am majoring in computer science in the Pyongyang institute of technology, one of the best tech schools in the free world. And while I'm studying there, because I have some free time, I also work for Google, and I'm an intern there. Specifically, I work in this project called "google settler" one of the biggest, that they have, you obviously you don't know it, but it's a massive space colonisation project and it's really really huge. There's a lot of hardware and a lot of software, and I work on the software part. It's almost 4 million lines of code, it's huge and it's very worrying because ‑‑ it's mainly Go, and, some JavaScript, I work mainly on the JavaScript part, and there's some Bash, as well, 1 percent is a lot of Bash from four million lines, so this is not very nice. What's worrying though is that this project is getting so, so slow, it's impossible to develop new features, we're stuck. And Google keeps putting just trillions and trillions of dollars on it. This is very unfortunate because it's not the only instance of this, the whole industry, the whole software industry is at this point. We cannot ‑‑ no one can really develop big systems because we just don't have the tools or the languages to do it. So, this ‑‑ one guy if this project, Lyn Bohoi, he just one day decided this was enough and started leading a kind of shady unofficial project called Renaissance this project is basically doing some research on programming history, and trying to find a point in time where things could have changed, so where we had the tools, and the ideas to kind of, you know, step up, but we didn't do it for some reason. And then, the second part of the project is sending people back if time and trying to push those ideas, the thing, the only problem is that time travel was outlawed by the United Nations after world war III, so it's very secret, they cannot just send anyone, they send interns because no one will ask if they cannot make it back (Laughing). That's why I'm here, they sent me, and I hope they will let me go back. This is programming the future, I'm Txus, some of you thought you knew me, you don't, the first question that we should ask, sounds like, obvious, but who is programming for? Any ideas? >> Dummies >> Everyone. >> Yeah, everyone, humans, but not machines. So, if we keep that many mind, we can start deconstructing some ideas that we, I think we take for granted in programming, and, I think they should not be like they are. So, the first thing is that we use, still, I say "we" in 2064, but you also used text‑based systems, and "they" in the past also used text‑based systems. You all know how it works, you're programmers, you write some character in a text file with some spaces and some new lines and stuff, and then just put it in a Compiler, and the Compiler does so much tragic and then your program runs. This has a number of problems. The first thing is we should ask ourselves why string, why is code just a blob of text? Paul Phillips made this interesting observation, and it kind of struck me, like, Hey, this is not obvious, we just take this for granted, code should be a string, maybe it shouldn't. So, the fact that code is a string has a number of problems, one, it has a huge mental translation cost. So, when we read code, we kind of parse it and try to reason about it when we write code, we generate code from our head. So, this translation cost is actually very taxing and very error prone, which is the worst because we don't always understand what we're reading or, you know, we don't always get right what we write. So, we want something more direct. Something that doesn't have this extra step or at least makes this extra step like smaller. Also strings are a flat representation of code, and this is important because we don't think of code as something flat. We think of code as something with depth. We think of modules and dependencies and stuff like this. This is not well capture in the the notion of text just a file of text, even if it's different files. And also, it's a representation and if you look at this, this is not a pipe. This is not. What if we wanted to see the pipe from the other side? We couldn't. What if we wanted to smoke the pipe? Could we? Not really, this is a picture, it's not a pipe. So with this we cannot do anything but just stare at it and imagine what it would be or something, that's exactly what we do when we look at code, so we cannot touch it, we just look at it, and imagine what it would do if it was real. So, we would like to strive for a more life representation of code ‑‑ live representation of code, to get more of a direct feeling with our program, as we write it. Then, another problem of text is that there's this low feedback, you write some text, compiling, see what it does (slow feedback) in some cases you know how to use a debugger, I did not know how to use a debugger, most people do not know, most people use print statements, which is very primitive, but it's the way it works, which is very sad. We want something more immediate, so we want to change something and see the reaction and then kind of, you know, poke around with it and get an idea, get a feel for the system we're building, especially if it's not ours, if we just go into some system that someone wrote and we want to understand it. So, this is just a fancy way of saying interactivity. We want interactive code or like an an attractive environment. This is very important because of how our brain works. So we are capable of understanding pretty complex systems, such as physics, when we get an object and we feel it a little bit and we throw it, we probably will hit a target, and we don't, we don't know about gravity or mass of the object or anything, we don't really know about that. We just kind of do it. And it works, and if it doesn't work if first time, it will probably work the second time, because our brain adjusted all the variables, observing from the outcome, from the first throw. So, this is a very powerful capability that we have, and that we don't exploit when writing code. You know, I think it's also how, you know, baby's learn about things, like they just see objects and they kind of interact with them in as many ways as they can, and then they get a feel for what they are, and what you can do with them. And, they don't understand those objects, they just know, you know, they kind of get them. So, in the same sense, the fact that we can interact with the system, very fast and get a response, gives us momentum, so, it gives us focus, of course, but my point with this slide is that ‑‑ you know, a quantitative increase in speed could lead to qualitative increases in things, for example like, standing on a bike, just, like this, it wouldn't work it's stopped and you would fall, if you go with a certain speed, it's fine, with planes, it's even more obvious that you cannot take off unless you're going really fast. So, that's my point, that if we achieve this speed when trying to interact with the systems, we could probably achieve some thought patterns, some ideas that wouldn't have been there otherwise. So, visual metaphors are very powerful. This idea is not new, in your time you actually get some people who already think about these things like Brad Victor, he played a lot with these concepts of building systems with visual metaphors. And you learn from the outcomes and then you create a mental model of what you're building. So, if you haven't seen this talk, you should see it. I think it's ‑‑ I think it's definitely out by 2014, if not you just keep going that link and it will eventually be there in the following months or years. So, Barbara Liskov says "programming Los Angeles are the way programmers think about writing programs" this seems obvious on technology, it's not, they actually enable how we think about programs, about writing them, and they can also con train that. So, it's really important that we look at the tools we use to kind of offed develop ideas and build those systems that we want to build so the tools are essential. They are not just a tool. Some people think that with any tool and enough patience you can build anything, but that's not the case, I think. So, if we consider programming as just what it is and we remove all the incidental complexity, the set up, the tools, everything, we could maybe argue that it's data transformation, Christianer, the guy behind light table he said that, and I thoughte thought, wow! If you think about it, programming is data transformation, everything else is just a hassle that we have to do to just get to this, data transformation, you get some data and you want to convert it into something else that's more useful. So he thinks that programming is unobservable, indirect, and incidentally complex, which is, I think, you all can agree with that. We cannot see what we do, because it's ‑‑ a running program is completely different from our source code that we read, it's indirect for the same reason, it's sine insent tally complex because wow have to learn all these things and set up just to compile a hello world program (Incidentally) in any language, even Ruby, you have to install Ruby. We would like programming to be visual, I just made a leap there, I see one unobservable, I could say observable, I chose visual, I chose to say that because I think it's an interesting idea to try out. I'm just throwing ideas, I don't know what the future is, I've only lived the future that you built, which is not pretty nice and not so different from what you have today, but I'm pretty sure that you guys can change that. So we want something interactive and we want something simple. So, in the '60s, there was this idea, as you see it's not a new idea, data flow programming, how many people have heard of data flow programming? Okay, how many have used Excel spreadsheets? Many more, I think this is a nearby idea that kind of got ‑‑ Niche idea that got stuck in Excel spreadsheets and music software, I think it's interesting to see as a general programming paradigm. What is it? It's declarative, which means that you don't, you don't define the when, you define the what. What to do, but not when to do it, it's more, and not how to do it either because there's no when, it's concurrent by default, so, this is pretty handy. I think. Let's see how it looks, imagine that we have ‑‑ we had this, and this we will call a unit, this thing. Let's think of this as a function that operates in streams rather than values, and, it just takes two numbers, and, outputs, the, you know, sum of them. So, when it's like this, just a suspended computation, so it doesn't do anything, it just sits there and doesn't really do fig. Then, as soon as it gets one value in one of it's inputs, the red wires is inputs and the green one output. It needs all of it's inputs fulfilled, so it does doesn't do anything. But as soon as the other input comes, it emits the output, as you see this is called data flow, you see the data flowing through thing as it comes and goes. So this is very simple, it's a very simple idea. We could try and apply some more ideas to it if ‑‑ functional programming has had great ideas about reusability and composing functions and, I think we could apply a lot of this today that flow programming. So let's imagine that units are the only primitive of this hypothetical programming language we're talking about. So, everything is built out of units and there's no special thing. It's just units. Then, if we make them generally pure, most of them, and, we keep some of them for the nicer things like IO and stuff like this, then we get really nice of things that come from you know, pure functions in functional programming, finally, if we get statically typed wires, then with all this, we can apply a lot of functional composition to these you fits, which are not like functions at all, but, you know, we could apply the tings. So, how do we do composition, imagine that we have two of these units with different RIDs inputs and outputs, so we could say that p the output of the left one and the input of the right one are the same RID one, and they are the same type then they are composeble, Jo us kind of fold them into this. So, this is like composing functions already, it feels so good, if you haven't done it, you should do it. How did we reuse codes, the concept of libraries, I write a library with some of these units and people can use them. Functional programming already solved that, we could have something that would called Functor units, very bad name, we could have units that wrap other units and deal with different types, for example. With that you could add then double thing in your library into your own types or whatever you have in your program, so, I think, this idea is pretty neat, but why are we not there yet? What are the challenges? We have everything, you have everything already nor 2014 to build this. But, why is it not there? So, I think there's a philosophical problem behind that. So, Alan Kay said the present is the least important time we live in. I think we're obsessed with the present. We are really thinking about the present all the time, as if it was the most important thing, so let me tell you something, the past has way more ideas than the present. Because the present usually forgets ideas from the past. So, and the future is obviously much more interesting, otherwise we wouldn't be doing anything. So, let's just not think about the present and try to get something from the past and think about how it would be in the future. And then my own quote: "The present is always the suboptimal outcome of the past." This looks obvious, but it's not. The present will never be the best possible present we have, impossible, no way. So, the idea behind this is we shouldn't get too comfortable with what we have, because it's definitely not the best. It's definitely not the best that could have happened, so we should always be critical about the things we use and the tools we use. Another problem, is almost engrained in human nature, technical Novelty vs wide adoption, a good example is UNIX, in the bottom part, so UNIX would be a very, very portable virus that spread very quickly although it didn't need to be the best one, it just was the most adaptable and the most portable and everyone started using it and everyone uses it now. And, another one that I could use is let's say Clojure vs JavaScript, in that order, I think Clojure is a delanguaging, and it's beautiful, but JavaScript is there ‑‑ in 2064 no one uses Clojure anymore, and people still use JavaScript (Laughter) I hope Rich Hickey doesn't see this. I want to share a quote, I was specifically told by the people at renaissance I couldn't share research or quotes are the feature, but I took the liberty to do it. (Laughing) I was at Google I/O, it was pretty nice in 2061, and, yeah, if you take something from this talk let it be this, be ware of local Maxima, because this is a lesson learned, I can tell you, local Maxima are dangerous because they make you feel good and you feel comfortable, but they are dangers. And another quote I like from Boh, I curse the day when software turneds back on computer science, because from that day we focused on just finding better answers, instead of asking better questions. It made me so sad that I decided to enroll in this crazy program to send people back in time, and I might not make it back home, but it's fine. I hope it wasn't ‑‑ I hope it was worth something. So, that's all, thank you for making history (Applause) >> Okay, so we have about fiver minutes for questions. >> From the floor: When you tab about data flow programming, I've heard the term, not too familiar, is it the same to functional reactive programming or ... >> I think in a they're related but data flow programming is an old concept, I haven't looked into functional that well, I think it's one of the most interesting things we have today, if you look at M for example, it's pretty interesting, I think that's a step in the right direction, definitely. >> Did Golang ever get generics? >> What version is now Go? >> 1 point  >> So it froze at 1.8 ‑‑ because it worked ‑‑ you know. They said, it works, let's keep it that way, and let's not invest anymore money in it. So it's 1.8. (Chuckles) >> Who is winning the soccer world cup in 2018 >> I'm sadly not interested in sports or lottery, so I cannot tell you anything. Can I ask a question to the audience. Because I've been in the previous talks, what is this MRI thing that people keep talking about? (Laughing) >> No trolling. (Applause) >> When's Rubinius coming out. >> It's already in it's version, six, actually, it's pretty successful. Yeah, yeah, exactly. How do you know? >> Okay, we have one more question if someone wants to ... >> From the floor: So in if future you don't like to use Go but what's your favorite language in the future, maybe you don't use it at Google but you wished Google used. >> My favorite language in the future, although it's outlawed, you cannot really use it, it's kind of shady, Haskell, no one uses it, because it's illegal, I'm sere use. It was too powerful. (Laughing) >> Okay, awesome, thank you very much. (Applause) (Talk by Txus)

    About Josep M. "Txus" Bach

    For the past few years Txus has been studying compilers and virtual machines, as well as developing web-based software professionally. His primary focus of interest is how programming languages and tools enable, shape and constrain the way we think about software. As a case study he is developing a new concurrent programming language that he uses as a playground for all these ideas.

    This talk

    For the past 50 years the art and craft of programming hasn't changed much. If anything, we have forgotten our history, repeatedly reinventing it poorly. The primitive tools we use today hinder us from building the robust software systems of tomorrow, and the new and shiny programming languages which we adopt every few years seem to systematically ignore decades of research in computer science. As programmers, we spend most of our work days fighting complexity by throwing more complexity at it. In this talk I'll show and reason about the need to take a step back and try to learn something from the rich (albeit short) history of our craft, which hopefully can give us some ideas as to how can we stop being slaves of our present and start being masters of our future.