Chris Riesbeck wrote:

> LOOP ... COLLECT vs. MAPCAR -- LAMBDA is a tie for me,
> but if you want to collect only certain values, then
>
> (loop for x in l
> when <test x>
> collect x)
>
> is hands-down clearer than
>
> (mapcan #'(lambda (x)
> (when <test x> (list x)))
> l)

Why didn't the creature simply write "(lambda" instead
of "#'(lambda"?

"(function (lambda ...)) is a pleonasm. lambda is a macro that
already expands to (function (lambda ...))."

Disciples of CL are the most mindless "programmers" on the
planet. Furthermore, they are very eager to make their
code as ugly as possible.

>
> while
>
> (remove-if-not #'(lambda (x) <test x>) l)

Why didn't the creature simply write
"(remove-if-not <test> l)"?

Disciples of CL are the most mindless "programmers" on the
planet. Furthermore, they are very eager to make their
code as ugly as possible.

>
> is OK but that double-negative leaves me cold.

Gauche Scheme:

(filter odd? (liota 22))
===>
(1 3 5 7 9 11 13 15 17 19 21)

See how much better it is when one uses a Lisp instead of
CL (COBOL-Like)?

Paul Graham:

"The good news is, it's not Lisp that sucks, but Common Lisp."

Paul Graham:

"Do you really think people in 1000 years want to be
constrained by hacks that got put into the foundations of
Common Lisp because a lot of code at Symbolics depended on
it in 1988?"

Daniel Weinreb, 24 Feb 2003:

"Having separate 'value cells' and 'function cells' (to use
the 'street language' way of saying it) was one of the most
unfortunate issues. We did not want to break pre-existing
programs that had a global variable named 'foo' and a global
function named 'foo' that were distinct. We at Symbolics
were forced to insist on this, in the face of everyone's
knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all
the specific things like this, but if we had had fewer
compatibility issues, I think it would have come out looking
more like Scheme in general."

Daniel Weinreb, 28 Feb 2003:

"Lisp2 means that all kinds of language primitives have to
exist in two versions, or be parameterizable as to whether
they are talking about the value cell or function cell. It
makes the language bigger, and that's bad in and of itself."

Jeffrey M. Jacobs:

"The CL effort resembles a bunch of spoiled children,
each insisting 'include my feature or I'll pull out, and
then we'll all go down the tubes'. Everybody had vested
interests, both financial and emotional."

Jeffrey M. Jacobs:

"CL is a nightmare; it has effectively killed LISP
development in this country. It is not commercially viable
and has virtually no future outside of the traditional
academic/defense/research arena."

Bernard Lang:

"Common Lisp did kill Lisp. Period. (just languages take a
long time dying ...) It is to Lisp what C++ is to C. A
monstrosity that totally ignores the basics of language
design, simplicity and orthogonality to begin with."

B. Pym wrote:

> Chris Riesbeck wrote:
>
> > LOOP ... COLLECT vs. MAPCAR -- LAMBDA is a tie for me,
> > but if you want to collect only certain values, then
> >
> > (loop for x in l
> > when <test x>
> > collect x)
> >
> > is hands-down clearer than
> >
> > (mapcan #'(lambda (x)
> > (when <test x> (list x)))
> > l)
>
>
> Why didn't the creature simply write "(lambda" instead
> of "#'(lambda"?
>
> "(function (lambda ...)) is a pleonasm. lambda is a macro that
> already expands to (function (lambda ...))."
>
> Disciples of CL are the most mindless "programmers" on the
> planet. Furthermore, they are very eager to make their
> code as ugly as possible.
>
>
>
> >
> > while
> >
> > (remove-if-not #'(lambda (x) <test x>) l)
>
>
> Why didn't the creature simply write
> "(remove-if-not <test> l)"?
>
> Disciples of CL are the most mindless "programmers" on the
> planet. Furthermore, they are very eager to make their
> code as ugly as possible.
>
>
>
> >
> > is OK but that double-negative leaves me cold.
>
> Gauche Scheme:
>
> (filter odd? (liota 22))
> ===>
> (1 3 5 7 9 11 13 15 17 19 21)
>
>
> See how much better it is when one uses a Lisp instead of
> CL (COBOL-Like)?
>
> Paul Graham:
>
> "The good news is, it's not Lisp that sucks, but Common Lisp."
>
>
>
> Paul Graham:
>
> "Do you really think people in 1000 years want to be
> constrained by hacks that got put into the foundations of
> Common Lisp because a lot of code at Symbolics depended on
> it in 1988?"
>
> Daniel Weinreb, 24 Feb 2003:
>
> "Having separate 'value cells' and 'function cells' (to use
> the 'street language' way of saying it) was one of the most
> unfortunate issues. We did not want to break pre-existing
> programs that had a global variable named 'foo' and a global
> function named 'foo' that were distinct. We at Symbolics
> were forced to insist on this, in the face of everyone's
> knowing that it was not what we would have done absent
> compatibility constraints. It's hard for me to remember all
> the specific things like this, but if we had had fewer
> compatibility issues, I think it would have come out looking
> more like Scheme in general."
>
> Daniel Weinreb, 28 Feb 2003:
>
> "Lisp2 means that all kinds of language primitives have to
> exist in two versions, or be parameterizable as to whether
> they are talking about the value cell or function cell. It
> makes the language bigger, and that's bad in and of itself."
>
> Jeffrey M. Jacobs:
>
> "The CL effort resembles a bunch of spoiled children,
> each insisting 'include my feature or I'll pull out, and
> then we'll all go down the tubes'. Everybody had vested
> interests, both financial and emotional."
>
> Jeffrey M. Jacobs:
>
> "CL is a nightmare; it has effectively killed LISP
> development in this country. It is not commercially viable
> and has virtually no future outside of the traditional
> academic/defense/research arena."
>
> Bernard Lang:
>
> "Common Lisp did kill Lisp. Period. (just languages take a
> long time dying ...) It is to Lisp what C++ is to C. A
> monstrosity that totally ignores the basics of language
> design, simplicity and orthogonality to begin with."

Don Geddis wrote

> I don't know about you, but it's _much_ easier for me to understand this
> oh-so-common idiom with the extended loop:
>
> (loop for x in *big-list*
> collect (1+ x) )

Why not:

(mapcar '1+ '(200 300 400 500))
===>
(201 301 401 501)