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?