Tim Bradshaw <tfb+google@tfeb.org> wrote:
+---------------
| John Thingstad <john.thingstad@chello.no> wrote:
| > Java is in it own right a champion here.
|
| I think this is to misunderstand the problem. I have always thought
| (and I still think) that Java is an engineering masterpiece: ...
| *it's simple enough for average programmers to use*, and we know
| about average programmers. ...you can produce substantial systems
| which sort-of run, without a functioning brain at all.
...
| Interestingly the same is historically true for Lisp: because Lisp
| implementations generally protect you against the low-level issues
| which blight C/C++ systems, average programmers can get further.
| And so `lisp is big and slow'.
+---------------
This is exactly what prompted me, circa 1972 or so[1], to coin my one
(and so far, only) "law", namely:
Warnock's Law for Why BLISS[2] Programs are Big:
BLISS programs are big because most space optimization is done
as a side-effect of debugging[3], and BLISS programs tend to
work "the first time"[3] much more often[5], so they don't
get debugged as much, so the potential space-saving algorithm
changes[6] that tend to be noticed during debugging... aren't.
I wasn't exposed to C until much later, but at least compared to assembler
the Law seems to apply to C as well. Not to mention Java and Lisp... ;-}
In fact, this syndrome seem to have only gotten worse: IME it is very
rare these days for programmers -- or *anyone* -- to read "working" code.
Unless there is a bug requiring the code to be opened up, most code is
"write-only". But since is my claim that it is in the *reading* (and
understanding) of code that opportunities for significant major algorithm
or data structure changes are noticed, we find ourselves in a Catch-22:
the more productive you are in a given language and the less debugging
you do, the bigger & slower the code you deliver. (*sigh*)
Is any good news here for Lispers? Could it be that the inherent
polymorphism of dynamic typing means that the original code tends
to be smaller in the first place? Does ease of refactoring make a
subsequent space optimization pass possibly cheap enough that it
gets done? I dunno. My own code certainly seems to accrete bunches
of "prototype" code that ends up being "good enough" that it never
gets changed...
-Rob
Notes:
[1] Probably the reason no one here ever heard of it before is that it
was just something I sometimes quipped to others at PDP-10 DECUS
meetings, especially SIGIL sessions (Special Interest Group on
Implementation Languages, which at the time was pretty much mostly
BLISS users). [Ob. disclosure: I was the chairman of SIGIL for a
couple of years, not that it matters.]
[2] BLISS (Basic Language for the Implementation of Systems Software)
is roughly at the level of C, but with *much* better macros and data
structures [in fact, the latter are a kind of user-defined macro, too],
and better lower-level control of the code generated for subroutine
linkages. It was developed by Bill Wulf & his grad students at CMU,
initially for the PDP-10 only, then for the PDP-11 (though BLISS-11
was a cross-compiler only, written in BLISS-10). BLISS-10 was a simple
"min-delay/max-doer" compiler, but BLISS-11 featured *extensive*
data- and control-flow optmization, which is covered in great detail
in the book "The Design of an Optimizing Compiler" (Wulf, et al).
[Note that the syntax analyzer gets only a brief mention in the book,
since BLISS is nearly LL(1) and is thus *very* easy to parse with a
hybrid of top-down recursive descent (for control constructs) and
simple operator precedence (for infix expressions).] Like Lisp,
BLISS is an expression language; every executable statement has
a defined value.
DEC soon picked it up, and used it for a number of projects (the
first was the "FORTRAN-10" compiler that replaced the previous "F40"),
and extended it into a "Common BLISS" for the VAX (BLISS-32), PDP-10
(BLISS-36), and the PDP-11 (BLISS-16, still only as a cross-compiler).
The users were outraged that FORTRAN-10 was *huge* compared to F40
(though it *did* provide massively-better optimization), and complained
to DEC about the increased memory requirement for running the compiler
(and other BLISS code).
[3] At least as programming was practiced in the 1970's, though I dare
say that phrase is still true today.
[4] Or at least with very much less debugging.
[5] ...than the alternative languages being used for comparable tasks.
BLISS tended to be used for large projects, such as compilers and
large "system utilities" (e.g., batch systems), and later, for large
portions of operating systems -- things for which, up until then,
had tended to be written entirely in assembler langauge. [To be sure,
the MACRO-10 assembler had a *marvelous* macro system that could do
significant amounts of computation at compile time. It was very easy
to write well-structured code in MACRO-10.]
[6] As we all know, major optimizations -- whether space or time --
don't usually come from tweaking the code at the level of individual
statements (or expressions), but usually from major algorithm or data
structure changes.
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607