Subject: Re: Comments, was Re: Parentheses Hierarchy
From: Erik Naggum <erik@naggum.no>
Date: 1999/07/24
Newsgroups: comp.lang.lisp
Message-ID: <3141842096510426@naggum.no>

* Samir Barjoud <samir@mindspring.com>
| The benefit, as I see it, of "READable" comments is that it would enable
| a programmer to work without files of source code.  Comments are the only
| information (other than whitespace) lost upon READing.  If comments were
| READable, than evaluating a bunch of definitions would be as good as
| saving them into a file.

  consider a READ function that returns data useful to the Lisp system.
  consider a READ function that returns data useful to an editor of Lisp
  code.  now, why would these two functions have to be the same?  instead
  of making comments part of the core Lisp representation, realize that
  during the writing code, some of the time, the syntactic structure of the
  code will be invalid.  structure editors are a pain, pure and simple, and
  if you had used them, you would know, but if you haven't used them, you
  only see their good sides because the pain is non-obvious.

  editing is task that is not well understood.  look at Word, with billions
  of dollars of research and development having gone into it, and it still
  is a piece of crap.  look at Emacs, with incredible amounts of time and
  work having been poured into it by sometimes brilliant people, and we
  still don't quite understand what helps people write fast and correctly,
  and many serious mistakes are yet to be made, especially as people cling
  to the stupid window-icon-mouse-pointer technology as if it were good in
  itself.

  representation-wise, however, there are some clearly advantageous lessons
  to be learned from the editors of the past: (1) navigation is the single
  most important property of a good editor.  (2) aiding and abetting
  authors with the nitty-gritty details without undue interference makes
  them _really_ happy.  (3) don't ever mess with the user's actual textual
  formatting -- if the editor gets it wrong, user frustration reaches
  record heights if the editor reverses the corrections.  getting these
  three issues right means we need to keep track of a lot of context and
  information, and it just plain doesn't work to do it with simple-minded
  data structures and semi-intelligent searching operations.

| Such a lisp system really seems appealing.  To edit a function in such a
| system you would check it out (function definition printed from lisp
| memory to editor buffer), modify it, and check it back in again (evaluate
| it).  Or you could check an entire package out.  The system could also
| handle version control on its own.  A dumped image could be considered a
| version control snapshot.

  you know, the SGML people wanted exactly the same thing a few years ago,
  and I'm not exaggerating when I say that users hate it.  the single most
  important reason users hate stuff like this that they aren't allowed to
  break the rules at any time.  and the reason for that is that if you let
  them break the rules, you need to be very, very smart to manage to get
  back in line.  I don't think it's wise to ignore these issues from the
  point of view of "structured" document editors.  feel free to repeat
  their experiment, however, but please see what they did and make sure
  that you don't repeat mistakes of the past.

#:Erik
-- 
  suppose we blasted all politicians into space.
  would the SETI project find even one of them?