From ... From: Erik Naggum Subject: Re: Eureka! Lexical bindings can be guaranteed! Date: 2000/03/07 Message-ID: <3161442459191997@naggum.no>#1/1 X-Deja-AN: 594356894 References: <8a2naf$e4v$1@nnrp1.deja.com> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 952453783 12675 195.0.192.66 (7 Mar 2000 18:29:43 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 Mime-Version: 1.0 NNTP-Posting-Date: 7 Mar 2000 18:29:43 GMT Newsgroups: comp.lang.lisp * Andrew Cooke | This is a serious question, and not meant to trigger a flame-fest, so | maybe it's best answered and asked (sorry) be email. Here goes... it's a contentious issue because there's no relevant research to support the static-typing crowd, yet they have an "intuitive edge" that is very hard both to defend formally and to attack informally. it's like arguing against adults needing milk. (we don't. really.) | While I like Lisp a lot, it strikes me that a statically typed language | might be preferable in extreme reliability situations (I'm thinking of | ML, for example). Is that an issue in your experience, and how do you | defend Lisp against that criticism? in my current setting, which is somewhat more down to earth than NASA's lofty projects despite dealing with financial news distribution, handling errors _gracefully_ has virtually defined the success of the project, which is expanding and providing new services at increasing speed. the reason explicitly cited has been that the old system that mine replaced died completely and randomly when a component died, while mine stops in a state that is usually continuable right away and never fatal. running a production system under Emacs under screen may seem rather odd to the old batch-oriented school, but what it means is that I can connect to the Emacs process controlling Allegro CL and examine the system state, talk to background debugging streams, and fix whatever goes wrong if the system hiccups in any way, which it has so far done only with really weird input from the outside world. to obtain this level of gracefulness in one of the usual statically typed languages would have required _massive_ amounts of code, simply because you can't combine the dynamism with static typing without recompiling, since _only_ the compiler is privy to the type information. conversely, if you need all the type information hanging around at run-time, anyway, why not make _full_ use of it? sadly, the static typing crowd believes this is inefficient because they never had to make it perform optimally, using their static typing the proof that it is so much easier to do it compile-time, but that only proves they never spent the effort to make it fast at run-time. incidentally, my main gripe with static typing is when it is explicit. implicit static typing (like type inference) has a bunch of specific advantages over both dynamic and explicitly typed languages, but in general fall short in terms of dynamism on one hand and the programmer's ability to predict what the system is doing on the other. | (In my very limited opinion I get the impression that static checking has | improved a lot recently (but it may be that this is decade old work that | has stalled) and that a statically typed language with flexibility | approaching that of Lisp might be possible - that's a separate issue | since you are dealing with existing languages, but is teh background to | my question). I think it's important to differentiate not on the basis of what the compiler can do with the type information, but what something other than the compiler can do with the type information. this is largely, but not fully, orthogonal to whether the language is statically or dynamically typed. debuggers for most languages maintain type information (mainly in order to access the memory they use, of course), but you can't use it if you aren't the debugger. in some development environments, you get help calling functions and using variables, but what's the big difference between a lookup system only available in some program after compilation and manual pages in external documentation? the dynamism of _current_ information is missing in all of these systems. I don't think it's possible to make a statically typed language as dynamic as Common Lisp environments are simply because the work involved in making a statically typed language able to handle the dynamism will involve _very_ intelligent recompilation strategies, mounds of debugging information that people will want to discard, and introspection will have to be added to these languages in environment-specific ways. #:Erik