BIG successes of Lisp (was ...)

[Adam Warner]

Hi Lulu of the Lotus-Eaters,

Lisp because of misconceptions, and threads like that |help dispel
those.

In my own mind, the biggest impediment to really liking Lisp is not the
annoying parentheses and awful syntax... it's many Lispers (especially
those like Tilton).

Sure David. Please don't make this personal as some may be less gracious
in overlooking your failings to even post correctly indented
Python-the-language code when arguing against Lisp and its syntax:
<http://groups.google.com/[email protected]>

Can't even insert four spaces without destroying the semantics of your
code three times in a row? I note you didn't later acknowledge the three
flaws, which indicates that you still couldn't see them when reviewing
your code:
<http://groups.google.com/[email protected]>

You may have more numerous libraries and a larger set of groupies but you
will never have the satisfaction of using a superior language. Please let
me know if this response makes me a shining example of a "truly vindictive
and nasty" Lisp user. Posters to comp.lang.lisp are extremely likely to
receive polite and extraordinary help. For a long time all newbies to
comp.lang.lisp could expect to be humiliated. That time has passed.

Regards,
Adam

 

[prunesquallor]

Google ate my long post, so I'll make it simple.

Lisp failed (yes, it did) because of the parentheses. Normal people
can't parse 13 close-parens easily. Functional notation is
non-intuitive and hard to read.

Damn, but I wish we'd noticed that! It would have saved us such
trouble. Who'd have thought that it was something as simple as
parenthesis?

I'm really surprised that McCarthy didn't realize this and invent some
sort of meta-language for lisp that resembled FORTRAN. Why didn't
someone with expertise in the translation of English into logical
expressions, like Vaughn Pratt for example, *do* something about this?

Perhaps we should have used curly braces?

The world is moving in the direction of languages like Python, that
fit naturally with how we speak and write.

That is to say:

world.MovingDirection = fit(we.speak() and \
we.write, fitfunctions.Naturally))

 

[=?ISO-8859-1?Q?Jens_Axel_S=F8gaard?=]

The story goes that in ancient Greece the sophists were recognized
experts on public speaking, who took pride in being able to sway their
audience into any point of view they liked, or got paid for. (Much
like todays "spin doctors", I believe.) This in contrast to the
philosophers, who were the experts on what is True, regardless of
popularity or any pragmatics.

So sophistry usually means something like a lot of fancy talk that
isn't very helpful in establishing what is true, or important, or
right, or bestest of parens and white-space.

And it often involved asking questions, whose answers were already known.

 

[prunesquallor]

|People don't like Lisp because of misconceptions, and threads like that
|help dispel those.

In my own mind, the biggest impediment to really liking Lisp is not the
annoying parentheses and awful syntax... it's many Lispers (especially
those like Tilton).

Yeah, that Tilton guy....

Hey, he's not looking. Let's all join comp.lang.python and ditch him.

 

[prunesquallor]

I'm not sure which is worse though... someone like Tilton is easily
smart enough to avoid sophistry, and yet he engages in it.

What can I say? Lisp attracts a more sophistricated kind of programmer.

 

[Rune Steffensen]

....it could have something to do with its users.

Now, if just someone would take this thread, and put it further up than
the sun will ever reach...

 

[Kenny Tilton]

We are a wicked gang indeed. Actually we were thrown out of the hotel
at the ILC this week because we were harrasing the other guests with
nasty lamda expressions in the elevators!

The Savages of comp.lang.lisp!

 

[Kenny Tilton]

The story goes that in ancient Greece the sophists were recognized
experts on public speaking, who took pride in being able to sway their
audience into any point of view they liked, or got paid for.

Oh, OK, thx. That was back in '71, I realized I could argue awesomely on
either side of a debate, and spontaneously lost all interest in
debating. After then...

(Much

like todays "spin doctors", I believe.) This in contrast to the
philosophers, who were the experts on what is True, regardless of
popularity or any pragmatics.

....yes, I went in search of the Tao.

kenny

 

[Kenny Tilton]

And it often involved asking questions, whose answers were already known.

Guilty! Guilty! Guilty! i did that when I asked someone about using
symbols as initargs instead of keywords on defstructs, when of course
defstruct creates the initargs without offering any overrides, so I knew
the answer: "um, no, those are keywords".

But then I felt my subterfuge would be obvious and it would be
understood to be a clever way to point out that there was a standard
practice the symbol initarg crowd was corrupting in order to calm their
package paranoia (induced by package abuse (necessitated by bad naming)).

kenny "the sophist"

 

[Kenny Tilton]

...it could have something to do with its users.

more personal attacks? <yechh> what part of the thread subject do you
not understand? You are reading this thread voluntarily, and your only
contribution is bile. Super.

The fact is, Pythonistas are using python because Java (and C++) did not
meet their needs. ie, thy are not sheep. They think for themselves.
Lispniks consider such folk Deeply Worthy.

This thread arose (in a prior incarnation) only because Python merely
/considered/ macros. Some mis-characterizations of macros arose and a
few of us swung by to say those characterizations did not match our
experience. We (I) do not give a rat's ass if Python adopts macros, but
we have a ball with them and we thought Pythonistas should have the Best
Information before rejecting them.


kenny

 

[Lulu of the Lotus-Eaters]

|> what is sophistry?

|The story goes that in ancient Greece the sophists were recognized
|experts on public speaking, who took pride in being able to sway their
|audience into any point of view they liked...

This is a good description of the word. But I think Kenny, in this
case, was making a rather nice joke: Being sophistical by pretending
not to know the word... a slightly self-deprecating self-reference.

If so, I give him many positive points for the meta-discourse.

Yours, Lulu...

 

[David Mertz]

|in overlooking your failings to even post correctly indented
|Python-the-language code when arguing against Lisp and its syntax:

Sure... but just imagine how badly matched my parentheses would have
been had I attempted to post Lisp code.

|You may have more numerous libraries and a larger set of groupies but
|you will never have the satisfaction of using a superior language.

Nah... I think Paul Graham has them lined up around the block, my
groupies only straggle in slowly. Still, do my callous remarks mean
that I will be blocked from downloading other programming language
distributions? Or is it just that I am too doltish to ever really enjoy
the satisfaction of CL?

|Please let me know if this response makes me a shining example of a
|"truly vindictive and nasty" Lisp user.

Not so much. I think my personal posting foibles slightly miss the
point, but the sting in observing them is in good enough humor.

Yours, David...

 

[Adam Warner]

Hi David Mertz,

Sure... but just imagine how badly matched my parentheses would have
been had I attempted to post Lisp code.

I suspect you pasted in validly formatted Python code:

def categorize_compose(filters, iter):
results = tuple([[] for _ in len(filters)])
for x in iter:
results[compose(filters)(x)].append(x)
return results

Before proceeding to indent it for display:

.....def categorize_compose(filters, iter):
..... results = tuple([[] for _ in len(filters)])
..... for x in iter:
..... results[compose(filters)(x)].append(x)
return results

Making this mistake will not affect the semantics of Lisp code. If you had
attempted to indent valid Lisp code you could not have made the same
mistake.

Even if you ultimately remember to indent everything correctly for display
you are still changing the semantics of the program with every interim
indentation change (and an interim failure could leave you with invalid
code). A related issue is moving a block of Python code within a program
and having to fix indentation of every line in the block to avoid changing
its original semantics.

Lisp parentheses combined with form analysis provide enough information to
automatically reformat any arbitrary block of code. Lisp's parentheses and
syntax are one of Lisp's greatest assets (and they also support effortless
code generation). One could say Lisp's syntax is essential for achieving
these aims. One could also say Python's syntax is essential for achieving
its aesthetic aims and markedly distinguishing it from other programming
languages.

Regards,
Adam

 

[David Mertz]

|I suspect you pasted in validly formatted Python code:
|Before proceeding to indent it for display:

Nah... that's not the specific error I made. It's plausible, sure. But
I rather hastily wrote the code directly in my newsreader, rather than
in a Python shell or Python-aware editor (and made some other
non-indentation errors in the process too).

Of course, then I copied the same function a couple times to create
variations of the behavior... never noticing the error in each of them.
Definitely a kicking myself moment (as I wrote in the subsequent post...
admittedly not belaboring every individual error).

I -did- do a little bit of Scheme programming lately (I guess before I
was barred from all future downloads ). Admittedly, this was
starting from little familiarity with the language (and also I cannot
get my little brain around emacs, and jEdit on my Powerbook doesn't seem
to want to reindent for me--maybe there's a plugin to do that).

I found that about 70% of the mistakes I made during playing with
variations on some (pretty simple) functions were because of misplaced
parentheses (most of the rest were from a fuzziness about the different
between strings and symbols; but I think I've worked that out). I sure
had to stare a LOT longer at those parens (and do lots of counting on my
fingers) than I would have had to look at wrongly indented Python code.
In fact, this much would be true even compared to way back during my
first few weeks of Python programming.

But maybe that error will go away over time. I have some doubts, but
also an open mind.

Yours, David...

 

[Adam Warner]

Hi David Mertz,

|I suspect you pasted in validly formatted Python code:
|Before proceeding to indent it for display:

Nah... that's not the specific error I made. [...]
OK!

I found that about 70% of the mistakes I made during playing with
variations on some (pretty simple) functions were because of misplaced
parentheses (most of the rest were from a fuzziness about the different
between strings and symbols; but I think I've worked that out). I sure
had to stare a LOT longer at those parens (and do lots of counting on my
fingers) than I would have had to look at wrongly indented Python code.
In fact, this much would be true even compared to way back during my
first few weeks of Python programming.

There is not one single gratuitous parenthesis in Lisp. But there are a
number of special forms and before those become hard coded into the brain
it's confusing. For example, consider LET:

(let ((symbol value))
...)

The binding of the symbol to the value is nested within another set
of parentheses because LET handles multiple bindings:

(let ((symbol1 value1)
(symbol2 value2))
...)

There is another less commonly used variation of LET that binds every
symbol to NIL, i.e.:

(let (symbol1 symbol2)
...)

Is shorthand for:

(let ((symbol1 nil)
(symbol2 nil))
...)

After one internalises _why_ each parenthesis is included everything falls
into place. Before that point the parentheses feel like line noise instead
of critical structure. The next step comes with automatic (re-)indentation
of code. To see a fault in a program one can just look at the indentation.
It's at this final point that the parentheses fade from consciousness
(incorrect indentation indicates a problem!)

Code may be slightly more verbose because of the parentheses but they also
encode some of the information required to reconstruct the formatting
of the code. Not having to manually reformat a function (I just press
C-M-q) is a big win.

As this reply was solely about (Common) Lisp I've set the followup-to
comp.lang.lisp only. But I also replied to comp.lang.python so you could
see my reply.

But maybe that error will go away over time. I have some doubts, but
also an open mind.

Everyone begins with doubts about Lisp, and the doubts easily intensify
before there is any obvious payback.

Regards,
Adam

 

[Tayss]

As soon as I try to learn more by reading discussions, I am bombarded
with weirdly fanatical (and very long) posts that are overwrought with
many misrepresentations (e.g. Python has "Lisp DNA", when pointedly it
does not by GvR's indication). Not that different Lispers even bother
with the same misrepresentations--just so long as they are clear that
programmers of all other languages are ignorant and stupid.

It is very strange. The Pythonista in me wonders if Common Lispers
(as a whole) realize what appeals to Python users. But then, their
most coherent marketing story is an attempt to reach those attracted
to Python for its powerful nature, not necessarily the mainstream
Python user.

The big appealing argument in favor of macros is with-open-files. You
set up a block, and the power of macros close the file automagically
when you're done. None of this try/finally madness. The try/finally
is hidden inside the macro.

So you basically have something like:
with_open_file f (filename, 'r'):
# read from f, do what you want;
# once you leave the block it will be autoclosed!
# Even if the clever user reassigns f it will be closed!

(In fact, I keep on wanting to describe Emacs's save-excursion as a
fantasy that you wake up from at the end. The system protects you
from the likely negative consequences of your actions.)


Alex Martelli argued that macros create hidden things that affect code
at-a-distance. But there are CL tools to fix this! I just used
macroexpand to see what with-open-file "really" becomes.
macroexpand(with_open_file f (filename, 'r')) would become something
like:
try:
unique_temp = open(filename, 'r')
f = unique_temp
# do work here with f
finally:
if unique_temp:
unique_temp.close()

Now, I don't know if macros can seriously be done within Python, it's
just a demonstration on how safe macros can make a language.


Another nicety of the lisps is you can have almost whatever names you
like, for functions and variables. Something like "number->string"
could be a name of a function that converts a number into a string.
Everyone gets those destructive Python functions like list.sort()
wrong at first, thinking that it returns a list. Why not have it be
sort!() for something that returns None? Of course, many of these
names would be up to kindly people like Guido & Co, so that coherent
guidelines could ripple through the Python continuum.

It's not absolutely clear if Common Lisp is readable in the small. I
believe the normal CL argument is about readability in the large,
since the Lisps have good abstraction facilities. (This way, you can
"name" nasty pieces of code with simple representations.) Scheme is
very readable in the small; but it's unclear whether it will evolve a
highly used Lisp anytime soon. But in terms of WRITING code, I prefer
Common Lisp even though Python's nicer to read. So a lot of CL is
invisible. In particular, the difficulty of reading CL may be partly
due to CLers removing patterns whenever they come up.

Anyway, just my opinion, as someone with the Pythonic and Lisp DNA.

 

[Edi Weitz]

I -did- do a little bit of Scheme programming lately (I guess before
I was barred from all future downloads ). Admittedly, this was
starting from little familiarity with the language (and also I
cannot get my little brain around emacs, and jEdit on my Powerbook
doesn't seem to want to reindent for me--maybe there's a plugin to
do that).

I found that about 70% of the mistakes I made during playing with
variations on some (pretty simple) functions were because of
misplaced parentheses (most of the rest were from a fuzziness about
the different between strings and symbols; but I think I've worked
that out). I sure had to stare a LOT longer at those parens (and do
lots of counting on my fingers) than I would have had to look at
wrongly indented Python code. In fact, this much would be true even
compared to way back during my first few weeks of Python
programming.

It is my experience that this definitely goes away very quickly if
you're actually using the language. When I started with Lisp some
years ago I initially had some problems with things like DO, LET, or
COND. It seemed to me as if I would forever have to look up the
definition and count the parens before I could use one of these.

It turned out that this only lasted for a couple of days. In fact,
once you get it, you realize that every single form in Lisp has
exactly the right number of parentheses and as long as you know the
arglist (tools like ILISP will help with that) it's a no-brainer to
know how many parens you'll need. Plus, should I ever make a mistake
with parens I'll notice immediately after hitting RETURN because Emacs
will get the indentation wrong.

As others have pointed out it is _essential_ to use Emacs or an Emacs
clone (like Hemlock or the editors coming with the commercial Lisps)
if you're going to write Lisp programs. Your editor should be able to
at least get the indentation right automatically, it should be able to
show matching parentheses, and it should feature a couple of
convenient ways to navigate through s-exps and lists, see for example

<http://www.google.com/[email protected]>.

Edi.

 

[Marcin 'Qrczak' Kowalczyk]

In fact, once you get it, you realize that every single form in Lisp
has exactly the right number of parentheses and as long as you know the
arglist (tools like ILISP will help with that) it's a no-brainer to know
how many parens you'll need.

The problem is not that I don't know why each paren is there. I know it.
It doesn't help with the fact that there are a lot of them and that code
is not easily readable because of deep nesting.

As others have pointed out it is _essential_ to use Emacs or an Emacs
clone (like Hemlock or the editors coming with the commercial Lisps)
if you're going to write Lisp programs.

What about reading (in books, on WWW)? I guess you would say
"indentation"...

Indentation in Lisp is not clear enough. Let's look at an example from
http://www-users.cs.umn.edu/~gini/aiprog/graham/onlisp.lisp:

(defun mostn (fn lst)
(if (null lst)
(values nil nil)
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))

Note that only one pair of adjacent lines is indented by the same amount.
Other alignments are in the middle of lines.

Here is a straightforward translation into my dream language; note that
there aren't a lot of parens despite insignificant indentation and despite
using braces (like C) instead of bracketing keywords (like Pascal):

def mostn Fun [] = [], null;
def mostn Fun (First\List) {
var Result = [First];
var Max = Fun First;
each List ?Obj {
let Score = Fun Obj;
if Score > Max {Max = Score; Result = [Obj]}
if Score == Max {Result = Obj\Result}
};
reversed Result, Max
};

| Lisp | Python | above
-------------------------------------------+------+--------+-------
different amounts of indentation | 10 | 4 | 3
at the beginnings of lines | | |
| | |
maximum number of nested parens | 9 | 1 | 4
| | |
maximum number of adjacent closing parens | 5 | 1 | 2
| | |
total number of parens | 60 | 16 | 18
where paren = ()[]{} | | |

This is why I don't find Lisp syntax readable. It requires apparently
3 times more complicated nesting structure to express the same thing.

 

[Kenny Tilton]

|> what is sophistry?

|The story goes that in ancient Greece the sophists were recognized
|experts on public speaking, who took pride in being able to sway their
|audience into any point of view they liked...

This is a good description of the word. But I think Kenny, in this
case, was making a rather nice joke: Being sophistical by pretending
not to know the word... a slightly self-deprecating self-reference.

I was reaching for my dictionary when it occurred to me that coming
clean on my ignorance was the best response/joke I could make. See sig
for my exemplar (whatever that means).

kenny

--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The Road to Lisp Survey

"I don't know what 'truculent' means, but if it's good, that's me."
-- Muhammad Ali, without missing a beat, after Howard Cosell
remarked on Ali's sullenness during an interview.

 

[Borcis]

> Procedural, imperative programming is
simply a paradigm that more closely matches the ordinary way of thinking
(ordinary = in non-programming, non-computing spheres of human endevor) than
functional programming.

There is no such thing as "the" ordinary way of thinking, except in
the mind of people who have not enquired enough about the ways of thinking
of other people to discover this "astonishing" fact - but I will concede that
failure to enquire is more likely to occur among adepts of procedural and
imperative authority (authority - not thinking).

This said, I find it a bit ridiculous to oppose lisp and python along that
scale; compared to logic programming (eg Prolog), or even to reverse-polish
stack-based syntax like in PostScript - and given that both python and lisp
are dynamic and don't require types declarations - programming in python and
programming in lisp feel very similar (except for a few things you can do in
lisp but not in python).

....

The same reason why programmers call lisp "mind-expanding" and "the latin of
programming languages" is the very same reason why they are reluctant to
learn it--its different, and for many also hard to get used to.

Everybody finds one's own mother's style of cooking more palatable, but that's
no excuse to reflect on things as if everybody had the same mother.

Python doesn't try (too) hard to change the ordinary manner of thinking,
just to be as transparent as possible. I guess in that sense it encourages a
degree of mental sloth, but the objective is executable pseudocode.

Python and lisp imho compete for the status of easiest language to program in;
python differs from lisp in that in leaves you less freedom to shoot yourself
in the foot with meta-programming (having access to code as an easy data
structure, something Prolog has too). And python also has for itself a free
reference implementation running on all platforms, with an extensive standard
lib (that's why I use it rather than lisp).

Lisp
counters that thinking the lisp way may be harder, but the power it grants
is out of all proportion to the relatively meager investment of mental
energy required--naturally, it's hard to convince someone of that if they
don't actually _use_ it first, and in the end some will probably still think
it isn't worth the trouble. It will take very significant and deep cultural
and intellectual changes before lisp is ever an overwhelmingly dominant
language paradigm.

The real issue is what language gets taught to beginners and what language is
required by employers, and such choices are mostly historical accidents of fad
and fashion.

That is, when it becomes more natural to think of
cake-making as

UD: things
Gxyz: x is baked at y degrees for z minutes.
Hx: x is a cake.
Ix: x is batter.

For all x, ( (Ix & Gx(350)(45)) > Hx )

(i.e. "Everything that's a batter and put into a 350 degree oven for 45
minutes is a cake")

...instead of...

1. Heat the oven to 350 degrees.
2. Place batter in oven.
3. Bake 45 minutes
4. Remove cake from oven.

(i.e. "To make a cake, bake batter in a 350 degree oven for 45 minutes")

This is not serious. Write down a piece of idiomatic python, and I'm sure some
lisper will show you how well lisp can mimic that.

...then lisp will take over the universe. Never mind that the symbolic
logic version has more precision.

Lisp isn't symbolic logic. Symbolic logic isn't the example you gave.