Subject: Re: The Next Generation of Lisp Programmers
From: Erik Naggum <erik@naggum.no>
Date: 26 Aug 2002 02:08:08 +0000
Newsgroups: comp.lang.lisp
Message-ID: <3239316488198320@naggum.no>

* Oleg <oleg_inconnu@myrealbox.com>
| Who said proper nesting is intrinsically a good thing, silly rules made up 
| by mortals notwithstanding?

  It is not the proper nesting that is the problem.  It is the infinitely stupid
  separation of start- and end-tags.  If you wrote @bold{foo} instead of
  <bold>foo</bold>, you would not even /want/ to say @bold{foo @italic{bar}
  zot} if you expected to get foo in bold, zot in italic, and bar in both.
  The stupidity of <bold>foo<italic>bar</bold>zot</italic> is not in nesting,
  it is in the moronic syntax.  I related my discovery that syntax matters
  when I had worked with SGML for half a decade.  It is because of the stupid
  syntax of SGML that things turn bad when people try to use it.  It is not
  because of some highly abstract concept such as proper nesting, which people
  do not, in fact, understand without serious mental effort.  (The reason many
  people do not understand Lisp but prefer multiple layers of different colors
  and shapes as they move up the abstraction ladder is very closely releated
  to this.  In nature, things that really are the same look different to us
  because we have a really hard time abstracting away physical size, and it
  sometimes takes genius to discover the counter-intuitive role that /scaling/
  has in human understanding.)

  The otherwise pretty smart people who dreamt up generalized markup (which is
  itself an important abstraction that few people have made independently)
  made a very serious mistake in making "tags" independent constructs of the
  element.  Yes, abstract elements have starts and ends, but it is a serious
  mistake to make both sides verbose and explicit.  (The reason many people do
  not understand Lisp but prefer murky syntaxes where the edges are intuited
  instead of made explicit is also related to this lack of natural ability to
  deal with explicit edges.  We seem to prefer the wrong kind of simplicity
  naturally, or find the wrong kind of simplicity too rewarding at too early
  an age, and people who refuse to think about things tend to go very wrong.
  For instance, people generally think that 2+2 is 4.  But it is not.  It is
  only when this expression is explicitly delimited from side-effects that
  the simple folk understanding holds.  (+ 2 2) is always 4.  In 3*2+2, 2+2 is
  definitely not 4, and it would be wrong to think about 2+2 to begin with.
  Most people wil recognize that the edges have moved in this expression, but
  fail to understand the power of explicit edges because they think they can
  always see them, just like stupid people for /ages/ (not just after computers
  arrived on the scene) have thought that they could omit the century in dates
  because nothing would ever last longer than 100 years.  Old and ancient works
  of art often contain the day, month, and year of the century, but you have
  to make some highly educated guesses as to which century because stupid
  people have thought the edges of the century needed not be specified.  It is
  wrong to give stupid people the means to hurt themselves.  Verbose, explicit
  start- and end-tags can only cause harm when stupid people use them, and
  when it comes to entering text for text processing applications, otherwise
  smart people often turn into vegetables because they think the problems that
  text processing presents are /stupid problems/ that are below them.)

  When you give people verbose, explicit edges of elements, they will think of
  them the wrong way.  It is not proper nesting that they do not understand.
  It is the fact that they see a kind of different edges than the syntax wants
  to represent.  This is not a problem unless you are anal-retentive about a
  different kind of edges.  If you wanted to make proper nesting work, you
  would make it very, very hard to make mistakes, such as by using the exact
  same terminator of all elements and make sure that you could not possibly
  mistake a start or end for anything else.  If you want people who see the
  wrong kind of edges to learn to deal with it, you must present them with an
  incentive to do so, not an incentive to break your rules.  This is how syntax
  matters.  This is why people do amazingly stupid things in languages with
  ugly syntaxes and behave rationally and write more elegant code when the
  syntax is more elegant.

  I find it ridiculous and evidence of a massive lack of understanding of the
  world they live in when someone argues /in a newsgroup for Lisp/ against
  proper nesting as intrinsically a good thing.  Of /course/ proper nesting is
  intrinsically a good thing!  It is simply how things are structured in this
  world.  If you fail to understand this, what /are/ you doing with Lisp?

  However, when it comes to font changes in documents, there is no point in
  making the edges visible to the user exactly as found in the /underlying/
  structure.  I write *bold* and /italic/ and _underline_ and `fixed´ in Gnus,
  for instance, and I think this is the right thing.  Whatever the underlying
  representation, the user interface can do me the favor of showing me bold
  and italic and special characters properly.  There is no point in forcing
  this on people, just as one would normally store a paragraph as one line of
  text, but show it as broken at the right margin by word boundaries.  Then,
  whatever the proper way to represent bold and italic internally, the user
  would not need to be aware of it.  WYSIWYG works great for the lowest level
  of information structuring, where we have become used to visual clues.
  Punctuation, capitalization, italics, paragraph breaks, etc, all live at the
  same conceptual level -- different from almost everything else.  It is wrong
  for a markup language to force people to do weird things at this level.

  If you /understand/ proper nesting, there is no problem.  If you do not want
  to understand it further than you already have, that will be evidenced in
  the choice of a verbose end-tag and tags that close at the wrong point as
  seen by the user.  Whether you use \i{foo} or @i{foo} or <i foo> does not
  matter much, but using <i>foo</i> is a major disaster as far as teaching the
  users the value of structuring information is concerned.

  In many important ways, SGML is its own worst enemy.  It has managed to
  teach information structuring completely backwards.  Instead of making the
  edges explicit but non-intrusive as in Common Lisp, the edges are much too
  visible and verbose with the stupid tags that very quickly consume more of
  the large volume of characters in SGML/XML documents than the contents.  I
  am sure it was thought of as useful back when people needed to be converted,
  but once converted, it gets in the way more than anything else and leads
  people to make mistakes if they do not think very carefully about what they
  try to do.  Most people would rather die than think, in fact, many do, so if
  one wishes to teach information structuring, it must be made conducive to
  accomplish people's fairly immediate goals.  SGML fails miserably in this
  regard.  Once you understand the concepts, SGML is harder than any of the
  alternatives.  And if you do not understand the concepts, SGML is harder
  than any of the alternatives.  Only when you are beginning to cross the
  border between not understanding and understanding does SGML offer something
  of significant value -- that is, as long as you think all these tags are
  kind of cool and typing markup is great idea.  This interim stage should
  pass fairly quickly unless you are working specifically with the languages.
  (That was my excuse...)
  
-- 
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.