XPost: comp.lang.scheme

(let ((x 5))
(mapcar (function (lambda (y) (+ x y)))
'(3 5 7)))

(8 10 12)

Programmers who are human get tired of typing and seeing
"(lambda" as an indication of an anonymous function. They
wish that something shorter like "(fn" could be used.
However, disciples of CL are willing and eager to make it even
longer by putting "(functon" in front of it---despite the fact
that doing so is a pleonasm; "lambda" is a macro that expands
to "(function (lambda".

CL lickspittles always try to make their code as ugly
and bloated as possible.

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.scheme

El Sun, 29 Sep 2024 00:35:53 -0000 (UTC), B. Pym escribió:

(let ((x 5))
(mapcar (function (lambda (y) (+ x y)))
'(3 5 7)))

(8 10 12)

Programmers who are human get tired of typing and seeing "(lambda" as an indication of an anonymous function. They wish that something shorter
like "(fn" could be used. However, disciples of CL are willing and eager
to make it even longer by putting "(functon" in front of it---despite
the fact that doing so is a pleonasm; "lambda" is a macro that expands
to "(function (lambda".

CL lickspittles always try to make their code as ugly and bloated as possible.

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.

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.

Well, I'd say Scheme and CL are both today equally bloated.
Scheme looks minimal, but the truth is that in order to be
usable, you depend on tons of modules.
You'll need either SRFI's and/or ICE-9's on Guile to do anything decent;
even for SICP you need two SRFI's (203 and 216) to do the exercises
under Chicken Scheme.

With Scheme you are lost on a sea of submodules and SRFI's.

With CL you might use closer-mop from QuickLisp if you like
objects to behave universally the same and that's it.

With MCClim your GUI will work on most libre CL implementations,
and QuickLisp will handle any dependency seamlessly. Fire and forget.

Also, for the 3 major books, a plain CL compiler (SBCL, CCL or ECL)
will work as is.

- Common Lisp: An Interactive Approach <-novices
- A Gentle Introduction to Symbolic Computation <-advanced
- Paradigms On Artifical Intelligence Programming <- almost expert

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.scheme

On Thu, 3 Oct 2024 20:05:02 -0000 (UTC), usuario wrote:

Well, I'd say Scheme and CL are both today equally bloated.
Scheme looks minimal, but the truth is that in order to be usable, you
depend on tons of modules.

So what would you consider to be a usable language that wasn’t “bloated”?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.scheme

B. Pym wrote:

(let ((x 5))
(mapcar (function (lambda (y) (+ x y)))
'(3 5 7)))

(8 10 12)

Programmers who are human get tired of typing and seeing
"(lambda" as an indication of an anonymous function. They
wish that something shorter like "(fn" could be used.
However, disciples of CL are willing and eager to make it even
longer by putting "(functon" in front of it---despite the fact
that doing so is a pleonasm; "lambda" is a macro that expands
to "(function (lambda".

However, that information means nothing to worshippers of CL
(COBOL-Like). Their religion has nothing to do with reason
and much to do with their craving for prolixity, pomposity,
and sheer ugliness.

Testing:

(let ((x 5))
(mapcar (lambda (y) (+ x y)) '(3 5 7)))

(8 10 12)

CL lickspittles always try to make their code as ugly
and bloated as possible.

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.

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.

Gauche Scheme:

(let1 x 5
(map (cut + x <>) '(3 5 7)))

(8 10 12)

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.


Brooks and Gabriel 1984, "A Critique of Common Lisp":

Every decision of the committee can be locally rationalized
as the right thing. We believe that the sum of these
decisions, however, has produced something greater than its
parts; an unwieldy, overweight beast, with significant costs
(especially on other than micro-codable personal Lisp
engines) in compiler size and speed, in runtime performance,
in programmer overhead needed to produce efficient programs,
and in intellectual overload for a programmer wishing to be
a proficient COMMON LISP programmer.


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?


Dick Gabriel:

Common LISP just was never designed to be a commercially
viable LISP. It was intended to serve as a compromise between
the manufacturers of LISP machines and other vendors of LISP
products. Never did we think of it as an industrial strength
system... So, to the extent that ANSI's ongoing efforts to
standardize on Common LISP exercise some influence over how LISP
is accepted in the world at large, I anticipate a disaster.


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


"There are no average [Common] Lisp programmers. We are the
Priesthood. Offerings of incense or cash will do."
-- Kenny Tilton at comp.lang.lisp


"we already know we are better then the rest of the
world, so we do not need to talk about that any further."
--- Markus Grueneis at comp.lang.lisp


Is it true that users of CL (COBOL-Like) inspired the making of
the movie "Idiocracy"?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)