Subject: Re: LISP and AI
From: Erik Naggum <erik@naggum.no>
Date: 2000/05/12
Newsgroups: comp.lang.lisp
Message-ID: <3167114384690645@naggum.no>

* David Thornley
| So I would design a personal environment, which might include a
| dictionary, encyclopedia, atlas, and the Hyperspec to read things
| in a context?  

  Yes, but also including your own comments on things you had read,
  other people's comments, and probably news wires and mailing lists
  that supplied interrelationships in the form of third-party links.

| So I could write something like "These links of Naggum to Norvig..."
| or compare the Naggum and Pitman links?

  Yes.

| Attempted summary of a very large snipped part:
| The problem is not HTML, but the fact that HTML is very basic.
| It is hard to think of doing some of these things in HTML.
| Similarly, Intel machine language is not a problem, but it is
| a good thing that there are compilers for other languages.
| It is possible for a Lisp programmer to do things that are very
| difficult for an assembly language programmer, and more specifically
| is likely to think of things that an assembly language programmer
| would not.

  A compiler is a also good starting point for a comparison, but I
  tend to think of HTML as the PostScript of real hypertext -- the
  language of the renderer.  It would be possible, but fairly time
  consuming and very difficult, to write anything directly in
  PostScript, so people prefer markup languages like LaTeX or SGML
  that "compile" to PostScript or WYSIWYG tools that constantly
  recompute the rendering.

  Note, however, that a compiler is still limited as a comparison to a
  fixed number of source files.  The crucial element in my argument
  against HTML is that there is no way to "load" third-party links or
  rules into the rendering environment from other documents.  At least
  PostScript has that -- you can download functions and modify the
  printer's behavior.  None of the "dynamic" features smacked on top
  of HTML manage to get any of this right.

| Therefore, it would be possible to write a real hypertext language
| that would process numerous things and deliver the result to the
| browser in HTML, much as it is possible to write a Lisp program and
| compile it.

  Yes, _provided_ that it is done sufficiently close to the reader
  that the _reader's_ experiences and context can influence the HTML
  that the browser sees and displays.  This requires _very_ powerful
  proxy servers and a "visual" recognition of the HTML that is being
  transmitted from various places.

| This has not yet become mainstream because most people don't see the
| desirability, much as most assembly language programmers would not
| see the desirability of being able to write functions that work with
| data types to be determined later.

  I think it is not yet mainstream because people _fear_ hypertext
  before they know how to navigate in it -- and with good cause, too.
  The navigation problem on the Net is basically unsolved, but tools
  that could remember and deal with your own set of links would help a
  lot, and those would have to be maintained as third-party links in a
  sort of "active history", able to answer the question "now, what did
  I come here to look for?", which is both unasked and unanswered
  today.  But convincing people that something conceptually more
  complex is a simplifier is very hard marketing work.  (Just ask the
  Lisp vendors. :)

| Is this a reasonable summary of what you're saying?  (I do not think
| that either of us is stupid, or inept in the use of the English
| language, so I figure that this has to be potentially difficult
| concepts to convey.)

  FWIW, I'm pleased with your understanding of what I've been trying
  to explain for years with admittedly limited success (hence my "I
  don't have the patience for this" which was rudely overruled :).

#:Erik