Subject: Re: horrible formatting
From: Erik Naggum <>
Date: 1999/02/16
Newsgroups: comp.lang.lisp
Message-ID: <>

* funcall-of-nil <>
| Accessing a linked-list data structure (which is what LISP lists are,
| doubly-linked, circular linked-lists) always requires one to
| "march-down-the-list" unless you have the address of the element (cell)
| as in a hash table or a C linked-list.

  are you saying that doubly-linked lists require sequential access and
  singly-linked lists don't?  that's pretty amusing.  considering that you
  don't even know how Lisp's lists are represented, maybe it isn't amusing.
  (how does CONS know which cell to point backwards at?  does it traverse
  the entire circular list to find the one that points to its argument?)

  why _is_ it so hard to get this stuff right?

| Paul missed the most important point, which was not whether the defun
| was the most efficient implementation.  For those who haven't worked in
| groups: code should be easy to comprehend.  The greatest cost IS the
| human factor.  This is a constant in the software industry, whether one
| usea C++, Java, or LISP.  Finally, the look of the code doesn't have
| anything  to do with its execution (lines with only parenthesis).  

  since the human factor is the most important, you hire good people and
  get rid of the incompetent fools.  that means "easy to comprehend"
  changes meaning drastically from compulsory groups such as you have to
  deal with during your education.  if someone doesn't "get it" too
  frequently, he's simply removed from the group.

  since the human factor is the most important, you ensure that _people_
  aren't unduly annoyed by ugly, stupid, or ignorant coding styles.  those
  who, are not welcome in voluntary groups, and if forced on people, case
  the group performance to go down so much the _manager_ should be fired if
  he doesn't clean up.

  Lisp programmers are generally more expensive than C++ programmers.  (I
  don't know the Java market.)  quite often, a project can succeed with one
  or a tiny group of expert Lisp programmers (you just don't do Lisp for a
  living if you aren't an expert¹), but would require a large group of
  average C++ programmers (the C++ experts are more expensive than almost
  all Lisp programmers).  and as we all know, group interaction is a _cost_
  that increases with the number of members in the group, so the less talk
  you can get away with, the better.  this means style is _very_ important.

¹ it takes _much_ less to become an expert in Common Lisp than in C++.