I'm trying to understand what it is that people like about LISP and whether
I should learn it. (I'm interested in AI)

Could somebody offer an example of a short (a few Kb or less) program in
LISP that does something useful and that would be relatively hard and
time-consuming to program in C++? (aside from such built-in niceties as
arbitrary-precision arithmetic please)

Thanks

  After you have written and debugged and deployed several hundred thousand
  lines of code in languages X, Y, and Z, and then find yourself shouting
  "there's _got_ to be a better way than this!", Common Lisp replies "you
  called, master?"  What I like about Common Lisp is that it takes care of
  90% of the boring details for me that I have had to deal with in every
  other language I have used.  Lisp is all about this delivery from tedium.
  (Hence, Scheme is not a Lisp in my view.)

  Incidentally, "LISP" is generally taken to be the pre-1980 typewritten
  manuscript rendition of the small caps tradition that was used to print
  acronyms nicely and without making them stand out like sore thumbs from
  the page.  This tradition has largely been superseded by initial caps and
  the rest lowercased.  So what an HTML-based author would write as
  <small>LISP</small> is now just Lisp.  You date yourself (or your
  sources) back at least 20 years when you write it in all caps.  Even
  Fortran and Cobol are written like words, now.

| Could somebody offer an example of a short (a few Kb or less) program in
| LISP that does something useful and that would be relatively hard and
| time-consuming to program in C++? (aside from such built-in niceties as
| arbitrary-precision arithmetic please)

  The real niceties are invisible to C++ programmers, because they would no
  more look for them than an illeterate would consult encyclopedia to learn.
  It is impossible to see certain things until you have been alerted to
  their existence, and such alerts cause too much cognitive dissonance
  among people who do not believe it can exist to work without experience.
  The way to get into this is just to read textbooks and the specification
  and to experiment with unexpected concepts.  Small examples will largely
  not work, because most of the features work best with larger projects.
  Anybody can create small nice things.  Creating large nice things takes a
  different approach entirely.  Common Lisp excels at the latter, sometimes
  regarded as a problem since most programmers start off with exceptionally
  small things and think they can grow a small cottage into a skyscraper
  simply by scaling it up and adding stuff to it.

  This is not to say that Common Lisp does not have its share of small
  programs that do useful things, but every time someone tries to answer
  such a question, C++ people crawl out of the woodwork to show that they
  can do it, too, like some paranoid and hypercompetitive athlete afraid
  that someone, somewhere, is good at something.  Language comparisons are
  largely only annoying.  Better learn the new language.  Yes, you should
  learn Common Lisp.  (Do not bother wasting your time on Scheme.)

(1) You can play with Lisp instead of reading about it (one good thing
about Lisp) and

(2) you can explore a not so new dataflow paradigm I stumbled on
independently while just doing neat stuff with Lisp (one bad thing about
using Lisp commercially is that any sufficiently complex project will
lead a Lisper to hack up a pet package and lose all interest in the
original project).

btw, I like: standard, compiled, fast, mature, interactive, closures,
macros, GC, CLOS, restarts in the backtrace, MetaObject programming,
single typespace (no Integer vs. int ala Java),special variables, all
the built-in functions, automatic formatting of code, the #$%^#%(
package system and logical naming scheme, AND THE GODDAMN PARENTHESES!
OK?!!

sorry.

:)

kenny
clinisys

  [1]> (load "othello.lisp")
  ;; Loading file othello.lisp ...
  *** - FUNCTION: undefined function SYMBOL
  1. Break [2]> backtrace

  EVAL frame for form #'SYMBOL
  EVAL frame for form (CROSS-PRODUCT #'SYMBOL '(? A B C D E F G H ?) '(? 1 2 3 4 5 6 7 8 ?))
  EVAL frame for form
  (LET
    ((SQUARE-NAMES
        (CROSS-PRODUCT #'SYMBOL '(? A B C D E F G H ?) '(? 1 2 3 4 5 6 7 8 ?))
    ))
    (DEFUN H8->88 (STR) "Convert from alphanumeric to numeric square notation."
      (OR (POSITION (STRING STR) SQUARE-NAMES :TEST #'STRING-EQUAL) STR)
    )
    (DEFUN 88->H8 (NUM) "Convert from numeric to alphanumeric square notation."
      (IF (VALID-P NUM) (ELT SQUARE-NAMES NUM) NUM)
  ) )
  EVAL frame for form (LOAD "othello.lisp")

Huh, he seems to think there's a function named SYMBOL.  If I'd read
the book, maybe I'd understand why (*ahem*).  But let's try this:

  [noc@malatesta foo]$ grep -rni "defun symbol" *.lisp
  auxfns.lisp:222:(defun symbol (&rest args)

Okay, so it looks like he's got some auxillary functions.  Let's load
them then try to finish loading othello.lisp:

  1. Break [2]> (load "auxfns.lisp")
  ;;  Loading file auxfns.lisp ...
  ;;  Loading of file auxfns.lisp is finished.
  T
  1. Break [2]> redo
  ;; Loading of file othello.lisp is finished.
  T

However, I imagine you'll get a lot more from it if you read the
chapter in the book along with playing with the code.  If you live
near a good library, they'll likeley have it (note the slightly
tautological usage of the word "good" ;)

  Well, I basically said as much.  You are facing some counter-information
  to your previously held beliefs and your reaction is known as cognitive
  dissonance.  Unless trained to deal with this feeling, it appears from
  the literature that "most people" will reject the counter-information out
  of hand, rather than investigate _why_ they think it is wrong.  I tend to
  regard contradictions and counter-information as a signal to re-evaluate
  what I thought I knew to be correct, and try to understand how both may
  be correct at the same time because they exist in different contexts,
  thus perhaps telling me something important I did not know previously.

  Since there are also a large number of idiots out there who have no idea
  how to deal with either information or counter-information, but instead
  believe only that which causes _no_ cognitive dissonance, which applies
  to the _first_ piece of information in any suitably narrowly defined
  area, or that which some suitably irrational authority tells them, there
  will be a lot of people who produce counter-factual disinformation which
  looks very much like counter-information, thus wasting people's time with
  their craploads of nonsense.  This is extremely annoying, and the habit
  of "most people" to ignore that which causes cognitive dissonance may be
  a good defense mechanism against the usual crapload of desinformation
  that we are exposed to, but it is not a good thing for an engineer or a
  scientist or an investigator of any sort of truth.

  Take a good look at my .signature and try to accept that what you have
  yet to learn will always out-volume what you know.  It is therefore much
  more important to determine whether what you already know is false than
  to "confirm" that it is true or just to assume that it is.

  C++ fails at its goals.  This is hard for C++ programmers to accept, but
  evident to everybody else.  Common Lisp succeeds at its goals.  This is
  harder for C++ programmers to accept, but unfortunately evident only to
  past and present Common Lisp programmers.  As life is too long to become
  an expert at C++, so those who have invested the effort tend to want what
  they believe to be true, regardless of the effort required to make it so.

  Learn Common Lisp.  Get into its spirit.  It will change you, so you have
  to let it.  Resist the temptation to write C++ in Common Lisp.  Absorb
  the language and the environments you get access to.  Start with one of
  the commercial offerings.  I recommend Allegro CL from Franz Inc
  (www.franz.com), but others think others would recommend LispWorks from
  Xanalys (www.xanalys.com).  The commercial offerings are so much better
  for learning the language than the free offerings, which currently lack
  good development environments.

| Besides, small is beautiful.

  It is actually the other way around: Anything is beautiful when small.
  The hard part is making something larger be beautiful.  This is where
  most languages _really_ suck, which is why they want small examples.
  Please think about the analogy to building a skyscraper by starting from
  a small cottage.  Or think about scaling an ant up to the size of an
  cougar (one of the most beautiful animals I know), or an elephant.

Wroot, I wonder, have you _worked_ on a large project in C++?  Or even
just a medium sized one?  The largest project I worked on in C++ was
in the 500,000 LOC range (20 programmers for 18 months, and would
be considered "medium size" in the industry.)

It was _hell_.  Hour long compiles, straight-jacket design to insure
interfaces don't break every day, mind-numbing debug sessions finding
out where some moron^H^H^H^H^H lazy contractor was obliviously trashing
the stack... well, I could go on, but you get the point.

I now believe that that project could have been completed, more successfully
(give C++ credit, we succeeded!) with 4-6 good lispers in < 12 months.

HOW in the world is C++ helping large projects and re-use?  I'll give
you a hint: there's no tool vendor selling Purify(TM) for CL.  In fact,
there's an entire _slew_ of those bogus "helper" tools aimed at the C++
market (e.g. http://www.parasoft.com/).  You'd think _somebody_ would have
figured out that if you need all this extra help, perhaps there's a better
way?  But, oh, I remember, that involves _thinking_.  Pass.

That crowd is _finally_ moving to Java, so there's hope!  In a decade,
they may yet learn about macros.  In two decades, they may discover
the MOP.  Meantime, take my word for it: life is just _too_ _short_.

Learn CL, you won't regret it.

Would you do me the courtesy of telling me what is the largest
C++ project you have personally worked on?  Thanks.

It's object system is far more powerful and MUCH easier to use. All the
generative and template meta-programming that is considered so cool and modern
in the C++ community is already old stuff in CL, and several orders of
magnitude easier to use. In lisp it's not just cool, it's _feasible_.

Take the time to learn lisp, it's a great tool to add to your toolchest. Make
sure you learn CLOS (the object system) as well as macros (templates on
steroids).

There are thousands of Common Lisp programmers, using at least 4 high
quality commercial Common Lisp IDEs, and a number of free compilers.
There *is* a market for tools here. The fact that there are no
"helper" products follows from the fact that they are not needed,
because the language (Common Lisp) is not broken at the design level
in the way that C++ is.

In contrast, if the painfully obvious still needs to be pointed out,
there are no helper tools for D, because practically no one uses D,
there are not 3 thriving Windows implementations of D (as there are
for Common Lisp), there is no high quality commercial D IDE for the
Mac or Linux (as there are for Common Lisp), there is no comp.lang.d
newsgroup, etc. etc.

You said: "If there is no helper software, then it is good". A common
fallacy, but nevertheless wrong.

BTW, there is an excellent book, by Lakos, on designing large C++ systems.
The amount of planning and care involved to succeed in such an endeavour,
and the fact that it needs to be so painstakingly explained [this is a
_very_ didactic book, thank God] _shows_ that C++ could not have been
"designed with large systems in mind".

On another note, I was shocked to read in another thread that Bjarne
didn't understand the difference between a language specification and
implementation, and that's why we now have C++.  I'll now have to read
"The design and evolution of C++", just out of morbid curiosity.

Can you imagine if all these hordes of programmers had instead been
working on an efficient, souped up simula instead?  Gee... MicroSoft
might have never happened.  :-)