Merge branch 'wip/transcripts' into 'master'

adding raw transcript files to the repository as .docx

See merge request Savage/hamming!3

transcripts/Hamming04_Transcript.txt → transcripts/txt/Hamming04-Transcript.txt

-Lecture begins at: https://youtu.be/Qmr-6qN-HC8?t=505 
-
-Shall we begin? The talk today is on software. Software got its name because hardware you could lay your hands on, software were the programs which told the machine what to do and they were somewhat soft. They got that name for this contrast with the hardware which you could lay your hands on because in the early days of machines people didn't really understand machines. Software is what tells the machine what you want done. That's some "totalment" (sic). Now in the early days with hand calculators, you turned a crank, and you threw the carriage over and so on, and you controlled it by your hands. And the early IBM machines were plug boards. You put wires from the columns and the cards to where you wanted in the machine. From where the answers were in a machine to where you punched on the card or where you want it printed. We wired up single boards and in the accounting room for example, each operation would have a board. It would be stored away, so each week we went through the accounting process, you picked up the same boards. You didn't rewire them because they were rather troublesome to wire - to say the least. 
+Shall we begin? The talk today is on software. Software got its name because hardware you could lay your hands on, software were the programs which told the machine what to do and they were somewhat soft. They got that name for this contrast with the hardware which you could lay your hands on because in the early days of machines people didn't really understand machines. Software is what tells the machine what you want done. That's some totalement. Now in the early days with hand calculators, you turned a crank, and you threw the carriage over and so on, and you controlled it by your hands. The early IBM machines were plug boards. You put wires from the columns and the cards to where you wanted in the machine. From where the answers were in a machine to where you punched on the card or where you want it printed. We wired up single boards and in the accounting room for example, each operation would have a board. It would be stored away, so each week we went through the accounting process, you picked up the same boards. You didn't rewire them because they were rather troublesome to wire - to say the least. 
 
 Now after George Stibitz’s first machine. He used paper tape and paper tapes are a terrible thing to use. You can't make insertions very well. When you glue the tapes together, the glue gets stuck in the fingers of the readers and its troublesome but you won't see much anymore. The ENIAC in ’45 – ‘46 was the first electronic machine. And it was designed to do integration of ordinary differential equations for trajectories to build bombing tables or ballistic tables. Well, that was the design and so it was designed pretty much like a glorified IBM plug board except the machine was in a room about this big and the cables went all the way around on trails around the room. 
 
 However actually the first problem run was part of the original studies of how to build hydrogen bombs. So the machine was used differently. And in fact, the way they wired it was so awkward that ultimately Metropolis and a guy named Dick Clippenger devised a method of wiring machine once and for all. So you then program from the ballistic tables and really set numbers, and that would be the program instead of rewiring it all the time. 
 
-Now real internal programming became a reality when we had registers. We began with machines with two and three registers. We got up to ten or twelve or fifteen - that was a lot. Well you can't do internally programming then. I am inclined to believe that people thought about it. When we got enough internal programming space so we could really write out programs, they began to discuss it as had Babbage. Now what happens is that von Neumann was hired as a consultant and he wrote up the reports on how to program and so it's attributed to him. But Harry Husky’s written that they had discussed internal programming long before von Neumann ever was a consultant.  Watching around, von Neumann never either claimed he had done internal programming or denied it. So since he’s dead you're left. But my inclination is that attributing the internal programming to von Neumann's is probably very dubious.
+Now real internal programming became a reality when we had registers. We began with machines with two and three registers. We got up to ten or twelve or fifteen - that was a lot. Well you can't do internally programming then. I am inclined to believe that people thought about it. When we got enough internal programming space so we could really write out programs, they began to discuss it as had Babbage. Now what happens is that von Neumann was hired as a consultant and he wrote up the reports on how to program and so it's attributed to him. But Harry Husky has written that they had discussed internal programming long before von Neumann ever was a consultant.  Watching around, von Neumann never either claimed he had done internal programming or denied it. Since he’s dead you're left. But my inclination is that attributing the internal programming to von Neumann is probably very dubious.
 
 Now in the early program, when you program absolute addresses. If there were an error here, you want to put something in, you took that instruction, replace with a transfer, put that one over the transfer place, put down the additions and transfer it back again. Now when you found another error over here, you do the same thing. And pretty soon the control was like a can of spaghetti. All over the memory in very strange ways. And it became very, very hard. And we lived with it for a long while. 
 
-Now we very rarely got the idea of reusable programs, even Babbage had the idea. We called them libraries in those days. We ran our square routine, we put it in the machine and we reuse it. Everybody wants to use the same one and we put them in definite locations at first. But if the score routine is in that location, and the sign is in that location, and so on, you've got to program around all those parts. And pretty soon the library is so big that it all can't fit the machine at once. So we turn to relocatable software which was in the von Neumann reports. The von Neumann reports were Army reports. They were never published officially. They were just issued and everybody had a copy. But they were never really refereed and published. The first published software book was on the EDSAC out of Cambridge. I told you I think that in 1946 Mauchly and Eckert held an open session and told everybody everything they knew about how to build computers. And Wilkes, Maurice Wilkes, of Cambridge was there. He attended the thing, went home and he built a machine and got it going before anybody else did. So his was the first machine and his book, which we'll talk about several times, was the first programming book.
+Now we very rarely got the idea of reusable programs, even Babbage had the idea. We called them libraries in those days. We ran our square routine, we put it in the machine and we reuse it. Everybody wants to use the same one and we put them in definite locations at first. But if the score routine is in that location, and the sign is in that location, and so on, you've got to program around all those parts. Pretty soon the library is so big that it all can't fit in the machine at once. So we turn to relocatable software which was in the von Neumann reports. The von Neumann reports were Army reports. They were never published officially. They were just issued and everybody had a copy. But they were never really refereed and published. The first published software book was on the EDSAC out of Cambridge. I told you I think that in 1946 Mauchly and Eckert held an open session and told everybody everything they knew about how to build computers. And Wilkes, Maurice Wilkes, of Cambridge was there. He attended the thing, went home, and he built a machine and got it going before anybody else did. So his was the first machine and his book, which we'll talk about several times, was the first programming book.
 
 Now pretty soon somebody had an idea that I could write a program which would take the letters ADD at read time, when it was reading into a machine, and convert it into the pattern of zeros and ones which was the crazy instruction the designers had built. And so we had symbolic addresses. Our symbolic names, converted. And then somebody said, well we could do the same with addresses. I could call the address A and you could let the machine assign that and the machine will remember where A is. Every time we refer to A it will give the absolute addresses. Those were primitive assembly programs, and what you tend to call machine language, but that really is a fancy business, already.
 
@@ -26,13 +24,13 @@ Now I tried out an experiment. You know the government frequently lets out contr
 
 Now in 1962 LISP language began. McCarthy thought of a language designing for logical reasons and it was improved and extended by various friends logically, abstractly. A student one day said hey I could write an assembler in LISP language itself and cause it by and large to assemble itself. McCarthy said, you could? He said sure, so they did. It’s one of the first examples of using a language to assemble itself. It's a very useful technique. 
 
-Now let me digress and talk about the 650 machines I used. It was a 10 decimal digit machine with a drum. And so therefore it was a two address system instead of the typical one-one. The first address told you where to find the number or put the number, and the second address told you where to find the next instruction. So you could carefully arrange it so as the drum came up there, right as you’re ready to read, that instruction was there. Rather than having to go all the way around to find next one, you could place them just so they would be right. And the machine would operate much faster. That of course also depended upon where the numbers were put. When you put them here, there, yon, it had to be right where you want it, when you want it, then it would run very fast. Otherwise, it would go around and around and do very little. So the problem of what we call minimum latency. How do you design a program to store here, there, yon so it will run as fast as you can make it?
+Now let me digress and talk about the 650 machines I used. It was a 10 decimal digit machine with a drum. And so therefore it was a two address system instead of the typical one-one. The first address told you where to find the number or put the number, and the second address told you where to find the next instruction. So you could carefully arrange it so as the drum came up there, right as you’re ready to read, that instruction was there. Rather than having to go all the way around to find next one, you could place them just so they would be right. And the machine would operate much faster. That of course also depended upon where the numbers were put. When you put them here, there, yon. It had to be right where you want it, when you want it, then it would run very fast. Otherwise, it would go around and around and do very little. So the problem of what we call minimum latency. How do you design a program to store here, there, yon so it will run as fast as you can make it?
 
 IBM produced a SOAP program, Symbolic Optimizing Assembly Program. They made two copies. They rode off straight up. Call them copies A and A. They loaded A in the machine and they ran A through it to get an optimized SOAP. Then they loaded the optimized SOAP in and ran A through again and observed how much faster the second pass was to the first was so you know how much SOAP did in improving the thing. Another example of a program which optimized itself. This business of using programs to do themselves have proved very popular very, very effective and you want to think about the recursive aspect of how you can make a lot of work be done by the work you're doing. It's a very powerful technique. 
 
-Now let me talk about that book from Cambridge, England. I reviewed the book. In Appendix D there was a little program which had been written because the program man wanted to write, could not fit into memory. So I wrote a little piece here in brittle of translation there. It was an assembler. It wasn't called that, but that's what it was. When I reviewed it, I stayed over it a long while and realized that's what it was. If they put Appendix D did they know? In the second edition, it was still in Appendix D. Did they know what they've done? No. I'm raising a question, when is something known first? We tend to give credit to the first person who says something but that really isn't right. There was a time when I and a bunch of other people in computing realized one day that computers really were not number-crunching machines. There were symbol manipulating machines. We went out and gave talks. And I could watch the audience nodding their heads all yes, and I knew most of them did not understand what I was saying. They did not understand they were not number crunchers there were symbol manipulators. But that's the way it goes.
+Now let me talk about that book from Cambridge, England. I reviewed the book. In Appendix D there was a little program which had been written because the program man wanted to write, could not fit into memory. So I wrote a little piece here and a ittle of translation there. It was an assembler. It wasn't called that, but that's what it was. When I reviewed it, I stayed over it a long while and realized that's what it was. If they put Appendix D did they know? In the second edition, it was still in Appendix D. Did they know what they've done? No. I'm raising a question, when is something known first? We tend to give credit to the first person who says something but that really isn't right. There was a time when I and a bunch of other people in computing realized one day that computers really were not number-crunching machines. There were symbol manipulating machines. We went out and gave talks. And I could watch the audience nodding their heads all yes, and I knew most of them did not understand what I was saying. They did not understand they were not number crunchers there were symbol manipulators. But that's the way it goes.
 
-Now you can say originally Touring's machine back in 1937 was and demonstrated similar manipulation. That's what it was. And you can also claim, if you wish, that he must have understood interpreter because that's how he proved that every machine was equal to any other machine. The universal Turing machine was really any one of the machines with a suitable interpreter. So he must have known, but did he? The answer is no, probably not. Now history tends to be charitable and give the first guy credit. There's a saying however, that says almost everybody who creates a field never understands it correctly. They apply a certainty of physicists. Many physicists have created a field and then they have been a drag on it. Einstein started quantum mechanics going but he never accepted quantum mechanics. He always opposed it. He didn't believe that God played with dice as a famous saying of his was. 
+Now you can say originally Touring's machine back in 1937 was and demonstrated symbol manipulation. That's what it was. And you can also claim, if you wish, that he must have understood interpreter because that's how he proved that every machine was equal to any other machine. The universal Turing machine was really any one of the machines with a suitable interpreter. So he must have known, but did he? The answer is no, probably not. Now history tends to be charitable and give the first guy credit. There's a saying however, that says almost everybody who creates a field never understands it correctly. They apply a certainty of physicists. Many physicists have created a field and then they have been a drag on it. Einstein started quantum mechanics going but he never accepted quantum mechanics. He always opposed it. He didn't believe that God played with dice as a famous saying of his was. 
 
 Well turning back to 650, having realized the machine was ten decimal digit machine and I want a floating-point and that was a fixed point machine, I would have to build an interpreter. So I hit upon the following idea. Of the ten decimal digits I would use three for A, one for the operation, three for B and C. Take the number that's in location A do this operation, would be like add, subtract, multiply or divide, and put the answer in C. I have four instructions but of course, only four of those, add, subtract, multiply and divide need both addresses. If I put a zero in here, the machine would look here for further information. What instruction you wanted. So I had a whole bunch more instructions. Well now I wrote this program in my mind. Start, you assign some register the current address register. You go there to find out where the instruction you want to obey is. You go to that location, get the instruction. You store the A, you store in the B, you store the C. You take the operation, add a constant to it, transfer. Here you find a subroutine describing an operation. Here's a bunch of which were transfer instructions. When these were done, they transfer to here. You added one to the current address register. You went back to start, after cleaning up. If it were a transfer instruction you transferred to here. Now you see, I have not told you the language. I've told you how to build a language. All meaning is contained in what those subroutines are, correct? Everything is contained in here. What do those instructions mean are what you put there. You can write any language you want. Now that was a language where every instruction meant what it meant, without any contingent about what went before or after. You could easily arrange, I could have, that if this is structural bait it sets a flag, when this is structural goodbye it looks at that flag, oh then do this if not, do that. I can make a language which depends about context. I didn't, this was a context-free program. But you see how you do it. I want to dwell on this. How utterly simple it is to build an interpreter. Now differences between an interpreter and a compiler is very simple. An interpreter does it and every time you come to the same instruction loop you do the same translation. A compiler makes the translation once for all, writes out the translation and then runs the problem. And there are subtle logical differences between the two. You've got to be careful, but fundamentally that's the idea. And for machine efficiency we usually make a compiler but if you’re going to do floating point, you have to really do this. I'm sorry, you have to be a compiler. You have to be an interpreter for floating point because you don't know which numbers are going to be where, how much you have to shift back and forth. You can't really build very good one. So sometimes you build interpreters. Sometimes you build compilers, and now we build compilers on top of compilers and interpreters on top of compilers and so on. We do this all the time. This is how we make a machine look like what we want. And I think it should be clear to you, if you can define a language, uniquely, write out the subroutine, write out something like that, and you have now the machine behaving in this language.