[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extending the address space of MIT Cscheme (long reply)
Date: Wed, 4 May 88 11:12:23 MDT
From: firstname.lastname@example.org (Stanley T. Shebs)
Writing nonprimitives in C. My eye happened to fall on list_to_string,
which is about three times longer and more complicated in C than in Scheme.
What earthly reason could there be for this? I suppose it could be worse;
KCL is an example. On the other hand, even KCL doesn't put a Fast Fourier
Transform and a regular expression matcher in its C "microcode"...
I dunno. The precedents are there. The VAX gives you a FORMAT statement in
I find it odd that haters of C would use macros to the extent that CScheme
[I'm speaking from the vantage point of someone who has NEVER seen the CScheme
sources, but who HAS tried to program abstractly in C]
Unfortunately, macros are the only way to do \syntactic/ extensions of the
language. I'm currently preparing a short class on code
maintainability/writing "good" code. One of the things we examine is why it's
hard to do reasonable abstraction in C. Part of the reason is that syntax is
tightly tied to representation. The only facility around that is macros.
>* We have virtually no documentation. This is obviously a terrible
>thing, and we are in fact generating some. But the bottom line for
>this is simply lack of time, plus the fact that none of us has much
>text writing experience.
I hear that excuse from froshes, and don't accept it from them either.
Documentation after the fact is inherently inferior, and leaves out
important details that the programmers have forgotten about.
Still, I do appreciate where you're coming from - it's something that
professional SEs have to contend with all the time (my own views have
no doubt been colored by one of my first jobs, which was to document
40,000 lines of Fortran written by several other people).
A marvelous exercise! I started my programming career working for a man who
had me go through various RSTS/E V5 system programs, document them, and rewrite
them "modularly." There's nothing like that kind of experience to make
"writing code" a superset of "writing documentation" (n.b. a superset; the
two aren't disjoint!)
In fact, my almost finished thesis is all about the analysis of
I'd be \very/ interested in a copy of this. Will they be available online?
STEVER@RIVERSIDE.SCRC.Symbolics.COM or SCRC-RIVESIDE.ARPA [arpa]
(617) 621-7634 [NYNEX]
4CC 02142-1421 [USPS]