This is kind of reminiscent of LDAP, which was once a simplification
of X.500, but is now probably much more complicated.

I imagine many people make their entry into the LISP world via Emacs.

Regs, Pierre.

PS: Of course everyone who has driven both ways knows that driving on
the left is intriniscally better ;)

Or are you saying that people knowing Lisp are less likely to learn a new
language than, say, people knowing C++, all other factors being equal?

I'd say, if you don't emphasize "all other factors being equal", any
ancient language (FORTRAN or Lisp that is) is likely to be your last :)

  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

  No.

| Or are you saying that people knowing Lisp are less likely to learn a new
| language than, say, people knowing C++, all other factors being equal?

  No.

| I'd say, if you don't emphasize "all other factors being equal", any ancient
| language (FORTRAN or Lisp that is) is likely to be your last :)

  You tire me.

--
Erik Naggum, Oslo, Norway

  Behave yourself.  Personal messages of this caliber should not be posted to
  a public newsgroup.  I did not attack you, so there is absolutely no excuse
  for your out-of-control emotions to bother anyone else.  When you receive
  criticism, listen to it and pull yourself together if your emotions run amuck.
  Realize that you may tire people and do something constructive about it
  instead of behaving even /more/ like a fucking moron, even if it makes you
  feel better for having taken revenge for your inability to deal with what
  another person has told you.  Such primitive behavior does not belong in
  public.  If you still feel like displaying your lack of intelligent coping
  strategies, write a scathing message so you feel better, then do not post it.

--
Erik Naggum, Oslo, Norway

Took up programming in 1986 (age 8). BASIC, Pascal, Z-80 assembler.
Later C.

Computer Science student since 1997. Discovered Common Lisp (via elisp) the
same year.

Using CMUCL and CLISP on Debian GNU/Linux, for educating myself and for
smallish personal projects.

It is not obvious that use of \i{foo} (or {i foo}) is always better
than use of <i>foo</i>. In TeX and LaTeX, for example, once the scope
gets "too big", a switch is made to the \start{}...\stop{} way of
doing things. While redundant, it helps in catching the types of
mistakes people (as opposed to computers and geeks) tend to make.

You make some misleading remarks with your (+ 2 2) vs. 2 + 2 example.
(+ 2 2) can certainly appear in a scope that modifies it to mean any
number of things other than 4. The difference between LISP and
Algol-like languages (say, C) here is that in C it is usually quite
easy to determine where the enclosing context that might affect the
expression starts and stops (assuming this is not a string/remark/etc,
you can limit your reading to the area between the previous and next
semicolons, for example). This cannot be said about LISP.

I probably won't be able to extricate myself from such a dual existence
for a while. In the meantime, there is always study.

    Oleg> Funny, but flawed analogy. There is a perfectly good reason for everyone to
    Oleg> agree to drive on one side of the road (to avoid collisions). What's the
    Oleg> reason to enforce proper nesting? Not having to do proper nesting can save
    Oleg> space.

    Oleg> Oleg
    Oleg> P.S. I just thought of something: only countries with roads not leading to
    Oleg> other countries drive on the left.

I think there's a road going from England to France now.

  This is a good point, but my counter-argument is that your editor should
  make these things easier for you if the element contents becomes too large.

| You make some misleading remarks with your (+ 2 2) vs. 2 + 2 example.  (+ 2
| 2) can certainly appear in a scope that modifies it to mean any number of
| things other than 4.

  Sure, but you will prove my point when you demonstrate the magnitude of the
  work involved in making alternative interpretations.

| The difference between LISP and Algol-like languages (say, C) here is that
| in C it is usually quite easy to determine where the enclosing context that
| might affect the expression starts and stops (assuming this is not a
| string/remark/etc, you can limit your reading to the area between the
| previous and next semicolons, for example).  This cannot be said about LISP.

  Sorry, but this is nonsense.

--
Erik Naggum, Oslo, Norway

The issue would most _certainly_ get pointedly political, as England
and France have been known to be adversarial empires, over the
centuries, and commonly get really snippety about the handling of this
sort of thing.

Hazarding a guess, I'd be totally unsurprised if the "Chunnel" traffic
were arranged in vertical layers, so that there wouldn't be any "left"
or "right" in the tunnel.  If there were two lanes on a particular
layer, both would be travelling either towards France or towards
England.  And the "parity" of the lanes would get managed at the ends,
with big irritating signs saying things like:

  "Entering England: Fromage-Eaters be aware you will enter on the
  LEFT side of the road.  Don't get it wrong, you frogs..."
     and
  "Bienvenue a France!  Ici on conduit les automobiles vers le droit!"

I will still use Perl for the small utilities & one-liners .Perl
developers have a treasure chest named CPAN, that
helps us do practically everything administrative-oriented
very fast.

It seems that a long time will pass until I lear to write
really efficient Lisp programs, so for performance-critic
applications, C++ is still my tool.

But I will do my best to write anything complex in Lisp,
as its beauty cannot be discarded. I wonder whether I
could acknowledge CL's enormous advantages if it was my
first language, and I hadn't seen how hard it is to do
the really complex things with traditional imperative
languages.

I think Lisp is clearly increasing in popularity.  Many of those who
turned down lisp (for perhaps good reasons) are fading away or
changing, and so are the dot-commers.

I'm self-taught; I went into the industry because I was able to help a
friend debug without knowing how to program, and things ballooned from
there.  The problem was that the stress was intense -- I programmed
C-style languages, and it was so ugly and imprecise.  I had the
feeling that there was some foundation underneath that made everything
simple, like Gödel Escher Bach alluded to, but I started believing
that it was just a dull, messy hodgepogdge of random ideas.

Then I started sniffing around Lispish languages, but found SICP to be
still a level above what I wanted.  There was still too much hidden.
Then I happened upon the following simple article about lambda
calculus,
and I felt happy that I had a good base to foresee things that SICP
mentioned:
http://216.239.39.100/search?q=cache:SE1obPoknssC:www.mactech.com/art...

I'm still wondering BTW, if there's a further level below.

Oddly enough, I've stopped minding programming in languages like Java.
 I accept their limitations; I program von Neumann machines with them.
 Big deal; I can always make a macro or use Jython.  I'm fast now.

BTW, this speech from Backus pushed me over the edge, along with KMP's
Slashdot interview and Paul Graham's (slightly insulting, but fun)
preaching:
http://www.stanford.edu/class/cs242/readings/backus.pdf