Xref: utzoo comp.lang.misc:6991 comp.object:2829 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.lang.misc,comp.object Subject: Re: Dynamic typing -- To Have and Have Not (was Runti Message-ID: Date: 21 Mar 91 12:19:31 GMT References: <1991Mar16.052952.10201@cs.cmu.edu> <352 <17928:Mar2012:22:5491@kramden.acf.nyu.edu> Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 47 In-Reply-To: brnstnd@kramden.acf.nyu.edu's message of 20 Mar 91 12:22:54 GMT Nntp-Posting-Host: cdollin.hpl.hp.com 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."