 I'm Andrew. I'm a dev. You can probably hear that I'm from the UK. I'm sort of mainly over here giving a talk or workshops sort of yesterday on Freya, which is an F-sharp system, for doing sort of accurate HTTP programming. But I also said kind of foolishly that I'd give a quick short talk as well on sort of thinking about HTTP and functional programming, given that I've spent the last year or so doing so. I actually forgot until sort of the middle of the week that I'd actually sort of said that I'd do that, which was slightly problematic. And I was looking through the spreadsheets to sort of see what I'd actually like quite like to go and see. And I sort of thought, oh, that looks kind of interesting. That sounds like that'd be just up my street. I wonder who's presenting that, which was an unfortunate way to find out. So HTTP and functional programming, I sort of start this off on a really positive note. The reason I care is obviously I've been sort of spending the last year sort of doing a fairly in-depth kind of approach to functional HTTP. Obviously, as I say, I've been working on the Freya stack, which is an F-sharp sort of approach to building a whole sort of full stack of everything from basically sort of server up to high level abstractions and hypermedia and that kind of thing. That's a reasonable reason for me to care. It's not particularly great for you to care, but there are probably reasons why you should. As much as anything else because sort of HTTP is just everywhere and getting more so. And it's usually really terrible. So most people are very, very bad at HTTP and most implementations suck in terms of actually being able to use what it's generally meant for. It's actually a really great standard, but people use about a third of it. So it could be a lot better. It's probably worth making it better. One of the reasons I sort of decided it was more important was I suddenly saw about two months ago an advert for a drone which was HTTP controlled and decided that I thought that sort of educating people on proper HTTP was now a higher priority. Seeing as 404s could now cause death, it was really a bad idea. So I should note sort of that this is a very entirely opinion based talk, which is a kind of polite euphemism for potentially wrong, but you have no way to prove that. I have this kind of contention that for all kinds of reasons HTTP is sort of the poster child for one of those systems which people use about a third of, but would have a massively nicer life if they actually use the other two thirds and that was easy to use. I'm not really going to talk about client side kind of stuff here, I'm mainly talking about server side kind of HTTP. It's not that the client side isn't interesting, it's just that I don't know a whole lot about the client side and there's definitely something to be said for picking subjects where you aren't likely to run out of knowledge by about slide four, which is this one. So FP is actually a really good sort of approach to HTTP, it maps really well to good ways of thinking about it and now's a good time to do so. There haven't really been many new ideas around approaches to web programming, HTTP, that kind of basic layer for some time and sort of big companies aren't going to do anything exciting. It's going to have to be open, it's going to have to be community driven and the communities where we see actually interesting things happening with sort of new forms of thinking around program construction and problem decomposition, that kind of thing. Right now I'm mainly functional communities, so yeah, hooray for us, that's always lovely. There are cool new languages, but things like Go and Rust and all the rest of it aren't really doing anything particularly exciting around sort of web programming, they're building good, solid systems, but they're not anything particularly new. They look a lot like the web frameworks and stacks, so however you want to sort of pick that granularity, they look a lot like the ones that we already have. So as a sort of kind of a side, I've sort of had the sort of feeling about some HTTP and web systems and this kind of thing, and this is where we get entirely subjective and personal, and I kind of make myself persona non grata at various programming conferences. So as an analogy, the AI winter for various reasons kind of killed off, or at least temporarily, a load of interesting thinking and development around things like LISP. Like the loss of confidence in AI research caused that kind of stagnation in funding and interest in all these kind of things. And LISP kind of stopped progressing as a side effect because the people that were wanting AI to produce this kind of magical, wish-granting unicorns and had all the military funding kind of went, no, no more of this so you don't get any LISP either, which is kind of a shame. So it's sort of an unintended consequence of something else that you ended up with this kind of stagnant marketplace. And this is a bit which gets me thrown out of things. So, and I mean this with love, like Ruby folk, it's great and please don't hurt me with your troublingly human syntax, which is just uncanny. So it's a bit stifling. So Ruby was this amazing success story. It did amazingly well. It did a bit too well, really. It sort of made some things really easy. It got tons of hype, everyone started adopting it and every language has to have its own rails and its own framework and everyone started building new rails like frameworks and stopped asking questions. So this kind of de facto architectural style got created where now, whenever people talk about new web framework, they start thinking about, okay, how are we going to do the routing or how are we going to wire up the controllers or all this kind of stuff without asking some more fundamental kind of questions. So we ended up with this kind of NBC style framework winning temporarily, hopefully temporarily, but it's kind of, you know, it's going away but it's still kind of there. We've had years of just, this is how web frameworks look, which isn't really brilliant. We could do a lot better. Again, it's kind of very much opinion-based but people got a bit too obsessed with the wrong program. And, you know, sort of solving the wrong problem here is kind of what's ended up, we've ended up with this good abstraction for the programmer but a really bad abstraction for what we're actually trying to do. You know, we've made it really easy to know how to structure a web app, you know, your controllers go in this folder and you have these views and this is how you show people things and that's great. But it's a really bad abstraction over HTTP which is theoretically what we're supposed to actually care about. We're supposed to care about actually getting data to other systems and having this great communication protocol. We've actually just made it really easy to organize our code in like neat folders. What we haven't done is made it any easier to really work out how the hard bit works which is taking your problem domain and mapping it to how do you represent that over HTTP. We've got all these systems which are, you know, these existing complex business systems or whatever they happen to be. But we haven't really solved any kind of problems about, right, you know, how do you actually make that work properly on the web and take advantage of what I can do. It's also really hard not to end up with all your logic kind of scattered around various places when all of your structure is based around your web framework and not around what you care about. You know, we even ended up with sort of MVC on the client side as well with things like backbone or this kind of thing. And again, it's sort of gone through the same kind of cycle where initially this seems so much easier because it's solved all these problems of organization and it's very reassuring to have this kind of comforting framework around it. But is it the right abstraction? Maybe not. It's an abstraction which is probably actually orthogonal to the problem you're trying to solve. It feels really neat and tidy but it isn't solving the right thing. So we've made the kind of simple developer centric parts really straightforward. We've come up with this kind of unifying framework but we've lost sight of what we actually want to do which is actually be accurate with thinking and we've cut ourselves off from how we should be thinking about building systems like this. It's become too easy to think in terms of things like Pages and CSS Pipelines and bundling and all the abstractions and all the minutiae. These implementation details and loose site the fact that HTTP on its own actually does huge amounts of stuff. One of the reasons why this matters more and more now is because we're getting HTTP2 coming along and the model assumptions actually change quite significantly in terms of what that means for people working with HTTP connected systems. If we're not familiar with the existing assumptions if we don't have the right tools in place now and we don't write mental models we're gonna miss out on what HTTP2 can give us as well. So we've got great tools and type systems and this kind of thing creating the useful stuff for the developer and we've made the devs life really easy but when we've actually started to look at the actual protocol, the hard work we're doing, you end up with other stuff which is not really great again. So we end up with these wonderful sort of strongly typed really opinionated frameworks which are all around how you structure these controllers but very little to be said around how do you actually make sure that you're sending the right thing to the client. It doesn't help you at all with deciding that this is a 406, this is a 418. Are you actually a teapot at the time? So we've got these blobs of text if we're lucky maybe some streams. If we're really lucky we might get an associative map of things we care about but it probably isn't anything wildly great to use. And functional tools and functional programming and by functional tools are really the mental ones that we have. Things like this sort of purity of functions, type systems potentially at least. Give us better tools to think about what this is. So when we look at HTTP, we've got this long form spec, we've got some grammars, we've got a bunch of RFCs but those aren't a wonderfully good place to start and actually it becomes a lot easier if we actually start to work with the tools that we're familiar with. So if we start to take, if you like a type system approach to HTTP, we can start trying to model things in a way that we can actually understand and then we can actually make tractable. So if we start to think about HTTP and what we would want it to do if we were starting from scratch we might start with something a little bit like this. We know we've got a request, we know we've got a response. And then I think, well okay that's fine but have I got a little bit more than that? Well I have, I mean obviously I've got this request to something so I've got a request and a world state and then I've got a response and then actually that asks administering questions about my understanding of HTTP. So is a request world response function actually pure? Is that referentially transparent? Does that always return the same thing if the world is the same? Well people argue with me on this one and people say things like, well if I had a get function which is a random number generator then obviously this is not gonna be the case. Unless you start getting really hand wavy and annoying like me and say, well maybe the random number generator seed is part of the world state in which case, yeah it is. So it doesn't actually imply nothing in HTTP spec says something about the fact that these things have to be referentially transparent about these. It doesn't do these things but because we've got a functional approach and we start to think in functions actually it makes it a bit more useful to start thinking about this and in our world it might be the case that actually yes this does always be a referentially transparent function. This might be pure. We might be able to make these assumptions about our problem if we start thinking about our problem in the right way. We can start to break down what we mean by a request and a response into a way which actually makes sense to us. So we can say okay if we're reading some data from a service and we've got some sort of selector which may be interesting in some way we're gonna want to know how to tell the server what we want. We're gonna have some metadata which might be something else to do with the query. We're either gonna be reading or writing to the server. We gloss over this. Writing might be a push. It might be a post. It might be a patch. But we're doing two things. We're either getting something or setting something. So we can simplify our assumptions there and say okay right well are these really special cases? Are they different cases? Yeah they are but we'll model them differently. We can go on and say things like right okay well our understanding is getting a little bit broader if we start to think about this. We can say that right actually this request is asking a question of a system and expecting an answer. That's all it is. We're asking a question which is do you have this? Can I see it? If we say that the metadata that we passed with this sort of thing if we were deciding this thing from scratch was some preconditions. So don't actually bother answering this unless you meet all the preconditions that I care about. And also don't bother answering if you can't meet my expectations about the answer. So unless you can tell me in this way I don't care. That's cool. And actually we find those concepts map directly to things like conditional requests and content negotiation respectively. But we could have got those really quite simply if we wanted to create a system which was usable. And it's probably easier for us to start reasoning about something like this or teaching people how to create repeatable accurate systems when they used to programming and when they used to functional programming especially if we take this kind of approach rather than 80 pages of plain text RFC. It's fun and it's exciting and everyone loves ABNF but it's not quite as applicable. That's two people actually sort of doing things on a day-to-day basis. If you can actually start to talk to people about, you know, yeah, okay, this is great but is there a precondition where you wouldn't care about this? Here's what a precondition means. Here's its type signature. This is potentially handy. So it's a great opportunity for us to take the functional programming approaches that were useful and apply them, you know, better than we've currently done with web systems. It doesn't just apply to HTTP but it's kind of near to my heart now because of what I've spent the last year doing. So the second chunk of this sort of lasted 10, 12 minutes of me ranting is a little bit about some directions which we're already taking which there are sort of interesting things that are happening within the functional programming community within different languages, different scopes and some things to sort of sparks some ideas around there's more to life than rails like things. So I've skipped all of the functional programming frameworks which are rails inspired. I'm arrogantly declaring them uninteresting in this scope. They're not, but you know, it's there's only so much time and I don't want to imply that there's nothing great already happening because there is and we'll see a little bit of that but it would be interesting to see, you know, the more people that we get thinking about these things and taking different experiences from different problems domains and applying it to things like web programming, web engineering, then that'll help. You know, this cross-domain thinking is a useful thing to have. Reactions to seeing what's out there are usually what spark the next useful idea and you know, there's definitely something better than rails which is possible at some point. So we've got a lot of functional concepts which we can bring with us which we can start off with in non-functional languages, dysfunctional languages, whatever we want to call them. We have all kinds of efforts to create things like standards around middleware, you know, these complex topics, how we deal with them, how you reason about behavior of middleware pipelines and all this kind of thing. We get all this stuff for free. You know, we can actually skip past a lot of these concepts because we know that actually half of these things are just function composition or partial function composition. You know, a pipeline that runs, that's great. That's just a composition of functions. Pipelines that runs until it hits a certain thing. Yeah, that's composition of either functions. Pipelines that maintain the request and response status who run them, it's composition of state functions. If we want to combine that, yeah, it's fine. We can probably do that. We've probably got some tools for combining these functions already. We have this in our toolbox. So we've got loads of things that we can use. So looking at various things that are currently happening and maybe sparking some ideas off, it's always nice to get some relatively new languages sort of shouted out at. The literature have taken some really great steps as a community in the first stage by sort of specifying how compositionality of a literature web frameworks and a literature web modules are going to work straight off the bat. So yeah, obviously it's optional, but they have a fairly strong and small community right now so they can say, right, okay, we're going to learn the lessons of this kind of, you know, non-compatible kind of world that a lot of languages end up with. And we're going to say, right, okay, plug is how this works. If you want to work with everything else, here's the way it works. It's pretty simple. It's quite low as common denominator. You can build your abstractions on some of this. Haskell has ended up in a similar kind of world but much later down the road. They went through various abstractions. They went through things like hack, probably ended up with something like web application interface in Haskell, which is at least a sort of functional standard which people can work with. It basically comes down to some fairly simple type signatures which you can implement. You know that if you have this kind of thing, it's tractable to other programs and to other people. We can take some ideas around things like type safe values. So, you know, we know that we've potentially got some interesting things about type systems, at least in some of the languages in the functional programming world. This is not to disparage languages which have different types of type systems. Closure and all those things are fantastic. But there are some things that we can do where we do have different types of capable type systems. So, you know, one of the things which has kind of been a theme in various sort of talks at this conference is making the, you know, invalid states unrepresentable. How close can we get to that with the tools that we've currently got? So, in Freya, which is the project we're typing, working on, I promise not to refer to that too much, we have a type system representing basically all of HTTP 1.1. So everything that you might want to do is strongly typed. Anything which you actually work with in terms of writing data, reading data, happens through a strong type system where you can only write essentially valid data. Underneath that, we have this horrible bunch of strings. It's a shame that's the way that .NET works we're doing a massive mutation of a nasty string field dictionary. But we can hide that with some of the functional tools we've got by applying all this through some lenses and morphisms so that where we actually got a string, what we see is this beautiful type and when we write it back again, it goes back to a nasty string. It's better than nothing and it's gonna make some of the programming that we do a lot safer. There's some lovely things in the Haskell world. So, yes, it'll take things a bit further than we currently do. They have a bit more of a type system to play with. They've got things like Haskell extensions in terms of things like quasi-quotation. So, compile time checking of more of the data which we're actually sending back to clients or compile time checking of the data which we're using to build and compose these systems. So, we can have compile time checking of templated content. We can eliminate issues around character encoding, around content issues, around having headers which will be invalid in certain contexts. So, we can actually get the compiler closer to enforcing HTTP standards. There are crazier people. There are the Agda community and thankfully this one is seemingly abandoned. It's probably too small. Oh, God, no, it isn't too small to read. I'm so sorry. This is a small extract from what I can only describe as a massive screed of insanity which seemingly now abandoned but which is essentially an effort to prove the RDF semantics in terms of a semantic web on top of Agda. In terms of all of it, every single thing is description logics is consistent proofs so that if you can construct this, it is by definition RDF. I'm not sure what that gives you. I've never found RDF useful but it's definitely valid RDF. As I say, it does seem slightly abandoned. I think this was last update about five years ago. There's only other one person that worked on it. I presume he's found something better to do with his time. It's probably, if he had the same reaction as me, that was probably because at some point he sort of looked at this and decided, yeah, not happening at all. Type safe combinators back to the Haskell world with some really interesting ways that we can take composition of programs. We can take them away from the type level and start to build them into larger chunks. So we have this kind of world in FP of our heuristic for what feels like good FP is composing larger things and more complex things from less complex things and smaller ones. And we've got a bunch of frameworks which is just bringing up around really interesting type safe combinator models. So servant is one where you can essentially define your APIs as applicative signatures. In the F sharp world, we have SWAV, which is a kind of similar sort of world. Everything is an applicative functor. You pass everything around. You have a set of operators which you can compose any other applicative functor with. You get something which is predictable and reasonable and hopefully deterministic. There are some interesting plans to make that non-deterministic, but yeah, those should probably only be discussed in the pub. Functional modeling is another way which moving further away from the mechanics and nuts and bolts of HTTP, we can actually start to look at the logical level. So traditionally speaking, in most of these frameworks, once you get a request in, you're kind of on your own. In a Rails model or anything else, you take over where the request arrives you hand responsibility back when you're done with it, when you have the response you want to send. So any logic and any sort of interpretation of how you should be interpreting the HTTP standard is down to you, basically. So I do hope you've memorized all of the five current RFCs, the 42 HTTP statuses and all of the logical gates which you should go through to decide exactly which one of those is relevant and decide whether it should be not acceptable or not found if you ask for something in a form you can't have, but it doesn't exist. Because HTTP doesn't actually tell you what the presence for that is. So you can handle all that yourself or you can take different approaches. So Erlang was one of the first languages to implement a machine-style framework. If we actually model the process of handling an HTTP request as a decision graph, as a set of states, a state machine that we move through where each of those state transitions is basically a decision about our request, that's kind of useful and we can allow the developer to actually say, right, I care about overriding these ones. I'm going to override whether my resource exists. I'm going to override the types and representations that are available. I'm not going to override the rest of it. I'm going to assume that the graph that's here is sensible. I don't need to care about doing all the nuts and bolts and the legwork anymore. I'm just going to answer a few questions with true or false values. I think Erlang and the web machine project was, as far as I know, the first significant implementation of that one. There are a few others, Liberator and Closure. Sorry, Freya does another one as well, but we take it a bit further. So we actually let you modify the graph and apply functions to the state machine. So if you actually apply functions of state machine to state machine on a per resource basis, you can actually modify how that graph works and what the logic expressed is. So you can say, okay, I'm going to write a function which transforms that graph, so it now supports webdapp as part of its decision tree, or maybe add HTTP 4.1.8 support in case the server is actually running on T-Pot-based hardware. As a random thought, I looked up when the RFC was created, the joke RFC for HTTP 4.1.8, and realized that it probably seemed a lot less likely that the internet of things would actually mean that programmers now would go, yeah, that's fine. I mean, I've got a database running in my fridge and that doesn't get a status code, so why is this even here? You can take that further too, unfortunately. Back to Agda and then the crazy people in that world. You can take that further and say, right, we have a graph, we can make that a proofable graph. We can actually write a set of proofs so that our default resource graph is guaranteed to return a correct HTTP response by composition of lemons for each stage. And if you want to modify this graph, that's fine, but you have to provide the modification and the proof that your modification is sound. As I say, I would have had a code sample for this, but I've never found a way to actually make it run, compile, or work in any meaningful way whatsoever, but it does look amazingly cool and I would really love to see it resurrected. So if anyone actually is an Agda genius and wants an interesting weekend project, it's probably only a few hours' work, feel free. Where have you been without an Idris example as well? So Idris Web, young as it is, is probably the furthest to anything he can go, so taking its embeddable DSLs, the syntax macros that they actually have to do this, they've come up with a framework for enforcement protocols such that all requests have to be safe in terms of all the resources they're using on the server side. So things like making sure that you cannot actually open a database connection, then do something with it if that database connection was invalid, they can enforce a compile time, not just at runtime, which, again, makes things kind of useful and if you start to look at how you can combine some of these techniques, you combine things like state machines, type safety, some of the sort of functional principles and composition that we have, you can start to envisage a framework for doing things usefully, which is way beyond what we have at the moment. Functional programming is this amazing sort of visualization tool and understanding tool for understanding systems like HTTP. Other ones as well, obviously anything where we have a protocol, everything where we have a definition, we can take HTTP, we could take abstract mathematics, we could do all sorts of other things. Anyone that saw Doug McElroy's really lovely tilt this morning will sort of see how well all high school maps to power series. It turns out the programming is actually a much better way of expressing our understanding of these things than just abstract syntax or ABNF or mathematical notation. It's actually sometimes amazingly useful to be able to put these things into type systems and run them and prove them. So on a final note, there's a load of things which we could be doing at this point and there are reasons to care. Fundamentally, we've got an amazing sort of level of momentum going in the FP community right now. The web sort of framework is often and the web sort of space is one of the places where we kind of lose when it comes to attracting people. I know from kind of painful experience that one of the sort of objections leveled against FP and other approaches on a regular basis is it's good for certain niches but it's not good for all things. It could be fantastic for all things and we've got an amazingly smart community that could add to that. And so hopefully we will find some new lessons and someone in here will come up with something which is a lot better than we have now. So thanks for listening to me around. Thank you. Thank you. Thank you.