 I think we'll get started, yeah? So, why is this talk for idle programmers? Well, it's a talk for idle programmers because this talk is not really about work. I'm afraid to say I'm not going to teach you anything useful at all in this talk. I'm not going to show you how to run your business better or how to scale your website or anything like that. Now, some of you might take a pretty dim view of literature criticism already. Someone like Paul Graham, for example, if you read through his essays, he seems to be really pretty down on literature. But I think there's something interesting in the subject, although you might not immediately see how it can apply to something like coding. Though, in my view, a programme is a lot closer in some ways to a novelist, or a playwright, or a poet than they are to the sort of more traditional metaphors of engineer or architect. We write for a living. Here are some quotations. Programmes must be written for people to read and only incidentally for machines to execute. My feeling is that when we prepare a programme, the experience can be just like composing poetry or music. Another one coming up from Nick Callan, who is the original author of Arrell, is writing in a blog post explaining how and why he wrote the library. All my open source projects share two attributes. First, the source code is extremely stylised and meant to be read more than used. They are literally arguments in code much more than a useful piece of infrastructure. It seems that at least some programmers see their activity as primarily artistic or literary. On the other side of the coin, from the literary critic's perspective, in a very famous book in the early 20th century, the very first line, the book is called The Principles of Literary Criticism, the very first line is, a book is a machine to think with. That seems to put the book back into the world of the engineer. You can take a book apart, see how it works, put it back together again. I really like this phrase. So this phrase sums up for me a lot of what literary criticism is about. Normally you think of things like novels that are somewhat frivolous, they're for entertainment or something. But when you think about them as tools to exercise the mind, I think that changes somewhat. So this is going to be a little bit unusual. For the first time, a programming conference, I'm actually going to do an example of literary criticism. It's going to be a somewhat simplified example. It's kind of like the hallow world of literary criticism, if you like. So I'm going to read you a poem. Mrs Darwin, 7 April 1852, went to the zoo. I said to him, something about that chimpanzee over there reminds me of you. So what do you think of that as a poem? Hopefully at least some of you find it slightly amusing. How should we criticise it? Well, let's start at the start of 20th century literary criticism around the 1920s and 30s. Before then there was literary criticism, but it was very much ad hoc. It wasn't formalised in any way. So you had people writing apologies for poetry, trying to convince people that poetry was a worthwhile activity. You had biographies of writers and so on. But the new critics wanted to bring the focus back to the words on the page. So you notice I haven't told you when this poem was written or who the author was. The whole point of that is it's trying to get an objective view of the poem. It's trying to avoid context as much as possible. So what's this poem about? Well, I mean like obviously on the surface, it's the idea that instead of getting the idea for the origin of species from his trips to the Galapagos Islands, Charles Darwin actually gets them from a throwaway comment by his wife because he looks presumably somewhat unkempt when they're visiting Regent's Park Zoo. So why do we find this funny? To a certain extent, I think there's something about bursting the bubble of authority going on here. Look at Darwin, look how serious he looks. He's kind of like one of the great minds of history, right? Sort of like putting the ideas that he's come up with in this context. Kind of makes him more human. Kind of brings him down to our level in some ways. What about the structure of this poem? Well, it doesn't really have any sort of traditional structure that a poem would have. Like it's not a sonnet, it's not a limerick. It's definitely got some sort of rhythm to it. I can put some stresses in so you can see clearly where the syllables lie. You'll notice that in the last line of the poem, the whole rhythmic structure seems to completely collapse and that's kind of the point where the flash of insight comes in. It's the sort of the sparking point for a whole sea change in thought and that's reflected in the structure. What about the style? Well, it's a diary entry, right? How can we tell it's a diary entry? Well, it's dated for one thing, but more than that. It's kind of a familiar way of writing. There are no subjects there, right? It's not we went to the zoo, it's just went to the zoo. It's off hand. It's also clearly placed in a period of the 19th century. Look at the fact that all the nouns are capitalised. That's exactly how something being printed of the 19th century would be. Again, notice the M dash before the speech. The speech is an in quotation marks. What about ambiguity? That's the other thing that the new critics wanted to look for. Is there any ambiguity in this poem? Well, that no explicit subject thing is sort of bugging me. Look at that hymn. Capitalise hyn, okay? So normally when you see that, that can refer to God, right? Maybe Mrs Darwin isn't in the park after all with her husband as we immediately suspected. Maybe she's kind of like inwardly blasfeming somehow. Maybe she's sort of thinking that a monkey is made in God's image, not man. So you might not be quite sure whether that reading is right or not. You might also think to yourself, well, did the author intend that? And the new critics wanted to get away from the idea of what the author intended. They called that the intentional fallacy. So you still might not become quite convinced. And you definitely might be convinced when I carry on. So in the 60s, there was a whole group of critics that sort of followed on and really wanted to push the boundaries of ambiguity. They called the structuralists or post structuralists, the boundaries between them are somewhat blurred. And what they were looking at was not really so much individual artworks but the instability of language itself. How that it was kind of impossible to avoid misreadings in any word you choose. So at this conference there are a lot of Max, right? And the O.S. Colonel of Max is called Darwin. So perhaps this poem is actually about the wife of an O.S. Colonel. Mac OSX, right? Os, ex, os, bones. Root of fossilized. Fossil certainly had quite a lot to do with proving Darwin's theories. Ex, ex chromosome, obviously. Part of genetics. Again something to do with the thoughts that Darwin came up with. So obviously that reading is stupid. The point is that language is hard to tame. That there are lots of unwanted meanings in words. Program has spent a lot of time naming things. I think it's worthwhile realising that every time you use a word there are all these other things that are sort of rushing in around it. Maybe it helps make sense of the phrase that's quite famous. There are only two hard things in computer science. Cash and validation and naming things. So I'll tell you now like a bit more about the context because I think it does add something. So the poem is by Caroline Duffy and she's currently our poet laureate. It's part of a collection called The World's Wife. And in this collection she takes a whole load of figures from history and myth and so on. And she kind of does like a female version. The wives and girlfriends of those people. So you get for example Mrs. Mephistofles, the crazed sisters, Queen Kong. It's kind of like a sort of a rewritten feminist history of the world. So it might not seem immediately obvious how we can apply the sort of thing I've just done to programming. Like I'm not going to ask anyone to tell me what the rhythm and meter are of their method calls, for example. But although the questions might be different, I think the aim is kind of the same. It's kind of like going back to that phrase, a book is a machine to think with. So programmes are definitely useful, right? You know, you couldn't buy things online with them, more boringly fin in your tax return or whatever. But I think it's also useful to think of them as machines to think with as well. So how do we criticise programmes at the moment, though? I would say pretty badly. We tend to say things like, you know, this code sucks or this library is made of awesome. You know, like the standard, you know, like measure, as we all know is, you know, WTFs per minute. OK, so now we might dress this up a little bit. OK, we might say for example of some class or it's not well encapsulated or the methods aren't very intentional revealing or the API is too broad. But at the end of the day, they all want like a scholar would call value judgements. We're saying for example that a class is not well encapsulated, coming from a sort of implicit standpoint that well encapsulated classes are good. Now, I'm not really saying there's anything wrong with value judgements. In fact, they're pretty essential if you're going to be building sort of production quality code and there are lots and lots of sort of books that will teach you how to make those value judgements wisely. So I don't know, Refactoring by Martin Fowler, Clean Code by Robert Martin. But the sort of criticisms they raise aren't really anything like the criticisms that I was making of Mrs Darwin. Notice I didn't really say at any point in that criticism whether I thought the poem was good or not. These books to me anyway feel a lot more like sort of manuals or writing well. They're the sort of books that will tell you how to use grammar correctly to not split your infinitives and so on. The point with that is so that readers can clearly understand what you're trying to say. So at work we're sort of amongst our team currently having a sort of background level debate about the single responsibility principle. So for those of you who don't know, the single responsibility principle states that a class just have one reason to change, that it should do one thing and only one thing. One side of the debate really, really likes this principle. They see it as making the sort of individual parts of the code very simple and it makes it easier to test and so on. And the other side of the debate sees it as leading to sort of more complexity overall. Sure the parts might be simple they're saying, but the overall program is simple. The problem is is the way that this argument is kind of phrased, it's always from a sort of an implicit standpoint in each programmer about what they find valuable. Again there's nothing wrong with that, but it's not really critical in the way that literary criticism is critical. So what would be sort of some example questions that a more literary critical approach would take? Well you might get a bunch of examples of things that follow the single responsibility principle and ask well how do they follow the rules? Well, if they've broken the rules, why? Is it because they've had to or because the author didn't know any better? What about extremes? What would a project look like if it almost completely went against this or used it 100% of the time? Maybe you'd ask things about simplicity in general. Are there different types of simplicity? Can you classify simplicity? Does this fall into one of those classifications? Or maybe you look at the historical context of the principle. Where did it come from? Who came up with it? Why did they come up with it? What came before? What influenced their thinking? Are there analogous principles from other disciplines? If there are, does that teach you anything? Does it make any difference if the programmer is intending to use it or just happened to use it but doesn't really know why? What about the environment that you're reading in? Is it different reading code that's using this principle in, say, a small talk code browser as opposed to files on disk and text mate? Does it make any difference if the program is big or if the program is small? Is it used more in enterprise development than, say, open source development? And if it is, why? What are the cultural things behind that that is creating that? Can you subvert it in some way? Could you make into a joke somehow? So all these questions come down to sort of one question, really, which is how is this interesting rather than is this any good? I'm trying to get away from these sort of questions about individual bits of code and more about understanding a principle in general. So let's go and treat an example actually in Ruby of what we can criticise. Again, I'm going to start right at the beginning with Hello World. So you might think you can't really say very much about that. But I think you can. So, well, first off, what is it for? It's not entirely useless, right? It's the first thing that you typically run when you're studying a new environment or language or whatever just to check everything's working. I mean, it's almost come to mean introduction, right? Everyone understood what I meant when I said I'm giving you the Hello World example of literary criticism. Well, we can also say some stuff, maybe a bit more about Ruby than the actual example here, like the well-worn comparison. It's not like the Java version, right? You can see instantly that Ruby's language seems to be a lot more easy to work with. There's a lot less ceremony. But look again. That word puts is kind of bugging me. Think about it how a non-programmer would approach this. Why is it puts? Why is it not at least put? Where are we putting this phrase exactly? Why is the word something not like show or display? I mean, that's what we're doing, right? I mean, sure, the other way of doing it is print, but again, that's weird. I'm definitely not using my printer here. What's going on? Well, although Ruby is well-known for being simple, actually, there's a whole load of historical accidents that are sort of spiking through. It's puts, right, because it's puts in C. Print also, it's from C, and presumably at some point, it actually would have been output on a printer as opposed to a monitor. One of the other things I really like about this actually, at least the traditional phrase, is the exclamation mark at the end. It's kind of like it's an amazement that we can get the computer to do anything at all. I feel to a certain extent that exclamation mark carries through with you, no matter how big your programs get. You're kind of just, you know, like, wow, it actually works. So, here's another example of Hello World, and it's completely different. I'm not going to show you all of it. 160 lines of heavily pattern-oriented PHP. So, this works. Okay? Now, if you start off by asking a question of this, is this code any good? Then you've kind of already missed the point. Obviously it's not good. That's not why it's been written. This code's satire, right? It's kind of mocking like an environment where design patterns are important with a capital I. You know, it's funny in PHP, it would be funny in Java as well, but I don't think it would be quite as funny in something like Ruby, because the community doesn't have the same obsession with patterns that they do. It also sort of comments on that stage of learning that everyone goes through immediately after learning about patterns, you know, where you're trying to apply them everywhere and it takes you maybe a couple of weeks or months or hopefully not years before you realise that that's stupid, makes you think on, like, reflect on design patterns as a tool, baby. It's interesting because it's a comment on other code. To a certain extent, all code is like that, right? You know, like, you can look at Rails as though it's a comment on the, you know, say the Java frameworks that DHH was working in before. Equally, you can see something like Sonata being, you know, like a reaction against Rails, you know, instead of being this sort of opinionated full stack thing, it's providing a piece of the puzzle. There are so many HTTP client libraries in Ruby, for example, and all of them are a reaction against the HTTP API. So, also, you can start thinking about, well, someone who starts programming today with Rails is probably going to have a very different experience reading that sort of code than someone who has been programming in struts for four years. They're not going to the, you know, they're just going to take for granted, for example, a lot of the sort of simplicity that the struts, the X struts programmer will be so happy to have. So, can programmers be ambiguous in other ways? Well, yes, programs aren't always deterministic, no matter how much we like to think they might be. So, for example, there are lots and lots of different Ruby interpreters, but no spec. So, there are always going to be edge cases where the language is doing something different from what you expected in one implementation. It's kind of like these interpreters are themselves readers of the program, just as we are. Now, normally, we kind of want to get so that what we have in our head as programmers and what the interpreter has in its head, as it were, are the same thing. But sometimes, people actively try and subvert that. So, the Perl guys write a lot of poetry. So, here is a Perl poem. This program runs in Perl. It doesn't do anything, it just, you know, it just runs without errors. But obviously, like as people, it's going to be reading a completely different message into that. Here's another example. It's on the Stack Overflow 404 page. And what this does is it just prints out 404. But it does it in six different languages all at the same time. So, you can run this in C, Perl, Python, Ruby, BrainFuck and Bethunge. I've not heard of Bethunge before. Bethunge is, I think, some sort of weird, almost two-dimensional language. The interesting thing here, I think, again, is that the computer is selectively reading parts of this text and, you know, doing a task that's assigned to it. And we as a human are reading a completely different message. So, these sort of things, programs are called polyglots. I managed to find one that was combined 16 languages into one file, too long for a slide. So, more seriously though, like, it is often the cause of bugs. So, we've all seen this one, right? It's not x equals equals some method call. It's x equals some method call. And the interpreter just completely ignores whatever the author intended here. But we as people can't because we know that this is a source of errors so often. It's very hard for us to tell is this a bug or is this working code. So, also, there are different ways of reading a program, right? Sorry, a program. It's not like reading a novel. You don't start the first line and work your way through to the end. So, most often people, like, jump around like in a static view of the program. You could also, for example, read a program by kind of trying to follow through what the computer reader is doing, you know, via a debugger or whatever. You could also read a program via its tests, right? You could see the test as kind of almost being another way maybe you read the program through its get history, seeing how it develops over time. Unlike, say, in novels, you know, like programs like are never really finished. So, reading process is complex. But let's get back to sort of more about, I guess actually sort of what programs and novels sort of represent. And by and large, that's reality. So, in the 19th century, there was like a movement, I guess, if you could call it that, around realism. Trying to get away from sort of specific genre-based writing like, you know, like the comic or epic or things like that. And try and represent the world as it really is. So, the most famous realist novels or, in my opinion, some of the best are probably in England is Middlemarch by George Elliott and in France, Madame Bovery by Flober. So, then forward to the 20th century and sort of the modernist way of thinking. And there you get a completely different way of trying to represent reality. And that's kind of the stream of consciousness. Trying to get away from the sort of, I guess, the textual rhetoric style into what people are really thinking. Both are trying to represent almost like what the world is. So, in the day job, you know, that's largely what we do, right? We represent reality through models of the world. We think about what to create, you know, not necessarily how we created, like some examples, you know, like an e-commerce site, you might have customers, products and so on. In a social network, you might have memberships, friendships, status updates. We don't really think very often, though, about how to model stuff beyond active record, though. At least in my experience on Rails projects. Now, we're all familiar with, you know, inheritance meaning an is a relationship, right? You know, so, you know, like cat subclass is animal because cat is an animal. Customer is an active record base. That doesn't sound right to me, like I thought our customers were human, right? I'm definitely not shopping with you anymore. It's like you've got a hit man right outside your store with a bazooka, and you're going to obliterate me as soon as I leave your shop. No, no, it's okay, it's fine. You can save me. It's an offer I can't refuse. So what the hell is going on here? I mean, we don't really get that involved in our lives with our customers. Well, the problem is, is like we're mixing two completely different things here. We're mixing the concept of the domain model, which is representing our real world and persistence, which is getting things in and out of the database. Does this matter? Well, in my opinion, yes. Like as the programme gets bigger, like testing, for example, you'll find it will become slow or become messy because there's no easy way of getting the database out of the picture. If you wanted to say, move from writing stuff to the database to writing stuff to a service in a sort of SRA model, it becomes, you know, serious surgery to enable that to happen. It's kind of like the more engineering side of things. I just think it's more bad style. It's a bit like, for me, in a realist novel, to have every other paragraph or so some detailed instructions to the printers on how you should type-set it. So the solution to this, as such, is an approach called domain-driven design, and the crash course on this is that the model, domain model, should be kept separate from any sort of infrastructure stuff. So in the domain model, you have entities which are things with identity. So they might be things like customers or products. And you have values which are things that don't have identity. So things like that might be numbers or money or maybe in some domain's addresses. And then you have repositories which provide the bridge from your domain model to your infrastructure. Key thing here is keeping the model isolated so that you've got flexibility to mould it such that it actually represents what the world is like, and so that you can try and use it as a language across both technical teams and business teams. So we kind of got there sort of halfway with the concept of fat model skinny controller. It's just we got a bit confused about what to put in the model. So a little bit of warning, though, it's still just a model, but after a while of sort of following this approach you might feel like, yes, I've got the real world nailed here. But it's not really like that. Just in the same way that a realistic novel is not actual life and neither is a stream of consciousness in a novel actually how people think. Similarly here, a rich domain model is going to still be smoothing over a lot of the ambiguities, a lot of the quirks of the real world. There's a real difference between abstracting something that's already abstract like a stack or numbers or something like that with different implementations and trying to abstract something like a customer. So some writers like trying to represent the real world but all of them are subject to constraints of some form. So even in the case of a novel you're subject to the constraints of probably length, vocabulary, grammar and so on. In programming we're also subject to constraints. Hardware constraints, memory, processor, that side of things. You've got algorithmic constraints. Sorting can only be this fast. So most of us think that constraints are a nuisance but some writers like have found them really, really liberating. So this guy is Georges Parec. He's a French writer. He kind of looks a bit to me like a sort of stereotypical Unix hacker which I think is kind of cool considering his work. And in 1969 he wrote a book called La Disparation and in that book he doesn't use the letter E once. Now I think that's pretty incredible especially in French. If you translate the books being translated into English which also must have been an extremely difficult task. But just think about the sort of words that you lose if you don't have E. There's no he, she, the in the book. So this sort of book is called a lipogram and that's where you consciously avoid using a particular letter. Can we do that in programming? Well yeah, let's try. So I did a lipogram in E. I chose fizzbuzz because it was simple. So before I show you the way I did it just stop and think about what you lose in Ruby if you're not allowed to use the letter E. Well you can't use any of the following keywords. Def, end, else, else if, return, next, break, raise, there might be others. Can't use each which is the standard way of iterating over collections. So this was the first way I solved the problem. I'd never ever used catch throw before doing this particular bit of code. And I think actually that's possibly one of the advantages of putting these stupid constraints on yourself is that it forces you to look at corners of the language that you otherwise ignore. So one thing I learnt about it is I'd always assumed it was very much just like a go-to construct. But actually it turns out it's a little bit weaker than that. You can't do backwards go-tos using catch and throw. Also notice that again like Ruby kind of helps you here because you've got flexibility in where you place the if statements. I'm not sure what you do if you didn't have that. So it turns out that actually I didn't need to do this. I could just abuse map, right? And like one of the things that I like about this is the fact that it looks kind of normal. You can throw away quite a lot of what you normally think of as the essential bits of a language and still have something that looks kind of sane. It's also kind of shorter than how you do it if you immediately sat down and just wrote it out. Just forcing yourself to not use certain things like actually maybe gets you almost to a better solution somehow. Also think about the way I'm abusing map here. I think there's a really important lesson for people who design APIs here. Like again it's about the intentional fallacy coming up. It's like I will use map how it is possible to be used, not how the author of the library necessarily intended it to be used. So Perrick wasn't alone in a prying constraints literature. He's part of a group called Ulypo that kind of kicked off in France in the 60s. And they were writers, artists, mathematicians, all sorts of people. They were generally interested in restrictions or exhaustions of subject space or combinations. One of the earliest work which I quite like is called 100,000 billion poems and it's 14 sonnets 14 lines. You stack them all up and each sonnet has a cut line so you end up with one of those identikit flip books. So there's 14 of the 14 different possible poems in there. So these sort of restrictions and exhaustion and so on is very similar to what we do quite a lot as programmers in terms of play. You might have seen things like the 1K JavaScript contest or code golfing or things like that where you're trying to pack as much as possible into a small space. Code catters as well where you try and solve the same problem over and over again but trying to do something different each time you solve it. Anyone who enjoys doing that should definitely read a book called Exercises in Style by Raymond Cunow and in that he tells an extremely simple short story which is of a man, he gets on a bus watches someone gets jostled and then he sees the same man later in a square in town. That's the story. But he tells it 97 times in completely different ways. Some of them are really funny, some are angry some are pretty incomprehensible. Definitely worth reading. So we've done FizzBuzz without using E. Are there any more extreme constraints we can apply to Ruby programming? Well, how about writing a Ruby script that consists entirely of underscores? So I did not come up with this by the way. This example is from a guy called Ysuke Endo who is a member of the core MRA team. You do require a library to run it but actually you don't require the library in the actual script file itself. So you need to grab the underscore library if you want it and then you run the code and it prints out, I consist only of underscores. So the cool thing is that the library to enable this the actual bit that does it is actually only 12 lines long. So you can see like we're going to go through it but we build something up with method missing basically and then at exit we evaluate something. Okay, so I'll just put the actual brackets in so you can see kind of see what's going on with the method calls. Like in this case we don't actually care about the arguments to each method all we care about is the number of underscores in the method name. So what we do is we're basically just adding the size of that to a built up code string. So by the end of the initial running of the script we're left with this array of numbers in an array called code. And then in the X hook that's where all the work actually happens. So first of all we join them into one string and group them into three. So those are basic representations of integers. So now what we do is we transform them back into numbers. This gives us an array of numbers. Each of those numbers is the ASCII character like for a particular thing, right? So then we use PAC to turn it back into a string. PAC is kind of like one of those weird methods that I look at and kind of run away screaming from. It's kind of like got these sort of inscrutable arguments. The uppercase C means treat each number as an unsigned character. The star means do it for the rest of the array. So like a more long-winded way of writing that would be something like this. So that eventually gets us down to basically in a vowel statement put, I consist only of underscores. So why was the code in base six? That's the other curious thing and doing a bit of digging. It turns out that's mainly for compression purposes. It's so that you can represent for example the number 112 as 12 underscores rather than 112. What about other constraints? Like so we've had the sort of things like representing reality or constrained on being constrained on some principle. But books can also talk about themselves. Like there's a great book also part of the Unipo movement called Why I Have Not Written Any of My Books. And in it we continually tries to start writing this book but usily fails. So we can do this self-reference probably is quite well known in programming as well and when we do it they're called quines. So the rules of a quine are it has to print out its source code exactly as the source code is. You're not allowed input so like this is out because otherwise it'd be cheating. So an example of how to do this in English like the trick is to find a phrase that also refers to itself. So in English an example might be is a sentence fragment is a sentence fragment. Let's have a look at a Ruby example. So I really like this one because it's kind of like the program stuttering. Hopefully you can see at least that there's this quotation plus action and that they look kind of similar. Like it's kind of purposely obfuscated. So I'll expand it out a little bit so you can sort of see what's going on a little bit more. So hopefully you should see really in the last line that the string is being passed into sprintf with itself and that's kind of the trick. Two little tricks that I learnt looking at this one was like first that sprintf is alias to the percentage operation in Ruby. It's kind of cool. And secondly that in the sprintf format percentagep calls.inspect on whatever you pass in. Didn't know that. Here's another one using a vowel. Here we're using percentageq instead of quotation marks to avoid a lot of escaping issues. Yeah, again they're pretty cool. People can go pretty far with coins. You might have seen sort of some relay coins where people do it through sort of several different languages, sort of before getting back to the original language eventually. Another well-known one is the club, which was also by the same guy who did the underscore stuff. And that's where it's sort of an ASCII art globe that sort of rotates through various positions before coming back to the start. So I'm coming to a close now. Oh, yeah, no, no. Sorry, one more actually. This one's really weird. If you can get to a state where if you put this in a Ruby file an executor in MRI that this is what will be printed out. So now this isn't really a coin in some senses. It's a bit hard to tell did the program work or not. It's again sort of comes down to that sort of that kind of disconnect between what the interpreter of the language is thinking and what we do with humans interpreter. Yeah, so I'm pretty much coming to the end now. Like I just thought I'd mention sort of one side of literary criticism that I haven't really covered and that's kind of a lot of where modern literary criticism certainly sort of post-60s came from. And it's always come from a sort of a very sort of, I guess, rebellious sort of point of view. So this photo is from the 1968 May in Paris. And there you'd have students on the barricades and the professors would be on the barricades with them. And there was a huge sense of trying to use criticism to overturn ideology of a very sort of sort of stuffy middle class France at the time. And I think that this is kind of like why I think it's valuable asking these sort of questions that aren't to do with value and to considering bits of code that are useless. I think that the whole sort of clean code approach and all that stuff is great. It has its place. That place is kind of our work to a certain extent. I think there's more to be done with programming than just building things to be useful. I kind of want to echo why the Lucky Stiff who at the first time in 2006 walked on to stage and just yelled, put your best practices away. Thank you. Questions I guess if I have time? I don't know. Probably it's all been focused on this talk actually. I think the underscore thing is just like pretty cool. He's got actually several... If you look on his github account he's got several weird things. Programmes are just numbers and stuff like that. I think that idea of taking an extreme like that and trying to solve it is just a really awesome way about approaching stuff. You've probably seen the weird things I've been looking at because they've all been in there. At the back. Ah yes, like Pilish. That would be really interesting actually. That's another good example. Some people have actually written poems like that. If you google for Pilish then you'll see people who have written 10,000 word poems and the constraint there is that each word needs to be the length of the letter in Pi which is awesome. No, but that would be a good one. I have tried doing it without if statements. That's a really good exercise as well. There's all sorts of things you can do with FizzBuzz. Again, I think FizzBuzz is kind of interesting because maybe a couple of years ago there was a huge blow-up on hack and use and stuff about how 98% of programmers going for interviews can do it and everything. So it's kind of that same sort of thing. It's code that if anyone ever shows me FizzBuzz now, I can't help but think of that. It's code that can comment outside of its environment almost. Anymore? Whiskey and beer then. Thank you.