Subject: Re: Eureka! Lexical bindings can be guaranteed!
From: Erik Naggum <erik@naggum.no>
Date: 2000/03/07
Newsgroups: comp.lang.lisp
Message-ID: <3161442459191997@naggum.no>

* Andrew Cooke <andrew@andrewcooke.free-online.co.uk>
| 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