Re: What's so great about lisp?

Jon Harrop <usenet@xxxxxxxxxxxxxx> writes:

> Joe Marshall wrote:
>> I think we can. We would need to quantify what you mean by
>> `likelihood', nail down specifically `those kind of errors', and
>> develop a criteria for `satisfaction'.
>
> I am unsatisfied already. It would be easier to unify physics, IMHO. :-)

The real issue is not about static vs. dynamic typing. I don't think
anyone in their right mind would object to the computer automatically
finding errors as soon as possible. There are actually two issues
that are of interest:

1. How much does the computer interfere with the task at hand when
it discovers errors, and

2. How willing is the programmer to change his style to aid (or
conform to) the computer's static checking.

`Strong-arm' type checking appears to be a popular choice in the
static typing camp. In this model, it is not possible to compile a
program until the type checker is satisfied that the program is free
from type errors. While it is true that once the program compiles it
will not have type errors (a trivial tautology), it can seriously
interfere with interactive development. When developing
interactively, it doesn't matter whether the untaken branch is type
safe. Being forced to write type-safe `stubs' that won't be executed
is simply useless busywork.

Static typing with inference and all the modern amenities is a far
cry from the static typing found in C or Java. Nonetheless, there are
programs that the type checker cannot prove correct, or cannot prove
correct without assistance from the programmer. The programmer must
either provide hints to the type checker *or* modify his programming
style to avoid constructs that will stymie the type checker. Some
people don't mind doing this because they percieve a real benefit to
satisfying the type checker.

Personally, I want as much static checking as possible provided that
it *never* rejects a program, even one that is provably wrong (it
should compile to a call to the runtime error handler!), never
complains when it cannot determine if the program is type safe, and
requires exactly *zero* effort on my part to use. I may be willing to
provide type hints and guarantees at some point of development, but I
never want the computer to force me to do so *before* I am ready.


.

Relevant Pages

  • Re: Python from Wise Guys Viewpoint
    ... You've turned into a PHB! ... Static typing is strong medicine. ... out like Joe without a clue of what I am doing. ... good chance of passing the type checker). ...
    (comp.lang.lisp)
  • Re: RAD vs. performance
    ... Then you're implementing static typing. ... type checking work to compile time as possible. ... that it is possible to invent dynamically typed languages that compile ...
    (comp.lang.misc)
  • Re: Which programming language is better to start
    ... >>> It may happen that some features in LISP render slower implementations ... >> work is done at compile time. ... >> In that kind of situations, static typing gets in the programmer's way ...
    (comp.programming)
  • Re: RAD vs. performance
    ... The non-existence of a good implementation is a valid reason not to ... Static typing implies that you do some type checking at compile time. ...
    (comp.lang.misc)
  • Re: Why I dont believe in static typing
    ... > I think that using this terminology, born from what many now regard ... The precise terminology would be to replace "compile-time" by "static". ... > a part of my compile process, then how relevant do those words ... My experience says that static typing à la Haskel/ML wins hands down ...
    (comp.lang.lisp)