The little editor that could

I used to work for an organization that made a website that was supposed to work for absolutely everyone in the UK. So, of course, accessibility was a big deal for us and uh we got audited on our work. So, we would finish a feature and then our work would be sent off to a team of people with various disabilities and impairments who would test it and find out what they thought of it, what the sticking points were, what worked, what didn't work, and then send us back often a very large report about the things we could do to improve it. and give it a score so that our organization could work out whether it was meeting the ambitions or not. Of course, this could lead to multiple rounds of changes. So, we tried to get things

right first time. As a result, I spent quite a lot of time using our software using a screen reader, which I would shut my eyes to do so that I would get a more accurate simulation as to the kind of information that was available as you went through the interface using that tool. If you've ever used a screen reader, you'll be aware that they are not necessarily the most intuitive to a cited person. you have to learn to use them and there are tutorials and techniques and many keyboard shortcuts that make them easier to work with. One

of the things that frustrated me is that sometimes a new colleague would spend some time with the screen reader and then they would be quite uh sort of demoralized, upset by the fact that uh visually impaired people had to use this clearly horrendous piece of software they couldn't work out how to use. was clearly unintuitive, not user friendly, required lots of sort of knowledge and uh you know specific actions which were not obvious to a cited person. But of course they thought this to a large extent because they weren't used to it.

And in fact this is a power tool. This is a piece of software that is very finely tuned for the people it's designed for. And I knew this because I'd spent some time watching videos of people using this software and I knew how good they could get at using it. In fact, if you're curious, you might want to look up some videos of blind programmers using screen readers because the speeds they get to are really impressive. I'm talking about speeds that you and I, if assuming you're not blind, uh, would not be able to understand a thing that was being said. In any case, the point of this is that my colleagues instinctively felt this software was badly designed because they found it hard to use, but in fact, it was very welldesigned, just not for them. There's another example of this

which has come up in my life recently. Uh, for reasons we don't need to get into at this point in the video. I've been spending quite a lot of time at my father's house. And my father was left-handed. And he's not just left-handed. He's very left-handed. Like, um, he made adaptations to the way he lived his life that were, uh, more extreme than I would think that the usual left-handed person does. For

example, I still can't use a bread knife very well because growing up, I grew up in a house where my father's bread knives were all serrated on the other side compared to a right-handed bread knife. So, uh, I learned to cut with a certain pressure and now whenever I try and cut bread, it's all in these wedges and causes me a lot of frustration, especially when I have particularly nice bread. There was another instance where recently uh my brother was trying to open some of his display cabinets and they're those cabinets that you push uh and then they sort of open. So, there's no handle, you just push and then it opens for you. But of course when my brother pushed the right hand side nothing happened because it was configured on the left hand side where my father who's left-handed would expect the thing to open. My father also configured his computer as many left-handed people do to swap around the mouse buttons. So the left was the right

and the right was the left. Uh depending on uh the way you expect mouse buttons to be but he went even further. He managed to get it everywhere he worked, which you know, it can sometimes be a bit uh finicky about these things. He

managed to get it to allow him to install a special piece of software that would flip around the mouse cursor so that it would appear left-handed. There's no actual benefit to doing so other than aesthetically it just looks right if you're left-handed. The reason I'm telling you this story is because this video is about a text editor. a text editor that has been sometimes called uh the most user unfriendly text editor ever invented. A text editor

that's probably installed very near you right now, even if you don't know it. It's called Ed. It's the standard Unix text editor. That means it's installed on essentially all Unix like operating systems. Text editors are interesting pieces of software for us as programmers because they're sort of the closest thing that you would get to the like cyberpunk avatar. Those are the things

that we go into the computer with and do our work. They're our vehicle that we travel around in. The thing that we do basically all of our economically useful activity in. People are opinionated about them. They have a favorite one. They don't like to change them. They're

important to us. They're the thing that we merge our minds with in order to enter the computer as technologists. You may have heard around that tools can become extensions of the body. Well, I

think that the text editor is the extension of our minds into the world of the computer. They're a kind of cognitive projection into that world. And this video is about one particular instance of that. One particular

projection of a person's mind at a moment in time and of a particular world. And I think through looking at this subject seriously, we can learn not just about then, but also plot it as a point in time that continued on and exists in the interfaces of today. even the most cutting edge and futuristic interfaces we have. If you know anything about ED, you're probably thinking that this is a bit highutin. So, uh let's get down to earth and take a look at it. ED

is a text editor. It edits one file at a time. Its interface has four core ideas: commands, address ranges, the buffer, and the current line. I'll run through a few workflows using ED and introduce you to the core ideas as they arise. First, the buffer. The buffer is a

representation in memory of the file that you're editing. One of the reasons that ED feels strange to us is that it does not show us a persistent visual representation of the buffer on the screen. To make it easier for us to understand what's going on, I'm going to visualize the current state of the buffer in the top right of this screen. Just remember that Ed doesn't show us this directly. For the ED user, it's expected that they keep this representation in their minds, not on the screen. As a side note, I always find the use of the term buffer here to be a bit confusing. To me, a buffer is

more like a temporary staging area for data that's getting transferred from one place to another. And I guess this is sort of a buffer, but it feels more like a working representation. Anyway, the ethmology of buffer here helped it make sense to me. A buffer originally was a protective layer designed to deaden the impact between two things when they hit each other. So if you had some object and you covered it with some leather for example and then hit it, it might make a sort of buff sound rather than a clang sound. And from

there, a buffer became metaphorically a thing that deadens the direct impact of one thing against another. In a text editor, the buffer is what prevents our direct edits from hitting the underlying file. That is until we save it. Now back to the main thread. We've now read in our file. So the state of the buffer is the contents of our file. In this case, it's some code for calculating a single fsbuzz term, but with a bunch of errors and emissions that we're going to go through and correct. In our first

example workflow, we're going to do this by going through line by line a bunch of times. Now that I've opened the file, I'm going to enter one to print line one. This also sets the current line to line one. That's another one of these core ideas of ED, the current line. It's quite simple, just a hidden value that points at a particular line in the buffer considered the current line.

We'll visualize it with this little yellow dot here. When we hit enter, we'll advance and print the current line. We can use this behavior to go through the file line by line. And we'll talk more about how that works later. If I want to insert a new line before the current line, I can use the I for insert command, which will insert one or more lines before the current one.

Conversely, the a command for append will insert one or more lines after the current line. If we want to alter a line, we can use the change command. The change command deletes the current line and then in its place puts the lines that you give it, which may be more than one. We can use this to replace the final brace with an else block. You may have noticed a problem earlier with the if n is divisible by four line, which really should be if n is divisible by three. We can use the substitution

command to correct this which is an s then a slash then a pattern to look for which might be a simple reg x and then another slash and a replacement and then a final slash. Editing lines in ed is sort of irritating. You can use the change command and just retype the whole line or you can do a search and replace possibly using a reg x but there's no cursor you can use to just move along and edit things as you like. And for this reason, ED is sometimes called a lineoriented editor as opposed to a character oriented editor. We can now

save the buffer to a file. And we're done with our work. We've covered the buffer, the current line, and four commands: change, substitute, insert, and append. We can specify commands by what they do to the buffer and what they do to the current line. For example, the change command deletes the current line from the buffer, adds zero or more lines, and then sets the current line to the last line entered. Insert and append work similarly. The substitute command

takes the current line, searches it for the first instance of the pattern, and then if it finds it, it replaces it with the replacement and it leaves the current line where it is. There is technically another command that we've seen, the new line command, but we'll come back to that. Before we do, we'll need to look at address ranges. I'm going to show you another workflow. Instead of going through line by line, we'll print the whole file out, take a look at it, and then make our edits. Here's another file with some errors in it. This time for generating a fbuzz

sequence. We can print out the whole file by running one, dollar, and then p. That one, dollar is a range followed by the command p for print. A range is a pair of line numbers or expressions evaluating to line numbers. Since we want to print out every line, we give it one, which is the first line, and then the dollar symbol representing the final line. These ranges are always inclusive,

which I like. So, this command says, take the range of lines from the first line to the last line inclusive, and print them out. We have a few changes to make to this file. First, I'm going to insert a line just before the end of the file using dollar i. The dollar means the final line in the file, and the i means insert a line before it. We use this to add in a return and that missing end brace. Then I can fix up those

brackets on line four. We have an address range four which is short for the range starting at line four and ending at line four inclusive. We have the command s for substitute. And then

we have an argument which comes after the s. Only some commands take arguments and s is one of them. I can do the same thing on line three to fix the off by one error. Hope you spotted that one. Next, let's say that we also want to rename sec to result. We can pass the s command arrange so it doesn't change the sack on line one and then an appropriate pattern and replacement. Note that this will only change the first instance of the pattern on each line. If we wanted

to change every instance on each line, we could put a G flag on the end. It's interesting to note that Ken Thompson's original version of Ed, the one he used to write Unix, did not have this G feature. I guess he was working in assembly for the PDP and so lines were typically pretty short and didn't have any kind of sophisticated expression syntax so he probably didn't need it. Another thing that the first version of ED didn't have is the U command for undo. It also didn't have this shorthand comma to mean the range of all lines in the file. It did have this next command

I'll tell you about. G for global command execution. You type G and then a delimiter by default slash and then a pan to search for and then a command to run. G will then find every line that

matches that pattern and run the given command with its current line set to that line. You can use this to print out all the matching lines for you to inspect or delete or run a substitution if you like. Let's think again about these address ranges. If you're sharp, you'll have figured out that each of these commands, if you don't give it an address range, it will use a default range. If you're really sharp, you'll have noticed that not all of the commands have the same default range.

The global command's default range is from the first line to the last line. But the a i p and most other commands default range is just the current line. This idea helps us explain the new line command and how it differs from the print command. The print command's default range is the current line. So if

we execute p again and again, we keep printing the same line. The new line command is identical to the print command, but its default range is the current line + one. Both the print and new line commands also have an effect on the current line pointer. They set it to the last line printed. All of this results in the new line command taking us through the file one by one. This

behavior also gives us the handy side effect that if we type in say line three and hit return, we'll print out line three and set the current line to line three. In this case, we've specified the range to give to the new line command. So, it will use that and not do any incrementing. If you want to inspect

what the current line is at any point or indeed inspect any address, you can use the equals command. This command prints out the address that it's given. So if we give it a dollar equals, we can see what the final line number is. Or if we

give it dot equals, where that dot stands for current line, we can see the line number of the current line. By default, it prints out that dollar, the last line number in the buffer. I'm going to show you just one final command in modern edge, and that's the end command. This will print out a range of lines with the line number on the start. I believe that it's incredibly significant that Ken Thompson did not build this into his original version of Ed, the version that he and Dennis Richie wrote the first versions of Unix in. Why would they not implement such an

obviously useful command? Here we get into Ed's reputation. Way back, even when Unix was relatively new, Ed had a reputation for having the most user hostile interface ever created. It has no prompt character. Its syntax is incredibly tur. If there's an error, Ed will simply print out a question mark and nothing else, leaving you to figure out what you did to upset it. By default, it provides no confirmation of the result of your commands. I mean, the

file you're editing is totally invisible. Why would anyone want such a thing, let alone use it to write such a significant piece of software? We 50 years later, can be forgiven for asking these questions. But the original ED haters back in the day, they had no excuse. They knew why ED was built this way and they knew that it couldn't possibly be user hostile. ED was in fact incredibly userfriendly. It was just built and optimized for one very specific user and one very specific purpose. It was built by Ken Thompson

for Ken Thompson to write Unix. He would hardly create a user interface hostile to himself. So in order to understand why it is built this way, we're going to have to go back in time and try and get into the mind of Ken Thompson. Something which I seem to be doing all the time on this channel. We want to try and figure out what made Ken Thompson make all of these strange decisions, which is what I've done. Not literally, of course, but I've spent quite a while with Ed now.

I've used it to write a non-trivial, well, semi-trivial piece of software, and I've researched the technology of the time. And I believe that I can now explain to you why ED is the way it is. And the key is the physical device that it was built to work with, the teletype. Probably the best way to explain the teletype is to forget about computers for a moment and talk about telegraphy.

Telegraphy has a long history, but we're going to start with electrical telegraphy. A common setup might be to have a telegraph key on one end and a receiver on the other end. You press down the key, current goes through the circuit, activating the receiver and creating a sound. Release the key, the current stops, the sound stops. A

language of symbols called Morse code enables you to combine long and short pulses to represent characters, which of course you can then use to transmit longer messages. They would typically want both ends to be able to send and receive. So they had keys and receivers on both ends and took turns using the line. Over about 100 years, various

people attempted to design a telegraphy machine which you could operate like a typewriter. Eventually, they succeeded and invented something called the Teleer printer, which became commonly known as the Teletype after one of the big brands of the day. Then you wouldn't have to learn to encode or decode the symbols manually, and you could instead just have two teletype machines, one on each end. When you typed on one of the teletype machines, it would print both onto the paper of your machine and the other connected teletype machine, and vice versa, the other end, all with the marvelous power of electricity. To make things even better,

they invented a special additional function where the machine could write and read to a special punched tape. That meant that you could type the message into a special typewriter whose sole job would be punching it into tape and then feed that tape into the teletype machine for transmission. And this means you could do your slow human typing offline and then feed it into the highest speed teletype machine. Meaning

you could use the transmission lines more efficiently rather than tying it up with your slow human typing. It's relatively easy to see how from here you could replace one side with a computer. Then you could type your commands on the teletype. The computer would interpret them and then send back the response which will be printed on your paper.

Your computer would be on one side and on the other end or possibly many ends would be the teletype machines you had it connected to and those would be known as your terminal. Before this the most common computer interfaces were punched cards, switches and blinking lights and the most common computer paradigm was batch processing. This teletype terminal was the key early interactive computer interface. You could sit down at the computer and speak with it using a technology, the teletype otherwise used for speaking with people. This teletype system also enabled a certain amount of offline work. You could write your commands using an offline teletype to punch them into tape and then when your session with the computer came up, you could read it in and then after that punch in the commands interactively if you wanted.

Remarkably, the Teletype, specifically the Teletype model 33 ASR, is the device that Ken Thompson, Dennis Richie, and others used to create Unix. They've been inspired by their work on the earlier operating system of Maltics, which had not gone so well. Here's a quote from Dennis Richie when he was looking back on all this in the late '7s. What we wanted to preserve from Maltics was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing as supplied by remote access timeshared machines is not just to type programs into a terminal instead of a key punch, but to encourage close communication. Just take a look at their computing environment. Two teletype

machines side by side. Be cooler if we had a photo of them using both, but look, they're basically pair programming. Unix was heavily influenced by this particular unusual moment in history where the teletype was the dominant interactive interface and visual terminals were not at all common or useful. You may have already guessed that the terminology TTY stands for teletype and that the terminal we use today is modeled after a virtual teletype machine. Edge, one of the first

Unix programs written and of course used to develop much of the rest of Unix also emerged from this mu. Let's take another look at its use the hostile interface with this in mind. Let's start with the prompt. In modern Edge, you can configure it to have a prompt character, but by default, it has nothing, just an empty line ready for your commands. So, why doesn't it have this seemingly obvious affordance? Well, printing characters takes time. If you ran a command, hit return to execute it, and then wanted to immediately run another command, you'd end up having to wait a moment for the prompt character to get printed, which would break your flow. One of the key design patterns in

Unix is that silence is golden. There are a few reasons for this, but back at the very start, we can see one reason for this particularly extreme version. Printing stuff took time and space that us programmers could use for other things. The same logic can explain why

commands don't tend to inform you of the result of their operations unless you specifically ask them to. It's a waste of time. Equally, error messages being a single question mark, possibly the most insulting part of the interface to a modern user, makes perfect sense when printing the error message is probably going to take longer than a power user is going to take to figure out what they did wrong. And obviously, Ken Thompson is going to be a power user of his own text editor. I probably don't need to

explain to you why Edge doesn't persistently display the contents of the file to you on a teletype. That would be totally impractical. But then again, perhaps in a way it did. The secret of Ed, the thing that I believe unlocks it, that makes it a truly wonderful editor, is also a wonderful feature of the Teletype. A feature so magnificent that now, having discovered it, I actually yearn for it. Ed and the Teletype did in

fact have a persistent display. The persistent display is reality. You can see this dotted around in a few clips from the era. Here's my

favorite. Early morning semi- detached Hyatt, London. Industrial consultant Rex Malik feels the business world's pulse from his bedside. Stock prices and market trends are available to him through Europe's first home computer terminal. Look, he's like doom scrolling from bed. This terminal is linked to a giant

brain 10 miles away in the heart of London. It's one of two Malikas installed for experimental purposes. There's no complicated language to master before he can understand what the computer's saying. The unseen brain sends its messages in good old-fashioned English. Every day, the computer sends Rex Malik a daily reminder of where he should be, for he stored his day-to-day diary with the brain. The computer can handle a year's shopping list for the home, final demands, and the exact state of Malik's bank balance. What I really love is that

when the teletype is finished printing off his little diary, Rex can simply tear it off and walk away. Keep it in his pocket, put it on his wall. It's produced a little physical artifact for him to carry around. Here's another example. This one focused on a

presumably fictitious bowling club secretary. Being a league secretary is indeed overwhelming, but tonight the turns. Tonight I'll get all the scores, averages, handicaps, team averages, team standings, high series, all automatically. Thanks to AMF data magic. First, automatic scorekeeping with Magic Score. And now automatic record keeping

with data magic. AMFP, you've made my job a snap. The computer prints out the report. He tears it off and then hands it directly to his fellow bowlers. What

an idilic, wonderful world of computing this looks like. There's also this tiny clip of this guy at the back scrolling back through a teletype's output and marking it up using a pencil. This is a workflow I actually love now, but it's still kind of annoying to achieve. Even

in this video a decade later, people were still using paper as a core part of their computing workflow. And it really looks wonderful. I find this idea of a world where computers produce a static printouts very compelling. You get the

information you need. It's on a light, thin piece of paper. You can take it away and study it. You can place it in

your environment, organize it spatially alongside other things, sketch on it, take it outside. It doesn't change. doesn't try to distract you and it isn't attempting to cram everything anybody might want in life into a tiny 6x3 glass brick. This teletype world may remind you of some other more modern visions for computing. For example, Brett Victor's Dynamic Land. Dynamic Land is a nonprofit research lab creating a humane dynamic medium. And what that means is a way for real people in the real world to explore ideas together. Not just with

words and pictures, but with computation. But for us, computation doesn't mean scrolling around in screens. It means working out in the real world with physical materials. Putting computational programs onto ordinary physical objects. And one reason to be out in the real world is that's where the people are. Because for us, computation doesn't

mean everyone inside their own computer. It means people coming together in the same space, getting their hands on the same thing, looking each other in the eye, being present in the same reality. It means everyone's work is out in the open where everyone can see it. So, everyone's learning from everyone else all the time, and collaborations happen spontaneously. It's like working in a

wood shop or a communal kitchen. It's tempting to believe that if we just flipped a few bits in our history, we could have ended up with a very different computational world, something less dominated by the technology of the visual display. My first thought, though, on watching Rex wake up and reach for his teletype wasn't dynamic land. It made me think of a much more shiny technological vision.

Introducing Apple Vision Pro. The era of spatial computing is here. When you put on Apple Vision Pro, you see your world and everything in it. Your favorite apps live right in front of you, but now they're in your space. This is Vision OS, Apple's first ever spatial operating system. It's familiar yet

groundbreaking. You navigate with your eyes, simply tap to select, flick to scroll, unseen, and use your voice to dictate. It's like magic. It's remarkable to see these ideas that we were once so close to. And in fact, Unix was one attempt to realize pop up again and again from the community oriented projects to the high-tech in the real world and in the world of fiction. Oh, I love this part. Fractured images coming in numbers

nine 9 and six. Let's get back to Ed, the most user hostile editor ever created. Basically, in add on the teletype, your persistent display becomes your teletype printouts.

I wish we could experience this together, but even if I did have a teletype machine that I could use, it would be hard to make it really authentic. So, instead, I've created this simulated abstract teletype environment complete with paper you can cut off and a little desktop you can put all your papers on. Here, I'm working with some of the original assembly code for cat in Unix version one. First, I

print out the labels using a reg so that I know roughly what my file contains. Then I navigate to one of the labels and print out the contents. I'm using some more complex addressing tools here than we saw earlier, but basically this means find the done label. That's the first address in our range. And after that,

find the put C label and then subtract one to get the line before it. That's the last address in our range. Then print out all the lines in that range. After this, I print out a couple other chunks. I organize them. I make some

changes. And then I put my new print out over the old one. Simulating all this using a display is a little bit limiting, but I hope you get the idea. Back in the 70s, you might print off your code using the teletype, take it away, maybe take it outside, do some annotation using pen and paper or pencil, or even you could make some sweeping changes by uh cutting things in half and then pasting new text in the middle that you'd written by hand. Then you could potentially grab an offline teletype machine and enter your editor commands into punch tape which later when you had an interactive terminal you could feed the tape in essentially playing back all your editor commands and then potentially assemble and run your code maybe fixing a few errors using interactive ed while you were there. I think you can see a bit of this

workflow also in these photos from Bill Gates illustrating what life was like for him using the teletype. Notice how all the walls are pasted up with these printouts too. If you think all this is a bit of a leap, I understand. But I'll give you one more startling fact. People

sometimes get the idea that ED existed and was so arcane because people were confined to using telet types at the time because they didn't have any better technology available. If they had visual monitors, then they would definitely have written the kinds of editors that we expect today. But this isn't true. Ken Thompson's motivating project for building the early versions of Unix was actually because he wanted to port a computer game that he'd written called Space Travel to a new computer which didn't have a lot of people using it. That way he could play it without having to wait for other people's batch jobs to complete. This underused mini computer,

a PDP7, was specifically allocated as a graphics terminal, so very well suited for his video game. And don't get the idea that they simply didn't have text editing software back then, because they definitely did. In fact, this footage here is from 1965 and shows some quite advanced video text editing. This was at least 5 years before Unix was made. Of course, I'm going to share this teletype environment with you, too. There are a

few versions. There's the one I just showed you, which you can drag in a file and then play around in the environment. Or there's a little choose your own adventure story where you end up back in time and have to help Ken Thompson with his work building Unix. And a third one exclusive to ODS members is a series of programs you can try out, fix up, and improve in order to try your hand at using Ed as a programmer, which I think feels a lot different to using it for text. Hello. I just finished the uh ED uh online web interface choose your own choose your own edventure uh software. Uh, so that puts me pretty

much ready to upload this video pretty soon. I think maybe today or tomorrow. So, it's time to record the epilogue. Um, and I will say I have had a lot of well fun be putting it slightly. You you'll get the idea. Um, yeah, this has been a very interesting video. I actually had the idea for this

video a few videos ago um when I got um as is classic for me so deep into the research I thought well I can I have the seeds of a good idea here but it's definitely going to take longer than 10 days to make so shelved it came back to it um and then um uh I'm about I'm about to talk about I'm about to talk about about to take a swerve into death warning so my father died in late February Um, and you know, very sad. He was only 68. Um, so I say only 68, of course. You know, it's it's not it's not a, you know, it's not 20. He's he's getting on, but we weren't expecting it to be that soon. He was quite

sick. Um, basically, he uh he had prostate cancer. So, uh, if you're putting off getting your prostate check, uh, I would highly recommend uh getting it um because it does make a difference. actually it turns out um and it makes a difference sometimes. Well, there are some things basically you can put off and it doesn't really matter. Like

there's a lot of stuff in life that you can put off, it doesn't really matter. This is one that if you put it off, it really can matter. So, um please go and do that if you are in such a position to need to do that. So when these things happen of course um you know it's a big thing for a person but it's also um you know you you realize after a while that life continues and your life has to continue and uh if you are self-employed and uh you are making videos for a living then uh this sort of thing can be a bit disruptive particularly if you're organizing a funeral um or part of organizing a funeral and you have you know estates and stuff to deal with. So, um, all this to say, uh, thank you one for to my father for the, um, the what I'm about to about to show you, which you may have noticed in the course of this video, not actually through, um, this exact footage, but some of the footage in this video has come via the uh, the Canon EOS R5, uh, my father's camera. He did not.

He He liked to take photos of glaciers and such. Uh not uh me. Um but uh I take photos of me. So how do I take videos of me? So um we've been benefiting all together through um the uh the lenses and camera bodies and all things I now know just a little bit more about. So uh

thanks uh to my to my late father for the upgrade to the channel. Appreciate it and hope you appreciate it, too. My other thanks goes to the ODS members who have been paying me for not doing well I've been doing things but I've not been delivering any videos for the past couple months. Um and um it would have

been totally reasonable to uh cancel your subscription um at that point. Many of you didn't and I really appreciate that because it helps me um get you know essentially make a project like this sustainable in in in the sense that there is you know there's real life and things sometimes happen. So um thank you. Stop touching the microphone. Okay. Thank you. um for doing that if you did it. I really really appreciate it. Um means a lot.

Uh if I guess feels like a funny segue into the pitch, but there is a nodes membership if you would like to support the project. It's about £10 or euros a month and for that you get extra stuff with each video, including this one. Uh this one I went to quite a lot more effort to produce an engaging interesting thing to uh play with a toy because I think the exercises to me are quite important that go with the videos. Watching videos is great and all, but nobody's learned practical skills through purely watching videos. You got to actually put it into practice. And I

want to give everyone here the opportunity and encouragement to do that and trying to make that as easy as possible to get into as well as fun and exciting to get into was really important to me. So, I'm putting a bit more effort into making those exercises into more web-based fun type things you can engage with that then you can possibly take into, you know, your own computer or whatever it is or, you know, develop in some other way. So, uh, try that out. Let me know what you think.

Uh, let me know if you'd like to see more of that stuff. Um, I was pledging actually for the membership. The membership, uh, this month you do get, um, an additional series of things to do with ED60, the, uh, the web the web that I've created. You get to do some, you get some programming exercises. And one,

the last one I actually think is a really cool one. Um, I I yeah, I find that one really fun. So uh if you want to sign up then click on the link in the description or in the top comment if I remember to do that and uh you will it will it will you will be guided to the right place to um give some money for that. You also get there was actually another video that I made shortly after my father passed away because I knew it would be a little while till I released my next video. So, I wanted to send out

something and what I sent out was uh a sort of side dish to this video uh which talks about how ED sort of fits into the theme of things we've been discovering recently around link lists. I had an idea that Ed was uh a good use case for link lists and without too many spoilers that video is about whether that is true and a bit of the history of that. So, you can find that in the extras section.

uh on the ODS website if you are a member. So, an additional thing to show my appreciation for ODS members. Um yeah, thank you again. So, the next video, which will be coming out uh quite a bit sooner than this one did, uh will be very likely focused, I'm not going to promise it, but very likely focused on fourth. Fourth is a very interesting language. Has some interesting history

as well as some interesting uh semantics. Works in kind of an interesting way. Not many languages out there that you're like to have used that work similarly to fourth, although I know some of you definitely will have done. It's a pretty conceptually neat language. So, I look forward to exploring it with you and I will do that reasonably soon. Anyway, that's all for this video. Thanks for watching and I

look forward to speaking to you again very soon. Have a great week.

2025-05-08 17:03

Other news