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.