I'm posting this because it explains beautifully why we don't need to expend any great effort on getting GDB or other debuggers working with Guile. If some code needs a debugger, then it invariably needs re-writing much more than it needs the debugger. And _programmers_ who need the debugger are invariably much more in need of training.
This is (a tiny) part of the Computer Security History Project interview with Roger Schell: http://conservancy.umn.edu/bitstream/133439/1/oh405rrs.pdf ======================================================================== Yost: And Edsger Djikstra was a visiting faculty member when you were there. Can you talk about any interaction you had with him? Schell: Yes, he was one of a couple of people that probably had a major influence on my perspective on computer science. You know my background was FORTRAN. I mean, that’s what we used. The military programs were either assembly language or FORTRAN, or JOVIAL. JOVIAL was a military program language—sort of like FORTRAN. When I joined Project MAC; well, one of the things that you do with graduate students is they’re free labor for various things that have to be done. And one of the projects I had was what we called the Bootstrap Project in Multics, which brought it from essentially the bare iron up to the point where it could begin to run. It had been written an assembly language. And in Multics, the whole story was to write things in a higher [level] language. That makes them inspectable and viewable, and that’s what I was working on, looking at that problem. Okay, rewrite the Bootstrap in PL/1, from assembler language. About that time Djikstra came to campus and he taught a class. And I took his class and his claims, of course, seemed to me pretty outlandish claims in terms of the ability to know that essentially you had, call it, bug-free programs. And I, of course, had read the T.H.E. paper that he had written about that and I was largely a skeptic. Well, it turned out his office was about three doors down from mine. By that time I had gotten an office in Project MAC; they had a cluster of graduate students that I was with. Down at the other end was Djikstra; they’d found a place for him. And so I’d go down periodically and sort of challenge his claims. Well, he was not a particularly patient person, and obviously, I had a lot of respect for him so you wouldn’t debate him as you would another graduate student; but still try and learn where he was coming from. So I sort of threw out to him; because his examples; although the T.H.E. was about an operating system, when he taught his classes they were about algorithms that were essentially applications. And I said well, I’m not sure that I am persuaded that I can get this approach really to work; he described it as putting beads on a necklace and you put them together, and that sort of thing. I said I’m not convinced. So he said to me, what are you working on? I said I’m supposed to rewrite this assembly language thing in PL/1. And he says well, you understand what I do? Well, I think so. Well, you try it. And so, I said okay, fine, I’ll do that. I’ll modularize it that way; I’ll introduce those sort of layering constructs; and when I had questions and such—it isn’t hard, and not a science as to how to construct that. And occasionally I’d say I don’t see how to do this, so I’d go down and talk to him and say well, okay, I don’t see; you know, it doesn’t seem to me like this goes; and he’d patiently, or impatiently, put me on the right track. And so I did that and produced that program in that way, and of course, with a Bootstrap program, you can’t do much more than a desk check and then go run it. And so you’d have to construct a new boot tape and it booted from tapes. You’d create all these files, then you put them out, and they had this process of creating these tapes, and that was the job. And I was familiar with that process; I had worked in Multics; I had learned how to boot things up. I had written at that low a level. So when the system would come up, if it incurred a flaw early on in the process, it would type that the operating system was dead; this bombed; this is not here; you’d get some sort of very cryptic message that the operator console—which was a typewriter—would type out. And so I put my PL/1 version of the bootstrap program, built the tape, and so I’m going to run my first test, and well, it’s where it’s going to crash first, right? I mean, the usual kind of question, is can I know what happened? So I start the tape running and went to the operating console and waited for the message to type out. And I waited; and I waited. And I said oh boy, I’m in trouble. The thing; it isn’t even able to give me an error message or anything. Nothing happens. I’m really in trouble! And I turned around and looked back at the processor. Well, when the system’s fully up and running, the background thing will flash the lights and a pattern on the console lights. And I looked back, and it was running. And, I said, what’d I do? Run the wrong tape? So I looked down and made sure I had my tape. I booted it again. What? And it came up! Well, you know, from my FORTRAN experience I’d never written a thousand-line program (which this was) that ran the first time, right? It doesn’t happen. And so that was one that definitely changed my perspective from a software engineering point of view, in terms of Djikstra’s impact, which is your question. Yes, it had a definite impact on the way I view software engineering; I became obviously very much of an advocate of that way of thinking about the problem. ====================================================================== Anyone who has used Standard ML functors knows this feeling, but more so: when the code _compiles,_ you just know it's going to work. The way a Standard ML functor works is it composes ML code together. It allows you to implement an interface, and then totally replace the underlying implementation by plugging in a different one. And the type checking catches almost all the mistakes that people commonly make. And if your ML compiler can assemble lightning code, you can do this with assembler. The functor will snap assembler modules together, and the resulting assembler, although quite complicated, _just works._ No debuggers necessary. One may ask what has this to do with scheme? Well, Standard ML can compose scheme or C code just as easily as it can compose assembler code. So a Standard ML functor can define a typed template that will allow one to exchange underling scheme implementations of functional interfaces as easily as it does ML. This is why I want to get Moscow ML working under Guile. Moscow ML is really light-weight when compared with Guile. My machine takes 42 minutes (no, really, I timed it!) to byte-compile just ice9-pp.go. By comparison, the whole Moscow ML autoconf/build cycle takes less than 50s. This includes the runtime, the Standard ML basis library, and the lexer and parser generators and the compiler and toplevel REPL. And there's a fair bit of junk we could trip out, and we could make it a lot faster once we JIT compile the bytecode instead of interpreting it, and when that JIT compiled bytecode uses native Guile SCM objects to representall its data, then there will no penalty whatsoever in a Guile program just switching to Standard ML when it seems like a good idea.
