Conference turris::languages

Sounds like a good idea. Maybe more people would be encouraged to learn
it then!

Jack

There is a programming language that provides the list-processing
features of LISP and substantial string handling abilities, with
graphics thrown in.  It was specifically designed for teaching
programming to children, so it has "English-like" keywords.  The
language is LOGO, of course, and you should take a look at it.
(Look at the *language*, not at one of the hack pc implementations,
which often throw away everything interesting to make it fit on a
micro.)

LISP isn't a language, it is the ABSENCE of a language.  It has an extremely
awkward syntax that stems from the reluctance or inability of its designers
to design a reasonable syntax.  Its only redeeming features are its 
simplicity, making it easy to learn, its implementations (interpreters) which
provide an easy to understand "environment" for beginning users, and its
machine-independent memory management.  A new advantage is becoming apparant 
also.  Since pure lisp allows no assignments (e.g. this note's title), it
is "applicative", which means that it can easily make use of multiple 
processors without needing to worry about synchronization.  This is a real
intellectual advantage, although it is problematical whether it is a practical 
one.

Its disadvantages are:

1) It spite of its widespread use, its programs are frequently non-portable
because of their incestuous use of implementation dependent features.

2) The programs are virtually unmaintainable because of its awkward syntax.

3) Since it disallows iteration (except in extended implementations), most
algorithms must be cast in recursive form, thus leading to extreme slowness
and inability to implement efficient algorithms.


It is widely quoted that LISP is widely suited to "artificial intelligence
applications".  I claim (flame) that this is just because people interested
in artificial intelligence are too lazy to learn a REAL syntax.  Admittedly,
after you learn it, you can probably prototype list-type applications fairly
quickly, but that is also true of several other languages, most of which don't
have the disadvantages cited above.
					-Kevin

	I agree with most of response 3, but not with the bit about
	"extreme slowness" of recursive algorithms.
	This is an old myth dating from the 1960s, when computer
	architectures didn't always provide for efficient implementation
	of recursion. Now, they all do. There is no appreciable
	performance penalty for a decent compiler generating code
	for a decent architecture.
		(In case you wondered, no I don't think the CDC6000 series
		 has a decent architecture)
						Nick

I've always thought that syntax was an undesirable in languages.   Why should
I have to bother with a syntax?

You seem to miss all the advantages of LISP and degrade it because it's
not a language like FORTRAN.

AMONG the advantages of LISP are:

1.  It's data representation, which is more appropriate for the kind of things
    AI people do than anything offered by FORTRAN or nearly any other of the
    various 3rd generation languages.   Thus LISP is a perfectly appropriate
    choice for people doing AI.

2.  LISP is a totally functional language.  It does have a syntax, a very
    simple syntax for a function call (fn arg1, arg2, ...).  That's all
    the syntax it needs (or wants) because evaluating functions is the only
    syntactical concept the language has.  If you want more syntax, use ada.
    ada has enough syntax to keep you happily busy for years.

3.  Interpretive languages have advantages, although just like compiled 
    languages, they aren't sufficient for everything you might ever want to
    do.  Interpretive languages are interactive.  We at DEC have long realized
    the advantages of interactive systems.  Much of these advantages apply
    to languages as well.  Interactive languages are more conducive to
    experimentation, modification, and have been demonstrated to be more
    productive.

Your comment about the maintainability of LISP is questionable.  I think
function oriented languages are inherently more maintainable.  Most of the
objection to LISP and APL I've heard is really a complaint about the
readability, and it always comes from people with little experience in
the language.

I'd also point out that maintainability is not always a high priority,
particularly in AI.   AI people are usually trying to model an idea, not
sell a product that is maintained.  Maintainability has almost zero priority.
They are looking for a language that allows them to efficiently produce
models in a prototypical fashion.

	db

Dave:
	How does one "do AI"? No, LISP is not always the most appropriate
language for AI applications (by the way, what's the definition of AI?)
I spent one summer working in England at ICL's research center doing work
on a parallel array processor (called DAP). I designed and implemented an 
AI program having to do with vision and pattern recognition - certainly an
AI application. This program was written in FORTRAN. It was the best 
language to use for that program on that machine. LISP would not have been
appropriate at all!

	Also, you say that most of the objections to LISP (and APL) have to
do with its readability, and they always come from people who have very little
experience with the language. I would venture to say that most people who
write in LISP now had some amount of difficulty with its readability - i.e.,
matching up the parentheses, etc. But, then again, I would venture to say that
a lot of people have been turned off to the language because of its parentheses.
Just as people are turned off to APL by its "funny symbols". Note: I am not
trying to put down APL as a language. It has its good points, just as it has
its bad points.

Kevin:
	You say that people in AI are too lazy to learn a "REAL" language.
Just what is a real language? I take it that FORTRAN is not a REAL language,
because I used to be "in AI", and I programmed in FORTRAN, Pascal, C, etc.
LISP certainly isn't very good for modeling parallel arrays, so I used FORTRAN.

Jack

I don't think I said (nor implied) that LISP was ALWAYS appropriate.

LISP is not only an interpretive language.  There is a compiler.  If you
want to develop code fast, stay interpreted.  When a function works, compile
that function (while in the interpreter) and things run faster.  Yes, you
can compile files too...

The parentheses are only a pain in the absence of good support tools.  An
editor that matches parentheses and a pretty printer are essential for
serious work.  I've noticed that the incidence of complaints about paren
errors in my current group is much lower than the incidence on complaints
about BLISS dot errors in every group I've been associated with at DEC.

The advantage of Lisp's minimal syntax may have been best stated by Joel
Moses:

	"APL is like a diamond.  It's perfect.  If you change it in any
         way it is no longer either perfect or a diamond.  LISP is like
         a ball of mud.  You can do anything to it and its still a ball
         of mud."

			(paraphrased from memory)

Many people don't solve AI problems in LISP - they invent a language which
is designed to solve their problem, implement the language in LISP, and
solve the problem in that language.  The new language may be anything from
a moderate extension of LISP to a totally new language with no LISP features
available.

As AI has progressed, it is becoming increasingly obvious that NO one
paradigm is likely to provide the total solution to large problems.  One
way of attacking such problems is to pull several tools, say a Truth
Mainenance Systen, a Rule Based System, and a Frame System, it your
LISP environment and glue them together with LISP.

							dan

Or Pascal. Or C. Or BLISS. Or ...

Any decent lisp has 
	an environment with editor so you can take advantage of the interpreted
		part of the lang
	a very powerful macro facility so you don't have to live with any of the
		stupid syntax you don't like.  This includes iteration, if then
		else, case, "do for all elts in list" etc.
	a compiler so you don't have to be interpreted all the time.

Lisp wins often because data structures are very simple and complete, and 
because the reader can save you from all kinds of REALLY STUPID details such
as end of file.  One of the real problems with it is that due to older
implementations being done on non-useful operating systems (e.g. utlisp on a
slobber (cdc cyber)) comments are often an extension.  That loses.

Lisp has very good vector operation expression via mapcar.

Parallel eval of args is problematical unless you're sure about side effects.

I've written many programs in lisp that had nothing to do with ai at all.  They
include a tape reader (read a vms tape on unix), address and instruction trace
analyzers, and check book programs.  There is nothing in lisp that makes it 
unmaintainable, and in fact the existance (typically) of debugging tools that
are at least a decade ahead of the typical vms things makes it a lot easier.

If you want to extend human use of computers by having experts write neat
programs, tearse wins.  Tearse <> cryptic.

"Tearse" is correctly spelled "terse".  Otherwise, I agree.  People
who make statements like "LISP is interpreted, hence slow" and "LISP
doesn't have iteration, you have to recurse" and "LISP makes you
count parentheses" are judging LISP by ancient implementations.
It's much the same as saying "I don't like cars because you have
to start them by turning a crank."

When I first learned LISP I found it interesting, both because of the
language itself and because of the types of problems I was trying to
solve with it.  I was like a game, much like primitive recursion problems.
However, I must add that I liked Latin (language of the Romans) also,
and studied it for 6 years.  Latin and LISP have something in common.
Neither is intrinsicly difficult or impossible to be read and written.
But, since they are so different from the mainstream, their following is
small.  Don't ever expect LISP to become a BASIC.  If you know it, and can
write fine code in it, fine.  The LISP tools, like Latin trots (translations),
help alot.  Any language without a good debugger is really a pain.
When people say LISP is not easily maintained, that means that it is not
understood well by enough people to grab someone and say "here fix this
bug".  Of course it is obvious that if you know it, it is easy to maintain.
When I did Latin homework everyday for 2 hours I was a wiz.  However,
unlike riding a bike, I forget most of my Latin and LISP.