Subject: Re: Please help
From: Erik Naggum <>
Date: 1999/04/09
Newsgroups: comp.lang.lisp
Message-ID: <>

| But of course it's not for "no purpose".  The purpose is to write correct
| code first time round as often as possible.

  that is supposed to be the consequence of successful training or
  education.  if you have to do something silly to get correct code, that
  _should_ have been a very strong warning sign.

| If you *really* want to avoid waste write assembler, or indeed machine
| code :-)


| Then decide where things can be modified for effeciency.

  if you have no concept of what is or is not efficient before you start,
  doing it afterwards will be very, very inefficient, in programmer time.

  you appear from the above comment not to understand that "wanton waste"
  is not restricted to what the computer does.  I suggest you broaden your
  perspective and appreciate that the whole idea of programming computers
  is to reduce the total cost of the tasks the computer is set to do.

| Sometimes the code you writing doesn't suit this style, because the data
| structures and algorithms you've decided are naturally expressed in an
| imperative, destuctive fashion. (As it happens I've spend most of this
| week writing code to shuffle bits around bit vectors, because this is the
| only practical way to get the kind of performance needed for the task in
| hand.)

  at least this looks like a redeeming quality, but I'm uncertain about how
  you decide on data structures and algorithms to begin with.

  in my view, functional programming is not usefully extended all the way
  down (i.e., we don't want non-destructive instructions or memory, which
  would have meant we'd need a new computer every billionth of a second),
  so clearly there's a point where the exported interface is functional and
  the implementation is not.  I extend this view to functions at any level:
  functional programming is about a design style that _exports_ a clean
  interface, but I should _not_ care what it does inside.  consequently, if
  I design a function with a clean interface, it matters not whether I use
  a "dirty" technique or not inside it as long as nobody is impacted by it.
  this, incidentally, leads to why I favor a more functional programming
  style: I don't have to deal with any "ownership protocol" of objects that
  have been allocated, but when I do know that I alone own an object, I
  have no compulsions about modifying it, or asking functions I call to
  modify it.  and I _don't_ see this as betraying the Functional Style.