Subject: Re: Common Lisp, the one true religion!
From: Erik Naggum <erik@naggum.net>
Date: Sun, 09 Sep 2001 07:04:52 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3209007891180601@naggum.net>

* Erik Naggum
> Not to mention the fact that these guys are taught from day one that they
> cannot be trusted to remember the types of their variables and now they
> are asked to relinquish their one safety net: type checking in the
> compiler.

* Ray Blaak
> Well, they can't be trusted. Or, if they can, other users of their code
> cannot. Or, they do remember, but mistype things. The point is that
> mistakes happen, and extra safety nets provide useful value in the
> appropriate situations.

  OK, I should have elaborated, but the point is that the appear to lose
  their safety nets because all they know about is static typing.  They do
  not realize that when you have dynamic types, you cannot just use the
  binary values, you have to do runtime type checking, instead, but to make
  people with "binary" written on their foreheads understand this, you have
  to tell them about how you represent your type-tagged binary values and
  how inexpensive and painless your type checking really is on modern
  hardware.

  My underlying point was that to get a C head to think Lisp, you have to
  give him a lot of nitty-gritty implementation details to re-establish his
  feelings of safety and trust which you took away from him several times.

> The issue of static type checking is orthogonal to the syntax style of
> Lisp. One can easily imagine a Lisp extended to have decent static
> checking (perhaps optionally) enabled for it (or at least a CL in which
> declare forms could be relied on to give decent warnings or errors on
> mistaches).

  I would just _love_ to be able to write code that used the hardware for
  what it was worth in Common Lisp.  In fact, I have been thinking about
  this and implementing various things for this over many years.  A friend
  of mine took one of my embryonic sets of ideas at one time and tinkered
  with the gcc backend, but by the time he was finished with it, it had
  lost all its Lispiness, but at least it was quite possible to thinker
  with the gcc backend.  If this could be done well, it would be possible
  to enter a new era of foreign-function interfacing and writing code in
  Common Lisp that would be usable by other programs.  Due to our very
  different ABI, we live in a separate world, and using some other language
  to do some of the work for us is way expensive compared to most other
  languages that work well with each others, both in programmer time and at
  runtime.

> That static type checking is not as necessary in Lisp as compared to many
> compiled languages does not nullify its utility as another tool in the
> programmer's toolkit.

  Precisely.  And since static typing is most frequently exloited to allow
  compilation of code that uses hardware types efficiently, I think the
  lack of direct access to hardware types is one of the things that make
  the transition from other languages much harder.  The types you are
  taught to think in tend to influence how you think, to paraphrase the
  Sapir-Whorf hypothesis.

> Taken to the extreme, the "real programmers don't make mistakes" idea
> would have us forgo language support for any error detection.

  I have never even implied that real programmers do not make mistakes.
  They just make _other_ mistakes.

///