[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.lisp

Re: On nil qua false [was: Re: On conditionals]

William James

2/2/2016 10:26:00 AM

Bruce Hoult wrote:

> > Pierre R. Mai wrote:
.....
> > I have yet to see one bug that was caused by (eq 'NIL '()) tripping up
> > some minimally-competent programmer (i.e. one that didn't just start a
> > CL implementation by accident, when he really was expecting Scheme, or
> > some other language), or forcing someone to write noticably more
> > convoluted code because of it.
>
> That's a great stock answer that can be used to justify any "feature" in
> any language or indeed application program. "If you were an expert in
> this program then you wouldn't have any problems. How do we know if
> you're an expert? Because you don't have any problems, of course!"
>
> Cool.
>
> Don't worry. CL is totally perfect just as it is. No other language,
> past, future or present ever had any idea better than the ideas already
> present in CL. Where CL is more flexible than other languages it's
> because such complexity is necessary. Where CL is more restrictive than
> othe languages it is because more generality is unnecessary.
>
> I get it now.

I agree with the sarcasm of Mr. Hoult.

There is absolutely no limit to the fanaticism, dogmatism, and
mindlessness of the worshippers of CL (COBOL-Like).


Here's what the experts say about CL (COBOL-Like):

"an unwieldy, overweight beast"
"intellectual overload"
"did kill Lisp"
"A monstrosity"
"ignores the basics of language design"
"killed Lisp"
"sucks"
"an aberration"
"the WORST thing that could possibly happen to LISP"
"incomprehensible"
"a nightmare"
"not commercially viable"
"no future"
"a significantly ugly language"
"hacks"
"unfortunate"
"a disaster"
"bad"

Don't believe me? Ask Barry Margolin. He apparently doesn't even
have CL installed on his computer.

In context:


Guy L. Steele, Jr., July 1989:

I think we may usefully compare the approximate number of pages
in the defining standard or draft standard for several
programming languages:

Common Lisp 1000 or more
COBOL 810
ATLAS 790
Fortran 77 430
PL/I 420
BASIC 360
ADA 340
Fortran 8x 300
C 220
Pascal 120
DIBOL 90
Scheme 50


-----

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.

-----

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.

-----

Gilles Kahn:

To this day I have not forgotten that Common Lisp killed
Lisp, and forced us to abandon a perfectly good system,
LeLisp.

-----

Paul Graham, May 2001:

A hacker's language is terse and hackable. Common Lisp is not.

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

Historically, Lisp has been good at letting hackers have their
way. The political correctness of Common Lisp is an aberration.
Early Lisps let you get your hands on everything.

A really good language should be both clean and dirty:
cleanly designed, with a small core of well understood and
highly orthogonal operators, but dirty in the sense that it
lets hackers have their way with it. C is like this. So were
the early Lisps. A real hacker's language will always have a
slightly raffish character.

Organic growth seems to yield better technology and richer
founders than the big bang method. If you look at the
dominant technologies today, you'll find that most of them
grew organically. This pattern doesn't only apply to
companies. You see it in sponsored research too. Multics and
Common Lisp were big-bang projects, and Unix and MacLisp
were organic growth projects.

-----

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.

-----

Jeffrey M. Jacobs:


I think CL is the WORST thing that could possibly happen to LISP.
In fact, I consider it a language different from "true" LISP.

*****

Common LISP is the PL/I of Lisps. Too big and too
incomprehensible, with no examination of the real world of
software engineering.

.... 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.

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.


-----


Dick Gabriel:

Common Lisp is a significantly ugly language. If Guy and I
had been locked in a room, you can bet it wouldn't have
turned out like that.


-----

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.


--
You have politicians saying that ... as many Africans as want to come into
Sweden should be able to come.... They've already said that everybody from
Syria can come to Sweden.... [T]hey are actually thinking of commandeering
people's vacation homes because they need more housing for immigrants.
--- Dr. Kevin MacDonald (http://lnrlive.com/tpc/tpc201...)