 so it looks like we can go ahead and get started. So, my name is Colin Fulton. I'm a front-end architect and accessibility specialist at the University of Michigan Library, so I work on making our websites better for people with disabilities and also better for people because currently our websites aren't very good if you're a human, or if you're a non-human who's using a computer. So my first question is, who loves their text editor? Okay, okay. When talking to people who aren't computer programmers, they really didn't understand why it is someone could give an impassioned talk about text editors, but Wikipedia shows that we're really serious about text editors, so much so that our debates about text editors get their own Wikipedia pages. Second question, has anyone tried to make their own text editor? Anyone? And there's at least one person in the audience who's tried, okay, there are a couple of you. It's a really special experience, and as you develop it, you start to realize why most people would avoid doing this. Now the reason why I got into text editors is a long story, which I'll summarize this way. I wanted to make my own website because I do a lot of artwork, and so I need to present my art, and because I work as a computer programmer, I thought I'll build my own CMS. Can't be that hard. As I'm developing my own CMS to do things, I then think, well, maybe I can develop my own web framework, because then I can learn about how to build web frameworks, and after working on that for a bit, then figured that, well, I don't really like any of the HTML templating languages are out there, so maybe I'll develop my own, and I don't know that much about parser-alexer theory, so maybe I'll try to do that, and at the end of this really long yak-shaving expedition, I decided, well, you know, I'm spending all my time in text editors, and I don't really know how to write one of those, so why don't I spend some time trying to write the perfect text editor, and so far that's been the end of my long yak-shaving expedition, but this talk is not gonna be about showing off the text error that I've been working on. One, it isn't completed yet, because I don't believe in rushing personal projects like this. I prefer to take Rich Hickey's approach, where he took a year to think about how he was gonna construct his perfect programming language, as opposed to JavaScript, where they developed it in two weeks, and then, you know, just let everything go from there. So, in summary, what this talk is gonna be is first we're gonna travel through time, and look at text editors throughout history. If any of you are old Unix gray beards out there, and you've been using ed since day one, then you can just sort of snooze through this bit, but for the rest of us, it's really interesting to look at where our text editors come from. Then we're gonna talk about the philosophy of tools. Why is it that development tools look the way they do, and why are the UIs for development tools so different from the UIs that we create, and for example, all the web commerce products that a lot of us spend our days producing? And finally, we're gonna spend some time building a time machine. Most text editors have a time machine in it, as well as a number of other features, so we're gonna spend some time building up these various features. In addition to all three of these subjects, we're also gonna spend time doing some other things. Also, if these slides ever get too hard to read, just shout at me, and I can make them a little bit easier to read by changing the colors to something much uglier. So just let me know if any of the code gets too hard to read. So first, semantics. A text editor is different than an IDE. An IDE is a big, powerful program with lots of features in it. It has a debugger, it has a, let's flip that, is that better? Okay, an IDE has a debugger in it, it has a number of development tools along the sides, it has a bunch of wizards that pop up to show you how to do refactorings, and it usually has a very small, very poor quality text editor inside of it that you actually manipulate the strings with. A text editor, on the other hand, is a program which you simply use for editing strings. Notepad is probably the prototypical text editor that a lot of people think of when they think of a really basic text editor, and it's not that much different than Vim or Emacs, it's just a very simple way of manipulating strings, it's just that in this case it doesn't give you very many tools for doing that. So let's go back to the dawn of time. There weren't any computers and everything wasn't interesting, so let's get forward a number of years to when computers were invented. You didn't have screens and keyboards for quite a long time, instead you had key punch machines where you'd fill in a bunch of punch cards and you would type in what various commands you would wanna, or characters you wanna put in, and it would punch holes in the text cards and if you wanted to undo anything you'd have to load in a new punch card and then type everything in again. These were sort of primitive line editors in that you could reorder all the lines of your code real easily, especially if you dropped all the punch cards and they went scattering across the floor. This was not a very great way to work, which is why eventually people started hooking up teletype machines to their computers. Teletype machines are machines which have sort of a typewriter with a long print tape that just continuously can print things out. You would type in the characters that you wanted to transmit the computer, those who get transmitted the computer, and the computer would transmit back to the teletype machine what to output and this is why our command line interfaces look the way they do today. You couldn't go back and edit things that had been written before because they were actually being written on a piece of paper and so the way that command line interfaces work and still work to this day is you type in a command, it then shows that command on the paper or the screen, prints it out, then prints out the response of what the computer did and then it gives you another command prompt to type in the next thing. Eventually, dumb terminals were created that did the exact same thing, only had a screen so instead of wasting paper it could just print things out on the screen and this is how a lot of early important computer development happened. This is how Unix happened, this was how the C programming language was created with these dumb terminals. Eventually over time they got smarter and you could fully refresh the entire screen and you could get sort of privative text base user interfaces like Vim or Emacs that actually rewrite the whole screen as opposed to doing everything literally but we'll get into that in a little bit. So what did text editors look like back in the early days? A really good example is Tico. Tico was a very popular text editor written in the 1960s at MIT which had a very, very intricate and complete command language. It had if statements and loops and all sorts of different ways to manipulate files and manipulate text. Each individual command was only one character long so that you could very easily type things in very quickly without having to deal with the horrible pain of having to type in commands which were two or three or even five characters long because God forbid you have to type in more than one character. The problem with having a really powerful command language that people are gonna wanna write really complicated macros and they did and since each command was only one character long you ended up with programs like this. This is a valid Tico program. It's an interpreter for a programming language and because there are children in the audience I won't say what programming language but if you go on Wikipedia this interpreter is there and you can look and giggle at the fact that this is actually a rather complicated working piece of code. Now, UNIX is the operating system which a lot of the work that we do is based on and a lot of the development tools that we use this day were developed in UNIX and indeed with Linux now running most servers UNIX is still kind of the standard that we all operate it on. Now the first editor in UNIX that really got popular and the one that indeed most of UNIX was written in is an editor called Ed. Ed is a very simple editor thus the very short name. Very few people use it today because it's rather limited in its capabilities and using it as kind of an exercise and frustration. You really had to know what you were doing. If we load up Ed and we load an example file into it the first thing it does is it prints out how many bytes are in that particular file which is really useful to someone probably back in the 1960s but today it seems a little bit weird that this number randomly pops up. Now we're allowed to enter a command. If we enter in 42 what Ed's gonna do is it's going to operate on the line 42 and we didn't give it anything to do so it just returns that line and tells us what's on that particular line of the file. Now let's say we wanna look at more than one line of the file which I know is a really crazy idea. Ed actually would allow you to do that. If you typed in a comma between two numbers that would give you a range of lines to operate on and of course if we run that it only returns one line because Ed only returns the last line that it operated on. If you actually wanted to look at multiple lines you would have to insert a command like P or N at the end of your command and then that would allow you to see what was at the end of the line and on this file if we run this particular command it will give us a question mark which is super useful because what does that mean? I don't know. Actually I do know. That means that Ed encountered an error and obviously it is explaining to us that we got an error with the simplest means necessary. A question mark and then we have to enter another command to ask what on earth was that error that you just gave me and now it will tell us oh it's an invalid address error. You asked for a line that didn't exist and so obviously I'm gonna return a question mark. Now if the line that you were trying to edit happened to only have a question mark on it then have fun trying to figure out that little bug but we can move on. Ed really is a pretty ugly editor to work in and these commands aren't very elegant but at the same time there's a lot of things that you can do with these commands and they're very short and you can put them together and do very powerful things very quickly. So what people eventually did is they extended Ed, removed this sort of live editing mode and turned it into sed which is a Unix tool which many people still use today. It allows you to create ed strings of commands and operate them on a file and then use that in a typical Unix pipeline to do lots of complicated operations. Sed may be ugly but it's made for professionals. It's made for people like us who can spend the time learning how to use an editor and the reason why this ugly, terrible, hard to use program is still used today is because our needs as professionals is different than what a lot of other people need. A lot of people talk about UIs a little bit after this time period by talking about modal versus modeless UIs. A modal UI is something like Ed where there's a command mode, an insert mode, a preview mode, Vim works this way, Emacs works this way and many early command line tools wouldn't actually even tell you what mode you're in. You just had to kind of maintain that state in your head. And so what a lot of people started arguing for in UIs was to have modeless computer programs. Computer programs where everything was open to you and you didn't have to switch modes to do different operations. You would just do the operation you wanted to do and the program would automatically switch modes to make everything work. These days though, I don't think this is a very useful binary to draw our programs in. Modal operation still happens in a lot of things. For example, if a dialog box pops up to walk you through some wizard to do a refactoring that's putting you in a separate mode and there's nothing wrong with that. Modal is fine as long as it's direct to you in the right direction. So when talking about developer tools like this, I have a different divide which I like to use. There's hand tools and there's wizards. And to give you an example of what I mean by this, let's say we have to cut some wood. This right here is a Japanese saw. It's a beautiful woodworking tool. It is absolutely fantastic to use and many woodworkers have at least one of these in their shop. What makes it different from a typical European saw is most European saws cut on the push stroke. Now this may seem like a small thing but the reason why they did that is then you can throw your whole weight into it as you make a cut and you can cut through big pieces of lumber a lot faster. Japanese saws cut on the pull stroke. Now there are some philosophical reasons as to why they made this choice but because the blade itself is under tension as you pull it, the blade isn't gonna wobble and bend as it would if you tried to push it through the wood. This means they can make a much thinner blade which means the kerf, the amount of wood removed with each cut is a lot smaller and so you can make much finer cuts. Japanese carpentry is renowned for having extremely fine and beautiful joinery work which is why these tools are used. Now most people wouldn't wanna use a tool like this because it's a lot harder to use but if you're an expert craftsman who knows what you're doing, this is a really wonderful thing. And a side note, since this is a Ruby conference, the Japanese word for a wood saw is no-ku-giri which those of you who are familiar with the famous XML library which is either your favorite thing in Ruby or your least favorite thing in Ruby depending on how much you've had to use it just an interesting little side. Now wizards work differently. Let's say we wanna cut some wood and we're not a carpenter. We just need to get the job done because our deck just fell down and we need five two by fours which are three feet long. Instead of learning how to do the art of craftsmanship we can just go to a home center and say can you give me a bunch of two by fours cut to this length? They're not gonna be cut as well. They're not gonna be of the same quality. The lengths may all be slightly off but that doesn't matter because we don't need exacting work in this case. We're an emergency situation or we're doing something really complicated that we don't fully understand so we can rely on someone else's expertise to do that, give up some of the fine control but gain the ability to be a little bit more productive. Now wizards can be really terrible. There are plenty of situations in the history of computer programming where people have created the worst wizards and they are hyperbolically bad. But wizards can also be great. Let's remember what a wizard is. It's a magical creature that can take you on a guided journey. When you encounter a Balrog if you have a wizard with you it'll just take care of that for you and you don't have to think about it and you can go on your merry way. IDEs are a lot like wizards. They give you a lot of things that magically do stuff for you. There's not that much different from your IDE popping up a message as you type along to say, hey, are you trying to write this method? I can give you a completely formatted version of this method if you'd like, if you just hit enter. And that's not that different than Clippy saying, hey, it looks like you're writing a resume. It all just depends on designing it well to be a good tool for the job. Hand tools can also be great. They get a lot of guff because they're hard to use but if you learn how to use them and how to become a craftsman with them they're a really powerful option. Git is a beautiful hand tool. It allows you to do incredibly complicated things with your version control and communicate really complicated ideas and work very quickly once you spend the time to learn how Git works. It has a lot of powerful tools and it's constantly growing and expanding to give you everything that you could possibly want as long as you take the time to learn how to use it. Hand tools also can be really terrible though because of that really high learning curve. Git is a really terrible hand tool because it has an absurdly high learning curve. Git doesn't really help you out along the way. It just says I'm in detached head state and leaves you as a young inexperienced developer to go, oh my God, I just beheaded my program. Am I gonna get in trouble? It's also completely inconsistent on how it works on the inside and there are a lot of ways that can be improved. Linus Torvalds has said that Git is really hard to use and he doesn't care. That's kind of the point of it. Just get over it, learn to use it and you'll get along okay. Hand tools have other advantages though which aren't talked about as much and they're usually breast-aside of small things but I think they're worth mentioning. Wizards do magic for you and this is why wizards are great. But hand tools make you feel like a wizard. By this I mean if you've ever worked around really experienced developers who are really good Emacs or Vim or Unix, they're constantly just never touching the mouse, moving their hands on the keyboard as fast as possible. Windows are popping open. They're completely refactoring all their code and you can't even understand what they're doing because a bunch of gibberish is just getting typed on the screen and somehow magic productive work is happening. By the way, if any of you are not familiar with XKCD which this is a technology conference so I know you all are, please feel free to just leave this talk now and go read all of XKCD. It's gonna be much better for you in the long term than sitting through this talk. So when it comes to wizards and hand tools, both are fine as I've explained and it's just about choosing the right tool for the right job. If you need to do complex version control every single day, you're gonna want a hand tool like Git. However, if you're doing data recovery, you're not gonna want a complicated tool that you have to learn how to do because whenever you use a data recovery program, you're in an emergency situation and you just need to get stuff done. In that case, you're gonna want a wizard that just has the magic please give me all my data back button and takes care of that for you. I should also note that wizards and hand tools are not mutually exclusive. You can mix and match these. You can have a small subset of commands that let you compose a lot of interesting things and gives you a lot of power while also adding on wizards to do the more complicated things and refactors that you are doing very often. Now hand tools have kind of gone by the wayside in terms of editor creation today and this is why older text editors still have a place in today's programming. Ed, that program terrible, terrible editor which we mentioned before, eventually was expanded upon and became X and eventually someone create a completely visual mode that didn't work in a purely command line way that actually repainted the entire screen every time you did something and this visual mode of X was called VI and eventually someone came along and wanted to improve this and so they created Vim. Vim is a great text editor which is still being developed today and it's fantastically powerful. Even though it is really difficult to use, one reason why we as programmers gravitate towards it is because it has that hand tool nature. It lets us do really complicated things as long as we're willing to take the time to learn how to do it. Tico on the other hand, that editor which had the absolutely crazy macro construction system in it, had a big following and a lot of people started creating interesting macros for it. One of these sets of macros was called editor macros or Emacs. Now eventually Emacs got rewritten into a small core that they then built a Lisp style language on top of but Emacs is a really fantastic editor in that it gives you a lot of really powerful macros to do a lot of work. You have to spend a lot of time learning all of the complicated metakey combinations to do everything and to get all the plugins downloaded to do what you wanna do but once you spend the time to do that you gain a lot and can do hugely powerful things. I should note that as a Rubyist I'm personally not a huge fan of Emacs and that's because I like fun when I'm programming and to define a function in Emacs you have to write D fun and that just hurts me emotionally. Now we can do better. All of these editors are old. Lots of them were written when computers filled entire rooms and the situation has dramatically changed now. We have supercomputers that sit on our desks now. We have gobs and gobs of memory and sure it's bad to be wasteful as a programmer, blah, blah, blah, blah, blah but we're at a Ruby conference, we're not at a C conference. We know that you can take advantage of how powerful machines are these days to write really elegant, concise, beautiful programs that may not be as efficient as they would be if we wrote them in the style that these older text editors were written in but they can be really expressive and easy to expand upon and grow. So let's go through some examples of improvements that we can make. One thing is a better command syntax. Vim itself uses a command syntax which is largely based off the syntax of ed. They expand it on it and they really expand it on it to create a lot of complicated things but to understand the particular syntax which Vim uses we have to look at this. The ADM3A, it was a particularly popular terminal back at the time that Vi and eventually Vim were written and in the case of Vi, if we take a closer look at the keyboard and I don't know if you all can see this, let's, yeah, that's better. If we all take a closer look at the keyboard, there are a number of things that give us clues as to why Emax or why Vi and Vim have this really weird looking syntax. One thing is let's look at the HJK and L keys. They actually have cursor arrows on them. The reason why Vi and Vim have HJK and L as cursor keys is because these were the cursor keys on the keyboard that it was created with so obviously that's what they're gonna use. Today that's kind of wasting the home row with something that I know a lot of Vim users don't like moving their hand all the way over to the cursor keys but that's valuable real estate on the keyboard that we could use. A lot of Vi and Vim users talk about how important the home row is and yet to switch modes, something that we do commonly, you have to use the escape key which is really far away. Except on this keyboard where it's right next to the keyboard or it's right next to the key key. It's really easy to get to that and so the command syntax was largely based off what's easy to do on this particular obscure keyboard which no one uses anymore. Something else to note for all you people who use Unix, the tilde key says home above it. It's a little hard to read there but if you go online you can see that. That's why in the command line if you do CD tilde it goes the home directory because obviously you'd use this key because it says home on it. It just makes perfect sense. Now in building our own command syntax we're gonna wanna do a number of things which really are just good OO principles. We're gonna wanna follow the single responsibility principle. Let's not have commands that do really complicated things. Let's make a small subset of commands. Each one that does their own separate individual thing and it does it well. Then we can use composability to put these commands together and build more complicated interesting macros to sort of do the work and do more complicated functions. And if we use higher order abstractions to sort of organize all these commands we may not have complete knowledge and a complete memory of what all the commands are that are available to us but if we understand the higher order of abstractions of the various sorts of commands we can do we can then go and look them up a lot easier and maybe build it into the editor where it can say oh you're trying to do a selection here are all the options for selection commands in case you forgot. And finally having documentation would be really great to have just core in the editor and why not put static typing in our command language so that way when we mistype a command the command can just tell us oh you put a number in something that expected a string that's why I'm not gonna do anything as opposed to most command line text editors which when you input an invalid command just say nope and then you have to figure out what happened. So when we take a look at all these we try to figure out sort of what can we do to make a command line syntax that sort of follows all of this in our command line text editor. So we can divide all of our commands that you pretty much ever want inside of your editor into three categories one is selection. Your find command, your go to line command your select a function command your select the parentheses command all of these are just different ways of selecting things. And if we allow multiple selections we can then use our find command to find multiple things select which ones we want and then do our transformations from there. So instead of thinking about moving a cursor around on the screen we can just think about telling it what we wanna select and then perform our operations from there. We then need some modification commands to sort of nudge those selections so maybe we selected everything within a set of parentheses and we just don't want the parentheses so something to sort of nudge it inwards or maybe we have two selections we wanna find the intersection of them we need some tools to do that but there aren't that many there necessary. And finally we need the actual commands for doing editing but these don't have to be very complicated. You have a delete command and a replace command and an insert command but all those are really kind of the same thing. A delete command is just replacing your current selection with an empty string. Cursor is just a selection of zero length and so we can just sort of combine all these into one giant command where if you just enter the command with no arguments it'll delete it because it'll replace your selection with no strings and then if you enter a string as an argument it'll then just replace that. And so we just take these three things we can build a really powerful command language that lets us craft text in lots of interesting ways and something that we can expand upon. So if you're working in a language like Ruby that has blocks you can add a select block thing or if you're working within a list you can add something like parse edit which just manipulate selections using the ideas of how to select things around parentheses. And to build this we need a better extension in scripting language because a lot of text editors currently they give you lots of options for creating your commands but it's kind of a hodgepodge of you can use all these different languages but most of them are only half supported and if you really want to do it you have to use our special internal language. Emacs list was really great at the time because it gave you a small simple scripting language for creating things that was a lot easier to read than something like Tico and gave you all the power of a list but it's still a scripting language that was designed in the 1970s. We can create something better. Now if we're building a text editor in Ruby we have an advantage. We have Ruby on our side. Ruby's a really great language not only for writing code but also for writing scripts and for creating DSLs. So I have a little example here which may be a little bit difficult to read but we'll flip it over of the kind of DSL that we can use for creating commands. If we look at the top we're creating a delete command which you will type in by hitting the D key. We then give a bit of documentation on what that does right in line with the functions where our documentation is a first class citizen in this particular syntax which we've created. We then say string as an argument right before we create our block and that's where we do our static typing. We just say this thing has one argument and we want that to be a string all the time so we'll just pass in a string and then we'll pass in our argument and create our function. The select command app that is a little bit more complicated instead of just passing in one possible type for that one argument to be, we pass in multiple types and so now we can have dynamic typing with our language and yes this is a very very primitive type system but if you have a really complicated command set with a really complicated type system in it you're probably making something a little bit too complicated to use and you're gonna be violating some of the rules of creating very simple easy to use UIs and then we just sort of loop over our particular query there to perform selections depending on what kind of selection you put in. So the next thing I'd like to talk about is the fact that the time machine in your text editor is probably broken. I did recently discover that this isn't a problem in Vim but they hide this feature really well. The edit history feature in a text editor is really magical. It allows you to go back in time to see what you did before, copy from that, undo things. Imagine if we could do this in everything. Imagine if we had databases which just natively allowed us to have undo functions showed a complete history of things. Those of you in the audience may know there are some databases that let you do that but most of us live in the world of relational databases where that's not a native feature. Editing history is a really powerful feature of text errors and one that we often overlook. So one way to implement a edit history is to create a doubly linked list. We have our first insertion and we have a pointer to it to say this is the item in the history that we just performed. When we perform another item in the history we link the two items together. We tell the first item that the item after it is this next insertion and then we tell the next insertion the item before you is the previous insertion and then as we go along inserting or deleting text we can build up our string. And then when we wanna perform an undo we simply ask the item that we are on what's the previous item in this chain and it will return the previous item and we can set the pointer to that and so we can start moving backwards in the history. Now to implement this in Ruby is actually relatively simple. If we look here we have this history step module because this is not just we don't wanna create this as a class we wanna inherit this elsewhere. So we define our initialized method and we set the next and previous instance variables to be self. The reason why we do that is because if you're at the beginning or end of the history or if you only have one item in the history and you call undo or redo on it you're just gonna want it to loop back to itself because you don't wanna pop off the end of the history and return no. You just when you keep hitting undo eventually wanna just stick at the last point in the history. To create those next and previous links we first wanna call whatever function makes sense for performing the undo or performing the redo which we define specific to that particular edit step. So an insertion to undo it you delete the text which you inserted and then for redoing it you do redo the insertion and then a delete command is simply the inverse of that you flip what the undo and redo methods are and you have your delete command. Now to be able to extend this history step and sort of build out our history we need a couple more methods. First we're gonna need a method which sets the next item in the history and this is relatively simple it just tells the next item in the history hey I'm adding you as the step after me can you add me as a step before you and this is how we create our doubly linked list and then we set the next item in the history to be whatever was passed in. Then we have a protected method which only history steps can perform which set the previous item. So now we can build out our history in one direction but can't build it out backwards because building a history chain backwards would end in some really weird stuff that I can't fully comprehend or understand why anyone ever wanna do it. However, this is all great and simple but there's a terrible bug in this setup and it's a bug which most text editors have. It works like this. Let's say that we're in our history and we have our pointer to that second I am the history. We undid a bunch of stuff because we did an insertion earlier in the code which we deleted and we wanna copy the text out of this and I've done this many times. I go hit undo a bunch of times I find myself in the point history I want and I go to hit command C to copy it and I accidentally hit command X. Well what this history interpretation or what this implementation of history will do in this particular case is it'll say, oh, you're inserting the next step which in the case of command X, a cut command is gonna be a delete. So it says okay, I'll set the next item to be the delete. And now our entire history goes away because we just inserted a delete command there. This is really bad. If the point of history is to allow us to save and protect our work, we're running into a serious problem because we have a situation where our history can dump all the work which we had previously done. Luckily, the solution to this is to create a branch history similar to how Git works. Now Git is a very complicated bit of software but we can create a very simple implementation that just extends our previous history model to add alternative history lines and it works a little something like this. We're in a similar situation where we're at that second insert command and we're about to perform a cut which is gonna insert a delete in the history. Before we perform that delete, we take the next item in the history which is the third insert and we store it in an array inside of that second insert command. This array is for the alternative histories. Now the reason why we only have to store the next item in the array is because it has references to everything that comes after it and they all reference each other. So by just pulling out the next item, all the references are preserved in the chain and we can go about our day. Then we can safely insert the delete command and if we undo again and perform another operation, we can just take that delete command and pop it into that alternative histories array and perform an insertion or whatever else we want to do in the history. Then all that we need is a method which allows us to access those alternative necks and swap between them and then we can have a history which preserves all of our history no matter where we go inside of it and we can edit at any point in the history and know that we're not gonna delete any of the work that we've done before. So how do we implement this? Well, it's relatively simple. We take our previous history implementation and just add a couple of things. In our initializer, we add that alternatives variable which we just sent to an array. That's the array of alternative histories and alternative next steps. And then in our setNext function, we just need to take the next step whenever you're gonna set a new one and insert it into the alternative histories. There's a little unless there to prevent us from inserting ourselves because that would just end in some kind of strange bugs. And then the rest of the implementation is exactly the same. The only other thing we need is that method to switch between these alternative histories but that's very easy to create. We take the current next step in the history, we push that onto the array of alternatives and then we shift off the last item in the array and set the next item with that. And if we continuously call that, it'll just cycle through all of the items in the alternative history array and allow us to just sort of freely browse between them. Now what's really cool about this is that this doesn't actually have any knowledge of editing text documents. The undo and redo operations are something that we can just define wherever we include this module. This means that we can use this kind of persistence layer for having a history throughout our text editor. It would be really cool to have a text editor where when you hit undo, it didn't just undo the particular changes you made of the text, it also showed you what were the commands that you were entering in in that particular point of history because maybe you just wanna change up one of those commands. You could also take your whole windowing system, build it inside of this history model and then as you're hitting undo, it's changing the windows to show what you were previously doing. So if you undo to some point where you were making it edit because you were running the debugger, it could reopen the debugger, rerun it for that step and you could just completely step through the real history of your document. Not just the history of the text that you've changed but the history of all the operations that you've been doing as you've been working. Now all this is really cool and these are features which some people have implemented in plugins and various editors and some editors have made first class citizens but they've never really been mainstream features. They've never really been mainstream features except in some alternative timelines in our current universe. You see, things didn't end with Vim and Emacs. Things didn't magically stop developing on the command line as soon as everyone got GUIs. This guy, Jeff Raskin, he was one of the main developers who worked on the Macintosh. The Macintosh is a fantastic computer which sort of brought the idea of GUIs to the consumer market. It showed that everyone could use a computer and it did this through a mode list interface where you just had a bunch of buttons and everything was available to you and for those of you who are really pedantic, yes, the Macintosh actually stole a lot of its ideas from Xerox PARC's Alto computer and yes, if you really, really wanna be pedantic, all of the ideas of GUIs that Xerox PARC used were largely stolen from Douglas Engelbart who in the mother of all demos showed that implementation of a computer which would have hyperlink text, editable text documents, a mouse for editing things as well as video conferencing, screen sharing over network and a number of other features and he showed off all of these in 1968 before most people even knew what a computer was. If you're curious, I'd recommend going on YouTube and looking up the mother of all demos because in terms of mind blowing talks, this blew everyone's mind because it was kind of like a person coming from the 1990s going back in time to the late 1960s and showing everyone what the world is eventually gonna look like. So back to Jeff Raskin. He was the main sort of instigator of the Macintosh at least in his mind but he didn't like the way it turned out. He didn't like that everything was kind of simplified and dumbed down so it was very easy to pick up but also lost a lot of power. He worked with Canon to create this computer which is called the Canon Cat. A couple of things worth noting here. One, you'll note it doesn't have a mouse and two, there are these two red buttons right below the space bar, right where your thumbs would rest. He called these leap keys. Instead of using a mouse you could use these leap keys to jump back and forth in whatever you're working in. If you hit the leap forward button and started to type something in the cursor would actually move forward to whatever you were typing in. You could also leap to text documents, leap to separate directories, leap forward into various other structures or headers within your document and navigate really, really quickly and intuitively without using a mouse. Now this isn't as obvious as moving a mouse around and just clicking in the thing you want but with just a little bit of extra effort if you learn to use this interface you can work very productively with a relatively simple thing and have the power of something like Vim or Emacs but without a really complicated command set. Another example of where people were working on alternative command line ways of editing text is Rob Pike. You may be familiar with Rob Pike as he's the creator of Go which is an up and coming programming language which he's been working at Google to create. He also is one of the developers who worked on C as well as Unix back in his days at Bell Labs and he created a number of text editors. One of them was called SAM. It's a relatively simple text editor. It only has about 30 commands but allows you to do way more than what a lot of other command line text errors would let you do. He based everything on what he called structural regular expressions. We don't really have time to dig in the details but there's a lovely paper which is only a couple of pages long which is available online talking about these. The idea is that instead of basing a text editor off lines which is how we normally think of our code instead we think of it as regular expressions that select on that text. And so we perform a regular, instead of going to a line and editing some text or moving a cursor around we set up a regular expression to select the thing we wanna operate on and then call an operator on that particular regular expression. And then all of our documents become structured around the regular expression. This is also really cool because as far as implementation goes it's a lot easier to implement this because in Unix a text document is just a stream of bits that all it is. It has no idea about lines. You have to go through and parse the document to find where all the line breaks are and create some sort of data structure to give you access to that. If you base everything on regular expressions you're dealing with text as it actually exists on the machine. You're dealing with it as a stream of bits and you can sort of process that and do commands on it. He also worked on plan nine which was an operating system which was supposed to be the next step in Unix. It took Unix farther than Unix went by applying the Unix philosophy to an operating system. By that I mean the Unix philosophy has a number of rules in it. One of which is that everything is a file but anyways use Unix or Linux knows that not everything is a file. In plan nine if you want to make a network access to another machine on your network you simply open the file directory for that machine and browse through it. Every single bit of the operating system is operating on files. Another thing is that they wanted to build developer tools that are relatively simple to use and actually were very, very small and compact and could be composed to get rid of interesting things. Also Glenda, the bunny who's the mascot for plan nine has to be the second most adorable mascot in all of computing. Only beaten out by Hexley who is the mascot for Darwin which is what OSX has built on. And if you think that Hexley is not as cute as Tux I dare you to look into those eyes and not awe because that is a very adorable platypus. So we're working on plan nine. Rob Pike started to work on a more advanced text editor. This text editor was called Acme. If we take a look at what an Acme window looks like at first it looks like a relatively standard document. We have a bunch of separate sections open and each one of them has a menu bar at the top. But as we dig into it there are a couple of interesting things. The eagle eye among you might notice that some of those commands in the menu bar have weird names like snarf. That was just the copy command. They gave it a silly name because why not have a little fun while you're at work. You'll also notice that inside of each of those menu bars you may or may not see at certain points a cursor. A menu bar is just a big string of text so why not make that another editable text area. This means that whenever you open up a document you can edit the menu bar, add whatever commands make sense for that particular section of what you're working on and go from there. Imagine if you had a text editor where you opened up a Ruby document and you're like oh wait I need a quick access to my build chain. You could just put a little command right there as you're editing into the command or into the menu bar and just click on that and access it whenever you want. And you could change that and edit it over time and build it however you want without having to deal with writing a bunch of plugins or things to alter the GUI of the text editor. This actually extends into the body of the document. If you select any text in plan nine including the body of your text document and click out on the right way it'll execute that command. This means that you can insert comments into your text document which say to run a test on this particular method please use or please build this particular RSpec file and when you show the RSpec file name you could just highlight that click on it and ACME would automatically open a new section which would run that. Now these particular tools Sam and ACME became really popular with the people at Bell Labs. Rob Pike still uses them today. Ken Thompson and Dennis Ritchie the creators of Unix and C who worked on those together both of them throughout their development careers did and have used both of these editors and their preferences vary but they continue to use them because they really like the power of these as development tools. Brian Keranigan who worked on one of the most popular early books on the C program and language as well as developing the tool said he prefers using these editors and finally that last name there is the creator of C++ who also prefers using them. Now the really cool thing about these particular editors is that you can still download and use them today. All of the development chain of plan nine was ported into a thing called plan nine for user space or from user space which is not only a clever name it's also a port of all of these development tools into OSX, Linux, Windows, BSD and pretty much any other operating system you wanna work in so you can go ahead and use these text editors today if you want. So what are some takeaways? First, when you're designing development tools take some time to think about what you're doing. Are you building a hand tool that's gonna let people perform lots of complicated operations and you have a bunch of composable stuff or are you building a wizard? Rails is kind of built like a wizard it gives you a lot of magical commands to let you do things that you don't have to do very often or they're so complicated that you don't wanna dig into them. Sinatra and Rack are more like hand tools they're really useful they may be more difficult to build complicated applications with but they give you that fine grain control which is really nice. I'd also recommend that if you haven't already try building your own text editor even if it's a simple one. If you don't know that much about IO it's a great way to learn about IO especially in Ruby where it's a rather pleasant experience. You can learn about data structures as you implement more efficient ways to read from files you can learn about interface design which I've talked a lot about here but you may have your own ideas and you may think I'm completely crazy and have terrible ideas well why don't you show me up by developing a better text editor I'd really love to see what you guys could come up with. If you wanna learn about threads you could build a really efficient text editor which allows you to run searches in the document without freezing up the interface it's amazing how many text editors aren't multi-threaded you could go ahead and implement that yourself. It's also a great way to learn about software architecture all these individual components of the text editor are great ways to experiment with OO design patterns. And so all of these and even more things are great things that you learn by trying to implement even a trivially simple text editor on your own. Finally, if you don't do any of this or if you do just try and take some time to learn a new text editor. If you're someone who's only using GUI editors there are lots of tutorials out there which can give you a basic introduction to VIM and Emacs. Not only can you learn a little about how to use these tools but if you have our SSH into a server it's a lot faster to be able to just pop up in VIM or Emacs, make your quick changes and get out and you may end up liking it. You may end up finding out that these are really powerful tools that you want to use every day. If you're someone who's already an extrovert in VIM or Emacs why don't you try out SAM or ACMI try out some of these weirder text editors. You may find that they may be a little bit more difficult to learn because of the kinds of commands that they used to but they're really really going to be great to learn. And so last I just want to mention that we stand on the shoulders of giants. A lot of this talk has been focusing on computer science history. Dig into computer science history if you haven't already. There's a lot of amazing stuff there which people haven't implemented. Papers from the 1970s which have beautiful data structures in them which are still useful today. You can find me as Jess Collin on GitHub. I don't have any of this code up there yet but over the next couple of weeks I'm gonna be uploading that and thank you very much for your time.