info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Extended loop macro
163 views
Skip to first unread message
WJ
May 10, 2012, 10:59:11 PM5/10/12
to
Antonio Menezes Leitao wrote:
> Edi Weitz <spamt...@agharta.de> writes:
> > (loop with scheme-char-seen-p = nil
> > for c across string
> > when (or (char-not-greaterp #\a c #\z)
> > (digit-char-p c)
> > (member c '(#\+ #\- #\.) :test #'char=))
> > do (setq scheme-char-seen-p t)
> > else return (and scheme-char-seen-p
> > (char= c #\:)))
>
> Lot's of extremely nice examples! And the last one even ends with a
> smile. I hope you can see it!
>
> Thanks a lot,
In other words, test whether the string begins with a
sequence composed of a-z, 0-9, or [.+-], followed
by ":".
This is easily done with a simple regular expression.
Racket:
> (regexp-match #px"^[a-z\\d.+-]+:" "abc:")
'("abc:")
> (regexp-match #px"^[a-z\\d.+-]+:" "abc?")
#f
> (regexp-match #px"^[a-z\\d.+-]+:" ":abc")
#f
> (regexp-match #px"^[a-z\\d.+-]+:" "888:")
'("888:")
> (regexp-match #px"^[a-z\\d.+-]+:" "-:")
'("-:")
> (regexp-match #px"^[a-z\\d.+-]+:" ".:")
'(".:")
> (regexp-match #px"^[a-z\\d.+-]+:" "ABC:")
#f
> (regexp-match #px"^[a-z\\d.+-]+:" "**:")
#f
Of course, as a rule, users of CL (COBOL-Like) are
not familiar with regular expressions. As a rule,
they are computer illiterates who refuse to learn
anything besides their sacred scriptures, the CL
Hypertrophied Spec, and who actually pride themselves
on their ignorance.
Only the abysmally ignorant don't know about
regular expressions; even Microsoft Word lets
you do a regular expression search.
Here we saw one mindless worshipper of CL proudly
displaying his bloated, convoluted LOOPy code and
another typical worshipper of CL thanking him
for it!
CL truly attracts the worst "programmers" in the world.
COBOL-Like is definitely not a Lisp.
Here's what the experts say about 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"
"bad"
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.
-----
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.
*****
One of the key issues that I consider distinguishes "Real
LISP" from Common LISP is indeed the strong committment to
the equivalence of data (meaning list structures) and code.
I consider this idea one of the foundations of "Real LISP",
and Common LISP intent is vague at best. InterLISP, for
example, still makes a declaration of this philosophy in the
manual, and it is still one of the keystones in the teaching
of LISP (although whether it should be when teaching Common
LISP is open to question).
-----
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.
> Edi Weitz <spamt...@agharta.de> writes:
> > (loop with scheme-char-seen-p = nil
> > for c across string
> > when (or (char-not-greaterp #\a c #\z)
> > (digit-char-p c)
> > (member c '(#\+ #\- #\.) :test #'char=))
> > do (setq scheme-char-seen-p t)
> > else return (and scheme-char-seen-p
> > (char= c #\:)))
>
> Lot's of extremely nice examples! And the last one even ends with a
> smile. I hope you can see it!
>
> Thanks a lot,
In other words, test whether the string begins with a
sequence composed of a-z, 0-9, or [.+-], followed
by ":".
This is easily done with a simple regular expression.
Racket:
> (regexp-match #px"^[a-z\\d.+-]+:" "abc:")
'("abc:")
> (regexp-match #px"^[a-z\\d.+-]+:" "abc?")
#f
> (regexp-match #px"^[a-z\\d.+-]+:" ":abc")
#f
> (regexp-match #px"^[a-z\\d.+-]+:" "888:")
'("888:")
> (regexp-match #px"^[a-z\\d.+-]+:" "-:")
'("-:")
> (regexp-match #px"^[a-z\\d.+-]+:" ".:")
'(".:")
> (regexp-match #px"^[a-z\\d.+-]+:" "ABC:")
#f
> (regexp-match #px"^[a-z\\d.+-]+:" "**:")
#f
Of course, as a rule, users of CL (COBOL-Like) are
not familiar with regular expressions. As a rule,
they are computer illiterates who refuse to learn
anything besides their sacred scriptures, the CL
Hypertrophied Spec, and who actually pride themselves
on their ignorance.
Only the abysmally ignorant don't know about
regular expressions; even Microsoft Word lets
you do a regular expression search.
Here we saw one mindless worshipper of CL proudly
displaying his bloated, convoluted LOOPy code and
another typical worshipper of CL thanking him
for it!
CL truly attracts the worst "programmers" in the world.
COBOL-Like is definitely not a Lisp.
Here's what the experts say about 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"
"bad"
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.
-----
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.
*****
One of the key issues that I consider distinguishes "Real
LISP" from Common LISP is indeed the strong committment to
the equivalence of data (meaning list structures) and code.
I consider this idea one of the foundations of "Real LISP",
and Common LISP intent is vague at best. InterLISP, for
example, still makes a declaration of this philosophy in the
manual, and it is still one of the keystones in the teaching
of LISP (although whether it should be when teaching Common
LISP is open to question).
-----
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.
Kaz Kylheku
May 11, 2012, 12:10:07 AM5/11/12
to
On 2012-05-11, WJ <w_a_...@yahoo.com> wrote:
>> Edi Weitz <spamt...@agharta.de> writes:
>> > (loop with scheme-char-seen-p = nil
>> > for c across string
>> > when (or (char-not-greaterp #\a c #\z)
>> > (digit-char-p c)
>> > (member c '(#\+ #\- #\.) :test #'char=))
>> > do (setq scheme-char-seen-p t)
>> > else return (and scheme-char-seen-p
>> > (char= c #\:)))
>>
>> Lot's of extremely nice examples! And the last one even ends with a
>> smile. I hope you can see it!
>>
>> Thanks a lot,
>
>
> In other words, test whether the string begins with a
> sequence composed of a-z, 0-9, or [.+-], followed
> by ":".
>
> This is easily done with a simple regular expression.
>
>> Edi Weitz <spamt...@agharta.de> writes:
>> > (loop with scheme-char-seen-p = nil
>> > for c across string
>> > when (or (char-not-greaterp #\a c #\z)
>> > (digit-char-p c)
>> > (member c '(#\+ #\- #\.) :test #'char=))
>> > do (setq scheme-char-seen-p t)
>> > else return (and scheme-char-seen-p
>> > (char= c #\:)))
>>
>> Lot's of extremely nice examples! And the last one even ends with a
>> smile. I hope you can see it!
>>
>> Thanks a lot,
>
>
> In other words, test whether the string begins with a
> sequence composed of a-z, 0-9, or [.+-], followed
> by ":".
>
> This is easily done with a simple regular expression.
>
> Of course, as a rule, users of CL (COBOL-Like) are
> not familiar with regular expressions.
You maggot!
> not familiar with regular expressions.
You really put that slimy gastropodic foot in that orifice that passes for a
mouth, ever so deeper than usual.
You see, Edi Weitz, is the author of CL-PPCRE, a nice and widely used
regular expression library for Common Lisp.
(Which of the languages you flog here have a regex package written in those
languages that can stand up to CL-PPCRE?
Holy donkey. Man, if I pulled what you just did, I would not show myself around
here again from the indelible sense of shame. But something tells me you will
cheerfully live this down.
Opinion Poll: who is the lower niedermensch? Seamus Macrae or James Waxman?
Tim Bradshaw
May 11, 2012, 3:41:05 AM5/11/12
to
On 2012-05-11 02:59:11 +0000, WJ said:
> This is easily done with a simple regular expression.
Ah so you hate LOOP, but regexps are just fine. Hmm.
> This is easily done with a simple regular expression.
Xah Lee
May 12, 2012, 6:51:30 AM5/12/12
to
nicely formatted with sources links, at
〈Common Lisp Sucks〉
http://xahlee.org/comp/Common_Lisp_quotations.html
question:
------------------
Richard 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.»
source?
------------------
Gilles Kahn (1946〜2006):
To this day I have not forgotten that Common Lisp killed Lisp, and
forced us to abandon a perfectly good system, LeLisp.
Source?
------------------
«I think CL is the WORST thing that could possibly happen to LISP. In
fact, I consider it a language different from “true” LISP. …»
who is Jeffrey M. Jacobs, and source?
------------------
Chez 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
who is Bernard Lang, and source?
Thanks.
Xah
〈Common Lisp Sucks〉
http://xahlee.org/comp/Common_Lisp_quotations.html
question:
------------------
Richard Gabriel
«Common Lisp is a significantly ugly language. If Guy and I had been
source?
------------------
Gilles Kahn (1946〜2006):
To this day I have not forgotten that Common Lisp killed Lisp, and
forced us to abandon a perfectly good system, LeLisp.
------------------
«I think CL is the WORST thing that could possibly happen to LISP. In
fact, I consider it a language different from “true” LISP. …»
who is Jeffrey M. Jacobs, and source?
------------------
Chez Bernard Lang:
«Common Lisp did kill Lisp. Period. (just languages take a long time
ignores the basics of language design, simplicity and orthogonality to
begin with.»
who is Bernard Lang, and source?
Thanks.
Xah
WJ
May 14, 2012, 9:49:40 PM5/14/12
to
Xah Lee wrote:
> nicely formatted with sources links, at
>
> =E3=80=88Common Lisp Sucks=E3=80=89
> nicely formatted with sources links, at
>
> http://xahlee.org/comp/Common_Lisp_quotations.html
>
> question:
>
> ------------------
>
> Richard Gabriel
>
> =C2=ABCommon Lisp is a significantly ugly language. If Guy and I had been
>
> question:
>
> ------------------
>
> Richard Gabriel
>
> locked in a room, you can bet it wouldn't have turned out like that.=C2=BB
>
> source?
If I remember correctly, this quote (and some of the others)
was found on a forum or mailing-list. Unfortunately, I didn't
save the url because I assumed that google would always be able
to find it. But now google can't. Has it been dumbed down?
None of these quotes were fabricated by me, but now I'm having
difficulty proving it.
>
> ------------------
>
> Gilles Kahn (1946=E3=80=9C2006):
>
> To this day I have not forgotten that Common Lisp killed Lisp, and
> forced us to abandon a perfectly good system, LeLisp.
>
>
> Source?
Google can't find it.
> To this day I have not forgotten that Common Lisp killed Lisp, and
> forced us to abandon a perfectly good system, LeLisp.
>
>
> Source?
>
> ------------------
>
> =C2=ABI think CL is the WORST thing that could possibly happen to LISP. In
> fact, I consider it a language different from =E2=80=9Ctrue=E2=80=9D LISP. =
> =E2=80=A6=C2=BB
>
> who is Jeffrey M. Jacobs, and source?
I don't know who he is, but here's the source (in comp.lang.lisp)
> who is Jeffrey M. Jacobs, and source?
of one of his quotes; the other two are also from comp.lang lisp:
http://groups.google.com/group/comp.lang.lisp/msg/000c29799e6ee0d8
>
> ------------------
>
> Chez Bernard Lang:
>
> =C2=ABCommon Lisp did kill Lisp. Period. (just languages take a long time
> dying =E2=80=A6) 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.=C2=BB
>
> who is Bernard Lang, and source?
Here's something about Lang:
> who is Bernard Lang, and source?
http://dl.acm.org/citation.cfm?id=512972&CFID=103040887&CFTOKEN=24410986
>
> Thanks.
>
> Xah
Xah Lee
May 15, 2012, 10:38:01 PM5/15/12
to
WJ, thanks for the sources.
On May 14, 6:49 pm, "WJ" <w_a_x_...@yahoo.com> wrote:
> Xah Lee wrote:
> > nicely formatted with sources links, at
>
> http://xahlee.org/comp/Common_Lisp_quotations.html
> > =C2=ABI think CL is the WORST thing that could possibly happen to LISP. In
> > fact, I consider it a language different from =E2=80=9Ctrue=E2=80=9D LISP. =
> > =E2=80=A6=C2=BB
>
> > who is Jeffrey M. Jacobs, and source?
>
> I don't know who he is, but here's the source (in comp.lang.lisp)
> of one of his quotes; the other two are also from comp.lang lisp:
>
> http://groups.google.com/group/comp.lang.lisp/msg/000c29799e6ee0d8
good old thread, 1987. That's before i touched a computer.
though, there we see the oldbie Barry Margolin, who still posts now
and then.
but am not sure Jeffrey Jacobs is notable. Might have to remove his
quotes/attack on Common Lisp.
> > Chez Bernard Lang:
>
> > =C2=ABCommon Lisp did kill Lisp. Period. (just languages take a long time
> > dying =E2=80=A6) 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.=C2=BB
>
> > who is Bernard Lang, and source?
>
> Here's something about Lang:
>
> http://dl.acm.org/citation.cfm?id=512972&CFID=103040887&CFTOKEN=24410986
again, the quotes should be from notable figures of Common Lisp. Else
it amounts to collections of petty complaints, which we find tons
about every language from nobody geekers.
PS in another thread, i found a interesting (second hand) quote from
Will Clinger about the idiocy of lisper's infatuation of certain hand-
waving sense of how code is data in lisp.
Jeffrey M. Jacobs wrote, 1987:
--------------
Will Clinger, in <1...@tekchips.TEK.COM>, writes a very nice
explanation of the problem, but then goes onto confuse things
with a SCHEMEr's viewpoint of the world (valid but different). To
wit:
>By the way, lists are not expressions either. The general principle
>is that data structures and code are entirely disjoint. Apologists
>for Lisp have historically done their best to say that data structures
>and code are the same, and Common Lisp retains some really bizarre
>things to make that seem so, thus the confusion continues.
---------------
Xah gave a defining characteristic of lisp's “data is code” concept:
«A regular nested syntax, makes it possible to do source code
transformations trivially with a lexical scan.»
〈Programing Language: Fundamental Problems of Lisp〉
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
Xah
On May 14, 6:49 pm, "WJ" <w_a_x_...@yahoo.com> wrote:
> Xah Lee wrote:
> > nicely formatted with sources links, at
>
> > =C2=ABI think CL is the WORST thing that could possibly happen to LISP. In
> > fact, I consider it a language different from =E2=80=9Ctrue=E2=80=9D LISP. =
> > =E2=80=A6=C2=BB
>
> > who is Jeffrey M. Jacobs, and source?
>
> I don't know who he is, but here's the source (in comp.lang.lisp)
> of one of his quotes; the other two are also from comp.lang lisp:
>
> http://groups.google.com/group/comp.lang.lisp/msg/000c29799e6ee0d8
though, there we see the oldbie Barry Margolin, who still posts now
and then.
but am not sure Jeffrey Jacobs is notable. Might have to remove his
quotes/attack on Common Lisp.
> > Chez Bernard Lang:
>
> > =C2=ABCommon Lisp did kill Lisp. Period. (just languages take a long time
> > dying =E2=80=A6) 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.=C2=BB
>
> > who is Bernard Lang, and source?
>
> Here's something about Lang:
>
> http://dl.acm.org/citation.cfm?id=512972&CFID=103040887&CFTOKEN=24410986
it amounts to collections of petty complaints, which we find tons
about every language from nobody geekers.
PS in another thread, i found a interesting (second hand) quote from
Will Clinger about the idiocy of lisper's infatuation of certain hand-
waving sense of how code is data in lisp.
Jeffrey M. Jacobs wrote, 1987:
--------------
Will Clinger, in <1...@tekchips.TEK.COM>, writes a very nice
explanation of the problem, but then goes onto confuse things
with a SCHEMEr's viewpoint of the world (valid but different). To
wit:
>By the way, lists are not expressions either. The general principle
>is that data structures and code are entirely disjoint. Apologists
>for Lisp have historically done their best to say that data structures
>and code are the same, and Common Lisp retains some really bizarre
>things to make that seem so, thus the confusion continues.
---------------
Xah gave a defining characteristic of lisp's “data is code” concept:
«A regular nested syntax, makes it possible to do source code
transformations trivially with a lexical scan.»
〈Programing Language: Fundamental Problems of Lisp〉
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
Xah
WJ
May 16, 2012, 12:52:34 AM5/16/12
to
Xah Lee wrote:
> > > who is Jeffrey M. Jacobs, and source?
> >
> > I don't know who he is, but here's the source (in comp.lang.lisp)
> > of one of his quotes; the other two are also from comp.lang lisp:
> >
> > http://groups.google.com/group/comp.lang.lisp/msg/000c29799e6ee0d8
>
> good old thread, 1987. That's before i touched a computer.
>
> though, there we see the oldbie Barry Margolin, who still posts now
> and then.
>
> but am not sure Jeffrey Jacobs is notable. Might have to remove his
> quotes/attack on Common Lisp.
This post by Jacobs seems to be my source for the Dick Gabriel
> > > who is Jeffrey M. Jacobs, and source?
> >
> > I don't know who he is, but here's the source (in comp.lang.lisp)
> > of one of his quotes; the other two are also from comp.lang lisp:
> >
> > http://groups.google.com/group/comp.lang.lisp/msg/000c29799e6ee0d8
>
> good old thread, 1987. That's before i touched a computer.
>
> though, there we see the oldbie Barry Margolin, who still posts now
> and then.
>
> but am not sure Jeffrey Jacobs is notable. Might have to remove his
> quotes/attack on Common Lisp.
quote. Jacobs seems to think he got it from WESTEX 86:
http://www.osti.gov/energycitations/product.biblio.jsp?osti_id=6747954
That work is searchable, but not viewable, at Hathitrust;
doing a search for "Richard P. Gabriel" yields two hits.
http://babel.hathitrust.org/cgi/pt/search?id=uc1.31822000573600&view=image&seq=21&q1=%22Richard+P.+Gabriel%22
Here are a couple of interesting quotes from Gabriel's essay
"Lisp: Good News, Bad News, How to Win Big":
We've seen that the right thing attitude has brought us a very
large, complex-to-understand, and complex-to-implement Lisp --
Common Lisp that solves way too many problems.
Unix and C are the ultimate computer viruses.
0 new messages