Good morning, everyone. Welcome to the conference. Welcome to this talk. My name is Michael Soiman, and I am a functional programmer. Today, I want to talk about how, in general, in the software industry, we choose our languages, our libraries, and our frameworks. What I'm going to be saying applies to all three of those. Mostly what you're going to hear me say is going to be focused on languages, just to avoid saying those three things over and over again. The main question is, how can we do it better than we do it today? And I'm going to start this talk off by talking about my history of how I've chosen languages and how I eventually got to where I am today. I've been programming for about 25 years, and I've been doing Haskell for the past 10 years. So how did I get there? The first two languages that I learned, I learned in grade school. There was someone who came into our class and gave us a lesson on LogoWriter. Has anyone here ever heard of LogoWriter? So it's a little bit of a stretch to call that a programming language, but we'll call that my first language. I pestered him relentlessly throughout the course on how to do other things, and he kept telling me, no, you can't do that, you can't do that. And eventually, he relented, and he gave me a book on QBasic, or QuickBasic, towards the end of that course. And I had a DOS computer at home, so I was able to use it. And that was it. It's fair to say that that changed my life, and I became a programmer after that. But you may notice, choosing those first two languages was very, very easy, because I had absolutely no choice. This is exactly what was delivered to me. I had no access to other kind of information. Someone told me, this is what you're gonna do, and that's what I did. Later on, at the local bookstore, I was able to find on sale some book on Visual C++. There was probably some old edition of it. I didn't even have a Visual C++ compiler, but I somehow made it work. And I learned C++, and I did that for a year. And then Java became really popular. Java was gonna take over the world. Everything on the front end was gonna be done in Java. The web browser was gonna be dominated by Java applets. You all remember that, right? Yeah. Of course, that was obviously gonna be the case. Today, we're doing Java everywhere on the front end. So I learned that, because that was what the world told me I needed to learn. And then I did Java for quite a few more years. The language selection process for all four of those is pretty obvious. There was not much of one at all. I did not have access to a lot of learning material. I had very limited access to tooling. I followed whatever the obvious choice at the time was, whether it's because someone gave me the book or the world had decided that this is the programming language that I should be learning. All of that said, it sounds like I'm saying this is a terrible idea, but actually that was pretty decent criteria at the time, given the constraints that I had. However, something happened. We got the internet. We got access to a lot more information and a lot more material became available online. It became easy to get learning material, to get compilers, to download IDEs. All of this stuff was suddenly available. If I had enough time to wait for my 56K or 28K, whatever it was, modem to download the Java SDK or Python or whatever it was that I was gonna be trying out now, I could do it. And suddenly we were in the paradox of choice. Is everyone familiar with the paradox of choice? Have you guys heard this term? Basically, the fact that I had all of these choices available to me made the situation more difficult, not easier. There's still some defaults that remain, even in a world where we have access to a thousand programming languages available to choose from. If you're on a specific platform, you may be pushed in a certain direction. So if you're doing iOS development, you could do it in Haskell. You could do it in Rust.   These days, if you're doing Android, you're probably gonna use Kotlin, because that's what's recommended. A few years ago, that would have been Java, but that's fine, things change every time. If you're working on an existing code base, if you have been thrown at a project that is a 200,000 line C code base, you're probably not gonna rewrite it in Haskell overnight. You're probably gonna write that in C. And when you get thrown into some soul-sucking corporate job that has a corporate coding standard, you're gonna follow the standard because you wanna keep your job. So there's still some cases where you have a very easy choice. The paradox of choice disappears. What do you do if none of that applies? What if you're in one of these programming domains where you could use legitimately 20, 30, or 100 different languages? How do you choose which one of these you're gonna work with? Well, here's a non-starter approach. Fully evaluate every single one of these languages. You've got a project, I know. I'm gonna take all 100 languages that are available and I am going to implement the full project in that language, in every single one of those languages. This obviously is not going to work. It takes too much time, it costs too much, and I don't just mean the cost to the business or to yourself.   Theoretically, there's some kind of a deadline that you have to meet, so I don't think that's gonna happen. And at the rate that languages come out, this is actually a never-ending task. You will never be done testing every single language that you could be using. This by the way is Sisyphus, so he is constantly pushing the boulder up the hill. We will be doing the same thing with our programming languages. So obviously we need some help. And what I'm gonna describe now is the process more or less that I think most of us use today to determine which language we're gonna be using when we start a new project. We use some kind of evaluation tool. These things are gonna help us make that choice, which up until now seemed very difficult since we've already eliminated all of the easy ways of doing this. And what we wanna be able to do is we wanna be able to prune that set of languages. We want some kind of a system where we're gonna take that 100 languages, 200 languages, whatever it is, and we're gonna get it down to a manageable list. And manageable is probably very short. It's probably in the range of about five languages. And then we wanna be able to sort that in some kind of a priority queue and then start going through these things. The first tool that I think a lot of us use is benchmarks because we programmers love benchmarks. I've seen this personally. If I write a blog post and I spend weeks working on this blog post and I talk about how awesome it is to work in a certain language or I talk about some features or I teach a very deep technical topic, okay. If I throw together a benchmark in five minutes and I claim that something I wrote is 73% faster than the competition, everyone will get excited. That's just the way we are. Unfortunately, benchmarks can be misguided. We think that they are going to apply to what we're doing. Usually we're not testing the same thing that we're doing. We're usually testing something which is not the bottleneck in our program. One of the common examples is HTTP benchmarks and I've worked in that. Usually in most web applications, HTTP processing is not the bottleneck of your application. So as excited as we get when we see that one web server is 90% faster than the competition, you're gonna be lucky if you get a 5% performance difference from that in practice. Do not take this as me saying that no one needs to worry about performance. That is the opposite of what I believe. However, relying on benchmarks isn't the best thing to do. The thing about benchmarks though is that they are objective or at least seemingly objective and everything else we're gonna talk about is not objective. Most things that we end up talking about when deciding on a language are subjective criteria. And this is why I think benchmarks always come up as one of the first things people look at when deciding which language they wanna use. You get a graph, you get numbers. Numbers can't lie, it's impossible. We all know that numbers are absolute truth in all cases and we like that. But benchmarks are deeply flawed. All of that said, they are still valid and they should be part of this evaluation metric. If you have some kind of performance criteria that you must need in your application, looking at a benchmark and seeing whether something has any chance of needing it or not is valid. My only point here is I think we weight the benchmarks a little bit too heavily in this process. And we consider them objective truth even though we know that they can be misleading because as we know people in our industry have gone ahead and created misleading benchmarks and they may not be as relevant as we expect. All right, so that's tool number one. Tool number two is hype. We love to follow what everyone else is doing. If something is popular, it has to be good, right? No one has ever created a programming language which was massively popular but it wasn't actually that good in practice. If everyone is using it, it's gotta be a good thing. We know that this is deeply flawed. We know that this is not a good way of evaluating something but it does provide some signal.  So I'm not saying you get no information from hype, you get some. Let's change that term and not talk about hype, let's talk about reputation. Reputation doesn't sound quite as loaded and we'll get into why hype is such a loaded term in a sec. Reputation that a language has may be accurate or it may be inaccurate. Therefore, you need to know whom to trust. When you go through this stage of the process, odds are you're not going out to random strangers, you're probably going to your friends, your co-workers, your colleagues, people you trust and asking them for their opinions of these different languages. You can also observe market trends on the assumption that if dollars are going somewhere, if money is being spent in a certain direction, that's also some kind of an indication even if it's not the best. Of course, the best way to choose a language is to just trust Reddit. All right, so why is it that we hate hype so much? It's because of marketing. In our ideal world, how much hype a language has would be directly correlated to how good the language actually is. But we know that's not true. We know that it's possible to game the system. It's possible to make a language look better than it actually is by marketing it. And that's why we have this visceral negative reaction to hype and know that we can't really rely on it. So the solution to this comes down to something in economics, game theory. And I say you have to hate the game, not the player.  That's the only way to level the playing field. If someone in the marketplace is gonna be doing the marketing, everyone has to do the marketing, otherwise it's unfair competition. We'll get into this a little bit more later. One of the things that I think we are going to need to do in the functional programming community is do a little bit of this kind of marketing. But we have to do it correctly.  Okay, so I've gone over this process. Where are we now? We know that we have no default or obvious choice to make in this programming language. We've eliminated a few languages that are too slow to use. We've let reputation eliminate some others. We've come up with a list. And now we have a short list of five languages that could reasonably solve our problem, whatever that happens to be, has decent enough performance numbers and there's some subset of the world that you trust that likes this language. Finally, it's time for step three, on rampant. And this is the hard part. This is the point where you take these languages and you try to actually use them. This is hard. This requires getting used to these languages. You have to download tools. You have to figure out tools. You have to go through tutorials. You have to implement Hello World. You're gonna implement some kind of other example.   You're gonna get really upset that this language has curly braces or maybe that it doesn't have curly braces. Whatever the case is, you're gonna hate something about the language and you're gonna complain about it. This is a hard process and it takes some real time. But after going through one, two, maybe three of these languages, maybe you'll go through all five, eventually you are gonna figure out that one of these languages is the right language. This is obviously the best and you are gonna go ahead and implement your project in it and now language X is your language.  You identify that way. And I think this is a process that most people in this room have probably gone through to some extent in the past. Especially if you're at a functional programming conference, you've probably done that soul searching, looking for what the next language is going to be. There are problems with this approach. The process I described can easily take one to two months to make a decision. That is a non-trivial amount of time and a significant amount of work. From a business perspective, it's still costly. And I'm gonna claim that all of that is unavoidable. As much as we would like to jumpstart that process, we can't. Even if I go to someone and say Haskell's good, go use it, they're not gonna just listen to me and they shouldn't. They should do this analysis themselves and figure out what to do. So I'm gonna call these fundamental inherent problems that must exist, but there are two more other fundamental problems that are even worse. The first is the sunk cost policy. And this is another, I think this is my last economics reference, so don't worry. So the sunk cost policy is part of human psyche. When you've invested enough time and energy into something, you wanna defend that choice.  You put in blood, sweat, and tears into learning that language. And you don't wanna admit that that was a mistake. We are biased to defend the choice that we made. We chose LanguageX and no matter how much new information comes to our attention, we will, maybe not intentionally, but at least subconsciously, we will ignore that information to defend the choice that we made previously. This is a real problem. And we see this happen a lot in industry. Sure, many of us can see times in the past. I can, for sure. Sure, many of us can see times in the past where we fall into this. Second problem is really the point of the talk today. That everything I've talked about so far is at best half the story. Benchmarks tell us about performance as flawed as they may be. And that initial evaluation tells us about initial productivity on a project. What I've not talked about at all is long-term maintainability of a piece of software. What's the bug count gonna be when maintaining software like this? How difficult is it gonna be to re-architect? What if requirements change? What if the product owner comes forward and says, no, no, no, we've gotta add a new feature? Are you gonna be able to add that? Are you gonna have to rewrite the entire codebase each time?   Inevitably, there's going to be technical debt. Are you going to be able to pay it down? All of these are fundamental, important questions to how we write software. And at no point in our analysis did we think about it once. You may think, well, hype is really going to protect us here. There's no way that all of these people out in the world are continuing to hype up the language and talk about it and go on Twitter and write it and say how wonderful it is if they're going through maintenance nightmares all the time. That's not true either. I already told you that there's a sunk cost policy and those same people who are going on Twitter and write it and talking about how wonderful their languages are subject to the exact same problem. Therefore, we have an information hiding problem. This is a functional programming conference. So at some point in here I should talk about functional programming, you would imagine. How is all of this related? Most programmers today start off with either imperative or object-oriented programming. Those are the languages that are taught in schools. Those are the languages that are dominant in industry today. These are languages that usually have very large budgets for making very nice tooling that's easy to get started with. Because there's such a large market for this, there's a lot of educational material either in the schools, in the marketplace, in industry, or Riley, whatever it is, the material is easy to get access to. And these languages also have a lot more money for marketing, generating more of that hype. As a result of all of this, we see that it's very easy to unwrap with these kinds of languages. And so our initial evaluation is gonna be biased against them. I'm gonna claim we're fighting a losing battle. The way that everyone is doing things today, assuming that my assessment of it was correct, is not going to do a fair analysis. I'm gonna claim, and there's no evidence to back this up, this is just my own personal opinion, I'm gonna claim that when it comes to writing the first version of a program, V1, MVP, whatever you wanna call it, a highly trained Python developer and a highly trained Haskell developer can probably implement it in about the same amount of time. Let's say 10 to 20% difference. Nothing significant. That may not be true, but just go with me on this. Let's assume that's the case. There's no doubt in my mind that if you take a non-functional programming experienced developer and you put them down with Python and you put them down with Haskell, it will take them far longer to do it with Haskell. And I'm saying that as someone who likes Haskell. They're not gonna be able to be as productive as quickly as they will be with Python. This initial evaluation hamstrings us. This is a battle that we can't win on these terms. Now there's a silver lining to all of what I'm saying and I'll get into this a little bit more later. Recently, functional programming does have a significant uptake. Lots of languages out there are talking about functional programming.  So it's not quite as dire a situation and things are better today, but I wanna make them even better than they are. So why does all of this matter? Why am I making such a big deal about maintainability of software? In any kind of successful project, the initial development time is a tiny fraction of the work that you're going to end up doing, especially once you consider how many people end up working on the maintenance phase of a project. If a project took six months with a two or three person team to get to MVP, and then you have 10 people working for the next five to 10 years maintaining it, the amount of time on that initial phase is tiny. We're ignoring that long tail, all of that work that's going on at the end. This applies both to commercial and open source work. I've written a lot of open source libraries and I can tell you, I spend more time maintaining all of them than I ever did writing them in the first place. We know for a fact that requirements are going to change. This is just the nature of our industry. We would love it if the requirements document came down from on high, was handed to us and never changed at any point in the future. It's not reality. We know that we are going to write bugs. As painful as it is to admit it, there will be bugs in our software and we are going to need to fix it. Technical debt is going to accrue. Architecture is going to need to change to respond to things, whether it's changes in the way that in best practices or changes in those requirements. And our standard evaluation practices are not going to touch any aspect of this at all. Our industry needs to improve. We write buggy code. The industry as a whole writes buggy code. Unmaintainable code. It is not uncommon to do full rewrites when it comes to V2 and that's not the way that things should be. So my goal, my encouragement to everyone really comes down to this. I want us to change the conversation. I want us to start talking about maintainability more. I want us to be spending, to be putting it in blog posts and getting it out there in social media. I want to talk about it with our manager. Next time management comes forward and says what language should we be writing this in, the question should be, how difficult is it going to be to maintain this if we write it in language X versus language Y? Sure, we have to talk about how long it's going to take to get to the first version in production. We need to include that talk about maintainability also. And don't pass maintenance off to the junior devs. This happens all too often. It's just maintenance, junior people can do that. It's insulting and it's wrong. And maintenance is not just a junior task. Maintenance is hard work. But even senior developers can have a difficult time with it and claiming that the juniors are just going to take care of it is wrong. My belief, and again this is one of those places where I don't have any data to back it up, is that strongly typed functional programming is great for maintainability. It's not a panacea, it will not solve all ills in the world. You can very easily, and I've done this myself, you can very easily write bad code in a strongly typed functional programming language. You can design your APIs poorly. You can subtly break backwards compatibility with semantic bugs that show up in production. Or you cannot use the type system correctly and not actually take full advantage of what these languages are offering you. But I truly believe if you do things correctly, FP is awesome. You're able to focus, you need to focus on quality and maintainability to make that happen. And you still have to test your code. Do not be one of those people who says, well it compiled so it's gonna work, ship it. No, tests are necessary also. We don't get a free pass. What I'm talking about is the things that we're able to add in addition to what the rest of the world has without typed functional programming. My anecdotal experience is that I've been able to onboard coworkers to massive Haskell code bases very quickly. The fact that we have very little mutable state, we usually use data types and we use data to drive the way that the entire application works. We usually encode a lot of the invariance and a lot of the concepts of what's going on in a program in the data types themselves. Allows the compiler to be your ally instead of your enemy. And then once you have that in place, you can do what we call compiler driven development. You change a line of code, you change a data type, you hit compile and four hours later after you've fixed all of the places where it didn't compile, now you're able to run your tests and if the tests pass then probably things went right. I've been able to refactor and rearchitect code bases in Haskell and seen other people do this as well in ways that I would have been terrified to do in a different kind of a language. The fact that I don't have to worry as much about mutable state getting into weird situations due to immutability. The fact that the types do guide me through what I'm doing. And the fact that I get much faster feedback from the type system than I ever could from unit tests as well as much better coverage of what I'm looking at. Now I think you guys will lynch me if I don't include at least some code in a talk like this. So let's look at a few examples. This is Rust, I'm choosing Rust because Rust is one of those languages that has both an imperative and a functional flavor to it. And I wanna compare those two flavors. Both of these functions do the same thing. And of course this isn't really a function, it's a sub-procedure, but they call it function so I'll go along with that. Both of these functions do the same thing. They add up the numbers from zero to nine. The first one is an imperative approach. It uses mutable variables, it uses loops. The second one is clearly functional in nature. It's using a fold. And I've had conversations about which one of these is easier to work with. And here's how a typical conversation will go. The functional programmers, probably most people in this room say, well the fold is obviously easier. If I go back and I look at it, the fold looks pretty easy to most of us I'm guessing. But the conversation I've had with imperative programmers, at least in the past, and again this is changing as functional programming is becoming more common. But at least in the past, I hear things like, well that's too complex. You have to deal with closures and all this other complexity, it's higher-order functions. That's weird and I have to learn some new stuff. I know that loops always work, so why would I learn this new thing when I don't have to? And there's this weird, there's a concern, not a weird thing, there's a concern in the back of everyone's mind that the fold's gonna be slower. I have absolute control of the loop. And if you'll notice this conversation and you think back to what I said previously, this conversation talks entirely about short-term productivity and performance. For someone who is not familiar with functional programming idioms, the fold is going to take a lot longer to write. The for loop will be easier to write. And performance comes to the discussion. But obviously this discussion ever talks about which one of these versions of the code is gonna be easier to maintain. And keep in mind, everything that I'm showing can fit on a single slide, so maintaining a piece of code like this is kind of silly. But, just use your imaginations and imagine scaling up to something a little bit more complex. So, let's say that we're gonna have one of those weird changing requirements things that never happens in practice. We decide we want to only add up the even numbers. Well, this'll work. You'll notice that in the imperative version, I've added in an if, and I've checked whether things are even before mutating. And in the functional version, I just added in a filter. Who here thinks that it was easier to see the difference in the functional version? Who here thinks that the imperative version is clear? It's okay, you're allowed to disagree on the function. I happen to think that once you get used to the idioms, this one is much easier to follow. It's easier to change the requirements. Let's come up with a more contrived modification. Let's say that you wanna add the number three after you know that it's even.  Which of these is easier to follow? Is it easier to follow the functional version or the imperative version? Functional's starting to get a lot easier to follow. By the way, there's a bug in both versions of the code. Which one can you find faster? Functional, all you have to do is point out that map comes after filter. Well, the requirements clearly said that the map has to come before filter. Well, that was easy. The imperative one, you have to think much more about what's going on. You have to think about the mutable state. When is I getting modified? When is I being tested? Personally, I find that easier in the functional version. And again, this is subjective. Most of what I'm talking about now is subjective. But in my opinion, the functional one clearly allows you to see bugs faster and therefore avoid the bugs or fix the bugs much more quickly. All right, let's talk about types. I've got a Python program and I've got a Haskell program. The Python program defines a person class, a person constructor that takes a name and then provides a method to say hello to that person. And the Haskell program does basically the same thing. We don't have, well, we do have classes. We have type classes. So here we're gonna use a data type because that's the equivalent. We're gonna define a person. We're gonna define this function, greet. And then we're gonna call greet in the main function. And if someone who isn't familiar with Haskell, the Haskell code probably looks pretty irritating. What's going on with this IO thing? Why do I have to put types everywhere? What's that unit doing after the IO? Why am I having to deconstruct a data constructor? What's going on with all of this? It's overkill. And an imperative or an object-oriented programmer probably is not gonna like this too much. It doesn't gonna see much benefit in this. Especially people who love dynamically type programming languages. But again, let's say that the requirements change. And now we have to capture someone's first and last name. So we update the data constructor. Sorry, the class constructor. And we update the greet function. But we forget to update the call to that constructor. Is this gonna fail compile time or run time? Well, there's no compile time, of course, run time. It's gonna fail. The only way that you're gonna be able to stop this from getting shipped to production is if you have a unit test, which is gonna check for this. And you better make sure that your test suite covers everything. Let's see what happens in the Haskell version. So in the Haskell version, I change my data type. And I change my greet function. And now I have the exact same bug. I forgot to update the call. And now the person has a name instead of a person in the last name. What's gonna happen? Compile time failure. The compiler is not your enemy. The compiler is your friend. The compiler is preventing an entire class of bugs from occurring at run time. This is a good thing. Obviously a minimal example like this isn't particularly compelling. If you can see all the code at once, and it's pretty easy to see that there was a bug. But you can imagine. If this was spread out over 100,000 lines of code, it's much easier to let the compiler do the heavy lifting for you than to have to go through all of those places yourself. Just to make it clear that I am making fun of other languages, let's make fun of Haskell a little bit. It is quite possible to write dysfunctional Haskell. There's a saying in the Haskell community that Haskell is the world's finest imperative programming language. This code is not functional in any way. We're using mVars, which are mutexes, and we're doing multi-threaded transfers between these two different mVars. I'm emulating bank accounts, which seems to be the only thing I know how to do when giving an example of concurrency in Haskell. So we create our first account, we create our second account, these are both mutexes, and now we transfer between the two accounts. First in one thread going from one to two, and then in the main thread from two to one. And in the transfer function, we lock the mutex, the first mutex, and then we lock the second mutex. Who can guess what this program is gonna do? This program is going to deadlock. We've locked the first variable in the first thread, the second variable in the second thread, and neither thread is now able to continue and complete its task. If you write code in an imperative style, even in a language like Haskell, which is functional and purely functional, it forces you to think in a functional way. Even in Haskell, you can shoot yourself in the foot. So of course the solution is to use more FP. I think that STM, software transactional memory, is one of the coolest features that we have in Haskell. It's a great demonstration of what functional programming and purity are able to provide. If anyone isn't familiar with that STM and wants to talk with me about it anytime today, I will be more than happy to talk your ears off about why STM is so awesome. So here, instead of a mutex variable, an mbar, I'm gonna create a tbar, a transactional variable. And our transfer function now looks significantly simpler. There's no locking. People who come from a different background, more unfamiliar with STM, are probably thinking that there's a data race condition here because you can be modifying these things simultaneously in two different threads. However, the way that STM works is based entirely off of functional programming, pure functional programming, and the purity of Haskell, the referential transparency. Inside an STM transaction, we know that there are no side effects. And the runtime system is able to handle all of the retry logic to make sure that we have an atomic transaction. That's why the word atomically is sitting there on the screen. This program is not gonna deadlock. This program is not gonna have a race condition. And we got all of that by using functional principles. Again, for an example this small, it's not terribly compelling. You could have made the mbars work. You could have done some kind of ordering of the mbars to make sure that you locked them in the correct order. But when you start getting into large programs with large blocks and a lot of variables, the ability to simply compose things together without thinking too much is very valuable. I'm also gonna throw in a little bit about my other favorite library, which is the Async Library, and this concurrently thing here. The fact that we treat IO as a first class action as opposed to something which implicitly just happens allows us to write imperative, sorry, a concurrent code in a very elegant style. And again, if you want me to tell you all about why I think the Async Library is one of the coolest libraries, I will talk to you about that too. I love those two things. Okay, so what can you do? What can we do? I already said that we've been getting the functional programming ideas into the mainstream much more over the past few years. When I would go to a conference five, 10 years ago and talk about Haskell, people looked at me like I was crazy. People still look at me like I'm crazy, has nothing to do with Haskell at this point. People aren't afraid of holds anymore. FP, in fact, is usually seen as an advantage. You'll see lots of programming languages out there touting the fact that they have functional programming features. JavaScript is a functional programming language. Java, C++, they all have functional features now. That wouldn't have happened 10 years ago. So we're winning that battle. People are acknowledging the fact that functional programming offers something. And as a result of all of that, the learning curve is reduced. When that developer that I was talking about comes to compare Python and Haskell, they're probably still gonna find Python an easier on-ramping experience, but not nearly to the same extent as they would 10 years ago. We need to make it fun, easy, and exciting to learn these functional programming languages. We have to acknowledge the fact that people are still gonna be hitting that on-ramping cost. And we need to give the motivation to push through and continue. And I'll tell you the rest of my story in a bit and you'll see how that ties in. And we need to change the conversation. We're fighting on the wrong grounds. If we continue to only talk about productivity and performance, we're not gonna be able to win. We need to change the conversation and get people to think more about maintainability. We also need to be talking about practical benefits. It's very nice Haskell functional programming, the Lambda calculus. These are elegant, beautiful solutions to problems. But if you talk to most developers and definitely most managers and you tell them about how elegant the solution is, they're gonna nod and they're gonna continue writing Java. We need to make it practical. Tell them the real bugs that are avoided. The real advantages. The real productivity gains. STM that I just mentioned gives real productivity gains when you're writing concurrent code. And we need to be talking to that much more. What I wish is that we actually had some data to back up all the times I'm making. Everything I'm making is just my opinion and my experience, my anecdotes. We don't really have this kind of hard data in our industry. No one is doing the studies to show that functional programming either does not help industry move forward faster. I would love to see these kinds of studies happen. I'm not particularly hopeful that we're gonna see it. Doing those kinds of studies would be very expensive and there doesn't seem to be a lot of interest in doing that. So I work it up to complete and when we talk to companies about programming languages, about tools, about anything, DevOps practices for that matter. We always talk about three different pillars in software. And it's performance, productivity, and maintainability. And you've heard me mention those all in this talk. Performance has to do with the hardware itself. Either how much hardware do you have to throw out the problem? Or how quickly the hardware is able, the same amount of hardware is able to solve the problem. Productivity in business terms is really easy to translate. It's time to market. How long is it gonna take you to get this piece of software out there? Maintainability is the bug rate, evolving a code base, adding features. These are things that business people understand. They understand that users are going to be upset when the program crashes. They're going to be upset when they don't get the new feature in a reasonable amount of time because no one can figure out how to modify the legacy code base. These are things that you can talk about with your managers and get the conversation started. I'm talking about maintainability today because it is the most overlooked, in my opinion, of these three. All three of them are important. We can't write software without considering all three. But let's get maintainability back into the conversation. So I started off by telling you guys how I got to be a Java developer. Let's tell you guys how I stopped being a Java developer. I guess it was 12 years ago, 13 years ago, I decided to do some web development. In Java, of course, because I was a Java developer. It sucked. Maybe the situation's better today. I've been too afraid to look again. But at the time, I just found it way too painful. It was so painful that I was able to overcome my sunk cost policy. I was able to realize, even though I've been programming Java for years, this is not where I want to continue. And so I moved on to PHP, which was a wonderful programming language to follow up from Java. I actually liked it because it was so much more fun to write this code than it was in Java. After a year or two of doing PHP, I eventually realized I'm not gonna be able to maintain this code. It struck me and I realized I'm just not smart enough. It's not something I'm capable of doing. I got lucky and I was able to overcome that sunk cost policy a second time.  The two that I stuck with the most were probably Perl indeed. And I got to Perl and someone came out with this thing in Perl 6 called PUDS. It was the first implementation. Has anyone here ever heard of PUDS? PUDS was written in Haskell, which is a language I'd never heard of before and I was curious. Why would they write this thing in Haskell as opposed to writing it in Perl? Perl's the greatest language ever created. So I looked into it. I was a math person. I enjoyed math. I actually studied math in school and math in computers. And Haskell was a mathematical programming language. So I thought, hey, why not? Let's have some fun. I didn't like do it for anything real. It was gonna be a hobby. As I started looking into it at the time, things are better now, but at the time documentation sucked. It was all over the place. The tools were terrible. This is before we basically had any kind of command line tools.  It was a mess. Compared to what else was out there at the time, Haskell looked like a joke. And I knew there was no way I was ever gonna use Haskell in production or use it as part of my career. It just wasn't a reality, but it was fun. And so I played with it. I overcame that learning curve and I stuck with it because I thought I was going to enjoy the experience. And I did. And I stuck with it long enough when I was a stubborn enough person that I fell in love with the language. And 10 years later, I'm still using it as my primary programming language. And through a lot of luck and perhaps some self-delusion, I found what I believed to be a really great programming language. And even though I didn't have the language 10 years ago to talk about maintainability the way I can today, I ended up finding the language that addressed the concerns that I knew that I had about writing code in a non-functional approach. We can't rely on luck. I got lucky, others may not. It's too easy to give up when things get difficult and just try something else which looks easier, which is a completely rational thing to do. It's far too easy to make an initial guess that takes you in the wrong direction. I did that multiple times. And many other people are doing the same thing. And then it's way too easy to get locked into a bad choice. I believe we have a responsibility to help our industry improve, to get functional programming out there. I think we can make the world, the software world and the world in general, a better place through it. I am gonna encourage everyone here to go listen to the rest of the talks here, learn much more about functional programming, and then take the ideas back out into the rest of the world. Talk about the benefits of functional programming. Talk about how it helps us make better code, more maintainable code. Talk about the performance productivity as well. But don't forget to bring the maintainability into the conversation. Enjoy the conference and learn a lot. Thank you. Thank you, Michael, that was awesome. Time for questions. Yeah, so this is gonna sound weird. The thing is, my question is, what are some bad FP languages? What are some bad FP languages? Yeah, that we shouldn't be learning. I'm not gonna answer that one. Okay, no, I mean, I'll give you my own personal biases. My personal bias is towards strongly typed languages. So I personally prefer things that give you a strong type system and static type system. Functional programming overall, I think, is an improvement. But I personally believe that getting the strong typing gives you much more of the benefits than other things. So you can extrapolate from there which languages I'd like more than others. Hi, Michael, what was your first production Haskell project? And what was the state of Haskell at that time? Okay, so before I left the United States, I was working as an actuary. I was working in the insurance industry and we needed to do some kind of large data conversion. Now, this was large by our standards. We had to do, we were required to do all of our programming in Visual Basic and Excel. So large there meant one gigabyte, which is obviously not a big deal. But we did a little bit of an analysis and the way that Visual Basic was working, whatever, one of my coworkers discovered it was gonna take three weeks to run the program. Yeah, so we decided, well, that sucks, we're not gonna do that. So I did it in Haskell instead. That was the first, and I think maybe the only time where I got really bitten by a space leak and I had to debug one of those. It was one of those programs that was only gonna be run once and then it was gonna disappear. So no one cared that it was written in Haskell. I got away with it. And I actually got very scared when that space leak happened, like, oh my God, I'm never gonna be able to solve it pretty easily. Everything moved on from there. Yeah, and that was it. And then we converted it, and I think it ran in like five seconds instead of three weeks. All right, so first of all, I love this topic and I'm glad you decided to do something like this. The good news is that I think your cynicism about the lack of research out there is unnecessary because I think actually there are some people who have published a few papers on strong typing and the effects on bug counts and bug rates and other productivity metrics out there. And so they're having people who are doing some research like that. But one of the biggest difficulties is not money for this stuff. It's the fact that nobody actually cares. And this is a real problem. So I think actually talks like this are important because people don't want to invest in the HCI of programming language design. And if you look at the big conferences where people are trying to publish research on programming language design, it's almost impossible to get a usability study published in those conferences. And so as a community, I think we need to be pushing strongly, culturally towards honest actual real usability evaluations, which we do have the skills to do those studies. It's just that nobody wants to do that. I think partly because a lot of people are very scared about the results of that kind of research. So firstly, if you can share some of that with me later, I would love to see it. And yeah, I mean, there is the reality. I'm making all these claims, but I think functional programming, I think Haskell is gonna rule the world. It's the best language. We have to accept the fact that we might be wrong. The studies come out and they say that everything we're doing is incorrect. And we could just say the study was done badly, but then we're like the nutrition industry and we are doing horrible things. Yeah, I heard what you're saying. I'd love to see some of that. This is regarding performance, sir. So as it is immutable, let's say I have a big list and I want to do map filter and like 10 operations. So all of them will be kept in memory. I actually think it's easier in functional programming than in imperative programming. In order to do it in imperative programming, you have to shove everything into the same loop. You have to make sure that everything, and you don't get any kind of composition. In functional programming, let's just take the lazy list example, which is the way that we do things in Haskell though, it applies elsewhere also. In Haskell, the way that you would do these things is you would just go ahead and chain a map, a filter, a fold, all of them together. And because it's lazily generated, it always takes up constant memory. So it's gonna generate one value in the list. It's gonna put it through that processing pipeline. It's gonna fold it together and you get constant memory usage. Not in all cases, you can screw it up. But for the most part, you get constant memory usage in these cases. There are even more advanced techniques, like streamfusion, the vector package is very popular in Haskell and it has a streamfusion framework. And with streamfusion, it even takes it another step and is able to completely bypass a whole bunch of heap allocations and do, and if you look at the assembly that it generates, it turns into the exact same thing that you would have written by hand in C. Doesn't always work, but in many common cases that you would end up having, you get high level expressivity and the low level performance that you want. And I'd be happy to show you some examples that there are some great papers on it. The immediate answer is yes, it's a problem. We have to solve it. Let me elaborate a little bit. It's not a functional programming problem. You know, the C language forms are infamous for having this kind of attitude as well. So there is an elitist attitude in some places. And I'm not saying, my point is it's not limited to functional programming. It's all over the place and anywhere we see it in the programming world, I'd like to get rid of it. I do think we need to take some active steps towards addressing it as much as we can. Just two days ago, I actually wrote a published a blog post called New User Empathy. And it was based, yeah, and yeah, no, I absolutely, it was, it was not completely unintentional that I published it before coming here. I had all these thoughts in mind as I was preparing this talk. Yeah, I absolutely believe that's the kind of thing that we need to do a better job with as a community. Figure out ways to improve the tone that we use when we're welcoming new people in. And I don't have a complete answer on how we're going to do it. But yeah, I want to solve the problem. I'm sorry, could you say it again? Oh, introspecting at the run. Oh, like getting runtime statistics and things like that. Right, so we don't have tools that may be as good as the JVM. This is one, you know, some things out there are better still. We have some really nice profiling tools built into the Haskell, into GHC. And you're able to get great, like, heat profiles and things like that right out of the box. We have statistics, garbage collection statistics. At the workshop that I did two days ago, we actually used the statistics quite a bit to be able to analyze memory usage and figure out ways to improve things. I'm not gonna claim that the tooling is as good as other languages. We definitely have room to improve. Hopefully, you know, this is one of those chicken and egg problems. Hopefully, industry becomes so massive around Haskells, you know, everyone's using Haskell tomorrow. Google adopts it, they drop go, they're using it, and then they, you know, they put a team of 10 people working full-time on making Haskell performance analysis tools.


All right, so thanks for coming, guys. We are at Rise today, as opposed to our usual venture in Leicester Square. So thank you to Rise or Sponsor. They're an incubator. They have all sorts of interesting projects, so I really encourage you to check them out. In terms of all the sponsors, we'll go straight to the sponsors. So we have Crypto Compare. You probably know them. Vlad, unfortunately, and Charlie couldn't make it. But they asked me to tell you that if you have any need for information around the pricing of crypto and things of that nature, feel free to visit their site, Cryptocompare.com. It's pretty cool.  It's a big change, right, from Reddit. We also have the Blockchain Connector, a new sponsor. Where's Antonio? Where is he hiding? Antonio, you want to say a few words, maybe? Yeah, you need the mic, though, if you want to say something. You'll do a lightning presentation at the end, yeah? But basically, if you guys are looking for developers or if you're a developer looking for a job, I would recommend you talk to this gentleman over there, Antonio. And there's Socket. Yeah, Socket is a small startup. It's pretty interesting. I like it. I think they're pretty good. So a lot of people are saying, hey, what are you doing since the dark? Blah, blah, blah, you know? So I thought that I'd show you a little bit what we've been up to. So this is share and charge. It's a project that we're doing in partnership with a giant company called Enoji, which is a big energy giant in Germany. They used to be called RWE. And what's different about it is that it's live. It's a real project that uses Ethereum today, not in 30 years down the line. And what people do, this is translated, by the way, you have to forgive the broken English. This is translated straight from the German because it's in live beta in Germany. If you have a charging station and you want to share it because you want to recoup the cost of your investment, you just do so and it's completely handled by the blockchain transparently. And similarly, if you're a user and you're looking for a charging station, there's a little map here and it tells you where to go, where to find it. So why this is important is, hey, it uses Ethereum, which I think we all agree is cool. And second, it allows to have up to 25,000 new charging stations in Germany, as opposed to the existing 5,000 that are opening up thanks to peer-to-peer technology. And I think that's really important for electric vehicles because a lot of people don't want to buy an electric car because they're wondering, where am I going to charge my car? So that actually answers a need today and it's in beta. We have feedback in there that you can go and have a read and people can just choose how much they want to charge out their own electricity, if you will. Yeah, so have a look at that. That's what we've been up to and we continue working with these guys and others on right now we're really focused around mobility solutions. Okay, so without further ado, let's go back to the main presentation. I'll just press the right button, there they are. And yeah, a couple of admin stuff. So if you want Wi-Fi, this is the password. Feel free to take a picture and if you can use the hashtag, that'll be awesome so that way people know next time to use the ETHLDN hashtag. Speakers, tonight we have some an interesting mix of speakers actually. We have PWC, you also may have heard of this little company. We're going to present a solution that interfaces Ethereum with the enterprise world so I really look forward to that. We have another small company called Thompson Reuters that's also gonna present small, tiny startup. And these guys have some interesting stuff going on around ID, identity that is. And they recently run a very successful hackathon as I understand it, and I'm sure they organize others, they'll present that to you guys. We also have Alice.si, who haven't arrived yet, is Alice in the room, oh, you've arrived. So that's completely different from the other two. I think it's a charity. So it's gonna be really interesting to see how we can apply Ethereum to more not-for-profit causes, which is something I'm really interested in too. And that's about it, so in terms of volunteers, I also wanna thank Andy, Andy, where are you? And he's over there. I give him a hand, he's done a lot of work.  So thanks, Andy, and organizing the whole thing. So thank you very much. That's it, I haven't forgotten anyone. Have I, Andy? No, oh good. All right, so without further ado, please welcome. I believe it's PWC first, Fergus and Ajit. My name is Ajit Tripati, I work with PWC. I'm also widely blamed for having started our blockchain practice in the UK, well credited. And Fergus was there before me. So Fergus has been there from the times that the only thing on blockchain was cryptocurrency and Fergus was going around the firm saying, hold on, the revolution is taking shape, we really need to get behind it. And since then we've built a 20-member engineering team, we have done some really cool things for some very big clients. Now in this community, I mean, we're now gonna talk about some of the coding we have done, because I mean, that wouldn't go down very well with some of the coolest folks in town, right? I mean, I'm sure a lot of developers here are way better than anything that are doing really cool things that you won't see in the enterprise world anytime soon. But what we're gonna talk about is something more around how we essentially are gonna help our enterprise clients go from POCs to production because over the last few years, there has been tremendous activity in blockchain, but at the end of the day, we gotta get out of POCs and we have to see some of the more industrial applications happen outside of the public blockchain as well. I mean, the technology is tremendously useful. At the beginning of this year, we did a project with the central bank, the Bank of England, and that was on Ethereum, where we helped them build a trade, a settlement POC. And one of the things that we tested as part of that, or demonstrated as part of that was that, well, let me take a step back. October 2014, the Bank of England's real-time gross settlement system went down, right? And this is the system that processes 500 billion pounds worth of payments, interbank payments every day. Now, when that happens, then the economy sort of doesn't really move on that day. So it took eight hours to come back up and that's one thing that the bank never wants to see again, right? So one of the things that they are really focused on is resilience and we help them actually explore the technology and take that central bank note down in the distributed ledger and then demonstrated that banks can continue to do what they do and the central bank can actually build a system that doesn't require the central bank systems to be alive for the transactions to continue. So that went on really well. I mean, that was taken by the governor of the Bank of England and publicly he spoke about it. And since then we've done a lot of work with our enterprise clients and today we're gonna talk about where we're going from here and how we see our role as big boring auditors. I mean, I was an engineer before and I didn't imagine that I would end up an auditor but today we're gonna talk about how as auditors we are essentially helping our clients and how we can sort of helping some of this stuff go into production. But yeah, what we'll share with you today is really some of the observations I've had over the past year of working clients and the conversations we've had. Again, there'll be some, you know, a slight banking and financial services slant to it because that's my sector. But some of the things we'll talk about are relevant across sectors and for all sizes of business looking to experiment with Ethereum, whether that be the public chain or private chains or third party solutions. And we'll come on to sort of cut it into six distinct areas where I think recurring themes that clients keep talking to me about that need a bit more clarity before it goes prime time. Outside of work, I'm a crypto enthusiast. I love Bitcoin, I love Ethereum. I was lucky enough to get involved in the crowd sale. I wish I'd done more but I'd been stung by Litecoin by $24. So I'll always blame Charlie Lee for me not having more ether and still having to be here talking to you. I've also recently done the B9 Lab Ethereum engineering course which I'd highly recommend to anyone. Eduardo, sorry for shouting out a competitor. So hopefully I can give you some insight and hopefully it's not too consultancy related. Regulation and law, we all know the challenge is there. Key management, a subject close to my heart and security obviously really important and maturity and integration. We'll go through each one of these quickly. And then we'll have enough time for Q and A at the end. So I won't labour the point around AML. It's a non-starter with banks. If you walk up to a compliance team and you say I want to go and play around on the Ethereum public chain, I need to buy some native tokens to decentralize peer-to-peer network that sits outside of the financial system and there are no AML controls, there are no customer controls. It's just not happening at the moment. A couple of areas I do think that are relatively interesting to know around data. So data privacy, both in a regulatory point of view and also from a business point of view, a lot of banks don't want public transparent transactions across a network. You will have all seen the hype around Zcash and that coming out recently in zero knowledge proofs. Some of you might have read the Hawke White paper around smart contracts on Ethereum that implements the Zcash protocol. I think that has a lot of potential but I also think it's two early days and I don't know anyone that actually really understands zero knowledge proofs. So if you go into a bank and try and explain that, I'll be really interested to know how you do that. The other area I've seen popping up recently is this idea of the right to be forgotten and the right to erasure in current European laws. How does that even work with the mutability in the blockchain space? How can you ensure that you'll be able to actually erase and forget people's data if it's on the blockchain? I don't know about the applications that are being built but I'm sure some of them will look to put data on chain. Perhaps you'll need the Accenture editing blockchain. I don't know, maybe that's the use case they were thinking about. And then there's a new regulation which I don't know a lot more about than I do the general data protection regulation which is coming in which has much more owner as terms in terms of banks and companies needing to delete people's data that they hold on them within 48 hours I think for a request coming. So if you think about that in the context of Ethereum and blockchains and the mutability, how does that play into that's one area. Moving on to legal uncertainty. Again, we've heard this all before. Are smart contracts legal? Are they legally enforceable? I think one of the past Ethereum meetups a couple of months ago, there was a great panel of lawyers on there talking about these subjects. So please go and check that out afterwards. One area I'm really interested in is jurisdictions. If you're looking at public chain, what jurisdiction is a smart contract in who's accountable for it? And then in the private chain space our clients are talking about are smart contracts legally enforceable? Check out Nina Gilbride from Monarch. She's done some great blogs on the enforceability of smart contracts. There's a great deal of law out there already on electronic contracts which should really cover a lot of this. I think it's just a matter of time. But there are no precedents yet with smart contracts and blockchains, I don't believe. So that just causes concern amongst businesses. Next, key management or lack thereof? Key management, yeah. Key management obviously a hugely important area in Ethereum and all blockchain implementations.  Now that isn't so bad in an individual case.  But you put that into the business sphere and suddenly you're talking about huge amounts of value going across networks. You're talking about smart contracts that control important processes in regulated environments. And I've not seen enough being said about key management where they're generated. I don't see anything on standards. I haven't seen any frameworks or best practices out there for businesses to get hold of, to educate their staff, to do training. I've not seen any real hardware security module work going on that I'm aware of that's appropriate for business. Again, I've got a ledger in NANOS for myself now after my losing of the ether. But again, who's doing that and where is that? And where are all the controls and frameworks in place to have that there? So it's another big area. Related security. Again, it's been an interesting six months through Ethereum. We've had issues at smart contract layer. We've seen bugs, we've seen not enough testing. More recently we've seen denial of service attacks going after op codes. We've also seen, I think just last week there was small incidences where variables could be overwritten. So again, we're talking about not fatal things and actually Ethereum I think will get stronger from learning through all these things and being tested in the open in the fire. But again, when you put it through a business lens people hear these things and suddenly they start questioning them. There aren't many people inside the business that really understand the difference or the importance of whether it's an issue at protocol level or just at smart contract level. And these things just delay projects. They cause people to rethink their investment decisions. And that's just one of the other features. And one thing I've been noticing recently actually is the massive decrease in the hash rate on the public chain. I think we're down to about 5,000 giga hash per second which was up at about seven and a half thousand. Say three, four weeks ago this is largely attributed to Zcash. But again, hash rate in a network is very important. So that's one to keep an eye on. Now coming onto that too this is just a bit around how mature is Ethereum as a piece of software, as an ecosystem. It's only a couple of years old, Max. We're not even hitting the metropolis or serenity releases yet. So everything I've just said you have to take with a bit of a pinch of salt. But again, established businesses and banks they want mature solutions. They wanna know that what they're buying or what they're using is stable. They wanna know that it will do what it says it will do. And interestingly, I think a lot of banks want to hold someone accountable which obviously doesn't really make sense in the public space necessarily, but in the private space. You know, if we're talking about them using early stage companies like Clearmatics or Monax are they bigger than have they got the balance sheet to really satisfy a bank's decision-making engine? So keep an eye out for them moving towards bigger players like Microsoft and IBM who may not have the best solutions that they may do but they certainly have a balance sheet and a reputation to make companies feel comfortable. And finally from potentially something that is not mature enough to something that is probably far too mature legacy infrastructure at banks and other companies. How easy is it for them to interoperate and how easy is for them to implement Ethereum into these legacy stacks? And it's not just the technology itself it's also do they have the devs do they have the right people internally? Do they have the guys that know how to develop deploy and maintain this software? Do they have, do they have those guys and I think Eduardo will come on and maybe talk about that a bit later? And also does it fit in with their current businesses good current business functionality and how they operate today? You know, a lot of the time I get pushed back saying but can we write our daily reports out of Ethereum or a blockchain? You know, aren't they write only aren't they optimized to write and append data to? It's this type of thinking around how business process will change and how blockchain technology and Ethereum in particular is a whole new different business model that people need to get their head around. And so, you know, that being said that's, you know, those are six areas I think need a bit more thinking before you'll get the business community really happy and really comfortable. So any questions? So I'm 25% older than Fergus so I have a lot of stories and I'm gonna go over some of the stories about each one of these things, right? So one of the things I think we need to recognize about so first of all, when we talk about blockchain there are two whole other two completely distinct communities, right? And there is some interaction but you have the open source cryptocurrency community and we are really excited about cryptocurrency and smart contracts on the public chain but then there is this and that's where a lot of real innovation is happening, right? So some of the most exciting ideas come out of this community but then there is a whole other market which is essentially big banks, firms like us which are essentially looking to first of all create new business models which are much more efficient than what we have today but at the same time upgrade the technology on existing business processes, right? So if we operate, let's say a supply chain a certain way or if we do faster payments a certain way in the case of the RBS announcement then does this technology allow us to do the same thing 50%, 25%, 10% better, right? And in that scenario there is a strategy question which is what's my role? Now if I'm an intermediary and this new solution takes away my role entirely then maybe that's not where I need to be and if it creates a better business for me that's much more efficient then maybe I need to play in that. So there is a whole enterprise marketplace opening up for the underlying technology and that's where I think you've spent a lot of time. Unfortunately or fortunately when you're doing then let's say the DAO happens then you don't get a call from the SEC at least I hope you haven't but when it happens for a big bank then immediately they get calls from at least 10 or 12 regulators around the world depending on where the victims were who heard about it and so on and so forth which is why large banks have massive compliance functions, right? After the financial crisis. So before the financial crisis I was a developer at Goldman and we used to make changes straight into production sometimes in SECDB which is our pride and joy.  Functional programming in Slack, slang not Slack, it was beautiful but now you must have heard Barclays. You have to write 38 different artifacts before you change a single line of code. So it's completely different from how it works when I'm messing around with Ethereum on my wonderful Mac. So that's why regulation is important. Regulation is central to financial services. What we want to be able to do is make the task of complying with some of those regulations painless with the technology with by building some of the tooling technology and best practices around the kit that's already out there, right? So privacy is absolutely central to European regulation now and so R3 have one type of solution where they're saying they will only have data being shared between the nodes that should be involved in the transaction. Other people are saying they will keep the actual transaction off the node and just update the ledger with the transaction. None of these are really exciting. To me Zcash is much, much more exciting but at the end of the day I'm not really just about it for us isn't really just about it. It depends on the engineering problem we're trying to solve. Legal uncertainty, I spent three hours today at ISDA International Swaps and Derivatives Association and one of the things that came out was smart contracts are brilliant and derivative contracts are standardized. They are relatively straightforward in terms of implementing, the basic interest rate swap is quite a simple contract. You can easily implement it in an Ethereum like platform but the challenge is the legal precedents around the context. So for example, if your counterparty has defaulted, if your Goldman and Lehman are trading, Lehman goes down and that trade involved the smart contract implemented on an Ethereum like chain and the money has already been sent then you're in a world of pain. So there is a lot of stuff that happens outside of this wonderful world of blockchain that you really need to worry about as we found out with Bitfinex and with the DAO and so on so forth. But when you're actually trying to build a solution like that, you have to read through like 10 years or 15 years of case law to figure out how the courts actually ruled in each one of those scenarios. When bad things happened, what did the courts do? Because there are hundreds of thousands of consumers to be protected and at that point, anything goes wrong, there is a dispute, it's back to the courts, then court is not law anymore. So it depends. Key management, we saw this with Bitfinex, we saw this with MtGox. I mean, it just goes on and on. So we saw, well, let me take a different example, Swift, right? Swift is a system, a messaging platform that's been running for years and years. If you talk to the Ripple guys, they will say, Swift is gonna go away because we have a better solution. There are other people like JP Morgan and RBS who have built payments like FBOCs on Ethereum and they are looking for better solutions as well. But I mean, if you can't secure the endpoints as we saw in the case of Bank of Bangladesh where they had left four computers or something on the internet and then the hackers got through those computers into Swift and used the banks identity to essentially send money to Philippines, all bets are off, right? But the reputation still sticks. So Pakistan, I've spent a fair amount of time comforting our enterprise clients that hold on, hold on, hold on. Everything, it's not the chain, it's not the protocol. It's the entire ecosystem meant to end and when you're building enterprise solutions, you really have to worry about not just the protocol, not just the code, but the end to end ecosystem and the people and the processes, right? That's where it gets really non-nerdy and not a little bit more boring, but extremely important. In fact, some of the most important things are really boring. So security, again, Ethereum, early days, but it's, I mean, I've seen tremendous growth. In fact, our engineers in Belfast lab, they built the Bank of England solution in five weeks, and then, so we have a guy called Igor who should come and speak because he's, he can do some demos and really, really cool. He's one of our most technical guys. He's literally Igor from the lab, no jokes. So he said that six months before we built that thing, we built that POC, we couldn't have done it in the time we had, right? So the maturity is coming through, but then depending on the application that we are solving for, it's really important to focus legacy stacks. This is where a lot of things are gonna go wrong in the enterprise. When we start transform integrating with legacy, at those endpoints, we had really had to be careful. That's it, thank you for listening. So our role, what we're trying to do is create a whole ecosystem of processes, checklists, tools, software to essentially automate a lot of this thinking and checking so that we can speed up the adoption of the technology in the enterprise because when we are dealing with regulators and you know, market intermediaries and lots and lots of money, we really have to be careful. That's it, thank you. Okay, good evening everyone. So yes, Richard and me, how we, well I run a dev team in Thomson Reuters, have a few guys we've been working on blockchain for a couple of years and with Ethereum for about 14 months. We're an enterprise here, we work with some private blockchains, but really it's gonna be a very different presentation from the last one. We see all the same problems, it is difficult working with blockchain when you're a big corporate and we haven't got the solutions either right now, but at the same time, we think in, well, we made a decision a few months ago, it doesn't really matter if all the problems are there, can we solve some of the smaller problems so we can try to start working with the community? Because we are starting to feel quite embarrassed because we come to these meetups all the time, we work with the Ethereum community and we seem to be taking things out of it and we just thought, well, we wanna try using what we've got to perhaps bring some simple tools back and that's why we're here today just to talk about Block1ID and what it does and we've already presented this in a hackathon a few weeks ago that we ran, we had many, many, I think we had over 150 developers applied to come and I think on the first day we had about 80 or 90 turn up and really good attendance all the way through and lots of great solutions. So we're really serious about working in the public space, I think actually we were working much more in the private space and realized that we were in sort of, not in a real world, it felt like, we were taking Ethereum branching it, doing all sorts of things to it and really not making it what it was and we couldn't keep up and we realized that we needed to work in the public space and that's what we're doing here. So, okay, so, Block1ID then, I mean, just first of all, just so you know, some some ways isn't just about Reuters, the news agency, everyone thinks it is, but we have a lot of businesses and financial risks so we have a KYC business, for instance, what we do for banks today, we do data feeds, which we do a lot of Oracle services to blockchains right now because people need them. We also have a legal business, we do a lot of tools for lawyers, software services, et cetera, and for governments as well and tax and accounting. I mean, this isn't probably the most exciting work but there's a lot of blockchain use cases in these things and so when we're looking for what things we can do, we're looking at our businesses. The other thing we're doing as well when we're looking for what we can do is looking at the strengths that Thomson Reuters brings. We are always voted in the top 10 to the most trustworthy and ethical companies in the world and we have to be right, we're reporting the news so we need to be it unbiased and we feel that's a big strength to bring to this community. I know we talk about trust in different ways and we talk about consensus but when we start to bridge these worlds, trusted companies I think can really help especially on the edges of blockchains. So we think that we can really bring our brand to that and really help and we also have great scale. So we're talking to lots of banks, lots of governments, lots of different forums so we can get people into those meetings and see how we can start to bridge these worlds. And again, we don't know the answers, we're just trying to start to bridge these worlds and see where we go and the solution today is exactly that but we're just trying to bridge some worlds that we can get going. So we started with a problem and this was a simple problem for us which was if we're gonna try and use a public blockchain and what problems, what problem are we gonna hit and what can be solved? So the first thing that we came across and these were really, really simple problems was we really are used to knowing the users that we deal with. We don't just give out content, we don't just give out services to people we don't know and that's just a reality of our business. If we give out content, often it's not our content, it's licensed inbound to us so we have to provide a license going out. So we have to know what that person is so we can get them to sign our license or at least know they have a license to have that content. It's a very simple problem but it requires some diligence from us. We can't do that easily on a public blockchain today. Sometimes, as I said, we need to get the user to accept terms, very simple thing, but again, it's accepted around the world in web, it's just not in blockchain and we also then need to entitle based on that. In the blockchain world, we know we entitle on addresses, those addresses are opaque and you don't know who they are and especially when you're on the blockchain side, when you're enforcing contracts or interfaces to contracts, you really can't, it's not very easy to reach out and work out as this user with somebody I know. You might know an address but you may not know if they're a user or the user that signed up. We've also seen problems with key management and we thought, well, let's find a simple solution to that. Certainly don't have the best solution necessarily but we have a pragmatic one and we also wanted to preserve this user ID of obfuscation. We don't want to put users information all over the blockchain. That's not to say we won't put private information on a blockchain but obviously encrypted but we're certainly going to try and respect users. Now, all of these things are relevant to public. We also look at these in private and some of them aren't as important but to be honest, we're not really applying block one ID in the private space. It's very much in the public space and to provide a key building but to see how it can be adopted. So, what is it doing? It's very simple really and this might be really against some of the principles but what we wanted to do was create some sort of controlled spaces on the public blockchain and by control what I mean is that we can decide if our service is offered to users or not. And we felt that this was a pragmatic solution because a lot of what we've been doing is looking at private chains and we're thinking well actually, this really doesn't seem to be going with the principle of block chains and especially when you look at the private space a lot of them aren't really block chains at all. They just basically remove the whole trust element and go for a truth concept and we really felt that that wasn't what we wanted to go for. So, we thought well let's see if we can create a controlled space on the public chain and see if we can function that. And that's what this is trying to do. So, we started with a very simple interface which has been there for many years and that is when application owners or developers or service providers want to talk to their users and want to manage their users in some way. Now, we didn't want to go down an app store sort of approach where you enforce these relationships and try to control them. But what we thought is that we could add some value in this space and use Thompsons Royters brand and trust to try to help developers be able to understand whether users have accepted terms or whether the users are able to use their service. And by users I mean people, I don't mean addresses. So, what did we do? We built two services. Well, I think we built three services really but two, the delegated identity service. So, we wanted an identity service which was really compatible with the rest of the world and the obvious solution to that was to use OAuth. It's just used everywhere in all of our web systems. What we're also finding is when we add blockchain into these systems, even if it's public or private, it's not the only piece of functionality. We often have a lot of web services alongside. And so we wanted a simple system that would just combine these things together. And this is how we know our users today we use OAuth. So we thought, okay, let's use that and let's combine it with a wallet. So what we do is we manage private keys against user IDs, a hosted wallet. Now, we do not see the keys there completely. If all we do, think of us like a dropbox for encrypted blobs. We don't ever see or decrypt those or we're not able to decrypt those blobs. So the side, everything is just provided to the clients and everything is decrypted in the client. So, and that's done through the user and their passwords. We never pass those passwords around. So it's not about us acting on behalf of the user on the blockchain. Indeed, we can't. It's just about us managing the storage, if you like, in an encrypted form. But we felt that we had to build a wallet to make this work. It's not to say that we have to own the wallet in the future, but we certainly thought to get this to work initially. We needed to build into our OAuth system a basic wallet. On top of that, what we felt was really interesting was to build an entitlement or authorization service based on this user profile. So the idea being that when you're blockchain side, you can check whether a user has signed up to your application or your service or your DAF. And so what we do is every time a DAF is registered by any developer, we write a contract onto the public chain and we manage that contract in terms of addresses that are allowed or entitled to use that service. So think of it like a quite a simple authorization model, but based on users rather than, obviously it's implemented by our addresses, but it's opaque as to which user it is on the blockchain. Well, you can see all the addresses that are allowed. And we manage that contract on behalf of the developers. So it's a pretty simple system, really. A delegated identity system, along with an entitlement service based on that identity, and it's glued together with the wallet because it's a nice interface to blockchain. Just a very simple architecture diagram. We've got our two services. We have our developer console, where developers obviously get to log in and register the DAFs. And we have a wallet manager, which is our admin page. So you can understand your wallet if that's for any user. On top of that, then obviously we have the blockchain with the entitlement contract that we're writing. And then that obviously is associated with the actual DAF contract. And they use that to understand which users can access them. And of course, they're UI extension. Very complicated. Just in terms of where we're going with this, you'll see now we're going to do a demo in a minute. I want to get away from the slides. We're going to, at the moment, we're using pop-ups for the wallet. It's all web-based, the interface. And then we're going to move to also have a web extension, sorry, a Chrome extension, so that we can make the UI those quicker. We're thinking about APIs that we can add. And more interestingly, I think these are really APIs for developers to exploit more information about the users that are using their applications. And so they can understand which users are using them, how many, et cetera. So some user-level analytics, as well as basic users information. And also I think we're thinking about extending the APIs so that we can integrate other wallets into the system in the future and we focus more on the entitlement. And then I think we're on to the demo. So we're going to show you the full developer sign-up and how they go from signing up their DAP to actually constructing the contracts and then building a web app that integrates our JavaScript UI for the wallet as well. And hopefully that works. We'll see how the Wi-Fi is. Hi guys, my name is Mihai. I prayed really well to the demo gods today. So let's see if we can build a simple DAP and hook it up to the ProPoint ID service to our clients. All right, so I have this Ethereum node, a Go Ethereum node that is connected to our private Ethereum network. I chose that because of speed. We already launched on the public Ethereum test network but that is a bit slow right now. So in the interest of doing this quickly, I chose this one. All right, so let's see if it's really connected. All right, so we have peers. That's good. All right, this is our developer portal. So we log in and we have a choice of a few auth providers. I will choose Google for this. This is, I zoomed into this so it's a bit stretched. But it's a simple portal. It's register our DAP, register. So we're trying to build a color survey, the most complicated DAP ever. But choose your favorite color. I'm gonna choose the network to be used as Edgeware. I don't know if you're seeing this on the screen. Just play there. So this is the target blockchain where our entitlement contract will be deployed from our backends. Let's put in a unique identifier here. This is how our backend identifies our DAP. And this will be baked into our registry in order to find the entitlement contract that needs to be deployed. Explain what this is. This is where your DAP will be called back by our identity service to deliver JWT. So the DAP knows the identity of the user. All right, let's grab a very nice logo. And this is the license agreement that Richard was mentioning. Our users need to accept it. Lots of text there. All right, and I hit register now. Our backends go and do their job to deploy this on the Ethereum network. But in the meantime, we already have a template of a contract here that we can use to deploy our own. All right, I'm gonna quickly explain what's here. So we have our entitlement registry which is a DNS basically, which is hard coded at this address. And our backend will bake into this entitlement registry and the address of our code here are colors, our DAP. So we're taking that and we wrote a modifier which we will basically use to know if the client that is currently sending the transaction is open or not, there's all that. I'll quickly copy from the documentation. So there's a full documentation of what I'm building today. So you can reproduce it at home if you want. Grab this, put it right here. So basically it's just a function to vote for your favorite color, which is red or blue. And we're applying this modifier here to guard our function basically. All right, that's about it. So we're gonna quickly grab this to deploy on our node. Somebody with some blocks. Oh, actually I'll back in with some blocks. All right, all right, this is our contract. And now this is the web app that will be used to interact with the blockchain. We need to include the web tree and a block that comes from us which will govern the interaction with the identity service. We need to put the contract address here. And the other important bit that is needed here is from the colors, which is the ID of all that. Other things are the current blockchain network that we want to plug it. And these days are our standards, which says the services that the deaf needs to interact with will be applied away from here. Yeah, so that's about it. This will be hosted locally. I have a web service here, which I'm gonna restart, and it's right here, login. We will now login as this other guy, authorize. All right, and now this workflow is given by the way the blob that I showed you here that comes from us. It works the user to create a wallet before interacting with the app in the first place. We're going, this is our wallet terms and conditions. As you can see, we're using an HD wallet, so I'm gonna pretend to save those, right? This is the licensed agreement that the user needs to accept, all right? Now our backend is going and invoking the address into the entitlement contract, and now the contract of the DAP knows that this user has registered and is able to use the DAP. Let's see if it actually works. These buttons are basically, so we're pulling from the blockchain once every second, the values red and blue to be shown there, and this is the function to send the transaction, which is taking the current account, which is right here.  You'll see that in a moment. But before showing you that, let's go to the actual wallet. So this is a page that the user will use to manage his wallet, explain a few things. So inside our wallet, we get different namespaces, we call them. As you can see here, we are on the Edgeware network with this namespace and the same on this one. This default namespace used to hold your ether, you can get as many of these accounts as you want other accounts right here. And for each DAP, we're creating a separate namespace, so each addresses that are designed for the DAP will be separated from other DAPs and from your personal ether account. We also have a magic ether button here because we're in a network where ether doesn't cost money, so we can get ether for this as well. You can backup your wallet, change your password, et cetera. Yeah, so this is our wallet management page. Because we already have some ether, so we have money to pay for this transaction, we ask for it, let's see if we can actually use this thing. All right, so important fact here is that this popup is on a tonsil Reuters domain and not on a DAP developer domain. So that means the DAP developer and the DAP doesn't ever have access to the private keys. They only see the public key and then when they send us the role transaction and we sign the transaction and we deliver it to the blockchain. And we only deliver the fashionable transaction back to the DAP, all right? Here we, you can see more details. This is the unique ID of the DAP. You can see the account we're sending from, account, the smart contract address we're sending to and the actual role transaction if somebody is interested for the most technically minded. But for the day-to-day users, the information is very brief. You can see your gas cost here and you need a password. You can see we need to put the password quite so many times. So we're trying to get rid of that with the browser extension, we'll be doing that. All right, so let's confirm our transaction. And this is to demonstrate that the DAP got the transaction hash and we actually built it. So that's about it. We're at my own, this is Jacob and we're from Alice, we're a blockchain philanthropy platform. But before I explain exactly how that works, can I just ask everyone, is the last time that you didn't donate charity? So you know what I mean by didn't donate, right? The other day I was at Waterloo Station, I saw these guys walked straight past them, didn't talk to them, didn't donate anything. And well, actually I felt bad about taking their picture so I did stop and then they convinced me to give them something anyway. But you know what I mean, every day there are so many opportunities to give to charity. People doing fundraising appeals in the streets, there are TV appeals, charity shops, and yet we routinely just pass on the opportunities to give. And the question really is why that is. And if you're like most people, it's a question of trust. It's a bit like feeling like Mowgli in the Jungle Book and charities are just asking you to trust them and give them your cash exactly. And this year actually the charity commission recorded the lowest ever level of public trust in charities ever recorded. And when they looked and they dug into why that trust deficit exists, they found that it's very intuitive actually. It's down to the fact that people just have a perception that there's a lack of transparency and a lack of accountability into how the charities use your money. And so it's against that background that we decided to use blockchain for Alice. And the good thing is that charities are starting to look at blockchain technology as a way to enhance trust and transparency. So this quote comes from a report that was put out just earlier this year by a charity think tank, a charity aid foundation. And the fundamental, I mean, I'm not gonna, generally at this point, I do the whole what is blockchain thing, but I think you guys all know. But it is really down to them trying to figure out how they can really restore public trust in the sector. And certainly it's why we got into this space as well. So Alice's mission is to make it really easy for charities to be as transparent and accountable as possible. So the 160,000 charities in the UK can raise more funds for all the amazing work that they're doing, helping homeless people or helping people deal with their mental health issues and the other sort of loads of causes that they're involved in. And there are different ways that we're tackling this, but the very first one is basically a radically transparent way to donate to charity that we've developed. We're gonna run our first pilots in January next year with two homeless charities. And what they're gonna do is they're gonna put out their appeals to the public to donate to their causes. Except they're gonna give the public a success guarantee, which means that when people donate, they will get their money back if the charities don't manage to deliver on the outcomes and the impact that they promise. And that's gonna be the Alice promise, if you like. So the way it works really quickly is obviously there's a smart contract at the center of all of that. We took the decision that we were going to collect money in fiat because people are used to donating to charity that way. And so we take that, we collateralize it. Jacob's is going to explain a little bit better how that works in a second. Collateralize and tokenize it. And then the charities can then just go off and run their programs. And they will basically have to deliver on the outcomes. So if the homeless charity is saying that they are gonna help rough sleepers find sustainable accommodation, the proof of that is actually the fact that they signed the tenancy agreement. And we're not gonna ask them to self report because that would kind of defeat the purpose. So they actually need an external independent validator to sign off on the fact that the proof has been submitted and it's valid. And the every single piece of, every transaction, every validation, every donation is registered on the blockchain. And once that that proof has been submitted and validated, the charities can then redeem through these tokens, the fiat donations or whatever corresponds to those outcomes. And then it hits their bank account. So they get the money and donors have absolute transparency over how that will impact that money made, basically. So now I'm just gonna pass it over to Jacob to talk about the Ethereum integration. So for a user perspective, our sites look like a typical donating site, but behind the scene we process all of the integration with Ethereum platforms. Yet we still believe in the Ethereum idea of decentralization so whenever the donors are made sure enough to process all of the integration with Ethereum on their own, we get the ability to export the account and do all of the transactions manually. Another challenge is with accepting donation in Ethereum currency. We do not want to do it because we don't want to put extra burden to our donors to exchange the grants they use every day to Ether. And we are aware that Ether is still quite a volatile currency. So we don't want to gamble with donors' money. That's why we accept donation in a fiat currency and then we call it that ties them to our Ethereum tokens. We pack it one-to-one to a bounce and leak value and we are working together with Tronmolex, a company that gave the presentation last month. The first problem that we face was connected to the nature of donation. They are not evenly distributed in time. Usually around the Christmas time when you are with your family and you have a warm feeling and you want to share the joy with the less fortunate one, you want to make donations. So for us, actually it means problem because there is a very high peak in the volume of donation that we need to handle in a very short period of time. That's why we get the built up the mechanism of asynchronously processing all of the transactions of trusting them and for creating a steady stream of transactions to integrate with Ethereum. Yeah, we also want to have a peaceful Christmas time so we don't want to be down on our lounge today. So that's, we got this extra layer of protection between integration with Ethereum. If you've got more questions about the technology behind us, I'm available after the presentation. So these are our partners to date. So as Jake was saying, we work with TraminX on the fiat collateralization that was made public just a few days ago. They're part of the FCA regulatory sandbox. And the two homeless charities that we're planning our first pilots with are there as well. We got some initial grant funding from the Nominet Trust as well. So they're specialized in sort of social tech. If you're doing social tech, it's really worth applying for their grant. They're really great partners and we're also part of the social tech accelerator that's backed by the cabinet office and by Nesta called Bethnal Green Ventures. And all of that has been really helpful in helping us get everything off the ground. So that's us. We're Alice. We're helping bring transparency to the social sector using blockchain. We're looking for partners. We're looking for charities. We're looking for all kinds of people. If you're interested, please come talk to us. And in the meantime, if you have any questions, go ahead.