.Chuck Moore's Fireside Chat 2000
The Annual Forth Day meeting of the Silicon Valley Chapter of the Forth Interest Group was held on Saturday 11/11/00. It ended with Chuck Moore's traditional Fireside Chat. This is a transcription of the presentation.
A video of this presentation is available in the UltraTechnology store
on Tape 17 and on the
6 Video CD-ROM.
.
Chuck Moore
(Comments by and questions from the group in parenthesis.)
Here is where we start. Let me read this. This is a poem my wife found at one of her weaving conventions. Coloring Outside the Lines, the author is Sarah Hall Maney.
Coloring
Coloring
outside the lines
is scary business
Some days
I don't have the courage for it
at all
On my big, bold days, though
I let my red crayon
just streak across a line
Then I Swirl
my purple and orange
out there with it
in perfect freedom
no lines
Coloring
outside the lines is lonely too
I'm the only one
who doesn't get
a gold star
on my paper
The teacher frowns
the kids
call me weird
or dumb
or retarded
Why don't they see
that I'm not behind them -
I'm out in front
running free
outside the lines!
- Sarah Hall Maney
Now among the charms of this poem is that weavers think this way too. Maybe all artists do. The dynamic tension between obeying the rules and violating the rules, a little bit is good and too much is bad and everyone looks for a balance. No one is happy following the rules.
I like the word retarded because what I am doing with Color Forth and what I am doing with OKAD is like seventies technology. And every now and then I think that maybe I just don't get it. Maybe I'm stuck in olden times and need to move into the twenty-first century. And this poem kind of validates me, it says I'm not retarded, I'm advanced. (laughter)
It's on the web, you can search for it. Look for Sarah Hall Maney. It's the only thing I could find by her.
A bunch of sort of random comments. I can beat the dead horse that I have been beating before. I looked up "lines of code" the other day on the web. I did a superficial search. And a lot of it just goes back to Y2K when people were talking about mega lines of code and people trying to top one another in horrible examples.
Banks appear to be pretty bad. They have tens of millions of lines of code. I like the thought that the typical US bank, whatever that means, has ninety million lines of code. The second one is interesting, Banco do Brazil decided to rewrite their legacy code, to cut it down by a factor of four. It was an interesting thing to do but you have to wonder if it was justified. And you marvel at how little they actually gained.
Government is moderately interesting, the FAA with twenty three million lines of code to run the airways, if that's what that means. And then Windows NT at forty million lines. These numbers are rumors. You know somebody would throw out a number and I passed it along. I have no idea how many lines of code Windows NT really is. And I put it under Government because that seemed like a good place for it. (laughter)
Now the good stuff down here. Color Forth, these are numbers I just came up with the other day. The kernel of Color Forth is about four hundred lines of assembler code and it generates about six kilobytes of object code. Now those numbers are larger than I want them to be and I will invest some effort to make them smaller. But you know but they are six orders of magnitude smaller than the other numbers here.
Also I did a comparison, I had to look at some 'C' code. I looked at thirty two lines of 'C' code that did something that translated into seven lines of assembler. Now again, lines of code is a vague concept. I was counting comments and I was counting blank lines and I was counting lines that only have one little phrase on them. But hey those are lines and it is code and what are you going to do?
There was comment in one of these lines of code at some website that did some comparisons among different languages and the conclusion was that all high level languages really come out about the same, first order. And I think that's true. I don't think it matters what language you are working in, the programs are going to be this big, except for Forth.
(APL?)
All right, yeah Forth, APL and LISP are kind of all in a little cluster out there.
Now, I would like to address why this is, if this is, and particularly what we can do about it. There was a movie on one of the channels last night, It Conquered the World. (1956) This creature had flying bats that went out and bit people on the back of the neck, this is a very dangerous place the back of the neck, and turned them into slaves. I think it actually bit six people and that's what it means, "conquered the world."
But nobody realized what was going on with this kind of threat, its insidious. You don't realize that it is a serious "conquer the world" threat. Well it occurred to me that we are subject to that kind of attack. That somehow someone slipped into the software industry and has been taking over the world. And everybody has been going along with it accepting that this is the way things are in software and that forty mega lines of code is needed to do anything interesting.
Maybe its time to say no. This isn't the way it has to be. We know it doesn't have to be that way. Yet we are virtually the only people in the world who do.
A thought occurs to me, if I were to retire what would I do? One thing I could do is go out to someone who has a million lines of code and say, "Hey, I'll rewrite this for you. You pay me a reasonable amount and a bonus upon completion and I'll shrink it by two orders of magnitude."
(You should charge by the lines eliminated.) (laughter)
How could I do this? The problem is that a million lines of code is about twenty volumes, an encyclopedia set. I couldn't read that much. With ten people at a hundred thousand lines maybe you could read that much.
How can you rewrite legacy code? Now this Banco do Brazil, that's very brave. If each person could write say a hundred thousand lines they must have had, what, eight hundred people working on the project. Those would have to be really good programmers too.
(Imagine debugging that.)
That's one reason that you can't afford to rewrite legacy code. Not that you can't rewrite it, you can't afford to check it out. It's been checked out over a period of twenty years.
(Do you know if there was automated translation involved in that project in Brazil?)
What would that gain? How would that gain anything? Your just compounding the confusion?
(You start up the automated translation and at the end you have maybe a few hundred exceptions at the end.)
I couldn't have reduced this by two orders of magnitude with anything automatic. What I have to do, and again I tried to show you this this morning with my approach to blue tooth. You have to really understand the problem. You have to go in there and read it all, and then think about it, and say what they are really trying to do is this and then do that. Which is much much simpler than what they were doing.
Another take on this, I recently bit the bullet and I went out an bought a new video card for my computer. I got an ATI Rage Fury Pro. This is the best of the ATI of the product line of the last generation, now they've gone to Radion and all the rules have changed again. But this is something that is a good card and I have the documentation so I can program it in Color Forth.
Well, surprise, the documentation is incomplete, it's inaccurate, it's misleading and it's ... (laughter) I've got it to work with programmed I/O, that means I actually write to the registers on the card. And that works fine. I have done it three times. First I wrote to video memory and I saw pixels appear on the screen so I can do that. Now I've sent commands to the generator so it will put rectangles one the screen for me. Now I am trying to teach it to be a bus master on the AGP bus so that it will pick up a description of my screen and put it on the screen. The fourth step was going to be doing the same thing but in 3D instead of 2D. If anyone knows how to do AGP bus mastering I'll talk to you later.
I haven't gotten the bus mastering to work. I'm at a compete loss because I've run out of the documentation now and I'm in never never land. Actually there was one comment in the code that bothered me somewhat. It said, "This Linux code was ported from the DOS code, it has not been debugged, and it is know not to work." (laughter)
In the course of doing this I had to go through the Linux code looking for coding examples and register names and so forth. That's where I got the 'C' to assembler.
I reminded myself a little bit about how people write 'C' code and perhaps why there is sixty million lines of code in many applications. And it is almost understandable. I can excuse a lot here. There were a lot of programmable options that they had to test for. There were a lot of bits you might want to set or not set in a control word. And they had long names for those bits and they would smush them together and put em in a control word. I don't do things that way. To me it's an oxymoron. Those long names don't mean anything to me. I had to find a place in the documentation to find what that long name meant, what the consequences were of setting it or not setting it in order to understand what was going on.
Now having gone to all that work I can just set that bit in a hex word. I don't need the names and the conditions. I only have to do it once in one context. So one setting is good for all. That helped shrink the 'C' a little bit.
Then they had comments, comments ad nauseam. They would say "let us initialize the CCE engine" then there would be a routine called "CCEinit." That's not helpful. In fact it was expensive because I had to read it in case there was something there. But then one of my hot triggers about 'C' is that "CCEinit" would have left paren right paren to show that there weren't any arguments. Alright, that helps bulk up your program.
Other things were disturbing. I was converting into assembler so it's really not fair. They would have some code that was going to copy something from one part of memory to another part of memory and they wouldn't just use a move string instruction which does it all in one instruction after a little register setup. Instead they would have a loop where they would pick things up and move things and they would have plus plusses attached to pointers and such.
In one place it was particularly bad. I was actually surprised by this, but they would pick up bytes one at a time. They would pick up a byte and then pick up the next byte and then shift it left eight and then pick up the next byte and shift it left twelve and build up a word which was little endian and then ship it out. They guaranteed that the word was little endian although it was running on a machine which happened to be little endian and this was all nonsense. In other places they had cared about little endian and they hadn't bothered to do this. So it was bad code.
One of the things that happened, I guess twenty years ago, was that we had the concept of automatic code generation otherwise known as a compiler. And this did not let anyone write code that could have been written before but it did let less skilled people write code than what people were used to. So we introduced into the profession a very very large number of very very unskilled coders. You hardly can call them programmers.
Now this may just not have hurt a little bit it may have destroyed our civilization. The same thing is happening in VLSI design. The silicon compilers are attempting to do the same thing. Let lesser skilled people do what a small pool of experienced expensive people used to do. It isn't cheaper. It isn't better. It's just different.
This is what the bureacrats, the executives want. They want industrial scale workforces. Ten times as many people earning one tenth as much. The only justification is redundancy It is certainly easier to manage a large group of dumb people than a small group of smart people. You can't replace the smart people, but you can replace the dumb people.
What our culture is doing is trying to do is build a reliable system from a large number of unreliable parts. And to do that you need a large number of unreliable parts.
(Biology does that Chuck.)
It sure does and look at our DNA. 10^14 cells are needed to stand up here and talk to you. But it gets the job done. The tragedy is that this is the standard and this is the result of that philosophy.
We can live with it, we have lived with it. But it's going to become increasingly burdensome and it does kind of put a ceiling on what you can do. Because as soon as you accumulate this many lines of code you have got that many bugs that you can never get rid of. So you build an unreliable system out of unreliable parts.
We need to be more vocal and try to address this problem. Really there is no way you can examine that code and produce good code out of it. You have to go back and talk about the problem with the people and write good code in the first place.
And it is pretty hard to attract anyone's attention. But I think that there are places where that could be done. I've mentioned this before.
The joint strike fighter is going to have six millions lines of code. It's going to borrow three million lines of code from the F22 so they only have to write three million lines of code to attack ground targets. The F22, I would guess, would borrowed a million lines of code from the F16. So they only had to write two million. So each successive fighter only has add about the same amount of code as the previous, maybe twice as much as the previous, to the total. This is ridiculous.
(They use special lightweight compilers otherwise the planes would never get off the ground.) (laughter)
That's right. Fortunately the memory chips are getting smaller.
(What language is that in?) (Ada)
Probably Ada.
(That's really the one marketplace where you can't use a disclaimer.)
I'm sure that the one thing they don't do is the one thing they should do, but they don't do. They don't simulate the flight of the aircraft in of the aircraft. That's the obvious way to control it. Your running a simulator which is ten seconds ahead of where you are and so you know what is going to happen in the next ten seconds and you can change things if you want to.
A flight simulator does have a hell of lot less than a million lines of code. I don't imagine that it does it very well. But it would not be hard to write the software to fly an F16. It's certainly not hard to write the software to launch smart weapons because smart weapons to do everything that is difficult and all you have to do is watch it.
It would be in the interest of the Air Force to invest one tenth, one one hundredth of one percent of the budget to explore the issue and possibility of reducing the software. It's conceivable. In any dedicated application like that it is conceivable that you could persuade people that it is worth investing something to explore the possibility of reducing the software. It would certainly be a lot easier to check out the software.
(The government has the same problem with he paperwork reduction act. Of course that bill was huge. So they need a Software reduction act.)
We could talk to our representative and get the ball rolling.
(The paperwork reduction act has increased the actual amount of paper by adding the paperwork reduction act notice to most government documents.)
There is also a legal documents in English act and I have yet to see any legal documents in English.
(Plain English? Meaning you can read this document instead of your lawyer and interpret it for you.)
Actually some of the website non-disclosure agreements are fairly clear but they are too long.
We could maybe find applications that could be rewritten nicely. Then the question becomes, "Who are we?" I am I. I doubt I could rewrite the JSF software in any reasonable amount of time. I could perhaps demonstrate that it could be rewritten but then you would have to assemble a team of people to do it.
The Air Force recently got concerned about info-warfare. This is kind of amusing because they haven't been worried before. They fought two wars using info-warfare effectively against the enemy, one in the gulf and the other in the Balkans. Now it occurred to them to that they are increasingly reliant on communications and recon satellites and something might happen to them. Your enemy might have some information warfare capabilities and they need to defend against that.
The most effective technique is to incorporate some kind of trap door in the software in development before the whole thing is launched. Then you can trigger that trap door and shut down or redirect or whatever.
The Air Force has a problem with security clearances, code verification, code reading, examination, dealing with disgruntled employees including employees that you don't even know are disgruntled when they are doing bad things to your six million lines of code that you don't know are there. You have no way of knowing they are there. You have only a suspicion that they might be there. And certainly that problem is much more tractable if you reduce the amount of code by two orders of magnitude.
So there's another perhaps opportunity. A way of slipping in under the door and saying here is a reason for doing things in a way that you haven't considered.
I mentioned Verner Vinges book last year A Deepness in the Sky. This vast galactic civilization has got software that is three thousand years old and they can't do anything about it for the same reason that these people can't do anything about it. It is a terrifying future and one that I think we should perhaps tend to more diligently.
Again, I say that if I were to retire here is a new area to expand into. It does require the cooperation of the people of the vested interests who are doing things this way now. That is probably impossible to achieve. Like Wil way saying about the imperative of teaching. We address a problem that we recognize even if no one else recognizes it. So I leave you with that and I will switch topics and talk about Forth for a minute.
Someone asked this morning, George, "What is Forth?" Forth has stacks. Forth has definitions. Yes definitions are just like subroutines but in my mind definitions are very small and subroutines tend to be very large.
What else is it about Forth that is distinctive? And two things occurred to me that perhaps are being underestimated. One is that Forth is syntax free. This lets you define whatever syntax you want and still be within the rubrics of Forth.
(protocol)
You can take advantage of this to a greater or lesser degree. Wil is taking advantage of it by formatting the source in a an appealing way. I am taking advantage of it by dropping in color things here and there and I claim it is still Forth, Forthish.
I think John did a nicely formatted version of Fax encoding where you could describe an algorithm in a readable fashion and make it executable.
There are a lot of clever things that you can do and I value that cleverness. It makes it nice to write a program. To write a program elegantly, a program that is readable, a program that is pretty, is a very satisfying thing to do. It is a large component of the fun that Forth is and I have yet to find a person that says that 'C' programming is fun. You get the satisfaction of doing things in a way that is elegant.
Another aspect of Forth is analogous to Ziff compression. Where you scan your problem you find a string which appears in several places and you factor it out. You factor out the largest string you can and then smaller strings. And eventually you get whatever it was, the text file, compressed to arguably what is about as tightly compressed as it can be. And in the factoring you do to a Forth problem you are doing exactly the same the thing. You are taking, discovering the concepts which if you factor them out leaves the problem with the simplest description.
If you do that recursively you end up with, I claim, arguably, the most compact representation of that problem that you can achieve. It isn't that Forth isn't a better language than the other it is that Forth is the best language that there is.
This gets tricky because Goerdel demonstrated that you cannot prove the completeness of a system within the system, or even the consistency. So I don't think that will ever be provable. But it's demonstrable in any particular case.
(What can't be provable?)
That the Forth representation of a problem is the most compact. But hey, you're within epsilon of the optimum and that's good enough.
Bjorn Grinwald tried to quantify this. He addressed the problem of linear growth in complexity leading to an exponential growth of for conventional languages but a logarithmic growth of code in the Forth language. I did not find his argument convincing because all I could see was that he had assumed the result. It would be interesting to see a more convincing demonstration of that.
We all agree that Forth has logarithmic growth with complexity but none of these words have been defined adequately let alone quantified. So you can't prove it. I think other people either are not aware of that argument or find it completely unconvincing. That is the nature of the factorization.
The problem is that you can do a better job in other languages than people typically do in those languages. You could write small subroutines in 'C'. You could do anything in 'C' that you do in Forth but the only argument is that people typically don't.
You are also confounded by the fact that you have got good programmers and bad programmers. To do a really good job in Forth you have to be a really good programmer. If you are a really good programmer you can probably do a really good job in other languages too. But people don't.
Probably the people who care most about the quality of code is ironically Microsoft. They seem to make a corporate effort to write good code. And they fail. They certainly have good people. It isn't clear that the good people are writing the code. As soon as you draw a line and say here we've got analysts and here we've got programmers you've made a terrible mistake. Because the analysts don't have all the information that they need to make an intelligent design and the programmers are hamstrung by decisions which they are not allowed to appeal. Probably this is done in search of meeting deadlines. But much better to have vertical integration than horizontal.
(Don't you think that Apple programmers try a little harder and go a little further?)
Yeah that is probably true. In most other industries the quality of code is irrelevant. It doesn't earn anyone any points so it is not an issue at all. Microsoft is judged by the reliability of its operating systems.
(What about Cisco? Their stuff has to be pretty reliable.)
I don't know what Cisco does.
(They make a lot of routers which basically support the Internet infrastructure. So nobody sees their software.)
Is it complicated?
(I am sure it is.)
I think of a router as a very simple thing that takes data in and sends it out. Perhaps it more complicated than that.
(The Internet went down in San Jose a couple three days ago for oh, four hours because the San Jose router went down. It must huge because the total internet traffic for the city went through it.)
A router per city. Yes, we are building an infrastructure out of unreliable parts too.
(Did they have to call Router Rooter?) (laughter)
Another aspect of Forth has to do with the stack. When you are talking about building a small processor, something with a small architecture for the processor I find in F21 and its ilk that I miss having some registers, somewhere to put something and get it back quickly.
The Pentium is basically a register machine. It has a stack and you use it as the return stack and you have to do something to get a data stack. Looking at these various architectures it is clear to me that the stack is essential, you must have a stack. Registers are optional. If you had some registers you might be able to optimize the code for ways where doing it on on a stack is clumsy or difficult.
But to program a register only machine is much more difficult than to program a stack only machine. I think stacks are the important concept. Registers are a nice thing to have if you can afford them. Which is exactly the opposite attitude that everyone who designs computers has.
((Wil) Including me. Registers are very important and are much easier to program than a stack because not all algorithms work down to two arguments. There are complicated ones. There are ones which have to have more than two arguments and the handling of registers is an extremely useful thing. One thing is that the use of registers can eliminate memory access.
Working with PowerMac Forth I do not use local variables even though local variables are faster on the RISC machines. I have converted routines that I use often from Forth to straight assembler and the assembler routines are four to ten times faster because of the registers.
I won't ...
(And a lot easier to program.)
((George) With registers you can obviate the need for a stack. With registers you can optimize the use of the stack but for really huge deep applications the stack...)
((Wil) It doesn't have to be deeply used.)
No it doesn't. But it is so handy just to let things fall down the stack until you need them without having to anticipate where you are going to put them for future reference. ...
((Wil) But you have a worse problem of where you are going to get them back.)
You had better get them back, this is at the design level, if you have to do ROTs and PICKs then you are right. That's costly, that part. And your right you don't always need just two or three things accessible at one time...
((Wil) Even though that's enough. You can always use frame pointers. Certainly two are enough. For instance APL only has two.)
I like Bob's notion about modes. That is a powerful tool. You set something once and for all and you are done with it. You don't bother with it any more because you eliminate all the options that you would have to carry around on the stack. And...
((Wil) But that's global variables.)
Global variables, and they often do that in 'C'. 'C' tends to have a lot of local variables on the stack which can be addressed by name and for which the cost is invisible.
((Wil) And all the books on 'C' style warn against doing this.)
Do they? That's very wise of them.
(That's bad 'C' code to do that.)
I have one more topic and that relates to what Wil was doing earlier. He has this website full of good code. I would suggest that we have even more code at a website somewhere, examples of Forth that do more things, lots of things. You want to invert a matrix, I don't know what you have there. But all the ordinary things that people might want to do where you pick up a copy instead of having ... The code exists here and there and everywhere. Having it in one place where it is visible to not only us but to ...
((John R.) Or pointers to it in a lot of places. Skip Carter's, the Forth Scientific Library, that has a lot of stuff. Wil's stuff...)
Simpler stuff. Suppose you want to move an array from here to there.
I don't like libraries. I will argue about libraries at a future time. But examples are a very good thing.
(Heaven forbid that we have standard so the code would work.)
(One alternative that might be worth considering is a ring. I was looking for stuff on Tesla and they have a ring of sites. And you can say go to a random site in the ring or the next one. And there were a lot of broken links and crappy sites but on the other hand eventually I got to the sites that were really great. There are a whole bunch of really great ones and I found what I needed. And it was distributed all over the place. Some of it was in German but all you have to do is say I've got some.. (others))
Is there some way you can search the ring? I found that annoying in dealing with lots of little 'C' files. I wanted a word and I didn't have a decent facility for finding out which file it was in.
(You didn't have a library!)
(Chuck doesn't want just a list of the websites. You wanted to be able to search those websites for a topic.)
(That's what Alta Vista is for.)
(That's what Google is for. If you are not using Google you are wasting time.)
(What do you do about color blind people with Color Forth?)
Ah, brightness and ...
(Fifteen percent of the male population is color blind.)
That's shocking! We have to change those genes. (laughter)
Color is a tag for easily distinguishable. Color is a marker.
(You put "BLUE" in front of a word. What do you do with websites that you can't see because you are blind? Let them speak to you.)
((John Rible) A comment on learning or whatever. A friend of mine is teaching a beginning programming class at UCSC and they were doing a large scale study for which they did a pretest getting background information on usually freshmen or sophomores in college. And one of the questions was if you know any programming language write a program to given N display the first N perfect squares.
The high school students that learned BASIC did it, Charlie was saying, did it with BASIC programs that were two or three lines long. And there were some 'C' programs that were three or four lines long but most of the 'C' and C++ programs were between a half page and a full page to solve that problem.
They were theorizing that that was because in high school the focus is on the syntax, and the grammar, the mechanics of the language not about learning about algorithms or about how to solve problems. And so they want to follow up on that and they don't think that beginning programmers should ever learn 'C' or C++ as their first language. On and on and on. I think it was great.)
(applause)
