🚀 go-pugleaf

Dan replies:

   You're right, I should have said ``costs dearly in either compile time
   or run time, and in either case (for projects with many debugging runs)
   programming time.'' My point is that I can't afford to make that choice
   except for projects where the compile time or run time is going to be
   very small no matter what language I use. That's rarely the case.

OK, but I'm still puzzled as to why you included the option of dearer
compile-time costs at all. Can you illustrate a case where a compiler for a
dynamically-typed language is *slower* than a compiler for a statically typed
language - when the compiler is written in the same language for both (ie,
we're comparing apples and apples)?

As it happens, I have been writing a program in a dynamically-checked language
recently - a typechecker [ironic, eh?] for a specification language.

I am happy to report that the number of *type* errors that occurred was
trivially small; perhaps once there was a type error that took me longer then
fiven minutes to track dowm. [Usually it's a case of "bugger, forgot to change
the call of rename_sigentry in copy_module"; static typechecking would have
caught it about thirty seconds earlier.]

I am also happy to report that the genuine logical errors could not have been
caught by anything short of a full theorem prover operating from a fully
correct abstract specification. 

[I just timed how long it took to load the complete typechecker into the
system, starting from Unix command-line prompt and including the time it took
to type "load loader.p" to the editor; 1min 6sec for compiling 8000 lines of
source to MC68K machine code, on an HP9000/350. This time includes the program
setup-time (it constructs various tables of built-in identifiers on the way,
and reads a file describing the parse-tree magic numbers). Compiling the
database component from the toolset - written in C with a small Yacc grammar -
took 8 minutes for about 12000 lines of code, not including the time it would
take to build the standard library components; same machine, of course. The
figures are open to interpretation, but they're datapoints.]

[By the way, Dan, if you find Forth "expressive", you might like Pop; Forth's
open stack, sort-of Lispy datatypes, conventional syntax.]


--

Regards, Kers.      | "You're better off  not dreaming of  the things to come;
Caravan:            | Dreams  are always ending  far too soon."