My idea of the perfect language would be something like any of the
four following:
1)Logo that concentrated on lisp tricks and didn't even HAVE
turtle-graphics
2)Forth w/out all that OS STUFF, and stack STUFF.
3)lisp without so many parentheses
4)C without structured programming concepts
Anyone got a good candidate?
I'll even let you tell me how dumb I am for wanting what I want.
It seems that the common denominator of the four languages I like is
that they are all extensible, and I think all could be said to have
charachteristics of functional languages.
Someone could make me extraordinarilly happy by a real nice thorough
analysis of my essentially stupid and trivial thought(s) here.
From: Daniel Barlow
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <87y9hzauou.fsf@noetbook.telent.net>
······@ureach.com (zaphod) writes:
> 1)Logo that concentrated on lisp tricks and didn't even HAVE
> turtle-graphics
> 2)Forth w/out all that OS STUFF, and stack STUFF.
> 3)lisp without so many parentheses
> 4)C without structured programming concepts
5) Assembler without all that addressing mode cruft
6) Plain txt fils without the lttr '', bcaus lts fac it, it's silly
-dan
--
http://ww.tlnt.net/cliki/ - Link farm for fr CL-on-Unix rsourcs
From: Raymond Wiker
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <86pu3brnj5.fsf@raw.grenland.fast.no>
Daniel Barlow <···@telent.net> writes:
> ······@ureach.com (zaphod) writes:
>
> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > turtle-graphics
> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > 3)lisp without so many parentheses
> > 4)C without structured programming concepts
>
> 5) Assembler without all that addressing mode cruft
>
> 6) Plain txt fils without the lttr '', bcaus lts fac it, it's silly
^ You missed one.
Of the original list, the three first items seemed to be about
removing a (the) "defining feature" of the language - seems like a
pretty pointless exercise.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Raymond Wiker <·············@fast.no> wrote in message news:<··············@raw.grenland.fast.no>...
> Daniel Barlow <···@telent.net> writes:
>
> > ······@ureach.com (zaphod) writes:
> >
> > > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > > turtle-graphics
> > > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > > 3)lisp without so many parentheses
> > > 4)C without structured programming concepts
> >
> > 5) Assembler without all that addressing mode cruft
> >
> > 6) Plain txt fils without the lttr '', bcaus lts fac it, it's silly
>
> ^ You missed one.
>
> Of the original list, the three first items seemed to be about
> removing a (the) "defining feature" of the language - seems like a
> pretty pointless exercise.
I think I mentioned that! I covered all that junk. You probably read
the meat and ignored my side dishes! Don't eat ever eat in the
restaurant I want to own, or I might put a little surprise in the
secret sauce!
Thank you for replying!
Daniel Barlow <···@telent.net> wrote in message news:<··············@noetbook.telent.net>...
> ······@ureach.com (zaphod) writes:
>
> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > turtle-graphics
> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > 3)lisp without so many parentheses
> > 4)C without structured programming concepts
>
> 5) Assembler without all that addressing mode cruft
>
> 6) Plain txt fils without the lttr '', bcaus lts fac it, it's silly
Can I ask; what is a Plain text fil? Also what is adressing mode?
>
>
> -dan
From: Brian P Templeton
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <87g03qrkh4.fsf@tunes.org>
······@ureach.com (zaphod) writes:
> Daniel Barlow <···@telent.net> wrote in message news:<··············@noetbook.telent.net>...
>> ······@ureach.com (zaphod) writes:
>>
>> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
>> > turtle-graphics
>> > 2)Forth w/out all that OS STUFF, and stack STUFF.
>> > 3)lisp without so many parentheses
>> > 4)C without structured programming concepts
>>
>> 5) Assembler without all that addressing mode cruft
>>
>> 6) Plain txt fils without the lttr '', bcaus lts fac it, it's silly
>
>
> Can I ask; what is a Plain text fil?
``Plain text files without the letter 'e', because lets face it, it's
silly''
[...]
>>
>>
>> -dan
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> wrote in message news:<··············@tunes.org>...
> ······@ureach.com (zaphod) writes:
>
> > Daniel Barlow <···@telent.net> wrote in message news:<··············@noetbook.telent.net>...
> >> ······@ureach.com (zaphod) writes:
> >>
> >> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> >> > turtle-graphics
> >> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> >> > 3)lisp without so many parentheses
> >> > 4)C without structured programming concepts
> >>
> >> 5) Assembler without all that addressing mode cruft
> >>
> >> 6) Plain txt fils without the lttr '', bcaus lts fac it, it's silly
> >
> >
> > Can I ask; what is a Plain text fil?
> ``Plain text files without the letter 'e', because lets face it, it's
> silly''
>
> [...]
> >>
> >>
> >> -dan
I wonder if I earn more points for noticing I'm being ribbed, here, or
for ignoring it, or really if it much amtters, at this point?
From: Rahul Jain
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <87pu2qnun2.fsf@photino.sid.rice.edu>
······@ureach.com (zaphod) writes:
> I wonder if I earn more points for noticing I'm being ribbed, here,
> or for ignoring it, or really if it much amtters, at this point?
I think you've lost enough points for it to not matter. Fortunately,
in the midst of the flamewar you attempted to start, there was a bit
of useful discussion.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ············@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
From: Marco Antoniotti
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <y6cit92vilp.fsf@octagon.mrl.nyu.edu>
······@ureach.com (zaphod) writes:
> My idea of the perfect language would be something like any of the
> four following:
>
> 1)Logo that concentrated on lisp tricks and didn't even HAVE
> turtle-graphics
> 2)Forth w/out all that OS STUFF, and stack STUFF.
> 3)lisp without so many parentheses
> 4)C without structured programming concepts
>
> Anyone got a good candidate?
>
> I'll even let you tell me how dumb I am for wanting what I want.
> It seems that the common denominator of the four languages I like is
> that they are all extensible, and I think all could be said to have
> charachteristics of functional languages.
>
> Someone could make me extraordinarilly happy by a real nice thorough
> analysis of my essentially stupid and trivial thought(s) here.
I think that by definition, INTERCAL (whose design goal was to remove
any feature known to any other programming language) fits the bill.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a4bgqh$1ci4oh$1@ID-125440.news.dfncis.de>
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti wrote:
>
> ······@ureach.com (zaphod) writes:
>
>> My idea of the perfect language would be something like any of the
>> four following:
>>
>> 1)Logo that concentrated on lisp tricks and didn't even HAVE
>> turtle-graphics
>> 2)Forth w/out all that OS STUFF, and stack STUFF.
>> 3)lisp without so many parentheses
>> 4)C without structured programming concepts
>>
>> Anyone got a good candidate?
>>
>> I'll even let you tell me how dumb I am for wanting what I want.
>> It seems that the common denominator of the four languages I like is
>> that they are all extensible, and I think all could be said to have
>> charachteristics of functional languages.
>>
>> Someone could make me extraordinarilly happy by a real nice thorough
>> analysis of my essentially stupid and trivial thought(s) here.
>
> I think that by definition, INTERCAL (whose design goal was to remove
> any feature known to any other programming language) fits the bill.
No, he wants a functional language. So, I think this is closer:
http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche <······@cartan.de> wrote in message news:<···············@ID-125440.news.dfncis.de>...
> In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti wrote:
> >
> > ······@ureach.com (zaphod) writes:
> >
> >> My idea of the perfect language would be something like any of the
> >> four following:
> >>
> >> 1)Logo that concentrated on lisp tricks and didn't even HAVE
> >> turtle-graphics
> >> 2)Forth w/out all that OS STUFF, and stack STUFF.
> >> 3)lisp without so many parentheses
> >> 4)C without structured programming concepts
> >>
> >> Anyone got a good candidate?
> >>
> >> I'll even let you tell me how dumb I am for wanting what I want.
> >> It seems that the common denominator of the four languages I like is
> >> that they are all extensible, and I think all could be said to have
> >> charachteristics of functional languages.
> >>
> >> Someone could make me extraordinarilly happy by a real nice thorough
> >> analysis of my essentially stupid and trivial thought(s) here.
> >
> > I think that by definition, INTERCAL (whose design goal was to remove
> > any feature known to any other programming language) fits the bill.
>
> No, he wants a functional language. So, I think this is closer:
>
> http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/
I like esoteric languages. My favorite is OOK! The language for
Orangutans ("3) You cannot use the word Monkey.").
>
> Regards,
Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<···············@octagon.mrl.nyu.edu>...
> ······@ureach.com (zaphod) writes:
>
> > My idea of the perfect language would be something like any of the
> > four following:
> >
> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > turtle-graphics
> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > 3)lisp without so many parentheses
> > 4)C without structured programming concepts
> >
> > Anyone got a good candidate?
> >
> > I'll even let you tell me how dumb I am for wanting what I want.
> > It seems that the common denominator of the four languages I like is
> > that they are all extensible, and I think all could be said to have
> > charachteristics of functional languages.
> >
> > Someone could make me extraordinarilly happy by a real nice thorough
> > analysis of my essentially stupid and trivial thought(s) here.
>
> I think that by definition, INTERCAL (whose design goal was to remove
> any feature known to any other programming language) fits the bill.
>
> Cheers
Intercal is a joke. I'm very stupid; but I'm just smart enough to know that!
From: Marco Antoniotti
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <y6cr8norwqm.fsf@octagon.mrl.nyu.edu>
······@ureach.com (zaphod) writes:
> Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<···············@octagon.mrl.nyu.edu>...
...
> > I think that by definition, INTERCAL (whose design goal was to remove
> > any feature known to any other programming language) fits the bill.
> >
> > Cheers
>
> Intercal is a joke. I'm very stupid; but I'm just smart enough to
> know that!
Given your username.... :)
42
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<···············@octagon.mrl.nyu.edu>...
> ······@ureach.com (zaphod) writes:
>
> > Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<···············@octagon.mrl.nyu.edu>...
>
> ...
>
> > > I think that by definition, INTERCAL (whose design goal was to remove
> > > any feature known to any other programming language) fits the bill.
> > >
> > > Cheers
> >
> > Intercal is a joke. I'm very stupid; but I'm just smart enough to
> > know that!
>
> Given your username.... :)
>
> 42
Slarty would be too wise to say what I just did, and zaphod too conceited!
From: Julian Stecklina
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <877kpgw0vc.fsf@blitz.comp.com>
······@ureach.com (zaphod) writes:
[...]
> Intercal is a joke. I'm very stupid; but I'm just smart enough to know that!
But it's nevertheless interesting. I got headache after the first few
pages of the "specification". :)
Regards,
Julian
--
Um meinen oeffentlichen Schluessel zu erhalten:
To get my public key:
http://math-www.uni-paderborn.de/pgp/
From: Eric Moss
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C697B24.9D1A372@alltel.net>
zaphod wrote:
>
> My idea of the perfect language would be something like any of the
> four following:
>
> 1)Logo that concentrated on lisp tricks and didn't even HAVE
> turtle-graphics
> 2)Forth w/out all that OS STUFF, and stack STUFF.
> 3)lisp without so many parentheses
> 4)C without structured programming concepts
>
> Anyone got a good candidate?
Yes.
Common Lisp comes closest for you, despite your loathing of
parentheses. First off, your dislikes wrt the other languages appear to
be structural and therefore unavoidable. Your beef with Lisp appears to
be cosmetic. That is least problematic when it comes to making a
working piece of code.
Addressing the parentheses phobia, which I see in other students in my
AI course, I say several things.
Firstly, parentheses are actually a necessity. You have to have *some*
delimiter in a language, after all, and it can't be just whitespace.
Secondly, parentheses are an *advantage* over other delimiters. Note
that C uses {} and ; and " " and ",", so it only *appears* to not be
full of delimiters. Lisp is far more elegant, separating tokens with
whitespace and expressions with ().
Thirdly, with a good editor, the parentheses become minor blips on your
screen, and the indentation (which is orthogonal to what makes parsing
easy for the compiler) can be your guide. If you wanted, you could even
customize the indentation, although lots of experience indicates that
emacs does just fine.
To summarize, Lisp appears to have everything you want except for its
cosmetic "flaw", which isn't really a flaw. That can be gotten past
with experience or editor-tinkering. All the other languages have major
structural issues that can't be avoided.
Or something like that...
Eric
From: Thomas F. Burdick
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <xcvr8nq1in1.fsf@conquest.OCF.Berkeley.EDU>
Eric Moss <········@alltel.net> writes:
> zaphod wrote:
> >
> > My idea of the perfect language would be something like any of the
> > four following:
> >
> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > turtle-graphics
> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > 3)lisp without so many parentheses
> > 4)C without structured programming concepts
> >
> > Anyone got a good candidate?
>
> Yes.
>
> Common Lisp comes closest for you, despite your loathing of
> parentheses. First off, your dislikes wrt the other languages appear to
> be structural and therefore unavoidable. Your beef with Lisp appears to
> be cosmetic. That is least problematic when it comes to making a
> working piece of code.
>
> Addressing the parentheses phobia, which I see in other students in my
> AI course, I say several things.
>
> Firstly, parentheses are actually a necessity. You have to have *some*
> delimiter in a language, after all, and it can't be just whitespace.
Hell, since the parens are just the textual way of representing the
structure of the code, you could use a structure editor and never see
another paren again. Writing said editor is left as an exercise to
the reader.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222540975992591@naggum.net>
* Eric Moss <········@alltel.net>
| Addressing the parentheses phobia, which I see in other students in my AI
| course, I say several things.
I wonder if it is the parentheses or the enclosing delimiter. For some
time, now, I have been trying to understand how people react to Lisp, and
something occurred to me some tima ago that was recently reinforced. In
almost all other programming languages, parentheses are actually painful,
or symptoms of something painful. E.g., in those stupid infix syntaxes,
you need parentheses when the precedences of the operators you want to
combine are not related the way you want them to be. So the parentheses
become a means of resolving a conflict between the language and your
needs. In C-style languages, where type casts are necessary due to the
retarded type system, parentheses are used to resolve a conflict between
what the language thinks should be the type of something and what you
want it to be. The number of parentheses thus correlate with the level
of complexity, and the level of complexity with how hard it is to grasp.
The only "neutral" parentheses are those used in function calls. The
rest of the delimiters serve different purposes and also look different.
However, in (Common) Lisp, parentheses are the only game in town (well,
this is not true, but to the extent they are, bear with me), and all the
emotionsl responses to parentheses-as-pain-indicators from languages that
the programmer may have been previously exposed to come right back at him
at a very low level of consciousness. Any thinking person would observe
his reaction and think about it, but thinking peopla are never a problem.
Those who only react and feel that something must be wrong with all the
parentheses, may have a very particular reaction to parentheses. I have
had occasion to exploit this recently to test the hypothesis.
< and > are accetable delimiters these days, so I changed the reader and
printer to use them instead of ( and ). (The only practical problem was
that symbols with < and > in them needed to have that character escaped.)
Presented to two people who had previously been negative to Lisp, one of
them thought it was OK, now, the other went "you can't trick me into
liking Lisp". Presented to three people who were predicted to have a
strong dislike of parentheses, but had not had prior exposure to Lisp,
all three found it interesting, and one thought the parentheses of the
original code looked silly when presented with it -- the others quickly
figured out what the point of the exercise was, but did not react with
hostility to the parentheses. I found only one person whom I thought
would not be hostile to parentheses, but he was hostile to all the HTML
crap, instead, effectively being more annoyed with <> than with ().
This, of course, serves no useful statistical purposes, but I do not want
to run a research project on this. I would like to experiment with
working with this syntax for a while just to see how I think it works,
however. It might actually be the easiest way to get around the
parenthesis "perception problem".
/// 2002-02-12
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Software Scavenger
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a6789134.0202122241.bcb7e85@posting.google.com>
Erik Naggum <····@naggum.net> wrote in message news:<················@naggum.net>...
> I wonder if it is the parentheses or the enclosing delimiter. For some
> time, now, I have been trying to understand how people react to Lisp, and
My first reaction to Lisp parentheses before I started learning Lisp
was that there were three main reasons why I didn't like them. First,
I saw long strings of them in Lisp and wondered if I was expected to
count them every time I saw them, or how I could be sure they were
right without counting them. Second, parentheses are awkward on most
keyboards. They're more likely to be fumbled more often, because of
the combination of the shift key, the distance to the parentheses
keys, and the awkward combination of fingers used to type them.
Third, it seemed to me that infix syntax was making compilers do more
work to reduce the amount of work done by the programmer, and that
therefore the non-infix parentheses-based syntax was a way of taking
some of the work load off the compiler and putting it on the
programmer.
From: Holger Schauer
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <wheljpllhk.fsf@sowhat.coling.uni-freiburg.de>
On 12 Feb 2002, Software Scavenger wrote:
> Erik Naggum <····@naggum.net> wrote in (some) message:
>> I wonder if it is the parentheses or the enclosing delimiter.
>> For some time, now, I have been trying to understand how people
>> react to Lisp, and
> First, I saw long strings of them in Lisp and wondered if I was
> expected to count them every time I saw them, or how I could be sure
> they were right without counting them.
That was the one thing I really hated in the intro-course on Lisp that
I have taken. Once I learned the joys of Emacs (some five years
later), the parentheses "problem" disappeared without a trace. Hence,
the first thing I actually showed my students this year was a really
awkward and painful written peace of Lisp code. Next, I showed them
what it would look like to write it in Emacs. I then turned to show
them the same code with parens removed and told them not to count
parens but to use the structure of the code. Now that the course is
done, most of the code they've written actually looks pretty lispy.
> Second, parentheses are awkward on most keyboards. They're more
> likely to be fumbled more often, because of the combination of the
> shift key, the distance to the parentheses keys, and the awkward
> combination of fingers used to type them.
You should take a look at a German keyboard and try the key
combinations necessary to insert curly braces. Alt-Gr-7 and 8. Now
that's awkward (and the reason why German programmers sometimes prefer
using qwerty keyboards over German qwerty ones).
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
49: Version x.0
Kostenpflichtiger Preview als Bestandteil unserer Beta-Tests
(Kristian K�hntopp)
Erik Naggum <····@naggum.net> wrote in message news:<················@naggum.net>...
> * Eric Moss <········@alltel.net>
> | Addressing the parentheses phobia, which I see in other students in my AI
> | course, I say several things.
>
> I wonder if it is the parentheses or the enclosing delimiter. For some
> time, now, I have been trying to understand how people react to Lisp, and
> something occurred to me some tima ago that was recently reinforced. In
> almost all other programming languages, parentheses are actually painful,
> or symptoms of something painful. E.g., in those stupid infix syntaxes,
> you need parentheses when the precedences of the operators you want to
> combine are not related the way you want them to be. So the parentheses
> become a means of resolving a conflict between the language and your
> needs. In C-style languages, where type casts are necessary due to the
> retarded type system, parentheses are used to resolve a conflict between
> what the language thinks should be the type of something and what you
> want it to be. The number of parentheses thus correlate with the level
> of complexity, and the level of complexity with how hard it is to grasp.
> The only "neutral" parentheses are those used in function calls. The
> rest of the delimiters serve different purposes and also look different.
>
> However, in (Common) Lisp, parentheses are the only game in town (well,
> this is not true, but to the extent they are, bear with me), and all the
> emotionsl responses to parentheses-as-pain-indicators from languages that
> the programmer may have been previously exposed to come right back at him
> at a very low level of consciousness. Any thinking person would observe
> his reaction and think about it, but thinking peopla are never a problem.
> Those who only react and feel that something must be wrong with all the
> parentheses, may have a very particular reaction to parentheses. I have
> had occasion to exploit this recently to test the hypothesis.
>
> < and > are accetable delimiters these days, so I changed the reader and
> printer to use them instead of ( and ). (The only practical problem was
> that symbols with < and > in them needed to have that character escaped.)
> Presented to two people who had previously been negative to Lisp, one of
> them thought it was OK, now, the other went "you can't trick me into
> liking Lisp". Presented to three people who were predicted to have a
> strong dislike of parentheses, but had not had prior exposure to Lisp,
> all three found it interesting, and one thought the parentheses of the
> original code looked silly when presented with it -- the others quickly
> figured out what the point of the exercise was, but did not react with
> hostility to the parentheses. I found only one person whom I thought
> would not be hostile to parentheses, but he was hostile to all the HTML
> crap, instead, effectively being more annoyed with <> than with ().
> This, of course, serves no useful statistical purposes, but I do not want
> to run a research project on this. I would like to experiment with
> working with this syntax for a while just to see how I think it works,
> however. It might actually be the easiest way to get around the
> parenthesis "perception problem".
>
> /// 2002-02-12
Not with me. I have no problem with parentheses, except that I don't
know all the rules to their use, and I don't want to learn the entire
common-lisp language to find out; either. I may do so, but I WILL
find a better way, if I can!
From: Ed L Cashin
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <86sn84d7qj.fsf@cs.uga.edu>
······@ureach.com (zaphod) writes:
...
> Not with me. I have no problem with parentheses, except that I
> don't know all the rules to their use, and I don't want to learn the
> entire common-lisp language to find out; either. I may do so, but I
> WILL find a better way, if I can!
As far as this lisp beginner can tell, it's pretty simple:
* parentheses go around a list
* when a list is evaluated the first thing is treated as a function
and the following things in the list are the function arguments.
There are abbreviations (like the single quote character) and special
cases (special forms), and extensions (like read macrose), but that
seems to be the general idea. Add the fact that lists can be elements
a list, and you're off!
--
--Ed L Cashin | PGP public key:
·······@uga.edu | http://noserose.net/e/pgp/
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222681324844275@naggum.net>
* ······@ureach.com (zaphod)
| Not with me. I have no problem with parentheses, except that I don't
| know all the rules to their use, and I don't want to learn the entire
| common-lisp language to find out; either. I may do so, but I WILL
| find a better way, if I can!
Quite amazing. It is obviously superfluous to answer any of your
questions with technical answers. This is good to know.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Erik Naggum <····@naggum.net> wrote in message news:<················@naggum.net>...
> * ······@ureach.com (zaphod)
> | Not with me. I have no problem with parentheses, except that I don't
> | know all the rules to their use, and I don't want to learn the entire
> | common-lisp language to find out; either. I may do so, but I WILL
> | find a better way, if I can!
>
> Quite amazing. It is obviously superfluous to answer any of your
> questions with technical answers. This is good to know.
Yapp; reckon I'm an illiterat know knothing cluck; or maby you don't
know enough about me and my situation to know much at all about me or
my situation (look Ma; recursion). Sorry about my inadequacies. If I
put my attention purely on learning Common Lisp, I might surprise
someone with my astuteness as a student, then again; I might not. I
just wanted to let you know, that it's not neccasarilly an IRRATIONAL
dislike of parens. There just might be some rationality behind it.
In my case; I gave it a try, and discovered it wasn't as easy as I've
been lead to beleive, but I'm so dang low-brow, I hack trial and
error, when it seems right. I should have prefaced all with.
Me=newbie know-nothing, tho.
>
> ///
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222749131201678@naggum.net>
* ······@ureach.com (zaphod)
| I just wanted to let you know, that it's not neccasarilly an IRRATIONAL
| dislike of parens.
You failed.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Erik Naggum <····@naggum.net> wrote in message news:<················@naggum.net>...
> * ······@ureach.com (zaphod)
> | I just wanted to let you know, that it's not neccasarilly an IRRATIONAL
> | dislike of parens.
>
> You failed.
Oh well; Hey; if I were a line in a Snobol4 program, that would mean
you'd be likely to have trouble getting passed me. I probably am too
dumb to be involved too much in programming language discussions, tho.
I hope for continued forgiveness, on the part of most concerned, for
my many failings and inadequacies. I'm in no mood to try to sound
better than state of me-p. I here formally state that I make no
claims to being anything that deserv3es respect. Can we flame off
now?
>
> ///
From: Kenny Tilton
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C6D5AEC.54E7DC63@nyc.rr.com>
zaphod wrote:
> In my case; I gave [parentheses] a try, and discovered it wasn't as easy as I've
> been lead to beleive, but I'm so dang low-brow, I hack trial and
> error, when it seems right.
just curious: how long did you try? Did you have a nice
parentheses-matching editor to help?
thx
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"We have a pond and a pool. The pond would be good for you."
- Ty to Carl, Caddy Shack
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·················@nyc.rr.com>...
> zaphod wrote:
>
> > In my case; I gave [parentheses] a try, and discovered it wasn't as easy as I've
> > been lead to beleive, but I'm so dang low-brow, I hack trial and
> > error, when it seems right.
>
> just curious: how long did you try?
a total of 12 hours, with an at-least 2 week, if not 3-week interval
in between, and no user manual. My situation is kinda strange, and so
is my motivation and goal. I should not have implied that I was
typical, and should have laso made it more clear that my idea that
there are rational reasons to dislike parens is only relative to the
examples the author of the thesis arg offered. It's not that
rational, but seems to me to be more rational than the "reminds me of
the time" sort of examples that the author offered.
Did you have a nice
> parentheses-matching editor to help?
Nope. Mulisp 86, with EXTREMELY scanty documentation.
I'm still having lot's of trouble. My goals and motivations (for lack
of a better word) are, asI say, kinda eccentric. For one thing; I'd
like to know...this thing seems to have a single error message, or no
more than 2that I've run into. Not real informative; ya know. Is
that in the nature of lisp, or something I'm running into due to me,
or due to peculiarities of MULISP, exactly and particularly (figured
I'd try to get that question in there). Do most not-forkid's
languages tend to be scanty in describing how you messed up?
Anyone know?
>
> thx
From: Kenny Tilton
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C6F62AC.3203679A@nyc.rr.com>
zaphod wrote:
>
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·················@nyc.rr.com>...
> > zaphod wrote:
> >
> > > In my case; I gave [parentheses] a try, and discovered it wasn't as easy as I've
> > > been lead to beleive, but I'm so dang low-brow, I hack trial and
> > > error, when it seems right.
> >
> > just curious: how long did you try?
>
> a total of 12 hours, with an at-least 2 week, if not 3-week interval
> in between, and no user manual.
uh-oh. we don't call that "trying".
> Did you have a nice
> > parentheses-matching editor to help?
>
> Nope.
Well then fuggedaboutit. If you want to explore the Greatest Language on
Earth: (1) do so with an editor that groks Lisp (including parens); (2)
spend, oh, twenty-four hours on it; and (3) jeezus h. christ, worry
about something more important than parentheses; are you a programmer or
a troll?
kenny
From: Thomas F. Burdick
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <xcv7kpbvrfn.fsf@apocalypse.OCF.Berkeley.EDU>
Kenny Tilton <·······@nyc.rr.com> writes:
> and (3) jeezus h. christ, worry about something more important than
> parentheses; are you a programmer or a troll?
I thought the answer to this one had been clear for some time.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Kenny Tilton
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C708E5F.E7A75FB8@nyc.rr.com>
"Thomas F. Burdick" wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > and (3) jeezus h. christ, worry about something more important than
> > parentheses; are you a programmer or a troll?
>
> I thought the answer to this one had been clear for some time.
:) My assessment has varied from post to post, kind of a Heisenberg
thing...
k
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·················@nyc.rr.com>...
> zaphod wrote:
> >
> > Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·················@nyc.rr.com>...
> > > zaphod wrote:
> > >
> > > > In my case; I gave [parentheses] a try, and discovered it wasn't as easy as I've
> > > > been lead to beleive, but I'm so dang low-brow, I hack trial and
> > > > error, when it seems right.
> > >
> > > just curious: how long did you try?
> >
> > a total of 12 hours, with an at-least 2 week, if not 3-week interval
> > in between, and no user manual.
>
> uh-oh. we don't call that "trying".
>
> > Did you have a nice
> > > parentheses-matching editor to help?
> >
> > Nope.
>
> Well then fuggedaboutit. If you want to explore the Greatest Language on
> Earth: (1) do so with an editor that groks Lisp (including parens); (2)
> spend, oh, twenty-four hours on it; and (3) jeezus h. christ, worry
> about something more important than parentheses; are you a programmer or
> a troll?
Since I probably would fail any test to prove I'm a programmer; and
the only other choice is troll; I would have to say I'm a leprechaun!
>
> kenny
In article <····························@posting.google.com>,
······@ureach.com (zaphod) wrote:
>
> Not with me. I have no problem with parentheses, except that I don't
> know all the rules to their use, and I don't want to learn the entire
> common-lisp language to find out; either. I may do so, but I WILL
> find a better way, if I can!
The rules are very simple. Everything in lisp is either an atom or a
list. Atoms are single values; numbers, variables, strings, or a couple
of assorted other things that you won't need to use that much. If you
want something more complex than one of those (like, applying a function
to some arguments), you need a list. Lists are delimited by parentheses,
and their first element is the function you are calling or the special
form you are using (I'll get to the difference between functions and
special forms later). So if you want to add 4 and 5, you use the +
function (yes, in lisp + is a function like any other, it's not some
special operator), you write:
(+ 4 5)
=> 9
It's as simple as that! Here are some more examples. Say I want to add 4
to the result of multiplying 5 by 2. Starting from the outside, I write:
(+ 4 ...)
This applies the function plus the the argument 4 and the result of the
multiplication (represented here as ...). Now how do you do the
multiplication? Exactly the same way you did the addition:
(+ 4 (* 5 2))
=> 14
All function application works exactly this way. The interpreter or
compiler executes code by evaluating it. Evaluation for an number or
string returns that number or string:
4
=> 4
"foo"
=> "foo"
Evaluation of a symbol which refers to a variable returns the value of
that variable:
;; x has been set or bound before to 5
x
=> 5
Evaluation of a list (which is a function application) evaluates every
element of the list (I'm simplifying a little bit here, and using the
semantics of Scheme, rather than Common Lisp, because it makes more
sense that way), and then applies the function which appears at the
beginning to the (evaluated) rest of the arguments (I will use < and >
to enclose the evalueated value of the elements of the list):
(+ 4 (* 5 2))
(<function:+> <number:4> ...)
(<function:*> <number:5> <number:2>) => 10
(<function:+> <number:4> <number:10>) => 14
=> 14
The difference between a function and a special form is that in a
special form, it doesn't go through and evaluate every element. Instead,
it looks at the first one, and based on that decides how to evaluate the
rest. For example, when you are using if, you don't want it to evaluate
both the true and false conditions. For example, if you're writing
something that controls a nuclear weapon launch (this example stolen
from SICP), you don't want the statement
(if (at-war? us)
(launch missile)
(keep-waiting))
to launch the missile every time the if is evaluated!
So you see, parentheses in lisp are actually much simpler than those in
other languages. In C, you need to learn about precedence rules, square
brackets, curly braces, and all kinds of other delimeters, and
parentheses are used for three different things (typecasting, function
calls, and grouping arithmetic statements), while in lisp they are only
used for function calls and special forms.
If you don't want to learn all of Common Lisp, I would recommend Scheme,
which is much conceptually simpler than Common Lisp, but works in the
same basic way. There are some good intros online; go to
<http://www.schemers.org/>. Especially good is Abelson and Sussman, and
Sussman's "Structure and Interpretation of Computer Programs" at
http://mitpress.mit.edu/sicp/full-text/book/book.html (the link is kind
of buried if you try to find it on schemers.org).
(apologies for presenting scheme and advocating scheme on
comp.lang.lisp, but I think that it's better to introduce someone who
doesn't understand all those parentheses to scheme, rather than common
lisp, where you don't evaluate every element of the list uniformly)
--
Brian Campbell
Real email: lambda (at) cs (dot) dartmouth (dot) edu
From: Daniel Barlow
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <873d033kuv.fsf@noetbook.telent.net>
Brian Campbell <··········@yahoo.com> writes:
> The rules are very simple. Everything in lisp is either an atom or a
> list. Atoms are single values; numbers, variables, strings, or a couple
> of assorted other things that you won't need to use that much. If you
The first sentence is true.
As by definition an atom is anything that is not a cons, then insofar
as the second sentence is true, it's trivially true.
This gives us problems with the third sentence, as atoms thus include
things like packages, arrays, hash tables, and CLOS instances, which I
hope you will agree are generally _not_ "things that you won't need to
use that much"...
If in the second sentence you had instead said "Everything in lisp
_code_ is either an atom or a list", you could have made a rather more
defensible (if still not entirely justified) claim on the third
sentence, because code doesn't often contain literal hash tables.
OK, maybe I'm nit-picking, but confusing lisp code syntax with sexpr
syntax, and confusing the outward sexpr-based representation with the
actual objects are both common new-user mistakes, and I think it helps
to be exact with terminology when explaining.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
In article <··············@noetbook.telent.net>,
Daniel Barlow <···@telent.net> wrote:
> Brian Campbell <··········@yahoo.com> writes:
>
> > The rules are very simple. Everything in lisp is either an atom or a
> > list. Atoms are single values; numbers, variables, strings, or a couple
> > of assorted other things that you won't need to use that much. If you
>
> The first sentence is true.
>
> As by definition an atom is anything that is not a cons, then insofar
> as the second sentence is true, it's trivially true.
I need to define my terms. As the person I was explaing to doesn't
understand what all of the parentheses are for, I needed to make sure he
understood what atoms and lists were.
>
> This gives us problems with the third sentence, as atoms thus include
> things like packages, arrays, hash tables, and CLOS instances, which I
> hope you will agree are generally _not_ "things that you won't need to
> use that much"...
Do you see them literally in the code? It was the syntax, and how that
translated to the semantics, that I was explaining, not the actual set
of values that lisp can represent as data. Perhaps I should have been
more specific; rather than "everything in lisp", I should have said
"every expression in lisp". Besides numbers, symbols (which I called
variables here to draw the parallel with other programming languages),
strings, and lists, there's not much else that you see in the code.
There are vectors, and quoted symbols and lists, and a few other kinds
of atoms that can appear in the syntax, but as you said, you don't often
see literal hash tables. Also, since I was recommending he look into
Scheme if he didn't want to learn all of Common Lisp, I didn't want to
confuse him with things that were different between them; should I have
mentioned t and nil, or #t and #f? Should I have mentioned arrays, or
just vectors? As the atoms that I mentioned are common between both
scheme and common lisp, and make up 90% or more of the syntax that you
see, I decided to only include them.
>
> If in the second sentence you had instead said "Everything in lisp
> _code_ is either an atom or a list", you could have made a rather more
> defensible (if still not entirely justified) claim on the third
> sentence, because code doesn't often contain literal hash tables.
>
> OK, maybe I'm nit-picking, but confusing lisp code syntax with sexpr
> syntax, and confusing the outward sexpr-based representation with the
> actual objects are both common new-user mistakes, and I think it helps
> to be exact with terminology when explaining.
Yes, I was sloppy. I think that coming from the perspective of the
person I was writing for, it would still clear matters up more than it
would confuse him. Anyhow, both lisp syntax and sexpr syntax are the
syntax that can be parsed by the read function. There are additional
constraints on the lisp code, it is true, but lisp code is a use of
sexpressions for representing a program, and confusing the syntax with
the actual objects is a mistake, but that is why, when demonstrating
evaluation, I made sure to use a notation that distinguished objects
from their representation.
>
>
> -dan
--
Brian Campbell
Real email: lambda (at) cs (dot) dartmouth (dot) edu
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222747955200802@naggum.net>
* Brian Campbell <··········@yahoo.com>
| The rules are very simple.
Yeah. They go like this:
Rule #1: Don't feed the trolls.
Rule #2: Don't give the trolls the benefit of the doubt.
Rule #3: Don't let the trolls feed on you.
Rule #4: Sufficiently advanced ignorance is indistinguishable from trolls.
Rule #5: Get paid to write books for dummies and permanent newbies.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Ed L Cashin
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <863d04es3m.fsf@cs.uga.edu>
Erik Naggum <····@naggum.net> writes:
...
> I would like to experiment with
> working with this syntax for a while just to see how I think it works,
> however. It might actually be the easiest way to get around the
> parenthesis "perception problem".
I don't know. Holger Schauer has a point: emacs makes it easy to edit
lisp, but many people don't use emacs. If I didn't already feel
confident that emacs will keep track of the parens and the indentation
for me on first encountering lisp, the nesting might appear
overwhelming.
Also, I remember thinking that lisp looked like "text vomit" compared
to languages whose structure lexically mirrors what's going on.
Here's an example in ruby:
{
"foo" => "bar",
"baz" => "burfle",
}.each { |i|
puts i
}
Which, once you're used to it, looks at a glance like a hash table
followed by some code to do for each thing in it. More importantly,
even before you're used to it, the structure suggests that there's
some structured data on top and some code on the bottom.
Lisp is more verbose, and at a glance always looks like text and
parentheses:
(let ((h (make-hash-table)))
(setf (gethash "foo" h) "bar")
(setf (gethash "foo" h) "bar")
(maphash
#'(lambda (k v)
(format t "~A~%" k)
(format t "~A~%" v)) h))
I know that an experienced lisper could create a read macro to support
a syntax like in the first example, but someone encountering lisp for
the first time might not know that.
My first time seeing a large amount of lisp code was in the emacs
sources.
--
--Ed L Cashin | PGP public key:
·······@uga.edu | http://noserose.net/e/pgp/
From: Wade Humeniuk
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a4f9mn$ne6$1@news3.cadvision.com>
"Ed L Cashin" <·······@uga.edu> wrote in message
···················@cs.uga.edu...
>
> Also, I remember thinking that lisp looked like "text vomit" compared
> to languages whose structure lexically mirrors what's going on.
> Here's an example in ruby:
>
> {
> "foo" => "bar",
> "baz" => "burfle",
> }.each { |i|
> puts i
> }
>
> Which, once you're used to it, looks at a glance like a hash table
> followed by some code to do for each thing in it. More importantly,
> even before you're used to it, the structure suggests that there's
> some structured data on top and some code on the bottom.
>
I have a dumb question, but of what use is the preceding Ruby code? I do
not even see the hash table in that code, where is it and how do you refer
to it outside the code fragment? Overloading of {??
> Lisp is more verbose, and at a glance always looks like text and
> parentheses:
>
> (let ((h (make-hash-table)))
> (setf (gethash "foo" h) "bar")
> (setf (gethash "foo" h) "bar")
> (maphash
> #'(lambda (k v)
> (format t "~A~%" k)
> (format t "~A~%" v)) h))
>
All your ruby code above seems to do is
(write '((foo bar) (baz burfle)))
or more tersely
'((foo bar) (baz burfle))
Wade
From: Ed L Cashin
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <86wuxgda08.fsf@cs.uga.edu>
"Wade Humeniuk" <········@cadvision.com> writes:
> "Ed L Cashin" <·······@uga.edu> wrote in message
> ···················@cs.uga.edu...
> >
> > Also, I remember thinking that lisp looked like "text vomit" compared
> > to languages whose structure lexically mirrors what's going on.
> > Here's an example in ruby:
> >
> > {
> > "foo" => "bar",
> > "baz" => "burfle",
> > }.each { |i|
> > puts i
> > }
...
> I have a dumb question, but of what use is the preceding Ruby code? I do
> not even see the hash table in that code, where is it and how do you refer
> to it outside the code fragment? Overloading of {??
It simply illustrates that the code that creates a hash tables is
visually reminiscent of the relationships that the hash table
represents. To keep track of the variable for later you'd just use a
variable:
h = {
"foo" => "bar",
"baz" => "burfle",
}.each { |i|
puts i
}
h.each { |i| puts i } # or whatever you want to do with h
The lisp example did the same thing as the ruby example -- creating a
hash table and printing its contents. But my point was the visual
impact of the syntax and had nothing to do with the use of the example
code.
> > Lisp is more verbose, and at a glance always looks like text and
> > parentheses:
> >
> > (let ((h (make-hash-table)))
> > (setf (gethash "foo" h) "bar")
> > (setf (gethash "foo" h) "bar")
> > (maphash
> > #'(lambda (k v)
> > (format t "~A~%" k)
> > (format t "~A~%" v)) h))
> >
>
> All your ruby code above seems to do is
>
> (write '((foo bar) (baz burfle)))
>
> or more tersely
>
> '((foo bar) (baz burfle))
True.
--
--Ed L Cashin | PGP public key:
·······@uga.edu | http://noserose.net/e/pgp/
From: Tim Bradshaw
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ey3r8no5l6m.fsf@cley.com>
* Ed L Cashin wrote:
> It simply illustrates that the code that creates a hash tables is
> visually reminiscent of the relationships that the hash table
> represents. To keep track of the variable for later you'd just use a
> variable:
> h = {
> "foo" => "bar",
> "baz" => "burfle",
> }.each { |i|
> puts i
> }
> h.each { |i| puts i } # or whatever you want to do with h
> The lisp example did the same thing as the ruby example -- creating a
> hash table and printing its contents. But my point was the visual
> impact of the syntax and had nothing to do with the use of the example
> code.
Yes, I think this is what Lisp is about. Languages like Perl or Ruby
(or C) have decided that one sort of thing is interesting, and have a
syntax which has been greatly optimized for that single thing. Perl
is *really good* at string-bashing code with regexps, C is really good
at very terse OS code that both runs and can be compiled in reasonable
time on a PDP11-class machine, and so on.
Lisp has decided not to decide. Rather than provide a great mass of
syntactic tricks to support some particular style or programming
technique, Lisp provides a minimalist syntax which is just adequate to
express nested structures of various kinds without making any
commitment as to their meaning. The programmer then decides what this
syntax means in any instance.
Lisp is a toolkit for language design not a toolkit for solving
problems in particular domain. Of course, people will typically
evolve special languages in Lisp if they need to spend enough time in
any one domain to make it worth while, but since those languages are
usually application specific and not well-known, it's always easy to
demonstrate that any given language has a better syntax for any given
application than Lisp does.
--tim
From: Ed L Cashin
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <86it90cg9u.fsf@cs.uga.edu>
Tim Bradshaw <···@cley.com> writes:
...
> Yes, I think this is what Lisp is about. Languages like Perl or
> Ruby (or C) have decided that one sort of thing is interesting, and
> have a syntax which has been greatly optimized for that single
> thing. Perl is *really good* at string-bashing code with regexps, C
> is really good at very terse OS code that both runs and can be
> compiled in reasonable time on a PDP11-class machine, and so on.
>
> Lisp has decided not to decide. Rather than provide a great mass of
> syntactic tricks to support some particular style or programming
> technique, Lisp provides a minimalist syntax which is just adequate
> to express nested structures of various kinds without making any
> commitment as to their meaning. The programmer then decides what
> this syntax means in any instance.
Yes, and I think that's why it often requires a little bit of
experience with several programming that are good in a more limited
domain before lisp's generality can be recognized as a boon.
--
--Ed L Cashin | PGP public key:
·······@uga.edu | http://noserose.net/e/pgp/
From: Dorai Sitaram
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a4gkvf$olc$1@news.gte.com>
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>* Ed L Cashin wrote:
>
>> The lisp example did the same thing as the ruby example -- creating a
>> hash table and printing its contents. But my point was the visual
>> impact of the syntax and had nothing to do with the use of the example
>> code.
>
>Yes, I think this is what Lisp is about. Languages like Perl or Ruby
>(or C) have decided that one sort of thing is interesting, and have a
>syntax which has been greatly optimized for that single thing. Perl
>is *really good* at string-bashing code with regexps, C is really good
>at very terse OS code that both runs and can be compiled in reasonable
>time on a PDP11-class machine, and so on.
>
>Lisp has decided not to decide. Rather than provide a great mass of
>syntactic tricks to support some particular style or programming
>technique, Lisp provides a minimalist syntax which is just adequate to
>express nested structures of various kinds without making any
>commitment as to their meaning. The programmer then decides what this
>syntax means in any instance.
>
>Lisp is a toolkit for language design not a toolkit for solving
>problems in particular domain. Of course, people will typically
>evolve special languages in Lisp if they need to spend enough time in
>any one domain to make it worth while, but since those languages are
>usually application specific and not well-known, it's always easy to
>demonstrate that any given language has a better syntax for any given
>application than Lisp does.
I am inclined to agree, but just yesterday a coupla
posts here were praising special tools over
general tools. That also sounded somewhat agreeable
with at the time, except that their argument put CL
firmly on the side of the specializers, not
generalizers as the above seems to be doing (unless
Lisp is not being equated with CL).
--d
From: Tim Bradshaw
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ey3aduc5ajb.fsf@cley.com>
* Dorai Sitaram wrote:
> I am inclined to agree, but just yesterday a coupla
> posts here were praising special tools over
> general tools. That also sounded somewhat agreeable
> with at the time, except that their argument put CL
> firmly on the side of the specializers, not
> generalizers as the above seems to be doing (unless
> Lisp is not being equated with CL).
If you are referring to the article I wrote where I said I didn't try
and write general libraries or tools, then that's not quite what I was
trying to say.
What I meant was that doing `library standard' or `language standard'
systems is, in my opinion, very hard indeed (and many of the so-called
`standard libraries' such as, for instance, the Win32 API are in my
opinion good examples of systems which are *failing* to be good enough
and thus require endless reinvention).
I'm all in favour of general tools (which should be library/language
standard), and I think that CL is a very good example of such a
general tool whose design is actually adequate in almost all areas
(that is meant to be very high praise: there aren't any bits of CL
which I find unusably badly designed, which is not something I've come
across very often).
*But*, since I think that design of general tools is so hard, or at
least it is hard for me, I tend to not try, but instead to design
special tools for the job at hand. That way I actually get the job
done.
So I wasn't making a value judgement, more trying to describe how I
work.
--tim
From: Dorai Sitaram
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a4goig$oo7$1@news.gte.com>
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>* Dorai Sitaram wrote:
>
>> I am inclined to agree, but just yesterday a coupla
>> posts here were praising special tools over
>> general tools. That also sounded somewhat agreeable
>> with at the time, except that their argument put CL
>> firmly on the side of the specializers, not
>> generalizers as the above seems to be doing (unless
>> Lisp is not being equated with CL).
>
>If you are referring to the article I wrote where I said I didn't try
>and write general libraries or tools, then that's not quite what I was
>trying to say.
>...
>*But*, since I think that design of general tools is so hard, or at
>least it is hard for me, I tend to not try, but instead to design
>special tools for the job at hand. That way I actually get the job
>done.
>
>So I wasn't making a value judgement, more trying to describe how I
>work.
Actually, I was referring to Thomas [Burdick] and
Kent's articles rather than yours. If it was yours and
I was referring to it in a followup to you yourself,
let me assure you that I would find it weird to
third-person it so. :-)
--d
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> * Ed L Cashin wrote:
>
> > It simply illustrates that the code that creates a hash tables is
> > visually reminiscent of the relationships that the hash table
> > represents. To keep track of the variable for later you'd just use a
> > variable:
>
> > h = {
> > "foo" => "bar",
> > "baz" => "burfle",
> > }.each { |i|
> puts i
> > }
>
> > h.each { |i| puts i } # or whatever you want to do with h
>
>
> > The lisp example did the same thing as the ruby example -- creating a
> > hash table and printing its contents. But my point was the visual
> > impact of the syntax and had nothing to do with the use of the example
> > code.
>
> Yes, I think this is what Lisp is about. Languages like Perl or Ruby
> (or C) have decided that one sort of thing is interesting, and have a
> syntax which has been greatly optimized for that single thing. Perl
> is *really good* at string-bashing code with regexps, C is really good
> at very terse OS code that both runs and can be compiled in reasonable
> time on a PDP11-class machine, and so on.
>
> Lisp has decided not to decide. Rather than provide a great mass of
> syntactic tricks to support some particular style or programming
> technique, Lisp provides a minimalist syntax which is just adequate to
> express nested structures of various kinds without making any
> commitment as to their meaning. The programmer then decides what this
> syntax means in any instance.
>
> Lisp is a toolkit for language design not a toolkit for solving
> problems in particular domain. Of course, people will typically
> evolve special languages in Lisp if they need to spend enough time in
> any one domain to make it worth while, but since those languages are
> usually application specific and not well-known, it's always easy to
> demonstrate that any given language has a better syntax for any given
> application than Lisp does.
>
> --tim
So you are arguing that lisp is the most general purpose of general
purpose languages? Dost thou not remember the example of PL/I? In
fact; thats a good question? What stops CL from being the PL/I of
lisp dialects. My impression is that that is exactly what lisp is.
In fact; is lisp the new PL/I? I have heard it said that Scheme has
one of the smallest compilers around and CL one of the largest. Is
that true?
From: Eric Moss
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C773F88.CD2732BD@alltel.net>
zaphod wrote:
> So you are arguing that lisp is the most general purpose of general
> purpose languages?
If so, I would more or less agree. I look upon C as a special purpose
language--a nice assembler for vonNeumann architecture machines. I look
upon the other high-level languages as either partially-successful
attempts at creating part of lisp's semantics (e.g. Python), or as lisp
with a strict, narrow typing/meta-object protocol.
> What stops CL from being the PL/I of lisp dialects.
Yawn. Lisp's longevity and adaptability (despite committee-design ;))
indicates that whatever keeps that from happening has already kept that
from happening. You pick a style of programming, and lisp can probably
do it within the existing confines of the language. That is unlike
other languages that would require you to write (more or less) a Lisp
interpreter to accomplish it.
> My impression is that that is exactly what lisp is.
> In fact; is lisp the new PL/I? I have heard it said that Scheme has
> one of the smallest compilers around and CL one of the largest. Is
> that true?
(expt Yawn maximum-positive-double-float). Lisp isn't the "newest"
anything--it's been around in various forms since 1958 or so, indicating
it's inherent survivability.
Regarding compiler size, you can find out by downloading any of the
various Common Lisp packages. There are many different compilers, and
even the biggest distribution is <20meg compressed, including copious
docs and extra packages and so on. And so what if the Scheme compiler
is smaller? That's not a jab at you, but a real question. All that
matters to me as a programmer is that [1] I can express my algorithms
cleanly [2] they compile in a reasonable amount of time [3] they debug
nicely [4] they are developed interactively [5] they run in a reasonable
amount of time on reasonable hardware.
CL does that nicely, in any of the distributions. I'm sure there will
be something better down the line. What I doubt is that it will be
significantly different from CL in semantics or syntax. I can see it
being a streamlined CL, but that's about it.
Eric
From: Tim Bradshaw
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ey3ofigicwl.fsf@cley.com>
* Slarty wrote:
> I have heard it said that Scheme has
> one of the smallest compilers around and CL one of the largest. Is
> that true?
Compiler size is an implementation issue. CL compilers + runtimes
probably vary from ~1Mb to ~10Mb. Scheme compilers runtimes likewise.
C compilers from some 10s of K to the multi-hundred-Mb that is gcc
(this is unfair to gcc since it also compiles a multiplicity of other
languages).
--tim
From: Marco Antoniotti
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <y6cofisrw6s.fsf@octagon.mrl.nyu.edu>
Ed L Cashin <·······@uga.edu> writes:
> Erik Naggum <····@naggum.net> writes:
>
> ...
> > I would like to experiment with
> > working with this syntax for a while just to see how I think it works,
> > however. It might actually be the easiest way to get around the
> > parenthesis "perception problem".
>
> I don't know. Holger Schauer has a point: emacs makes it easy to edit
> lisp, but many people don't use emacs. If I didn't already feel
> confident that emacs will keep track of the parens and the indentation
> for me on first encountering lisp, the nesting might appear
> overwhelming.
>
> Also, I remember thinking that lisp looked like "text vomit" compared
> to languages whose structure lexically mirrors what's going on.
> Here's an example in ruby:
>
> {
> "foo" => "bar",
> "baz" => "burfle",
> }.each { |i|
> puts i
> }
(map* #'print
(make-hash-table* '(("foo" => "bar")
("baz" => "bar"))))
Hello!!!!!!
The point being that in CL you can modify the language, and make it
look like CL or something else.
Here is one of my favourite `primes' in conforming CL.
(in-package "SETL-USER")
(defun primes (max)
[n in (range 3 max 2)
/ (not (exist m in (range 3 (min (1- n) (+ 2 (sqrt n))) 2)
/ (= (mod n m) 0)))])
> I know that an experienced lisper could create a read macro to support
> a syntax like in the first example, but someone encountering lisp for
> the first time might not know that.
So? Does that warrant the application of Greenspun's Tenth? :)
> My first time seeing a large amount of lisp code was in the emacs
> sources.
A lot of ELisp code is not all that nice looking. Especially because
a lot of ELisp code does not (require 'cl) :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Christophe Rhodes
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <sqbsestaf7.fsf@cam.ac.uk>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Here is one of my favourite `primes' in conforming CL.
>
> (in-package "SETL-USER")
>
> (defun primes (max)
> [n in (range 3 max 2)
> / (not (exist m in (range 3 (min (1- n) (+ 2 (sqrt n))) 2)
> / (= (mod n m) 0)))])
I appreciate the point, but I thought that we decided that "conforming
CL" programmes needed to include their macros and reader-macros to be
properly conforming... :-)
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
From: Marco Antoniotti
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <y6c6650rpvp.fsf@octagon.mrl.nyu.edu>
Christophe Rhodes <·····@cam.ac.uk> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Here is one of my favourite `primes' in conforming CL.
> >
> > (in-package "SETL-USER")
> >
> > (defun primes (max)
> > [n in (range 3 max 2)
> > / (not (exist m in (range 3 (min (1- n) (+ 2 (sqrt n))) 2)
> > / (= (mod n m) 0)))])
>
> I appreciate the point, but I thought that we decided that "conforming
> CL" programmes needed to include their macros and reader-macros to be
> properly conforming... :-)
Come on! Throw me a bone here! :) The IN-PACKAGE is quite a give away
:)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Pierre R. Mai
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <87vgd0m5us.fsf@orion.bln.pmsf.de>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Ed L Cashin <·······@uga.edu> writes:
>
> > Also, I remember thinking that lisp looked like "text vomit" compared
> > to languages whose structure lexically mirrors what's going on.
> > Here's an example in ruby:
> >
> > {
> > "foo" => "bar",
> > "baz" => "burfle",
> > }.each { |i|
> > puts i
> > }
>
> (map* #'print
> (make-hash-table* '(("foo" => "bar")
> ("baz" => "bar"))))
Or, another way:
(maphash (lambda (key value) (format t "~A => ~A~%" key value))
(equal-hash-table "foo" "bar" "baz" "bar"))
The point being that hash-tables (_unlike_ many other data-structures
in CL), lack both reader-syntax and simple creation functions. Thus
the disadvantage when compared to Ruby/Perl/...; but I consider that
accidental, since CL does have such support for things like lists,
vectors, arrays, etc.
Probably make-hash-table should take an initial-contents keyword arg,
just like make-array does, e.g.
(maphash (lambda (key value) (format t "~A => ~A~%" key value))
(make-hash-table :test #'equal
:initial-contents '(("foo" "bar") ("baz" "bar"))))
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Wade Humeniuk
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a4hl9p$foj$1@news3.cadvision.com>
>
> Probably make-hash-table should take an initial-contents keyword arg,
> just like make-array does, e.g.
>
> (maphash (lambda (key value) (format t "~A => ~A~%" key value))
> (make-hash-table :test #'equal
> :initial-contents '(("foo" "bar") ("baz"
"bar"))))
I think hash-tables are meant to store larger amounts of unordered data and
I cannot see using the :initial-contents to populate a 1000+ key/value pairs
(or for that matter 100,000 values). I would rebel at doing the typing.
For me, storing 2 key/value or even 100 values in a hash table is just not
worth it.
Wade
From: Pierre R. Mai
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <87y9hvldwg.fsf@orion.bln.pmsf.de>
"Wade Humeniuk" <········@cadvision.com> writes:
> >
> > Probably make-hash-table should take an initial-contents keyword arg,
> > just like make-array does, e.g.
> >
> > (maphash (lambda (key value) (format t "~A => ~A~%" key value))
> > (make-hash-table :test #'equal
> > :initial-contents '(("foo" "bar") ("baz"
> "bar"))))
>
> I think hash-tables are meant to store larger amounts of unordered data and
> I cannot see using the :initial-contents to populate a 1000+ key/value pairs
> (or for that matter 100,000 values). I would rebel at doing the typing.
> For me, storing 2 key/value or even 100 values in a hash table is just not
> worth it.
The value for the initial-contents argument can be arrived at in any
way wanted. It is not limited to being a literal. Furthermore, in is
quite conceivable that the hash-table in question is going to grow to
many values (thereby validating the use of a hash-table), yet is
seeded with a smallish amount of initial-contents, where the typing
isn't problematic. And then there are many cases where you want to
interactively test a function that is specified to work on
hash-tables, where a few entries in the table suffices.
It is for those reasons that I think an initial-contents argument to
make-hash-table makes as much sense as it does for make-array. Of
course this is not something I'm going to fret about, but I've more
than once written a "make-hash-table-from-kv-pairs"-type function, and
wouldn't consider such an addition without some good will.
Of course your implicit point that alists are often a better choice
(which accidentally also have good support for literal input) for
smallish lookup tables is duly taken.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222747467111424@naggum.net>
* "Wade Humeniuk" <········@cadvision.com>
| I think hash-tables are meant to store larger amounts of unordered data and
| I cannot see using the :initial-contents to populate a 1000+ key/value pairs
| (or for that matter 100,000 values). I would rebel at doing the typing.
| For me, storing 2 key/value or even 100 values in a hash table is just not
| worth it.
When a hash-table is all you have, you tend to optimize it heavily. The
same goes for regexps. Both hash-tables and regular expressions are very
powerful and general tools, but they turn into monstrosities when all the
more specialized tools are effectively removed from the language they use.
Common Lisp has the disadvantage compared to the one-trick languages that
the different access functions for various kinds of mappings between key
and value are precisely that -- different. When there is only one way to
do it, being offered several ways is just confusing, and so people who
think "hash-table" when they should have thought "key-value mapping" will
miss simple and elegant things like property lists or association lists.
I mean, if { "foo" => "bar", "baz" => "zot" } is so great, why is not
(("foo" . "bar") ("baz" . "zot"))? Is it _only_ the sugar-coated syntax
that is so visually appealing to some? If so, a Common Lisp programmer
will write a small parser function that is called via the reader-macro
support to read this list. Why is this not more used? I belive it is
because most people who pine for other syntaxes have no clue how to go
about specifying them or writing parsers for them, and because once you
have grown that clue, you do not need it or, more importantly, want it.
But what the heck. Proof of concept follows.
(let ((mapping-types ()))
(defun readtable-mapping-type (readtable)
(check-type readtable readtable)
(or (cdr (assoc readtable mapping-types)) :alist))
(defun (setf readtable-mapping-type) (mode readtable)
(check-type readtable readtable)
(check-type mode (member :alist :plist :eq :eql :equal :equalp))
(let ((existing (assoc readtable mapping-types)))
(if existing
(setf (cdr existing) mode)
(push (cons readtable mode) mapping-types))))
(defun mapping-reader (stream char)
(declare (stream stream) (ignore char))
(loop
with mapping-type = (readtable-mapping-type *readtable*)
with key and value
with hashtable = (case mapping-type
(:eq (make-hash-table :test #'eq))
(:eql (make-hash-table :test #'eql))
(:equal (make-hash-table :test #'equal))
(:equalp (make-hash-table :test #'equalp)))
do
(when (eql #\} (peek-char t stream t nil t))
(read-char stream t nil t)
(loop-finish))
(setq key (read stream t nil t))
(if (eql #\= (peek-char t stream t nil t))
(read-char stream t nil t)
(error 'parse-error :stream stream))
(unless (eql #\> (read-char stream t nil t))
(error 'parse-error :stream stream))
(setq value (read stream t nil t))
(case (peek-char t stream t nil t)
(#\, (read-char stream t nil t))
(#\} t)
(t (error 'parse-error :stream stream)))
if (eq mapping-type :alist) collect (cons key value) into list else
if (eq mapping-type :plist) collect key into list
and collect value into list else
do (setf (gethash key hashtable) value)
finally (case mapping-type
((:alist :plist) (return (list 'quote list)))
(t (return hashtable))))))
Now, suppose the above is available in the Common Lisp world. A file
that uses this syntax could go like this:
(eval-when (:execute :compile-toplevel)
(setq *readtable* (copy-readtable))
(set-macro-character #\{ #'mapping-reader)
(set-syntax-from-char #\} #\)))
(eval-when (:execute :compile-toplevel)
(setf (readtable-mapping-type *readtable*) :alist))
(defparameter *roman-alist*
{ "I" => 1,
"V" => 5,
"X" => 10,
"L" => 50,
"C" => 100,
"D" => 500,
"M" => 1000 })
(eval-when (:execute :compile-toplevel)
(setf (readtable-mapping-type *readtable*) :plist))
(defparameter *roman-plist*
{ "I" => 1,
"V" => 5,
"X" => 10,
"L" => 50,
"C" => 100,
"D" => 500,
"M" => 1000 })
(eval-when (:execute :compile-toplevel)
(setf (readtable-mapping-type *readtable*) :equal))
(defparameter *roman-hash*
{ "I" => 1,
"V" => 5,
"X" => 10,
"L" => 50,
"C" => 100,
"D" => 500,
"M" => 1000 })
I chose this design because I figured that it would be annoying to change
the data if the access functions would need to change and that it would
be more convenient to specify this via a readtable-local setting than add
a lot more syntax for it. If you have support for the in-syntaax form
and named readtables, creating a named readtable to invoke this syntax
would obviously be the best solution.
Now, if you want other kinds of things to go on within { }, it is not a
lot of trouble to build a parser by hand, provided you are not a moron
and create syntaxes the like of C++ or some other horrible monstrosity.
Creating a writer for alists, plists, and hashtables that write data in
this syntax is left as an exercise for the reader.
Copyright notice: Copyright � 2002 Erik Naggum. The code may be used to
create commercial products without charge or other license provided that
the author is credited in each source file that uses it or the syntax it
allows. Creation of derivative works is permitted under two conditions:
No rewrites to use if* or not to use loop are allowed, and the author
must be notified by e-mail at <····@naggum.net>. Search engines are
permitted to index and retrieve this article in perpetuity and present to
users in either normal text or html-ized form, but no other form of re-
publication is permitted. Inclusion of this material in some "cookbook"
is expressly not permitted.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1502021156240001@eglaptop.jpl.nasa.gov>
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> Common Lisp has the disadvantage compared to the one-trick languages that
> the different access functions for various kinds of mappings between key
> and value are precisely that -- different.
...
> I mean, if { "foo" => "bar", "baz" => "zot" } is so great, why is not
> (("foo" . "bar") ("baz" . "zot"))? Is it _only_ the sugar-coated syntax
> that is so visually appealing to some?
I can't speak for anyone else of course, but what bothers me about alists
is not the syntax but exactly what you said in the first parahraph I
quoted: that the access functions for alists and other kinds of
associative maps are different. You say it's a disadvantage, and I
agree. It is a disadvantage because it tends to steer programmers towards
premature commitment to a particular implementation, and also towards
breaking abstractions (like pushing and popping things onto alists).
I would much prefer to simply specify that I want an associative map
without having to commit myself to a particular underlying
implementation. (Actually, associative maps are an important enough
abstraction that I think it's not unreasonable to think about taking the
decision away from the programmer and having the compiler or the runtime
system choose the implementation automatically.)
> But what the heck. Proof of concept follows.
[snip]
This is the right idea, but you need to add something like the ref macro
to complete the picture. By the time you've done that IMO you've done
enough work on a common enough problem that it's worth talking about
standardizing the interface and building it into implementations so
compilers can be smarter about optimizing it.
E.
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a4k0ma$srct$1@ID-125440.news.dfncis.de>
In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> I can't speak for anyone else of course, but what bothers me about alists
> is not the syntax but exactly what you said in the first parahraph I
> quoted: that the access functions for alists and other kinds of
> associative maps are different. You say it's a disadvantage, and I
> agree. It is a disadvantage because it tends to steer programmers towards
> premature commitment to a particular implementation, and also towards
> breaking abstractions (like pushing and popping things onto alists).
>
> I would much prefer to simply specify that I want an associative map
> without having to commit myself to a particular underlying
> implementation. (Actually, associative maps are an important enough
> abstraction that I think it's not unreasonable to think about taking the
> decision away from the programmer and having the compiler or the runtime
> system choose the implementation automatically.)
But when there is no difference whatsoever in usage interface of
assoc lists or hash tables, why would we want to use assoc lists in
the first place? I always thought that the main advantage of assoc
lists is that you have all those nice list functions for operating
on them in addition to the boring gethash, and can share data in
sublists if you operate functionally on them.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1502021848160001@192.168.1.50>
In article <·············@ID-125440.news.dfncis.de>, Nils Goesche
<······@cartan.de> wrote:
> In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> > I can't speak for anyone else of course, but what bothers me about alists
> > is not the syntax but exactly what you said in the first parahraph I
> > quoted: that the access functions for alists and other kinds of
> > associative maps are different. You say it's a disadvantage, and I
> > agree. It is a disadvantage because it tends to steer programmers towards
> > premature commitment to a particular implementation, and also towards
> > breaking abstractions (like pushing and popping things onto alists).
> >
> > I would much prefer to simply specify that I want an associative map
> > without having to commit myself to a particular underlying
> > implementation. (Actually, associative maps are an important enough
> > abstraction that I think it's not unreasonable to think about taking the
> > decision away from the programmer and having the compiler or the runtime
> > system choose the implementation automatically.)
>
> But when there is no difference whatsoever in usage interface of
> assoc lists or hash tables, why would we want to use assoc lists in
> the first place? I always thought that the main advantage of assoc
> lists is that you have all those nice list functions for operating
> on them in addition to the boring gethash, and can share data in
> sublists if you operate functionally on them.
I'm not 100% clear on what you're trying to say here, so I'm going to give
a couple of answers and hope a few of them are on-point.
1. Alists can be more efficient than hash tables, particularly for small
data sets.
2. Having "all those nice list functions" is only an advantage insofar as
they let you do something useful. Being able to operate on an alist as a
list is not in and of itself a feature, and can lead to problems if you're
not careful. I can't offhand think of anything useful you can do with an
alist that is fundamentally more difficult with a hashmap.
(Hashmaps, by the way, are one of Common Lisp's best kept secrets, one of
those "other" data types that doesn't get much attention among all the
hoopla over lists, atoms, and symbols. Hashmaps are tremendously useful,
and for a long time Common Lisp was the only language that had them.
Today C is about the only language in common use that doesn't have them.)
3. I don't understand the phrase "in addition to the boring gethash."
Gethash works only on hash tables, not on alists. To do the equivalent of
"gethash" on an alist you have to do (cdr (assoc ... more or less. I
also don't see why gethash is particularly more boring than any other
function.
4. Values stored in hash tables can share structure just as values stored
in alists can.
Was that anywhere near the mark?
E.
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a4kke8$gng$04$1@news.t-online.com>
In article <····················@192.168.1.50>, Erann Gat wrote:
> In article <·············@ID-125440.news.dfncis.de>, Nils Goesche
><······@cartan.de> wrote:
>
>> In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
>> > I can't speak for anyone else of course, but what bothers me about alists
>> > is not the syntax but exactly what you said in the first parahraph I
>> > quoted: that the access functions for alists and other kinds of
>> > associative maps are different.
[snip]
>> But when there is no difference whatsoever in usage interface of
>> assoc lists or hash tables, why would we want to use assoc lists in
>> the first place?
[snip]
> I'm not 100% clear on what you're trying to say here, so I'm going to give
> a couple of answers and hope a few of them are on-point.
[snip]
> Was that anywhere near the mark?
Yes, absolutely, thank you. I misunderstood you. I thought you were
saying that you didn't like having to use `gethash' in one case and
cdr and assoc in the other case etc. because you wanted to be able
to change your program quickly to use one instead of the other. I
thought that in order to do that you would have to restrict yourself
to use only the common subset of interface both structures have. As
I /still/ think that alists are a more luxurious thing than hash
tables, for the programmer at least, I wouldn't want to restrict
myself to that common subset. But then, maybe I am still
misunderstanding you :-)
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1502022018340001@192.168.1.50>
In article <···············@news.t-online.com>, Nils Goesche
<······@t-online.de> wrote:
> In article <····················@192.168.1.50>, Erann Gat wrote:
> > In article <·············@ID-125440.news.dfncis.de>, Nils Goesche
> ><······@cartan.de> wrote:
> >
> >> In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> >> > I can't speak for anyone else of course, but what bothers me about alists
> >> > is not the syntax but exactly what you said in the first parahraph I
> >> > quoted: that the access functions for alists and other kinds of
> >> > associative maps are different.
>
> [snip]
>
> >> But when there is no difference whatsoever in usage interface of
> >> assoc lists or hash tables, why would we want to use assoc lists in
> >> the first place?
>
> [snip]
>
> > I'm not 100% clear on what you're trying to say here, so I'm going to give
> > a couple of answers and hope a few of them are on-point.
>
> [snip]
>
> > Was that anywhere near the mark?
>
> Yes, absolutely, thank you. I misunderstood you. I thought you were
> saying that you didn't like having to use `gethash' in one case and
> cdr and assoc in the other case etc. because you wanted to be able
> to change your program quickly to use one instead of the other.
Yes, that is in fact what I was saying.
> I thought that in order to do that you would have to restrict yourself
> to use only the common subset of interface both structures have.
No, that is not what I was saying. Alists and hash tables have no common
subset in their interface. That's the problem. Erik's code solves half
of the problem. The 'ref' macro (discussed in another thread here a few
weeks ago) solves the other half. I'd like to see something like that
standardized.
> As
> I /still/ think that alists are a more luxurious thing than hash
> tables, for the programmer at least, I wouldn't want to restrict
> myself to that common subset.
Since the common subset is empty that would be a severe restriction. But
I'm curious: what is it about alists that you find "luxurious"?
E.
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a4l5uu$1tv$06$1@news.t-online.com>
In article <····················@192.168.1.50>, Erann Gat wrote:
> In article <···············@news.t-online.com>, Nils Goesche
><······@t-online.de> wrote:
>> As I /still/ think that alists are a more luxurious thing than hash
>> tables, for the programmer at least, I wouldn't want to restrict
>> myself to that common subset.
> Since the common subset is empty that would be a severe restriction.
Hehe :-) I meant the conceptual interfaces. Even if you have some
syntax and functional interface for addressing both of them in the
same way, you would be restricted to /using/ both alists and hashtables
in the same way. Otherwise you would lose the ability to simply
exchange both data structures in your code.
> But I'm curious: what is it about alists that you find "luxurious"?
Erik Naggum and Kent Pitman described that. After I had posted
the article I was angry that I had forgotten to add ``There is no
such thing as a free lunch.'' I am happy to see that Kent Pitman
apparently had the very same association (no pun intended).
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222828389147771@naggum.net>
* ···@jpl.nasa.gov (Erann Gat)
| 2. Having "all those nice list functions" is only an advantage insofar as
| they let you do something useful. Being able to operate on an alist as a
| list is not in and of itself a feature, and can lead to problems if you're
| not careful. I can't offhand think of anything useful you can do with an
| alist that is fundamentally more difficult with a hashmap.
Suppose it is a special variable. (let ((*alist* *alist*)) ...) allows
you to push key-value pairs on the list and have them work in a manner
very similar to scoping. You may temporarily push a single key-value
element to shadow another and then delete it when you are done, with a
simple (delete <key> <alist> :key #'car).
Alists are also just as efficient from key to value as from value to key.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Kent M Pitman
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <sfwaduavt1p.fsf@shell01.TheWorld.com>
Erik Naggum <····@naggum.net> writes:
> * ···@jpl.nasa.gov (Erann Gat)
> | 2. Having "all those nice list functions" is only an advantage insofar as
> | they let you do something useful. Being able to operate on an alist as a
> | list is not in and of itself a feature, and can lead to problems if you're
> | not careful. I can't offhand think of anything useful you can do with an
> | alist that is fundamentally more difficult with a hashmap.
(I'm reading out of context and assuming hashmap == hash table.)
You never get something for nothing. Everything is a trade-off.
Alists and plists Maintain an ordering. MAPHASH often goes in a very
unintuitive ordering. You may not _want_ an ordering; that's a different
issue. But certainly there is value to be had from those abstractions.
Order can be important both to presentation and to algorithm.
Also, alists and plists don't suffer from rehash problems upon garbage
collection.
And alists and plists are often short and just plain faster than hash tables,
since computing a key for the hash table involves a certain up front cost
that may not really matter. This depends a little on the hash table
implementation, of course. But I think most implementations of hash tables
have a certain degree of this.
> Suppose it is a special variable. (let ((*alist* *alist*)) ...) allows
> you to push key-value pairs on the list and have them work in a manner
> very similar to scoping. You may temporarily push a single key-value
> element to shadow another and then delete it when you are done, with a
> simple (delete <key> <alist> :key #'car).
Does anyone really do this? I have never gotten satisfactory results from
doing DELETE on a list (or alist) that was shared. As soon as I know someone
else is using it I have to worry I'm not maintaining it well for them.
Consider that there are *seriously* obscure "DELETE bugs" waiting if you
do
(setq l1 (list 4 3 2 1))
(setq l2 (cons 5 l1))
(setq l3 (delete 4 l2))
(setq l4 (delete 2 l2))
l4 => (5 3 1)
l3 => (5 3 1)
l2 => (5 3 1)
l1 => (4 3 1)
> Alists are also just as efficient from key to value as from value to key.
Alists don't suffer any more than other list formats from the problem I just
mentioned. I agree they are "as good as" plists, etc.
I prefer plists just because (a) they have better accessors in the language
and (b) they don't get caught up in that "dot problem" of ((a . b)...) vs
((a b)...).
I describe the basic trade-off between alists and plists this way:
alists are private
plists are restartable
That is, ...
If you do (assoc 'x '((a . b) (x . y) (z . 3) (x . m))) you get back
(x . y). If you wanted the (x . m), there is no easy way to "restart"
the search from the prior point; you have to use MEMBER (which breaks
the alist abstraction) to get restartability). _However_, what you do
get with alists is data privacy. If I want to hand you an object you
can SETF in order to update the table, I don't have to expose entries
to you that are irrelevant; if it were a plist, the only location I
could hand you is the tail of the list, which points to other data you
shouldn't have. That is, plists are not very private.
But as to restartability, if you do (get-properties '(a b x y z 3 x m)
'(x)) you get back X, Y, (X Y Z 3 X M). The third value can be used
to continue searching (i.e., to restart); contrast with an alist
lookup, where you get back the entry, which is not something you can
restart.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1602021131520001@192.168.1.50>
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> (I'm reading out of context and assuming hashmap == hash table.)
Right. I've been doing too much C++ hacking lately. :-(
> You never get something for nothing. Everything is a trade-off.
No argument. The question is when (and how) those tradeoffs ought to be
made. One of the great things about Lisp (as has oft been pointed out by
you, Erik, and others) is that it allows a programmer to defer a lot of
decisions that other languages demand you make up front. If I write a
function in Java I have to decide up front how many arguments that
function will take, what the types of those arguments are, and what the
return type of the function will be. In Lisp I don't have to commit to
any of those things. I don't even have to commit to the *number* of
arguments, or even the name of the function! Opinions differ over whether
in the grand and glorious scheme of things this is a good thing, but in
the context of this newsgroup I'm going to take it as axiomatic that it
is.
What I'm saying is that when it comes to associative maps -- an extremely
important abstraction (arguably the most important in all of computer
science, but that's another discussion) -- this philosophy of deferring
decisions breaks down, at least within the bounds of the current
standard. I can't say "I want an associative map, and I want to defer the
decision of whether the underlying implementation will be an alist, a
plist, a hash-table, a binary-tree, a trie, or something else." The
standard strongly influences programmers to choose an implementation up
front, and Lisp culture tends to influence them away from hash-tables --
in Graham's and Norvig's books they are barely a blip on the radar, less
then a dozen pages out of nearly two thousand -- and towards alists and
plists. As a result, a lot of code gets written that is O(N) when it
could easily be O(log(N)) or even O(1). It works fine on small problems,
but it doesn't scale well, and it's a lot of work to go back and fix it.
> Alists and plists Maintain an ordering. MAPHASH often goes in a very
> unintuitive ordering. You may not _want_ an ordering; that's a different
> issue. But certainly there is value to be had from those abstractions.
> Order can be important both to presentation and to algorithm.
IMO this is conflating two separate issues. You have a collection of
things that you want to access in two different ways, by order, and by an
unordered index. You should maintain those two organizations separately,
i.e. you should be maintaining both a hash-table index and an ordered
container -- probably a list but possibly something else, like perhaps a
balanced tree if you want sorted order rather than by-insertion order.
> Also, alists and plists don't suffer from rehash problems upon garbage
> collection.
Now this is something I'm not familiar with. Could you elaborate?
> And alists and plists are often short and just plain faster than hash tables,
> since computing a key for the hash table involves a certain up front cost
> that may not really matter. This depends a little on the hash table
> implementation, of course. But I think most implementations of hash tables
> have a certain degree of this.
Yes, which is exactly the reason why just using hash tables and forgetting
about alists and plists is not the best answer.
E.
From: Thomas F. Burdick
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <xcvd6z5i0kx.fsf@conquest.OCF.Berkeley.EDU>
···@jpl.nasa.gov (Erann Gat) writes:
> What I'm saying is that when it comes to associative maps -- an extremely
> important abstraction (arguably the most important in all of computer
> science, but that's another discussion) -- this philosophy of deferring
> decisions breaks down, at least within the bounds of the current
> standard. I can't say "I want an associative map, and I want to defer the
> decision of whether the underlying implementation will be an alist, a
> plist, a hash-table, a binary-tree, a trie, or something else."
Weren't you just posting a second ago about how much you like the REF
generic function? I'm certainly not the first person to go "I don't
even want to think about what kind of associating data structure I
want here -- I'll just say how I want to dereference it, and deal with
the how later -- (defgeneric ref ...". The standard gives you all you
need to write your application-specific abstractions to delay decisions.
The only reason to worry about standardizing something as trivial as
REF is in case everyone started having slightly different versions all
over the place. That would make it annoying to share code. Or, to
enable cute optimizations. It's certainly not needed to give
programmers the tool. And while it's a supported extension on the
Lisp system I'm working on, I'm dubious as to whether it needs any
sort of spec outside of the (hypothetical) Ciel-80 users' manual.
> The standard strongly influences programmers to choose an
> implementation up front, and Lisp culture tends to influence them
> away from hash-tables -- in Graham's and Norvig's books they are
> barely a blip on the radar, less then a dozen pages out of nearly
> two thousand -- and towards alists and plists.
Of course. Using hash tables sucks for debugging. It's easy to read
and maipulate a- and p-lists. You get shared tails cheaply. And you
get a record of how they got to where they are, because they're
ordered. Even when I know I'm going to end using a hash table, I
start by using an alist.
> As a result, a lot of code gets written that is O(N) when it could
> easily be O(log(N)) or even O(1). It works fine on small problems,
> but it doesn't scale well, and it's a lot of work to go back and fix
> it.
This shouldn't be true for well-written code. Just rewrite your
access functions. And remember, O(1) is a complexity signature,
algorithmically, it behaves as (1 + c1). And O(N) really means
((c2 * N) + c3). I'm certain you know this, but if c3 and c4 are
sufficiently small comapared to c1, the O(N) algorithm can be better.
Hashing time, the effects of GC, time spent rebalancing trees
... sometimes it's worth it, sometimes not.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Louis Theran
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <B8942DBD.77B0%theran@cs.umass.edu>
On 2/16/02 14.31, in article ····················@192.168.1.50, "Erann Gat"
<···@jpl.nasa.gov> wrote:
> What I'm saying is that when it comes to associative maps -- an extremely
> important abstraction (arguably the most important in all of computer
> science, but that's another discussion) -- this philosophy of deferring
> decisions breaks down, at least within the bounds of the current
> standard.
It's not that hard to write a library that lets you do this. (We have such
a thing where I work.) Though you do have to write it. I agree that the
standard could have been more friendly in this regard, but it doesn't seem
to be getting in the way. Or am I missing something?
>> Also, alists and plists don't suffer from rehash problems upon garbage
>> collection.
>
> Now this is something I'm not familiar with. Could you elaborate?
I suspect that if you have an 'eq hashtable and the obvious (at least to
this non-implementor) implementation of eq, if GC moves the objects in the
hashtable, it will need to be rehashed. (Since the representation of
non-immediate objects will have changed.)
^L
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1702020745180001@192.168.1.50>
In article <····················@cs.umass.edu>, Louis Theran
<······@cs.umass.edu> wrote:
> It's not that hard to write a library that lets you do this. (We have such
> a thing where I work.) Though you do have to write it. I agree that the
> standard could have been more friendly in this regard, but it doesn't seem
> to be getting in the way. Or am I missing something?
No, I don't think you're missing anything. All I'm saying is that IMO
converging on a de facto standard for an abstract associative map not tied
to any particular implementation would be worthwhile.
E.
From: Christophe Rhodes
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <sqwuxbzx4d.fsf@cam.ac.uk>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <····················@cs.umass.edu>, Louis Theran
> <······@cs.umass.edu> wrote:
>
> > It's not that hard to write a library that lets you do this. (We have such
> > a thing where I work.) Though you do have to write it. I agree that the
> > standard could have been more friendly in this regard, but it doesn't seem
> > to be getting in the way. Or am I missing something?
>
> No, I don't think you're missing anything. All I'm saying is that IMO
> converging on a de facto standard for an abstract associative map not tied
> to any particular implementation would be worthwhile.
Oh, goody, a volunteer!
Or did you want this standard to appear magically?
Christophe
No, I'm not bitter :-)
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1902021428310001@eglaptop.jpl.nasa.gov>
In article <··············@cam.ac.uk>, Christophe Rhodes <·····@cam.ac.uk>
wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
> > No, I don't think you're missing anything. All I'm saying is that IMO
> > converging on a de facto standard for an abstract associative map not tied
> > to any particular implementation would be worthwhile.
>
> Oh, goody, a volunteer!
>
> Or did you want this standard to appear magically?
Not at all. I'd be happy to write a draft proposal, but before I do I'd
like some indication that someone besides me thinks this is worth doing.
Unlike Erik, I'm not always sure that I'm right about everything. I'd
also like some indication that even those who don't think it's worth doing
at least think it's not doing any harm. At the moment the feedback I'm
getting is pretty much the opposite.
E.
From: Jochen Schmidt
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a4uoc9$8fu$1@rznews2.rrze.uni-erlangen.de>
Erann Gat wrote:
> In article <··············@cam.ac.uk>, Christophe Rhodes <·····@cam.ac.uk>
> wrote:
>
>> ···@jpl.nasa.gov (Erann Gat) writes:
>
>> > No, I don't think you're missing anything. All I'm saying is that IMO
>> > converging on a de facto standard for an abstract associative map not
>> > tied to any particular implementation would be worthwhile.
>>
>> Oh, goody, a volunteer!
>>
>> Or did you want this standard to appear magically?
>
> Not at all. I'd be happy to write a draft proposal, but before I do I'd
> like some indication that someone besides me thinks this is worth doing.
> Unlike Erik, I'm not always sure that I'm right about everything. I'd
> also like some indication that even those who don't think it's worth doing
> at least think it's not doing any harm. At the moment the feedback I'm
> getting is pretty much the opposite.
Why don't you simply write the draft and put it on CLiki. There is a
section called "Common Lisp Utilities" which is described as:
"Common Lisp Utilities is (are?) no more than an idea at the moment.
Motivated by the benefits of discussing design issues in public, possibly
utilities "that everyone writes" could be canonicalized and
(semi-)standardized."
You can find the page at:
http://ww.telent.net/cliki/Common%20Lisp%20Utilities
If you really want to help enhancing Common Lisp you should try to reduce
complaining to a minimum and better spend this time for writing some code.
ciao,
Jochen
--
http://www.dataheaven.de
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223192332962598@naggum.net>
* Jochen Schmidt <···@dataheaven.de>
| If you really want to help enhancing Common Lisp you should try to reduce
| complaining to a minimum and better spend this time for writing some code.
Erann Gat does not want to enhance Common Lisp, he wants to feel better.
He wants to complain about how unenhanced Common Lisp is so others shall
feel bad about Common Lisp and abandon it like he did, validating his
poor and painful choices. He has both gained and lost his faith in Lisp
by less than rational means and somehow thinks this is bad, so instead of
facing irrationality head on and maybe, just _maybe_, cut his losses and
move on, he has to hang around those he thinks have not yet seen the
light and work hard to make them lose their faith, too. If he succeeds,
he can feel that he was at least not _wrong_ in losing his faith.
But effectively, he is _begging_ the community to take him back in and
restore his faith for him in the only way he knows how: Make people pity
him enough to do what he says he wants, because he wishes hard for people
to miss him so much that they would do this out of pity alone. (It tends
to work quite the opposite way, which means more effort to generate pity
and more hostile reactions to same.) One way he thinks he can make
people pity him enough to do what he wants for him is to complain about
Common Lisp's faults and short-comings, yet claim that he wants Lisp
well, and "oh, if only this were fixed, I could come back". But he wants
himself well. That is all. Right now, he thinks part of his feeling bad
is located in Common Lisp, and so if Common Lisp were improved, he would
be. This is not an uncommon reaction to loss of one's sense of identity,
because to some degree, one has _become_ what one does and believes.
It should be obvious that Erann Gat is hurting really bad right now, but
it is none of our business any longer because he uses such dirty tactics
to try to force people to help him out. We can obviously not "improve" a
programming language just to make one community member, who has made it
clear that he is about to leave, happy -- that is holding the whole
community hostage to the irrational grief of one person. Things do not
work this way, but lots of dire experiences can make someone think they
do, concluding in a preoccupation with one's own feelings to the extent
that the rest of the world becomes more or less irrelevant. Acute
depression has that effect on all people.
Let me quote from The Penguin Dictionary of Psychology to put this in a
context I hope few others have thought of:
bereavement: The emotional reactions felt following the death
of a loved one. A full depressive syndrome is considered
normal in such a loss and is often accompanied by poor
apetite, insomnia, and preoccupations with a sense of
worthlessness.
It appears to me that Erann's loss of faith is akin to the death of a
loved _idea_, all the worse because this idea was not rationally founded
("alive") to begin with, so its death is probably also associated with
some shame for having held it in the first place, and for so long.
Helping those who are in the grieving period after such a loss is very
hard, and generally requires much more "bandwidth" than the written word
can usually provide -- the level of pain suffered by those who turn to
write poetry to get it out of their system is not something people should
want to experience.
What can be done about poor, suffering Erann Gat at this point? Well,
first of all, he needs to get out of the rut he is in. I doubt that this
can be accomplished without severing contact with _all_ Lisp people for
an extended period of time -- he needs something to fight for, not just
Lisp to fight against. Whether he wants to return afterwards, is an open
question, but if he found something valuable that was _real_ in his faith
in Lisp, he might, or he might just go the way of wasting it all, like
Paul Graham did, who was obviously also unable to be happy with what
somebody else had done before him. Considering the invalidity of much
Erann's recent reasoning, it is not very surprising that he should think
that the commonality of "people who now do something other than Lisp"
should reflect badly on Common Lisp. However, there is absolutely no
reason to fault something people leave for anything at all unless what
they move towards is largely homogenous. All we see when people have
been using some language for a while and then move on to another is that
they did not find what _they_ could live with. It says more about them
than the language. After all, some other people bet their lives and
carreers on each language. Is something wrong with you if you do not
find the love of your life on the first try? How often have people
"drifted apart" for no apparent reason, only indicating that they had an
accidental proximity at a particular period in their "life trajectory"?
However reasonable the cause of a failure of a relationship to work, it
would be unreasonable _not_ to expect a period of grieving when what one
invested a lot in has ceased to have a future. I mean, we have all been
there, and it is somewhat peculiar to watch people rediscover the process
of losing loved ones all over again as if they expected some loved ones
to last forever. If we fear the loss as a consequences of investing in
something, we will never try anything: It is better to have loved and
lost than never to have lost at all.
- -
Since all of us believe in a lot of silly things that turn out to be
wrong at one point or another, learing to cope with being proven wrong
and being able to discard what was wrong and pick up something new and
better according to what one has learned, even though it means being a
novice for a while where one used to be an expert and a hot-shot, is
_vitally_ important if one is to get more than one chance to be right
about something. Therefore, such a stupid comment as "Unlike Erik, I'm
not always sure that I'm right about everything" says to me that the
person who utters this idiotic drivel is generally unable to cope with
being wrong, and thinks that those who are able to cope with it and are
therefore much less wrong that others, are _frauds_. That has a very
serious negative effect on his own psychological approach to certainty:
If he gets too certain, he believes it must be irrational, and certainty
and being right become orthogonal qualities. If I am an fairly confident
that I am right in what I believe at any time, it is because I have
discarded almost everything I have found to be wrong, and those beliefs I
still hold that I know to be wrong just keep getting me into trouble:
like believing in predictable taxation, that stupidity can be cured, that
there is a constructive element to everything people do -- you only need
to find it. Being right most of the time, means that you change your
mind according as the facts change. If you hang on to something after
the facts have proved otherwise, of course you will no longer be right,
but is this really an enviable position compared to discarding what is
wrong and moving on? Note that those who criticize others for being
right implicitly argue that to be an ordinary, decent human being, you
must believe in a bunch of wrong things, but not know which are right and
which are wrong, so you do not believe too strongly in what you believe
to be right. The real question, however, is what you do with stuff you
believe after it has been proven wrong. Some people fight the universe,
pray to various deities, go insane, ignore the facts and go on as if
nothing had happened. It seems that very few people actively seek
counterinformation, information that can prove them wrong, in their daily
life and for their common beliefs -- it is somehow a good thing in
science but bad for you elsewhere.
Being wrong often is an unavoidable consequence of thinking about things
and trying to see patterns and make sense of your experiences. Believing
that something is _right_ prematurely is the worst habit of non-thinkers,
however, and so they invest far too much emotional energy into what they
should have seen was wrong much earlier than they do, and thus being
wrong is associated with pain, but it is not: What is painful is hanging
on to what is wrong. Being wrong is _good_, because it means that one
has an active imagination and care about figuring things out, but unless
you are also a moron, you also learn something each time you were wrong,
thus making it more likely that your next move is better.
Now, what kind of person gets so strongly opposed to others being right
that they make a point out of harrassing them for it? People who are
wrong, who know they are wrong, but do not _want_ to change their mind,
because their beliefs are far more comfortable to live in than the real
world.
Now, I wonder if Erann Gat can go heal somewhere else. It should be
clear even to him that he does not heal here.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2002021157430001@eglaptop.jpl.nasa.gov>
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> * Jochen Schmidt <···@dataheaven.de>
> | If you really want to help enhancing Common Lisp you should try to reduce
> | complaining to a minimum and better spend this time for writing some code.
>
> Erann Gat does not want to enhance Common Lisp, he wants to feel better.
Hm, an interesting theory. Plausible, but wrong, though I can think of no
way to convince you of that so I won't try.
Since we're all psychoanalyzing each other by remote control, I think I'll
take a shot at it too.
Erik Naggum does not want to enhance Common Lisp, he wants to be in
control. He has a set of Rules of conduct that he rarely makes explicit
(because he likes to change them around depending on the situation), but
which include things like "Always assume that whatever Erik says is
correct." (That one, he actually made explicit a while back.) They also
include nebulous things like "don't act stupid" (where Erik, of course, is
the ultimate arbiter of what is and is not stupid). They also include
perfectly sensible rules from which Erik (and his followers -- we'll get
to them in a moment) are uniquely exempt, like "Don't feed the trolls."
(What is this "Erann Gat just wants to feel better" bullshit if not a
troll?)
The Rules apply to everyone except Erik, who is free to badger, insult,
troll, and conduct himself in a generally uncivilized manner without
repurcussions. This is because in Erik's mind he alone knows what is
right and true and good for Lisp and good for this newsgroup. He is judge
and jury, and to the extent possible on Usenet, executioner. And he makes
a surprisingly effective executioner because has no inhibitions whatsoever
about conducting himself in the most vile manner. Even after watching him
for many, many years he often surprises me with the depths to which he is
willing to sink himself.
Unfortunately, Erik is not just a megalomaniacal lunatic, but he is also a
bright guy who knows a lot about a lot of things, including Lisp. (Not
surprising. Lots of megalomaniacs are very smart.) Because of this, and
the fact that disagreeing with Erik can have a very high price, most
people who are willing to call him on his mistakes and his bad behavior
are unwilling to do so. I'm an exception, which is why I drive Erik
absolutely bonkers.
Surprisingly (or maybe not) Erik has attracted a loyal band of followers
despite his patently antisocial behavior. (Every now and them one of them
crawls out of the woodwork to defend him when he gets into a fight. I am
reminded of the Jafar's parrot Iago in the movie Aladdin.) Of course, in
Erik's mind everyone wants to be in this elite clique, but only people who
obey The Rules are allowed. Therefore anyone who persistently breaks the
Rules must be either mentally ill or motivated by a passionate need to
gain Erik's approval without kissing his ass, which is, of course, not
possible.
How do I know all this? Well, I don't really, but it's a theory that fits
all the observed facts, including the following: Erik and I met once, at
the Lisp Users Group conference in San Francisco. We had dinner, and got
along quite well. I know, it's hard to believe, but there were witnesses.
What I did not realize at the time was that I had actually been accepted
as a junior member of Erik's little band. I know this because shortly
after the conference was over, Erik invited me to do a little of his dirty
work for him, as he sometimes relies on his liutenants to do. The record
of that invitation is preserved here:
http://groups.google.com/groups?selm=3150545409149313%40naggum.no&output=gplain
Unfortunately, I sent my refusal via email, so there is no public record
of it. All I know is that was the last time Erik and I ever got along.
E.
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223229945449312@naggum.net>
* Erann Gat
| Since we're all psychoanalyzing each other by remote control, I think I'll
| take a shot at it too.
Hm, an uninteresting theory. Implausible, and wrong, though I can think
of no way to convince you of that so I won't try.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a515p8$3t2q8$1@ID-125440.news.dfncis.de>
In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> Erik Naggum does not want to enhance Common Lisp, he wants to be in
> control. He has a set of Rules of conduct that he rarely makes explicit
> (because he likes to change them around depending on the situation), but
> which include things like "Always assume that whatever Erik says is
> correct." (That one, he actually made explicit a while back.)
Erik's saying this really made you angry, apparently; you've mentioned it
several times by now. I always wanted to ask you why. Maybe it's
because you're a scientist, not somebody who grew up in CS or mathematics,
as I did. To me, this attitude sounds totally normal: When I make a claim
about mathematics, I expect people to assume I am correct. And large
parts of CS, especially those parts dealing with languages, could also
be viewed as part of mathematics (that's where they come from, isn't it).
I switched to CS years ago, but didn't find much reason to change that
attitude: I may be far from that point in Lisp, but when I make a claim
about the C language, I expect people, too, to assume I am correct.
Moreover, I would feel *very* insulted if anybody didn't and probably
spit fire. That doesn't even mean that I know everything about the C
language, but only that I am perfectly aware of what I *know* and what
I only *believe* to be correct, just as no mathematician would ever
make a claim about some remote field he doesn't know much about,
if he knows that he isn't /at home/ enough in the field to make sure
his claims are correct. In fact, if he only /once/ made a false
claim about something mathematical, his reputation would immediately
drop considerably; two or three more times and nobody will read /any/
line he writes in the future.
I would really be surprised if this was different among scientists.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2002021645050001@eglaptop.jpl.nasa.gov>
In article <··············@ID-125440.news.dfncis.de>, Nils Goesche
<······@cartan.de> wrote:
> In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
>
> > Erik Naggum does not want to enhance Common Lisp, he wants to be in
> > control. He has a set of Rules of conduct that he rarely makes explicit
> > (because he likes to change them around depending on the situation), but
> > which include things like "Always assume that whatever Erik says is
> > correct." (That one, he actually made explicit a while back.)
>
> Erik's saying this really made you angry, apparently; you've mentioned it
> several times by now.
I think I mentioned it twice. And "annoyed" is a better description than
"angry".
> I always wanted to ask you why. Maybe it's
> because you're a scientist, not somebody who grew up in CS or mathematics,
> as I did. To me, this attitude sounds totally normal: When I make a claim
> about mathematics, I expect people to assume I am correct.
The phrase "I expect people to assume I am correct" is open to
interpretation. It could mean, "I expect people to give me the benefit of
the doubt and (tentatively) assume I'm correct unless (and until) they
have a good reason to believe otherwise." Or it could mean, "I expect
people to assume I am correct no matter what the circumstances." The
former position is reasonable (I hold that expectation myself), the latter
is not IMO.
The situation in this case was the following: Erik made a claim. Someone
responded and said Erik was not correct, and suppoerted their dissent with
a citation from the CLHS. So when Erik said, "assume I am correct" it was
in a context where someone had a good reason for thinking he might not
be. It's not unreasonable to suppose then that Erik's intention was the
latter interpretation, which I find unreasonable.
Does that answer your question?
E.
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a51ite$3v04m$2@ID-125440.news.dfncis.de>
In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> In article <··············@ID-125440.news.dfncis.de>, Nils Goesche
><······@cartan.de> wrote:
> The situation in this case was the following: Erik made a claim. Someone
> responded and said Erik was not correct, and suppoerted their dissent with
> a citation from the CLHS. So when Erik said, "assume I am correct" it was
> in a context where someone had a good reason for thinking he might not
> be. It's not unreasonable to suppose then that Erik's intention was the
> latter interpretation, which I find unreasonable.
>
> Does that answer your question?
Yes, it does, but unfortunately this was the only answer I could think
of myself... I think it's wrong ;-) Possibly unlike Dr. Weitz, you
know Erik for a long time, and should know that there is one thing
he is not exactly known for: being ``unreasonable''. So, it is rather
unreasonable to assume that the latter interpretation was intended :-)
But whatever, debates like this have already been held a hundred
times before. Let's not make this another one.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Alain Picard
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <86664r6vei.fsf@gondolin.local.net>
···@jpl.nasa.gov (Erann Gat) writes:
> The situation in this case was the following: Erik made a claim. Someone
> responded and said Erik was not correct, and suppoerted their dissent with
> a citation from the CLHS. So when Erik said, "assume I am correct" it was
> in a context where someone had a good reason for thinking he might not
> be.
Well, it turned out Erik was right. So the "good reason" probably
wasn't "good enough". The original poster's interpretation of the
spec differed from Eric's post. Eric's "just assume I'm correct" is
basically saying: next time your understanding of the standard differs
from what I post, first try to see if you can get "another
understanding" FIRST, or ASK about your current understanding, rather
than saying: you're wrong because the spec says so.
This seems perfectly innocuous to me, as explained by Nils. Don't
speak ex-cathedra unless you really mean it.
In fact, that's one of the things I _love_ about CL: there's all this
stuff in the grey book I just _don't understand_. The great thing about
it is I'm pretty convinced that _I_'m missing something deep there,
and I should keep digging. I _never_ assume something is stupid or
badly designed or "useless old baggage" in CL anymore. Then, months
later, I'll be trying to solve a problem and go a-HA! So THAT's
why that's [there|the way it is]! Great feeling. :-)
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223354178835416@naggum.net>
* Erann Gat
| The phrase "I expect people to assume I am correct" is open to
| interpretation. It could mean, "I expect people to give me the benefit
| of the doubt and (tentatively) assume I'm correct unless (and until) they
| have a good reason to believe otherwise." Or it could mean, "I expect
| people to assume I am correct no matter what the circumstances." The
| former position is reasonable (I hold that expectation myself), the
| latter is not IMO.
What does "assume" mean to you, Erann? What _you_ assume may indeed be
indistinguishable from fact and belief because _you_ never bother to
check the assumption, but other people are more intelligent and do not
act on assumption alone.
| The situation in this case was the following: Erik made a claim.
| Someone responded and said Erik was not correct, and suppoerted their
| dissent with a citation from the CLHS. So when Erik said, "assume I am
| correct" it was in a context where someone had a good reason for thinking
| he might not be. It's not unreasonable to suppose then that Erik's
| intention was the latter interpretation, which I find unreasonable.
We can trust you to find unreasonable interpretations of anything I say,
Erann. It is your chosen role in this forum, now. Nothing I say must be
allowed to pass without your helpful "interpretation" and I am certainly
not allowed to be jocular, not to use irony or sarcasm, or pull your leg
or anyone else's. This must be a dead serious forum, suitable for the
highly shizophrenic reader like yourself who fail to grasp the tone of
_any_ message I write and who need to have everything served in very
clear-cut form with no room for confusion. Do you want an example, now?
Let me quote an entire paragraph from you, quite recent, I do not need
google to dig up dirt on you, you see:
What I did not realize at the time was that I had actually been
accepted as a junior member of Erik's little band. I know this because
shortly after the conference was over, Erik invited me to do a little
of his dirty work for him, as he sometimes relies on his liutenants to
do. The record of that invitation is preserved here:
http://groups.google.com/groups?selm=3150545409149313%40naggum.no&output=gplain
I assume he means the last paragraph:
Erann Gat, are you still there? can _you_ get this insufferable moron
to take a hint? feel free to use a fairly heavy and blunt instrument.
Do _anyone_ else not see this as a stab at Erann's incessant willingness
to be a royal pain in the ass in this forum? Is it more reasonable to
"interpret" this as a request to some "liutenant" or to consider it an
joke at the expense of the overzealous moralist named Erann Gat who has
been known to run after me with heavy and blunt instruments in this
forum? Now, being a joke, could it be _ridiculing_ that role, when Erann
and I got along.
How _is_ it possible to think in terms like "Erik's little band"? Is
that how Erann himself felt after the fact? And where else do we find
this notion of "Erik's little band", if not in the minds of the truly
nutty who feel that I somehow commandeer the newsgroup against someone
who is clearly in the wrong quite independently of what I do or say?
There are people with some really interesting paranoid delusions out
there, and one of the most interesting ones must be that of me conducting
some kind of clandestine, behind-the-scenes operation against nutty
people. Of course, if you are nutty, it is just _great_ to find a way to
blame a particular individual for your "hardship" instead of trying to
figure out why a lot of people are "against" you or what you do. When I
observed wave after wave of attackers against me at a time, it sure
_looked_ like they were all trained by Marcus Daniels, using the exact
same rhetoric and the same amazing willingness to "interpret" that we
find in Erann Gat's postings, but they are all gone, and they never
contributed to this forum in any technical capacity, either.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2202020852260001@192.168.1.50>
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> We can trust you to find unreasonable interpretations of anything I say,
And we can trust you to find unreasonable interpretations of anything I say.
> Erann. It is your chosen role in this forum, now.
My chosen role in this forum is to present a number of points of view.
They are:
1. Despite the fact that Lisp had many more major language features much
earlier than most other languages, it isn't perfect, and should continue
to evolve if it is to keep its competitive edge.
2. That conclusions ought to be drawn from evidence and not from
arguments-from-authority.
3. That you aren't always right about everything, and that assuming you
are, while it may be a good heuristic for staying out of trouble, is not
100% effective at arriving at the truth.
> I am certainly
> not allowed to be jocular, not to use irony or sarcasm, or pull your leg
> or anyone else's.
Sure you are. But if you are allowed to do these things, then so am I. I
have never said you are not *allowed* to do these things. My position has
always been simply that you would be more effective if you didn't.
> and they never
> contributed to this forum in any technical capacity, either.
I must take exception to this. If not for me the contentions that it
takes 50 bindings to break even using hash tables instead of alists, and
that C++ and Lisp use the same binding protocols, might have gone
unchallenged. I consider those to be technical contributions.
We'd both have more time for technical contributions if we weren't
fighting with each other all the time. I'm ready to call this off any
time you are.
E.
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223396023393870@naggum.net>
* Erann Gat
| And we can trust you to find unreasonable interpretations of anything I say.
You have no basis for this stupid retort.
| 1. Despite the fact that Lisp had many more major language features much
| earlier than most other languages, it isn't perfect, and should continue
| to evolve if it is to keep its competitive edge.
An instance of the bleeding obvious with which nobody disagrees.
| 2. That conclusions ought to be drawn from evidence and not from
| arguments-from-authority.
An instance of the bleeding obvious with which nobody disagrees.
| 3. That you aren't always right about everything, and that assuming you
| are, while it may be a good heuristic for staying out of trouble, is not
| 100% effective at arriving at the truth.
An instance of the bleeding obvious with which nobody disagrees.
You clearly did not read the article you responded to when you found yet
another moronic reason to hurl yet another moronic accusation my way. I
suggest you actually read it, now, lest you repeat something that has
already been strongly refuted and falsified.
| Sure you are. But if you are allowed to do these things, then so am I.
| I have never said you are not *allowed* to do these things. My position
| has always been simply that you would be more effective if you didn't.
Yes, towards you and in your view, which I am obligated to disregard
because you are clearly nuts and unable to provide a balanced view or
even information.
| We'd both have more time for technical contributions if we weren't
| fighting with each other all the time. I'm ready to call this off any
| time you are.
Coward. I am not ready to call this off, as I think you are truly evil
and as long as you keep posting your purely destructive bullshit about
me, about Common Lisp, about other respected Lispers, you _will_ receive
harsh replies. You can stop fighting unilaterally. Unlike you, I do not
attack people who do not post anything bad. I do _not_ make the first
move. That is your peculiar modus operandi, and one for which you should
learn to accept full responsibility. One way to do that is to accept the
_humiliation_ you will feel if you quit posting your usual crap about and
to me. You will feel soundly defeated in your own view, but it is only
in your view, because you are completely nuts and so enraged at the
moment that you think that you will "lose face" if you do not respond.
If you feel this way, as I suspect, it is all the more important that you
actually stop fighting unilaterally.
Also, please realize this, because you are so hard of learning and have
such an investment in vilifying me far beyond anything reasonable, I am
not responding to your extremely disgusting behavior, but your abuse of
this forum with your incessant loads of crap, disinformation, confusion,
and general ill will. Just stop, return to whatever cave your ilk comes
from, and things will return to normal. Keep filling up this forum with
your special kind of putrid disinformation, and you _must_ be fought, not
just by me, but by anyone who wants comp.lang.lisp to be about Lisp, to
foster an environment and a community where professional Lispers and
those who want to become professional Lispers can find both personal and
professional needs fulfilled. You do neither, and it is your choice.
There is nobody you can blame for your behavior. Accept this and shut up.
And if you are so goddamn happy about Python, go kick up some dirt in
comp.lang.python, instead of making life so miserable for those who are
quite happy with Lisp and who are working tirelessly to make the world of
Lisp so much more enjoyable. You are hurting the community and the
ability of people to feel good about what they do. In this forum, you
are en evil influence. Whatever happened to your stupid "faith" in Lisp,
it is no longer our concern when you turn into a destructive bastard who
blames other people for your lack of self-control.
Show us that you are a man, and just quit.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Harald Hanche-Olsen
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <pcosn7veokz.fsf@thoth.math.ntnu.no>
+ Nils Goesche <······@cartan.de>:
| When I make a claim about mathematics, I expect people to assume I
| am correct. And large parts of CS, especially those parts dealing
| with languages, could also be viewed as part of mathematics (that's
| where they come from, isn't it). I switched to CS years ago, but
| didn't find much reason to change that attitude: I may be far from
| that point in Lisp, but when I make a claim about the C language, I
| expect people, too, to assume I am correct. Moreover, I would feel
| *very* insulted if anybody didn't and probably spit fire. That
| doesn't even mean that I know everything about the C language, but
| only that I am perfectly aware of what I *know* and what I only
| *believe* to be correct, just as no mathematician would ever make a
| claim about some remote field he doesn't know much about, if he
| knows that he isn't /at home/ enough in the field to make sure his
| claims are correct. In fact, if he only /once/ made a false claim
| about something mathematical, his reputation would immediately drop
| considerably; two or three more times and nobody will read /any/
| line he writes in the future.
I think you're exaggerating here. First, in mathematics there is of
course a difference between conjecture and proved theorems. But more
importantly, the occassion and mode of communication make a big
difference here. While arguing in front of a blackboard, for example,
mathematicians frequently make mistakes, and sometimes quite
elementary ones. Another example - I recently stood in for a
colleague, teaching his PDE class while he was out traveling. In just
a handful of pages of the textbook I came across two serious errors.
Is the book crap? No, in fact I still think it seems quite good,
though my experience indicates that the author ought to have spent
more time ensuring the quality of his product. Anyway, I wrote the
author, and far from being snappish, he was in fact quite grateful. I
would not dream of avoiding his writings in the future because of this
incident. Errors even make it into refereed journals, quite more
often than we would like to believe. But here, of course, the
standards are higher, and closer to what you suggest: You cannot
afford too many errors in journal articles - or even preprints -
without your reputation suffering seriously. But in some cases we are
more forgiving than in others. Case in point: Andrew Wiles' proof of
Fermat's Last Theorem. His first proof turned out to have a gap in
it. After what must have been a very tense year for him, he managed
to bridge it. The proof was such an impressive piece of work that I
don't think anybody would hold this mistake against him. (Though if
he had failed to fix the proof, things might have been different.)
Anyway, one nice thing abouth mathematics is that you don't have to
*assume* someone is correct. You can check it yourself. But if I
hear someone say something about mathematics that seems to contradict
what I know to be true, I will say so. Not because I don't believe
the other person, but because the contradiction needs to be resolved.
Sometimes it turns out I am wrong, and other times the other person is
wrong. But more often, there were underlying assumptions of which I
was unaware, but which explain why there is no contradiction after
all. In all my experience as a mathematician, this mode of discussion
has never caused any animosity or hurt feelings. Maybe I have just
been lucky, or perhaps computer scientists really are different?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a51dhp$3s1bu$1@ID-125440.news.dfncis.de>
In article <···············@thoth.math.ntnu.no>, Harald Hanche-Olsen wrote:
> + Nils Goesche <······@cartan.de>:
>
>| When I make a claim about mathematics, I expect people to assume I
>| am correct.
[snip]
> I think you're exaggerating here. First, in mathematics there is of
> course a difference between conjecture and proved theorems.
But conjectures have better be labeled as such :-)
> But more importantly, the occassion and mode of communication make a big
> difference here. While arguing in front of a blackboard, for example,
> mathematicians frequently make mistakes, and sometimes quite
> elementary ones.
Of course, everyone does. I have yet to see a book on mathematics
that didn't contain little or even gross errors in some of its
proofs. And correcting those glitches, no matter whether on the
blackboard or in books is indeed much appreciated by the
authors/lecturers, by me, too, when I held lectures. I meant wrong
claims on a somewhat larger scale; Wiles proofs surely contained a
(large?) gap, /but not one he couldn't fill/. The claim was, as I'd
put it, that there is a proof for Fermat's conjecture the way he
described. Ok, there was a gap, but after filling it, his proof
worked -- he didn't come up with a totally new one. If a book or
a paper contains some little errors, that's fine if those errors
can be corrected by the reader. It would /not/ be fine if the
theorems were fundamentally wrong.
And, of course, the tone matters a lot: In one paper I read that
was very important for me was something I couldn't follow, no
matter how hard I tried (for a few days). I sent an Email to
the author, who explained very friendly why that particular claim
in fact held. I am sure he did that because I formulated my Email
as a question. I did /not/ claim that there was something wrong
with his paper because it contained a /major gap/. It wasn't a
major gap, actually he gave a short explanation how it could
easily be filled, and I think if I had claimed that there was a
major gap in his proof, he would (rightfully) be angry at me.
On the other hand, if there /were/ a major gap in his proof, or
even a fundamental error, I wouldn't hesitate to point that out,
either: He'd see for himself that there is one.
Unfortunately, I once met someone who couldn't do that. I was
still a student at the University, and fellow students came
to me asking how to solve some homework problem, I think something
like ``Proof that a curve c : [a,b] -> R^n which is continous on
[a,b] and C^1 on [a,b) has finite arc length.'' I told them
that that claim was wrong, just consider
x -> (x, x sin 1/x), -1 <= x < 0, continously extended to 0.
They went and told their assistant teacher so. She insisted
that the homework problem was correct. They came get me, and the
assistant teacher and I had an argument for about an hour,
which became quite heated. The audience grew and grew,
everybody knew I was right, in fact I am sure that even /she/
knew that, but for some strange reason couldn't admit it in front
of students. The next day, the professor, who /invented/ the
homework problem in the first place, saw me, smiled, said
``nice counterexample'' and went into his office.
So, all I'm saying is: When you correct someone, either ask or better
be right :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Dr. Edmund Weitz
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <m3vgcr7ivk.fsf@bird.agharta.de>
Nils Goesche <······@cartan.de> writes:
> And, of course, the tone matters a lot: In one paper I read that was
> very important for me was something I couldn't follow, no matter how
> hard I tried (for a few days). I sent an Email to the author, who
> explained very friendly why that particular claim in fact held. I
> am sure he did that because I formulated my Email as a question. I
> did /not/ claim that there was something wrong with his paper
> because it contained a /major gap/. It wasn't a major gap, actually
> he gave a short explanation how it could easily be filled, and I
> think if I had claimed that there was a major gap in his proof, he
> would (rightfully) be angry at me. On the other hand, if there
> /were/ a major gap in his proof, or even a fundamental error, I
> wouldn't hesitate to point that out, either: He'd see for himself
> that there is one.
>
> Unfortunately, I once met someone who couldn't do that. I was still
> a student at the University, and fellow students came to me asking
> how to solve some homework problem, I think something like ``Proof
> that a curve c : [a,b] -> R^n which is continous on [a,b] and C^1 on
> [a,b) has finite arc length.'' I told them that that claim was
> wrong, just consider x -> (x, x sin 1/x), -1 <= x < 0, continously
> extended to 0. They went and told their assistant teacher so. She
> insisted that the homework problem was correct. They came get me,
> and the assistant teacher and I had an argument for about an hour,
> which became quite heated. The audience grew and grew, everybody
> knew I was right, in fact I am sure that even /she/ knew that, but
> for some strange reason couldn't admit it in front of students. The
> next day, the professor, who /invented/ the homework problem in the
> first place, saw me, smiled, said ``nice counterexample'' and went
> into his office.
>
> So, all I'm saying is: When you correct someone, either ask or
> better be right :-)
Yeah, if you're living in a world where everyone is unforgiving and
mistakes are not allowed.
If you know what you're doing and you're sure of yourself, there's no
reason to get angry at somebody who thinks you've made a mistake
IMHO.[1] If you can prove that you are right - fine, explain it to
him. If it turns out that you are wrong - well, no big deal either,
your whole self-confidence shouldn't be based on the assumption that
you are infallible. If someone instantly starts to yell at people
because they dared to think he could have made a mistake, that's just
a sign of his lack of self-assurance.
I've worked with mathematicians for more than ten years and I've met
some of the real heavy-weights. I've never seen one of them getting
angry, no matter how dumb or ignorant the person the talked to seemed
to be. An attitude like "I know what I'm doing and you better get your
things together before you question that" I've only seen with younger
students. They either vanished rather quickly or they finally grew up.
And of course you're right - tone matters a lot. That applies to both
sides, though.
Cheers,
Edi.
[1] Well, if that same person does the same thing repeatedly and if
he's always wrong, you might get a little upset sooner or
later... :)
--
Dr. Edmund Weitz
Hamburg
Germany
The Common Lisp Cookbook
<http://cl-cookbook.sourceforge.net/>
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a51hqh$3v04m$1@ID-125440.news.dfncis.de>
In article <··············@bird.agharta.de>, Dr. Edmund Weitz wrote:
> Nils Goesche <······@cartan.de> writes:
>> So, all I'm saying is: When you correct someone, either ask or
>> better be right :-)
> Yeah, if you're living in a world where everyone is unforgiving and
> mistakes are not allowed.
>
> If you know what you're doing and you're sure of yourself, there's no
> reason to get angry at somebody who thinks you've made a mistake
> IMHO.[1]
That's it: In your humble opinion. People are different, this whole
issue is about feelings. I don't yell at people that easily, either,
but I know several people who do. I don't mind if they yell at me
if I understand why they do and why they think, right or not, that it
was my fault. Those people are, in my experience, much /easier/ to
get along with because you can trust them: You know they don't have
a serious grudge against you when they are not yelling at you at the
moment. Those are exactly the people who are /not/ unforgiving.
People live under different rule sets. A very good friend of mine,
a Russian, has the habit of not laughing only because other people
do. Believe it or not, many Germans hate her for being arrogant
and what not because of that. I don't, because I understand why she
does what she does: She thinks that it would just be /false/ and
/lying/ if she pretended to find something funny when she didn't.
I like that. Her way might be ``impolite'' by German standards,
but when I'm with her and she laughs about something I said, I know
she does so because she thinks it's funny. It's just a different
way, even it is kind of ``forbidden'' by our politeness rules.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223352914239792@naggum.net>
* Dr. Edmund Weitz
| Yeah, if you're living in a world where everyone is unforgiving and
| mistakes are not allowed.
You have an obligation to a public forum to do your best. Mistakes are
certainly allowed, but when you start with the assumption that you are
correct and that somebody else is wrong and you do not even need to
bother to check the _references_, it is not _mistakes_ that are not
allowed, but sloppiness and laziness and the arrogance that come with
them. And drop the stupid bitterness -- just do better.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223319435692942@naggum.net>
* Harald Hanche-Olsen <······@math.ntnu.no>
| Anyway, one nice thing abouth mathematics is that you don't have to
| *assume* someone is correct. You can check it yourself.
This, too, has been blown out of proportion by the former Lisper turned
village idiot, Erann Gat, so let me try to explain a few things:
To assume that what someone says is correct does _not_ mean to believe
it, _not_ agree with it, and _not_ use it without establishing that it is
in fact correct. General assumptions make a very bad basis for action,
although for Erann Gat, something else must be going on since he reacts
to hostilely to such a simple statement.
If you read what someone writes and assumes it is correct, that meaans
that someone offers you possible counterinformation to something you
believe which may be contradictory or at least different, and you would
spend the time to _investigate_ the challenge. To assume that another
person is correct in what they write or say, is the _obvious_ position
you would take in learned company, in a professional forum, wherever
people speak in order to be helpful and to gain credibility, although for
Erann Gat, this is obviously not the purpose of comp.lang.lisp.
If you do _not_ read what someone writes and assumes it is correct, that
means that -- _before_ you have investigated it -- you feel righteous in
your conclusion that it is a fraudulent use of the forum, and you assume
that people are posting crap in order to annoy and confuse people. This
is indeed the position that Erann Gat holds about comp.lang.lisp, but he
is probably unable to introspect sufficiently to see what he is doing.
If you read what someone writes and assumes they are _incorrect_, that
means that your obnoxious arrogance has reached religious proportion.
This is the position that Erann Gat holds about himself, and which he
shared with every idiot who has ever posted to USENET: people are _not_
going to teach him something by disagreeing with him, and he fights me,
in particular, _because_ I am both right and disagreeing with him, and he
cannot change his mind because that means loss of "honor" to that kind of
primitive pre-intelligent human.
Now, what does it _really_ mean to assume that something you read is
correct? It means that crap that _is_ posted by the likes of Erann Gat,
receives far more initial credibility than it deserves. In effect, the
abuse of the forum becomes all the greater when crap is posted to a forum
where people take articles and eachother _seriously_. It is _because_ we
need to assume that other people's articles are correct and that they
post in a benevolent spirit that the criminals among us become so
villainous. People who each listen to others and go investigate when
they disagree have a right to get pissed if they were sent on a wild
goose chase or were the subject of a "practical joke". Taking another
person seriously and listening to them means that you try to figure out
where they come from, how they arrived at their unexpected conclusion,
ask them questions when you do not understand, etc. People who are not
of the serious kind, such as Erann Gat, completely fail to grasp what is
going on in a forum where people meet for the benevolent exchange of
_real_ information -- to get _informed_.
Let me give you a pretty simple example: If someone posts a question like
"which are the primitives in Common Lisp" and some jerkface posts a bogus
list of functions, the requestor, as well as every other member of the
forum, have a right to assume that it is at least intended to be correct.
Now, there _is_ no clearly defined set of primitives, no accepted way to
define what a primitive is, nor has anybody done any serious work in
trying to make such a definition. What then, is that list of functions?
It is an abuse of the forum, perpetrated by a jerkface who has failed to
understand that people come to that forum to seek help and be informed,
and who really thinks it is about jerking people around, being hostile to
the uninitiated, ridiculing the uninformed, etc. This is what Erann Gat
wants comp.lang.lisp to be when he rails against the assumption that
other writers and me in particular post stuff that is correct, and he
does an admirable job of tricking people into answering his bogus claims
and his ludicrous assertions.
Having _respect_ for another person is precisely the assumption that what
they say is not some unserious load of crap. I maintain that respect
must be the initial state towards other people. You do _not_ assume that
what someone else whom you do not know says is bogus crap on the face of
it. You have no reason to believe they are ridiculous morons, so you do
not treat them like it, either. However, there is _no_ better way to
smoke out the ridiculous moron than to treat him seriously. Richard
Feynman had an interesting metric about honest and competence that I took
to my heart. He said (paraphrased, because I cannot find the source),
that if you ask an honest and competent man intelligent questions about
his field (and I believe this is true for every field of human endeavor)
in order to really understand it, he will sooner or later run out of
answers.
This means that if you are really knowledgeable and know what you know
and separate it from what you are less than uncertain about, you will
know when to stop answering and start questioning yourself. Keep it up
for a while, and you will have a lot more answers, but you must still be
prepared not to know. But what do you do in a public forum where you
assume that your readers assumes that what you say is correct and you do
not know the answer? YOU DO NOT RESPOND! This is completely foreign to
a lot of the idiots out there, who think that because they see that
someone is certain about the answers they give those who ask, they must
be about everything else, too. It is a phenomenal _discourtesy_ to a
forum to post guesswork and halftruths and outright lies because you
"have to answer something", and it would be completely intolerable if
everybody had to answer every question and have to say "I don't know".
For someone who expects his readers to assume he is right, posting an
answer one is not certain about without saying precisely that is a
cardinal sin. Even answering something where one's knowledge and skills
are outright missing is potentially dangerous, because of the stupid
human tendency to associate "honor" with one's public positions (even if
you do not assume that your readers assume that it is correct), and then
it is harder to back down from it, or to retreat. This means that in
order to _learn_, you soak up everything people say, try to piece it
together and ask intelligent quesetions, but when the time comes to help
others out in a like manner, you do not _stop_ assuming that they are
correct, that they have done their homework, too, that they have not done
the best they could in the time available before they posted. Quite the
contrary, the more you know, the larger the surface of the sphere that
touches what you do not know, and the more you need to listen carefully
to others. However, the more you know, the more you see that others are
full of crap, that they post mindless shit because they need to feel good
about posting to a public forum and _look_ like they know what they are
talking about or because they feel good about themselves if they become
_visible_ to other people by virtue of the replies they generate. (I
could go on a tangent here about the deep psychological need to be "seeN"
by others, seen in everything from pets who destroy furniture to get the
owner's attention via children who destroy furniture to get the parents'
attention, to U.S. Presidents who do really stupid things in order to be
the center of world attention (at least I hope he had no better excuses).)
So when I say that you should assume that what I write is correct, only
someone like Erann Gat would interpret this as an emphasized "I". It is
a general position you take in a public forum, not my personal need. But
to someone with an inflated and/or seriously bruised ego, of _course_ it
reads as "Look at me! I'm certain about everything", and of _course_ he
rails against that. However, you seem to have to post a lot of things
that you _knew_ to be wrong at the time to approach Erann Gat's moral
standards of "human". The ability to know when you know and when you
must learn more, does not seem to fit with his modus operandi, but in
order for a public forum to work, we _must_ minimize the number of idiots
who post crap that abuses the _tacit_ and _general_ assumption that what
people post is in fact correct, at least as they see the world.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2102021453360001@eglaptop.jpl.nasa.gov>
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> To assume that what someone says is correct does _not_ mean to believe
> it, _not_ agree with it, and _not_ use it without establishing that it is
> in fact correct.
Ah, yes, I just remembered another one of Erik's Rules: he subscribes to
the Humpty-Dumpty theory of langauge: when Erik uses a word it means
precisely what Erik wants it to mean, neither more nor less. Those of use
who rely on dictionary definitions or common usage to determine the
meaning of what he says are out of luck. Note too that this is an example
of Erik's pesonal exemption from the Rules he expects everybody else to
live by, as he often takes people to task for disregarding standards.
I choose to subscribe the Tom Stoppard theory of language. (This is from
Stoppard's play "Travesties".) "If there is any point to using langauge
at all it is that words are taken to stand for certain thoughts and ideas
and not for other thoughts and ideas."
Foo!
E.
From: Kent M Pitman
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <sfwr8ne2yx1.fsf@shell01.TheWorld.com>
[I took this out of context and have mostly not been following this thread.
I edited out the interpersonal issues, which I'd prefer to stay clear of.]
···@jpl.nasa.gov (Erann Gat) writes:
> I choose to subscribe the Tom Stoppard theory of language. (This is from
> Stoppard's play "Travesties".) "If there is any point to using langauge
> at all it is that words are taken to stand for certain thoughts and ideas
> and not for other thoughts and ideas."
You say this as if there were no value to confusion. Language is very
flexible in its ability to simultaneously support what the speaker
says AND what the hearer wants to hear, regardless of how incompatible
those two might be.
As a career politician of sorts, I have to wonder if anything useful
could be done at all in the world if language really made hearers know
what speakers intended in all cases.
As a sometimes writer of humor, I am certain that for words to mean
only one thing would be very dry.
As an avid watcher of soap operas, I know there would be many fewer
good plots to be watched if people spoke plainly and were readily
understood.
Language survives only because it is so blunt and vague as it is; were
it made more precise, we would probably all kill each other, or
perhaps just stop talking to one another, but we would surely never
again for all future time reach an agreement. If you don't understand
what I mean by this, it's time to rent "A Man for All Seasons" and pay
particular attention to Sir Thomas's remark about an oath meaning
"what the words say", which is masterful irony because what he means
by this is that he may be able to say the words if he thinks they mean
differently than what the oathmakers think... that is, he introduces a
third party, which are "the words themselves" which seem to know their
own meaning. But then, again quoting from memory of the later trial
scene, "the world must construe according to its wits, [the] court
must construe according to the law". So I'll go with the author of
both play and film, Robert Bolt, in his subtlely made point that
survival in a world of words is best made, if at all, through clever
appeal to ambiguity.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2102021918320001@192.168.1.50>
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> [I took this out of context and have mostly not been following this thread.
> I edited out the interpersonal issues, which I'd prefer to stay clear of.]
Coward.
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > I choose to subscribe the Tom Stoppard theory of language. (This is from
> > Stoppard's play "Travesties".) "If there is any point to using langauge
> > at all it is that words are taken to stand for certain thoughts and ideas
> > and not for other thoughts and ideas."
>
> You say this as if there were no value to confusion.
The value of anything depends on one's goals. Confusion is often of great
value to charlatans, as it helps them conceal the fact that they are
charlatans.
I prefer clarity. The words "I choose" at the beginning of my statement
are not there just to take up space.
> As a career politician of sorts,
A politician who prefers to stay clear of interpersonal issues?
Interesting. Isn't that like an engineer who prefers to stay clear of
technical issues?
> I have to wonder if anything useful
> could be done at all in the world if language really made hearers know
> what speakers intended in all cases.
Language doesn't make anyone know anything. It's a speaker's *use* of
language that may or may not have this effect. Language can be used to
communicate true intent. It can also be used to dissemble. It can even
be used not for communicating but simply to cause pleasure (as with humor)
or pain (as with insults).
> As a sometimes writer of humor, I am certain that for words to mean
> only one thing would be very dry.
>
> As an avid watcher of soap operas, I know there would be many fewer
> good plots to be watched if people spoke plainly and were readily
> understood.
>
> Language survives only because it is so blunt and vague as it is; were
> it made more precise, we would probably all kill each other, or
> perhaps just stop talking to one another, but we would surely never
> again for all future time reach an agreement. If you don't understand
> what I mean by this, it's time to rent "A Man for All Seasons" and pay
> particular attention to Sir Thomas's remark about an oath meaning
> "what the words say", which is masterful irony because what he means
> by this is that he may be able to say the words if he thinks they mean
> differently than what the oathmakers think... that is, he introduces a
> third party, which are "the words themselves" which seem to know their
> own meaning. But then, again quoting from memory of the later trial
> scene, "the world must construe according to its wits, [the] court
> must construe according to the law". So I'll go with the author of
> both play and film, Robert Bolt, in his subtlely made point that
> survival in a world of words is best made, if at all, through clever
> appeal to ambiguity.
Since we're quoting literature, let me fill in the Stoppard quotation with
its context, because he can make my point much more eloquently than I
can. The players are Tristan Tzara, a Dadaist poet, and Henry Carr, a
British army WWI veteran. It is 1917. We are in Zurich.
<quote>
Tsara: Doing the things by which is meant Art is no longer the proper
concern of the artist. In fact it is frowned upon. Nowadays, an artist
is someone who makes art mean the things he does. A man may be an artist
by exhibiting his hindquarters. He may be a poet by drawing words out of
a hat. In fact, some of my best poems have been drawn out of my hat which
I afterwards exhibited to general acclaim at the Dada Gallery in
Bahnhofstrasse.
Carr: But that is simply to change the meaning of the word Art.
Tsara: I see I have made myself clear.
Carr: Then you are not really an <i>artist</i> at all.
Tsara: On the contrary. I have just told you that I am.
Carr: But that does not make you an artist. An artist is someone who is
gifted in some way that enables him to do something more or less well
which can only be done badly or not at all by someone who is not thus
gifted. If there is any point in using language at all it is that a word
is taken to stand for a particular fact or idea and not for other facts or
ideas. I might claim to be able to fly ... Lo, I say, I am flying. But
you are not propelling yourself about while suspended in the air, someone
might point out. Ah no, I reply, that is no longer considered the proper
concern of people who can fly. In fact, it is frowned upon. Nowadays, a
flyer never leaves the ground and wouldn't know how. I see, says my
somewhat baffled interlocutor, so when you say you can <i>fly</i> you are
using the word in a purely private sense. I see I have made myself clear,
I say. Then, says this chap in some relief, you cannot actually
<i>fly</i> after all? On the contrary, I say, I have just told you that I
can. Don't you see my dear Tristan you are simply asking me to accept
that the word Art means whatever you wish it to mean; but I do not accept
it.
Tzara: Why not? You do exactly the same thing with words like
<i>patriotism, duty, love, freedom,<i> king and country, brave little
Belgium, saucy little Serbia --
</quote>
A man may be an artist by exhibiting his hindquarters (which is not a bad
metaphor for what some people do around here) but he may not be an
engineer that way.
E.
From: Kenny Tilton
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C75D9D6.CF47CFF0@nyc.rr.com>
Erann Gat wrote:
>
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > [I took this out of context and have mostly not been following this thread.
> > I edited out the interpersonal issues, which I'd prefer to stay clear of.]
>
> Coward.
I would have said wise or mature.
kt
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2102022231530001@192.168.1.50>
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Erann Gat wrote:
> >
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > > [I took this out of context and have mostly not been following this
thread.
> > > I edited out the interpersonal issues, which I'd prefer to stay
clear of.]
> >
> > Coward.
>
> I would have said wise or mature.
Coward.
E.
From: Marc Spitzer
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <slrna7bt1i.2cmm.marc@oscar.eng.cv.net>
In article <····················@192.168.1.50>, Erann Gat wrote:
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>> Erann Gat wrote:
>> >
>> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
>> > <······@world.std.com> wrote:
>> >
>> > > [I took this out of context and have mostly not been following this
> thread.
>> > > I edited out the interpersonal issues, which I'd prefer to stay
> clear of.]
>> >
>> > Coward.
>>
>> I would have said wise or mature.
>
> Coward.
>
> E.
Do you know what the truly funny part of this exchange is? With Erik
not in this Erann must find other people to attack and this proves
everything Erik has said about him. Erann you MADE Erik's case for
him. YOU have proved him right. You have proved your self to be a
truly fucked up and vicious individual. And you have proved Erik to
not be like you. In fact you have proved Erik to be the better person
by your actions here today.
Please when you call someone a coward please post your supporting
delusions also.
marc
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2202020823150001@192.168.1.50>
In article <····················@oscar.eng.cv.net>, ····@oscar.eng.cv.net
(Marc Spitzer) wrote:
> In article <····················@192.168.1.50>, Erann Gat wrote:
> > In article <·················@nyc.rr.com>, Kenny Tilton
> > <·······@nyc.rr.com> wrote:
> >
> >> Erann Gat wrote:
> >> >
> >> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> >> > <······@world.std.com> wrote:
> >> >
> >> > > [I took this out of context and have mostly not been following this
> > thread.
> >> > > I edited out the interpersonal issues, which I'd prefer to stay
> > clear of.]
> >> >
> >> > Coward.
> >>
> >> I would have said wise or mature.
> >
> > Coward.
> >
> > E.
>
> Do you know what the truly funny part of this exchange is? With Erik
> not in this Erann must find other people to attack and this proves
> everything Erik has said about him. Erann you MADE Erik's case for
> him. YOU have proved him right. You have proved your self to be a
> truly fucked up and vicious individual.
I think the funny part of this exchange (or it would be funny if it
weren't so sad) is how blind Erik and his apologists are to the
double-standard they apply. I call someone a coward and that makes me a
"truly fucked up and vicious individual." But when someone says something
similar about Erik, who is absolutely notorious for hurling much worse
epithets around, he is the noble and undeserving victim of the attack!
> And you have proved Erik to not be like you.
Thank you. I consider that a compliment.
> Please when you call someone a coward please post your supporting
> delusions also.
Very well, I will.
Kent and I have actually discussed this issue by email, and the fact that
I call him a coward should come as no surprise to him. Kent is one of
Lisps's elder statesmen, someone nearly everyone (including Erik and
myself) respects. As such he has the potential to help resolve these
unproductive conflicts that occasionally arise on comp.lang.lisp. But he
chooses not to do so, to stay about the fray. Maybe that makes him wise
or mature, but I see this as shirking a responsibility of his role as
elder statesman and mentor. It was late and I was tired so I just called
it cowardice. He stays conveniently above the fray while those of us who
think that Erik's behavior is unacceptable should be spoken against get
all manner of vile epithets hurled at us like "truly fucked up and vicious
individual."
Now, when I saw Kenny's response it was even later and I was even more
tired, so I fired off my reply without really thinking about it very
much. At first I regretted my compulsiveness, but then I thought about it
some more and I came to a realization that made me decide to let it
stand. That realization was that my responding to Kenny as I did, with a
single word, could actually be interpreted in two ways. It could be
interpreted as my calling Kenny a coward, or it could be interpreted as my
simply repeating my earlier statement about Kent. I kind of figured
someone would choose to interpret it in the less charitable way, and that
would give me an opportunity to make a point, which I will now proceed to
do. But first, Kenny, if you took offence, I apologise. I don't think
you're a coward.
My point is this: your response to me proves *my* point about the Rules,
and the fact that everyone is subject to them except Erik and his
supporters. I call someone a coward and that makes me a "truly fucked up
and vicious individual." But you just called me much worse than a coward
(and without any supporting delusions I might add). What does that make
you?
E.
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a560oh$4u67l$1@ID-125440.news.dfncis.de>
In article <····················@192.168.1.50>, Erann Gat wrote:
> In article <····················@oscar.eng.cv.net>, ····@oscar.eng.cv.net
> (Marc Spitzer) wrote:
>> Do you know what the truly funny part of this exchange is? With Erik
>> not in this Erann must find other people to attack and this proves
>> everything Erik has said about him. Erann you MADE Erik's case for
>> him. YOU have proved him right. You have proved your self to be a
>> truly fucked up and vicious individual.
>
> I think the funny part of this exchange (or it would be funny if it
> weren't so sad) is how blind Erik and his apologists are to the
> double-standard they apply. I call someone a coward and that makes me a
> "truly fucked up and vicious individual."
Hey, you actually might have a point here ;-) I'm not sure if it's
what Mr. Spitzer wanted to say, but it is my opinion, too, that you
are doing something wrong here. It seems ok to me if you just have
a flamewar with Erik himself, if you disagree with him. I also
don't mind discussing such issues, which are undoubtedly very
interesting, by Email, as we did, too. I hope it helps you to
understand better what goes on in the minds of the so called ``Erik
apologists'', how they think different. But I think it's /not/ ok
trying to force everybody else into a public war. This reminds me
of the situation where you are sitting as a child next to your
parents at school listening how some teacher says lots of bad things
about you and you are supposed to sit still, look down to the floor
and say nothing, not allowed to defend yourself in any way. That
is the character such public discussions about third persons have,
even if they /have/ the possibility of participating. That's why
I find doing that very bad, even disgusting, something one just
``doesn't do''.
You would probably disagree. But you could take it as another
example that different people find different things unacceptable,
one just has to learn to live with that.
> Kent and I have actually discussed this issue by email, and the fact that
> I call him a coward should come as no surprise to him. Kent is one of
> Lisps's elder statesmen, someone nearly everyone (including Erik and
> myself) respects. As such he has the potential to help resolve these
> unproductive conflicts that occasionally arise on comp.lang.lisp. But he
> chooses not to do so, to stay about the fray. Maybe that makes him wise
> or mature, but I see this as shirking a responsibility of his role as
> elder statesman and mentor.
I can't understand this at all. Kent has no obligation to do anything
at all. Why should he be responsible for solving personal problems
between other people??
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2202021057410001@eglaptop.jpl.nasa.gov>
In article <··············@ID-125440.news.dfncis.de>, Nils Goesche
<······@cartan.de> wrote:
> But I think it's /not/ ok
> trying to force everybody else into a public war.
As Erik himself often points out, no one can force anyone to do anything
on usenet. I can't force Kent to do anything. But I can express my
opinion of his decision not to use his powers of persuasion to try to help
Erik and me resolve our differences. I do not believe that makes me a
truly fucked up individual.
> This reminds me
> of the situation where you are sitting as a child next to your
> parents at school listening how some teacher says lots of bad things
> about you and you are supposed to sit still, look down to the floor
> and say nothing, not allowed to defend yourself in any way. That
> is the character such public discussions about third persons have,
> even if they /have/ the possibility of participating. That's why
> I find doing that very bad, even disgusting, something one just
> ``doesn't do''.
Huh? I called Kent a coward to his face (to the extent that it is
possible to do so on usenet). Or is that not what you are talking about?
I have discussed Erik in the third person, but he cast the first stone in
that regard. In fact, if you go back and review this whole exchange you
will find that I have done nothing that Erik has not himself done much
more often and much more extremely in the past. (If you doubt this please
send me your counterexample by email so this doesn't get out of hand. Or
you can just assume I'm correct. That will save you a lot of trouble.)
So why am I the villain here? That's a sincere question, I really want to
know.
BTW, I think the situation is more like the Palestinian/Israeli situation,
with genuine and legitimate grievances on both sides. I have a sincere
desire for peace, but it's going to be a negotiated peace, not an
unconditional surrender.
Tell you what. I hereby declare a unilateral ceasefire. Erik proposed an
idea that I think is really good: a standard virtual machine for Lisp
libraries. I heartily endorse that idea. Let's put all this other crap
behind us and figure out how we can all work together to turn this idea
into reality, OK?
> > Kent and I have actually discussed this issue by email, and the fact that
> > I call him a coward should come as no surprise to him. Kent is one of
> > Lisps's elder statesmen, someone nearly everyone (including Erik and
> > myself) respects. As such he has the potential to help resolve these
> > unproductive conflicts that occasionally arise on comp.lang.lisp. But he
> > chooses not to do so, to stay about the fray. Maybe that makes him wise
> > or mature, but I see this as shirking a responsibility of his role as
> > elder statesman and mentor.
>
> I can't understand this at all. Kent has no obligation to do anything
> at all. Why should he be responsible for solving personal problems
> between other people??
"Responsibility" is not the same as "obligation." I said Kent has a
responsibility (IMO). He certainly does not have any obligation.
The truth is that labelling Kent a coward is actually grossly unfair, and
I did it in part because, as I said, it was late and I was feeling
grumpy. So Kent, I'm sorry I called you a coward. Nonetheless, it does
reflect a genuine sentiment, that Kent could help us work this out, and
I'm frustrated that he chooses not to do so.
E.
From: Kenny Tilton
Subject: Working out interpersonal conflict in a technical forum [was Looking for a language..]
Date:
Message-ID: <3C768D8D.EE152BFE@nyc.rr.com>
Erann Gat wrote:
>
> KKent is one of
> Lisps's elder statesmen, someone nearly everyone (including Erik and
> myself) respects. As such he has the potential to help resolve these
> unproductive conflicts that occasionally arise on comp.lang.lisp. But he
> chooses not to do so, to stay about the fray.
Minor objection: Not so. I clearly recall a long, strong,
counter-example article just before KP took a walkbaout from c.l.l.
Major objection: If you really respect someone, don't second-guess the
way they handle situations. You might even emulate them and learn
something.
> My point is this: your response to me proves *my* point about the Rules,
> and the fact that everyone is subject to them except Erik and his
> supporters. I call someone a coward and that makes me a "truly fucked up
> and vicious individual." But you just...
Your every exchange slides into futile interpersonal bickering from
which you take no pleasure. You do this publicly, explaining in part why
a Lisp renaissance has and will not bring you Lisp job offers.
KP's cowardly (not!) article deleted interpersonal stuff, showing you
the way out of your addiction to feuding: suppress emotional,
interpersonal stuff when dealing with others. Do not try to settle every
score. Do not react to each affront. Let sh*t slide. Don't make
unimportant people important to you by engaging them. The c.l.l. chorus
(I wager) admires the cooler head, the one who walks away.
FWIW.
--
kt
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223394384703344@naggum.net>
* Erann Gat
| I think the funny part of this exchange (or it would be funny if it
| weren't so sad) is how blind Erik and his apologists are to the
| double-standard they apply. I call someone a coward and that makes me a
| "truly fucked up and vicious individual." But when someone says
| something similar about Erik, who is absolutely notorious for hurling
| much worse epithets around, he is the noble and undeserving victim of the
| attack!
When you understand that _exactly_ the same standard is applied, you will
have matured significantly as a human being.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2202021156590001@eglaptop.jpl.nasa.gov>
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> * Erann Gat
> | I think the funny part of this exchange (or it would be funny if it
> | weren't so sad) is how blind Erik and his apologists are to the
> | double-standard they apply. I call someone a coward and that makes me a
> | "truly fucked up and vicious individual." But when someone says
> | something similar about Erik, who is absolutely notorious for hurling
> | much worse epithets around, he is the noble and undeserving victim of the
> | attack!
>
> When you understand that _exactly_ the same standard is applied, you will
> have matured significantly as a human being.
OK, it's time for a sanity check. Is there anyone out there besides me
who sees a double-standard here, or am I really the only one? If so, I
will go away and think deeply about the errors of my ways.
E.
From: Len Charest
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C76C823.1020407@my.inbox>
Erann Gat wrote:
> OK, it's time for a sanity check. Is there anyone out there besides me
> who sees a double-standard here, or am I really the only one? If so, I
> will go away and think deeply about the errors of my ways.
Hey, thanks for asking!
I see more than a double standard. I see a pathology. I don't care how
knowledgeable he is. The noise consistently drowns out the signal in his
posts.
I've lost track of the number of times Erik has, apropos of nothing,
called someone "insane" (or a variation thereof), and then gone on to
lecture the rest of us about interpersonal psychology. It's a kind of
Usenet terrorism.
Of course, this message will probably put me on Erik's enemies list as
well. So be it.
-Len
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2202021516520001@eglaptop.jpl.nasa.gov>
In article <················@my.inbox>, Len Charest
<··············@my.inbox> wrote:
> > OK, it's time for a sanity check. Is there anyone out there besides me
> > who sees a double-standard here, or am I really the only one? If so, I
> > will go away and think deeply about the errors of my ways.
>
> Hey, thanks for asking!
Thanks for responding. Nonetheless, I would ask that no one else
respond. It's time to bring this conversation to an end. It's way past
the point of diminishing returns.
Kent, thanks for your feedback. That was very helpful.
To all those who think I did more harm than good here, I'm sorry. That
was not my intent.
E.
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223408528992964@naggum.net>
* Len Charest <··············@my.inbox>
| It's a kind of Usenet terrorism.
Better call George W. Bush and have him stage a war like you have never
seen in order to squash this terrorism. Oh, come to think of it, that is
_precisely_ what happens. I just happen to believe that posting idiotic
drivel to a technical newsgroup is terrorism, and squash it. Gee, can it
be as simple as differing priorities? Some people like nice people who
say nothing controversial whatsoever. Other people like controversial
people who make intellectually stimulating points. The two are largly
incompatible from the outset. What I cannot figure out is that those
touchy-feely guys are looking for in a technical newsgroup.
| Of course, this message will probably put me on Erik's enemies list as
| well. So be it.
My supposed "enemies list" is another creation of Erann Gat. Like most
everything else he imputes to me, it does of course not exist. You are
entitled to your opinion, although you are clearly not sufficiently aware
of what you think to make a worthwhile contribution to this forum. Why
did you choose to make this vile crap your virgin post? This is what
Erann Gat and his style encourages, and I am saddened to see someone like
yourself lured into his trap out of overly emotional reasons. If you had
kept this shit to yourself, you would not have _contributed_ to the
hostile tone set by Erann Gat and others who mistakenly believe they
fight evil, when they are themselves much worse than whatever it is they
fight.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223402680406850@naggum.net>
* ···@jpl.nasa.gov (Erann Gat)
| OK, it's time for a sanity check. Is there anyone out there besides me
| who sees a double-standard here, or am I really the only one? If so, I
| will go away and think deeply about the errors of my ways.
Such is not the path to maturing. You yourself just recently said that
arguments from authority were not valid. The authority of "others" is
just as invalid. This is not about what other people think, but about
what _you_ understand. You can always find someone who are equally or
more immature than yourself. Do you really want to relegate your own
personal development to the existence of less evolved people? If you
had at least asked if there were others who thought there were no double
standards, you could perhaps have had a point, but since you are so
immature, that is precisely what you do _not_ do. So, try again.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Erann Gat wrote:
>
> OK, it's time for a sanity check. Is there anyone out there besides me
> who sees a double-standard here, or am I really the only one? If so, I
> will go away and think deeply about the errors of my ways.
After entirely too many years reading Usenet, I have concluded that most
of netiquette can be justified by simple appeals to enlightened
self-interest.
Generally speaking, the only way we form conclusions about people's
personalities on the Net is by reading their words, and all of us have
access to the same words. Suppose I believe that a certain writer on
the Net is out of touch with reality. There's no point to me slinging
personal accusations against the deranged writer. Either the other
people who read this person's posts form the same conclusion that I do,
or they don't. If they do, then my accusation is redundant. If they
don't, then my mere accusation won't convince them of anything.
By the same logic, if someone who only knows me based on what I post to
Usenet accuses *me* of having some noxious character flaw, I have no
reason to object. If other people who read my posts think that the
accusation has merit, then my protests *against the accuser* are
unlikely to change their minds. If they think that the accusation is
unfounded, then the accuser looks more foolish in their eyes for having
made the charge against me. Either way, I don't have to say anything.
>
> E.
--
"Any fool can write code that a computer can understand.
Good programmers write code that humans can understand."
--Martin Fowler
// seth gordon // wi/mit ctr for genome research //
// ····@genome.wi.mit.edu // standard disclaimer //
From: Marc Spitzer
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <slrna7dgvs.2eqc.marc@oscar.eng.cv.net>
In article <····················@192.168.1.50>, Erann Gat wrote:
> In article <····················@oscar.eng.cv.net>, ····@oscar.eng.cv.net
> (Marc Spitzer) wrote:
>
>> In article <····················@192.168.1.50>, Erann Gat wrote:
>> > In article <·················@nyc.rr.com>, Kenny Tilton
>> > <·······@nyc.rr.com> wrote:
>> >
>> >> Erann Gat wrote:
>> >> >
>> >> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
>> >> > <······@world.std.com> wrote:
>> >> >
>> >> > > [I took this out of context and have mostly not been following this
>> > thread.
>> >> > > I edited out the interpersonal issues, which I'd prefer to stay
>> > clear of.]
>> >> >
>> >> > Coward.
>> >>
>> >> I would have said wise or mature.
>> >
>> > Coward.
>> >
>> > E.
>>
>> Do you know what the truly funny part of this exchange is? With Erik
>> not in this Erann must find other people to attack and this proves
>> everything Erik has said about him. Erann you MADE Erik's case for
>> him. YOU have proved him right. You have proved your self to be a
>> truly fucked up and vicious individual.
>
> I think the funny part of this exchange (or it would be funny if it
> weren't so sad) is how blind Erik and his apologists are to the
> double-standard they apply. I call someone a coward and that makes me a
> "truly fucked up and vicious individual." But when someone says something
> similar about Erik, who is absolutely notorious for hurling much worse
> epithets around, he is the noble and undeserving victim of the attack!
I have never seen Erik use a double standard, he talks the talk and
walks the walk. I see you are now on the polite rant BS. I have
found Erik to be civil when people are civil to him. He does have
very high standards of what is civil behavior in CLL and that is his
right.
Now on to the coward thing. When you call some one a coward you are
using a grave personal insult. You are not attacking the action you
are attacking the person. And you are leveling a very serious charge
against him.
And the apologists bit. In the above paragraph I said Erik was
correct not that Erik needs to have allowances mad for his behavior.
It means that I think Erick is correct, you are fucked up and
vicious.
>
>> And you have proved Erik to not be like you.
>
> Thank you. I consider that a compliment.
>
All I said was that Erik was not mentaly dammaged as you apear to be
from your postings here. If that is a complement your welcome to it.
>> Please when you call someone a coward please post your supporting
>> delusions also.
>
> Very well, I will.
>
> Kent and I have actually discussed this issue by email, and the fact that
> I call him a coward should come as no surprise to him. Kent is one of
> Lisps's elder statesmen, someone nearly everyone (including Erik and
> myself) respects. As such he has the potential to help resolve these
> unproductive conflicts that occasionally arise on comp.lang.lisp. But he
> chooses not to do so, to stay about the fray. Maybe that makes him wise
> or mature, but I see this as shirking a responsibility of his role as
> elder statesman and mentor. It was late and I was tired so I just called
> it cowardice. He stays conveniently above the fray while those of us who
> think that Erik's behavior is unacceptable should be spoken against get
> all manner of vile epithets hurled at us like "truly fucked up and vicious
> individual."
>
Well adults solve their own problems and accept responsibility for
their own actions. And from the above paragraph you do not seem to
want to do that. You want the "adults" to come in and settle things.
This is not the purpose of this group. Now to consider your self so
immature that you cannot settle them your self so you must go to a
higher authority. Now when that "adult" decides not to solve your
problem he is a coward. And when people say he was exhibiting good
sense in not getting involved you call them cowards as well. Well
your actions speak for themselves.
> Now, when I saw Kenny's response it was even later and I was even more
> tired, so I fired off my reply without really thinking about it very
> much. At first I regretted my compulsiveness, but then I thought about it
> some more and I came to a realization that made me decide to let it
> stand. That realization was that my responding to Kenny as I did, with a
> single word, could actually be interpreted in two ways. It could be
> interpreted as my calling Kenny a coward, or it could be interpreted as my
> simply repeating my earlier statement about Kent. I kind of figured
> someone would choose to interpret it in the less charitable way, and that
> would give me an opportunity to make a point, which I will now proceed to
> do. But first, Kenny, if you took offence, I apologise. I don't think
> you're a coward.
>
So you are too lazy to just insult the people who you think need it.
It is so much less work on your part to insult everybody who could
possibly deserve it. You called Kenny a coward plain and simple.
Now the only way to really not take offense at an insult is to have
absolutely no respect for the source, then it truly is beneath
notice(for me anyway). So by saying "if" he took notice you are
claiming to be potentially beneath notice, that is sad for you.
> My point is this: your response to me proves *my* point about the Rules,
> and the fact that everyone is subject to them except Erik and his
> supporters. I call someone a coward and that makes me a "truly fucked up
> and vicious individual." But you just called me much worse than a coward
> (and without any supporting delusions I might add). What does that make
> you?
>
> E.
This is strange you consider being called "fucked up and vicious"
worse then being called a coward. That says more bad things about you
then I ever have. Moral courage is the foundation of being a good
person, I will do what I believe to be right and accept what that
brings is a fundamental thing to civil society.
marc
From: Espen Vestre
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <kwu1sa2b4n.fsf@merced.netfonds.no>
···@jpl.nasa.gov (Erann Gat) writes:
> Since we're quoting literature
When reading c.l.l., I'm often reminded of the famous William S.
Burroughs quote:
"Language is a virus from outer space"
:-(
--
(espen)
From: Kent M Pitman
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <sfweljdtfsq.fsf@shell01.TheWorld.com>
···@jpl.nasa.gov (Erann Gat) writes:
> Kent and I have actually discussed this issue by email,
Quite a while ago. And I suspect based on this message that there are
some lingering confusions, since my position is not fairly portrayed here
and requires some clarification.
> and the fact that I call him a coward should come as no surprise to him.
This is not of consequence to me. I have advocated that others ignore
namecalling on this forum and I'm happily willing to do likewise. Call me
what you like, it does not injure me. I've been called worse and survived it.
> Kent is one of Lisps's elder statesmen, someone nearly everyone
> (including Erik and myself) respects. As such he has the potential
> to help resolve these unproductive conflicts that occasionally arise
> on comp.lang.lisp.
I prefer to take a page from Bill Clinton's presidency. People called
him all kinds of names, but the reason so many of us continued to
support him was that in spite of it all, he kept his focus on doing
his job as President and didn't just melt down and cry and say
"they're calling me bad names. I don't want to be President until they
stop". My role here is to discuss CL and other tangential issues of
interest (emphasis on "of interest", not to be confused with
tangential brawling, which I find "not of interest").
> It was late and I was tired so I just called it cowardice.
It concisely summarizes your thought. If you were going to write something,
I'm glad it was thusly brief. I don't see how saying it at length would
have changed anything. What I object to is not the negative nature of the
remark nor the fact that it's directed at me. It rolls right off of me.
I just think it's all too off-topic and I wish people would just
"turn the other cheek" rather than letting this stuff continue on.
> He stays conveniently above the fray while those of us who
> think that Erik's behavior is unacceptable should be spoken against get
> all manner of vile epithets hurled at us like "truly fucked up and vicious
> individual."
This sentence is syntactically ungrammatical so is hard to reply to in the
chunks I'd like to, but I think what you wnted to say was that there exists
a set of people who think Erik's behavior is unacceptable and maybe also that
you think I am among that set, and therefore you conclude me cowardly.
I have said in the past that I find remarks "constructive" when they are
clear and to the point such that I can figure out how to respond in a
productive way, regardless of how they are presented. I will therefore
accept your remark as constructive in the sense that it offers me the
opportunity to clarify my position in an area where you think I have been
not clear. I don't plan to make a habit of this, by the way, but I do feel
it warrants a simple and clear statement.
In point of fact, I don't think Erik's behavior is unacceptable. See
http://world.std.com/~pitman/pfaq/usenet-freedom.html
for some side detail, but basically I think this place will always be a
free speech forum and if you want otherwise, you want another forum.
In point of fact, I don't think it is appropriate to "speak out against"
people violating harmony here because I don't see that as productive. I
think it is sometimes appropriate to make a reasoned statement and hope that
the person hearing it will merely say "oh, sorry. of course." and correct
their behavior. That sometimes happens. But when it doesn't, I'm pretty
sure that all subsequent conversation on the topic is going nowhere and
that anyone on either side who further fans the flames is no better than
the other.
I further believe that anyone who escalates a single remark to a whole thread
is doing worse by this forum than the person who started things.
I also do not believe there are grades of "name calling" so I find no
productive value in comparing epithets and saying "mine was more
acceptable than yours". It's not productive to do namecalling here at
all. I recommend that people not do it. But not because I regard it
as "unacceptable". If it were, both you and Erik would be guilty
equally. Fortunately, I think you are both acceptable. But I do
think name-calling is just not well-advised as a way to make one's
point. And, as such, I continue to recommend that no one do it. And
that we all just get back to talking about Lisp as quickly as possible
after these little eruptions happen rather than fanning the sparks of
feuds, vendettas, and such.
> My point is this: your response to me proves *my* point about the Rules,
There are no rules.
> and the fact that everyone is subject to them except Erik and his
> supporters.
I don't agree with that. He is protected by the same thing that now
protects you as you attack him in a forum which does not exist for the
purpose of your attacks. Only the fact that there are no rules keeps
you yourself (and probably now me, just to establish closure and not to
force someone else to make the same observation about me) from being
expelled.
> I call someone a coward and that makes me a "truly fucked up
> and vicious individual." But you just called me much worse than a coward
> (and without any supporting delusions I might add).
I'm using definition 1, not definition 2, of "same" from CLHS here:
These remarks you cite are the same under the "was it namecalling"
predicate, which is as deep a comparison as many of us care to go. We
simply aren't evaluating this at the semantic level of "is this a
force factor 5 or force factor 7 insult". We just don't care. We hear
only "I call someone a name and that makes someone else call me a name."
Who cares what the words are?
We just want there to not be infighting at all. And we don't find it
made better when people get all righteous and start joining the fray
on either side in some necessarily partisan notion of "Right".
So here's my clearer summary. It happens to be less cowardly, I
think, too. But my reason for making it is not that I've been forced
by fighting words to make a statement; rather, I felt you were putting
words into my mouth and I wanted to be clear about my own position
rather than have someone characterize me...
Erik: Your points are more clear to others when foul language is not
involved. But my posts have their problems, too, and I slug through
glitches in presentation by others just as I expect others to slug
through my own glitches. I nevertheless appreciate your presence here
and do not agree with those who either think your behavior
unacceptable (in part, but not in whole, because I believe there is no
stnadard of acceptable in this forum) nor with those who believe even
that alleged unacceptable behavior is somehow made better by ranting
against it.
Erann: Your points are no less name-calling merely because you avoid
foul language. It seems to me that your dislike of Erik is
subjectively arrived at and not agreed to as a universal truth here;
the more you seek to assert the rightness of your actions, the farther
I find myself positioned from you, because while I fall within your
general zone of personal comfort as to language, I fall very far from
your notion of rights and your apparent desire for vigilante justice,
especially in a forum whose very physics do not allow such, but also
in a forum whose core rules are not what you seem to believe they are.
I nevertheless appreciate your presence here and do not agree with
anyone who might suggest your behavior unacceptable (in part, but not
in whole, because I believe there is no stnadard of acceptable in this
forum). I disagree with you outright ont he question fo whether it is
worthwhile to "speak out" against alleged unacceptable behavior; I
regard this not only as vigilante justice since you were not elected
to be our forum's keeper, but also as improper justice since the rules
you so often assert to do not, as nearly as I can tell, exist, and
finally as ineffective justice since the enforcement techniques you
seek to use are provably too weak to accomplish your goal even if the
cause were provably right.
In all, Erann, looking back on these summaries, I find myself siding
more with Erik on this than with you. I didn't have any preconceived
notion of whether that was so because I honestly hadn't given it sufficient
depth of thought. As I say, I mostly prefer not to focus on these
useless issues, and I am annoyed to have wasted the last two hours
composing this message which has no technical merit at all.
This message of mine is perhaps not what you wanted to hear. But you
did speculate on my keeping silent, and it was not for the reasons you
suggest. The real reason is that I just don't think any of this
interpersonal flaming is useful.
Both you and Erik have a bunch of technical threads going on. I wish
you would both keep to those. And that I would, too. I don't plan to
re-issue this appeal on a daily or weekly basis. If I'm drawn into
commenting on this unpleasant business again, I'll likely take another
penalty time away from this forum. A lot of people tell me they like
reading my posts, but if all of them were rants about interpersonal
matters, I think my reputation would be quickly down the toilet. I
don't like how this presents me and I don't want to find myself doing
it a lot.
Thank goodness this tangent is buried at the end of a very long technical
thread and does not have a subject line of its own. If it had been in its
own tread, and if I had been sucked into responding, I would have considered
that a worse sin on my part, and I'd be harsher on myself for being
drawn in.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2202021526400001@eglaptop.jpl.nasa.gov>
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Kent and I have actually discussed this issue by email,
>
> Quite a while ago. And I suspect based on this message that there are
> some lingering confusions, since my position is not fairly portrayed here
> and requires some clarification.
I don't believe I made any representation at all about your position, just
an observation about your actions (or lack thereof). Nonetheless, if I
misrepresented your position I'm sorry. I didn't mean to.
> > and the fact that I call him a coward should come as no surprise to him.
>
> This is not of consequence to me. I have advocated that others ignore
> namecalling on this forum and I'm happily willing to do likewise. Call me
> what you like, it does not injure me. I've been called worse and survived it.
I knew that, which is one of the reasons I decided to pick on you.
[Much snippage]
Thanks for clarifying your position. I found this very helpful.
E.
From: Pekka P. Pirinen
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ud6ytms3f.fsf@globalgraphics.com>
I'm sorry to follow up on this, Kent, as I know you don't want to
discuss this any further publicly, and I'm tempting you to, but I
think you're on the brink of renouncing ethical responsibility for our
forum, and I can't let that slide.
Kent M Pitman <······@world.std.com> writes:
> [...] See http://world.std.com/~pitman/pfaq/usenet-freedom.html
> for some side detail, but basically I think this place will always be a
> free speech forum and if you want otherwise, you want another forum.
No one is likely to say they don't want free speech. But freedoms
aren't absolute; they are limited by other people's rights and
freedoms. Your web page explains that you would always choose the
poster's freedom over the reader's. "...its purpose is not to
restrict posters but to accomodate them..." This is an extremist
position; I doubt you actually hold it wrt. to spamming. I would
suggest that the ethics of acceptable behaviour on Usenet are more
complex than that.
> In point of fact, I don't think it is appropriate to "speak out
> against" people violating harmony here because I don't see that as
> productive. I think it is sometimes appropriate to make a reasoned
> statement and hope that the person hearing it will merely say "oh,
> sorry. of course." and correct their behavior. That sometimes
> happens. But when it doesn't, I'm pretty sure that all subsequent
> conversation on the topic is going nowhere and that anyone on either
> side who further fans the flames is no better than the other.
That is the kind of pragmatic wisdom I've come to expect from you. It
certainly seems to apply in this case. However, I'm not at all sure
that the first reproach is inapproriate, even if it is not expected to
be productive in procuring an immediate change of behaviour. It is
part of free speech to speak out against what you don't agree with -
for whatever reason. And sometimes a change of behaviour comes about
as a cumulative effect of the reactions of other people, so productive
effect is not a 100%/0% choice.
> I further believe that anyone who escalates a single remark to a
> whole thread is doing worse by this forum than the person who
> started things.
There are always (at least) two people doing the escalation, and blame
must attach to both. Each has a responsibility to the forum and
carries the blame for their own actions. Probably you agree with
that, but it's hard to find anything in your posting that could be
construed as critical of Erik's behaviour.
> I also do not believe there are grades of "name calling" so I find no
> productive value in comparing epithets and saying "mine was more
> acceptable than yours". [...]
I would agree only from the narrow point of view of judging productive
contributions to a technical forum such as c.l.l. Otherwise, there
are degrees of verbal violence just as there are degrees of physical
violence.
> There are no rules.
There are only the rules that we make as members of this forum. That
they are not agreed by a formal process and written down does not mean
there aren't any; that's the way most social rules are. The social
cohesion of Usenet is quite small, as we mostly only connect through
text, so the rules are weak. All the more reason for us to uphold the
ones we hold dear.
> [big snip]
> Erann: [...] your apparent desire for vigilante justice,
> especially in a forum whose very physics do not allow such, but also
> in a forum whose core rules are not what you seem to believe they are.
I thought there weren't any? I guess you're referring to "the
purpose" of Usenet as you see it and the "physics" of the forum. It's
a collective effort, though: it's what we make it. The physics of
discussion groups limit what we can do, but do not predetermine it,
and we endow it with purpose, each with our own. Our purposes largely
align with each other, creating something that might be called the
purpose of c.l.l. The charter and the history of the group are
important factors in that alignment, but not the whole of it. The
purpose of Usenet is a far more nebulous thing, and I'd hesitate to
make any pronouncement upon it.
I don't think Erann was asking for "justice", just jugdment on a
personal level from fellow members. However, if there is anything
that may be termed "justice" on Usenet, it is by definition vigilante
justice, since there are are no duly authorized officers of "the law
of Usenet". I rather prefer it that way, don't you?
--
Pekka P. Pirinen
Censure, not censor!
From: Kent M Pitman
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <sfw3czp9yi6.fsf@shell01.TheWorld.com>
···············@globalgraphics.com (Pekka P. Pirinen) writes:
> No one is likely to say they don't want free speech. But freedoms
> aren't absolute; they are limited by other people's rights and
> freedoms.
Offensiveness is not absolute either. It is determined by people's
differing sensibilities. There are all kinds of things that offend
all kinds of people. Nearly all of my posts offend Xah. Shall I not
post? Some of his posts offend me. Shall he not post? This forum is
not a "least common denominator" forum. The right solution is
filtering, not exclusion.
> Your web page explains that you would always choose the
> poster's freedom over the reader's. "...its purpose is not to
> restrict posters but to accomodate them..." This is an extremist
> position; I doubt you actually hold it wrt. to spamming.
Spamming is a bandwidth/resource issue and is fundamentally differnet
not by its content but by its volume. Incidentally, were I to make an
analogy I would say that the campaign by those reacting to Erik is
effectively a spamming / denial-of-service issue. A few people are
repeating the same opinion over and over and over and over to the
point that it cannot be ignored. In my book, that IS spamming. And I
regard spamming in many regards as a worse offense than a content-based
(subjectively defined) "offense".
Further, if you deny Erik the right to speak and/or you chase him away,
you do not just infringe him. You also infringe people who like reading
his many useful posts, and there are such people. For further reading
on this, see
http://world.std.com/~pitman/pfaq/freedom-to-hear.html
> > I further believe that anyone who escalates a single remark to a
> > whole thread is doing worse by this forum than the person who
> > started things.
>
> There are always (at least) two people doing the escalation, and blame
> must attach to both. Each has a responsibility to the forum and
> carries the blame for their own actions. Probably you agree with
> that, but it's hard to find anything in your posting that could be
> construed as critical of Erik's behaviour.
My prior post (in mid-January, before I took a half month off) was intended
to be middle-of-the-road and was read by most people as just coming down on
Erik. This time I write another middle of the road post and it seems to
you, at least, that I'm coming down on Erann. That's balance, I suppose.
All I'm really saying is that I don't see anyone accomplishing anything
and I think they should all stand down.
> I don't think Erann was asking for "justice", just jugdment on a
> personal level from fellow members. However, if there is anything
> that may be termed "justice" on Usenet, it is by definition vigilante
> justice, since there are are no duly authorized officers of "the law
> of Usenet". I rather prefer it that way, don't you?
The reason vigilante justice is bad in the real world is the same
reason it's wrong here. It denies due process. It assumes that the
people doing the "justice" have an obvious and correct sense of Right.
Here, I am not so sure there is such a sense.
Usenet is a forum where a "me too" post is considered wrong by some, where
a post that is on-topic but uses bad language is considered wrong by others,
and where a post that is off-topic but polite is considered wrong by others.
What gives one set of offended people more moral right than another group
to hijack on-topic conversation in the name of "justice" and to insist on
a protracted meta-discussion about an individual? I find it marginal but
tolerable for someone to write an isolated post saying simply "I find the
prior post objectionable" in direct response to a post that is. I find it
utterly out of bounds and beyond acceptable behavior for there to be a huge
extended conversation, especially one lasting months and consuming whole
threads, about one or a handful of posts.
If I were to go after vigilante justice, it would almost surely not be
after the same wrongs as you. And that doesn't mean my way is right
either. It means that IMO we should all get it out of heads that
there is a single meaningful notion of justice or acceptability in a
forum that doesn't insist on a behavioral code as a requirement of
membership.
I find my own post here on this to be unreasonably long and off-topic,
and am sorry you dragged me into it. I respect your opinion, Pekka,
but would rather have discussed it with you privately. I'll therefore
voluntarily decline to post for the rest of the month in penalty.
I keep hoping this will teach me to just let these things go by without
response. Which is what I think others should do, too.
Tim Bradshaw wrote:
> Yes, I do think it would help if you went away.
wo wow wow Mr. Bradshaw, let's not pick up Nagg'm's bad habits, ok?
Kindness has its place, and let's remember politness has a theory of
evolution aspect too. This comrade Erran Gat, i think has some
earnestness in him. In my years of unix-flaming, i've learned that
most people are not adamantly stupid, but simply don't know. You have
to teach them, sometimes patiently. To explain the errors or their
ways, and in the process you might learn a thing or two. On the whole
this is called conference.
One reason i love the cover of Abelson & Sussman's book (Structure and
Intepretation of Computer Programs) is the element of conference.
<http://xahlee.org/UnixResource_dir/sicp-cover.jpg>
Look at the wizard and witch, exchanging knowledges of computing, with
gestures and kindness. Give and take. Look, the wizard is even holding
the compass -- a math tool. The table holds tomes. Notable is their
sex. Man and woman. Look at the eyes of the witch, with deference and
sincerity. What a lovely bitch. Then there's the prominent lambda. Oh,
the magic and depth of mathematics, as to conjure up the moster foot
under the table.
This picture is in my vision the ideal society. All people are
knowledgable, filled with love, and no moment goes by without flirting
between the sexes.
--
Now Dear Erran Gat,
although i don't know Common Lisp, but i have sufficient background to
get the gist of debate, and do have a few opinion of my own.
The question we are all hearty about is some hashtable and something
called alist, the details of both i do not know. However, from my
experience of language debates, i conceive a solution that can
progress senseless debates tremendously. Of the members in a debate,
most will be language users (i.e. programers who uses the language.),
but some will be knowledgeable in compilers or how a language is
implemented. I would suggest, that we devise a way to immediatly drop
dead all the members of the latter group, so that the members of a
language debate will comprise of only language users. This way, when
they confer on language merits, they won't have low-level gobbledygook
inpurities, making the debate much more meaningful.
The knowledge of compilers isn't intrinsically bad by itself, but
clearly these folks don't fit into language debates. The critical
thing is that in language debates, those with low knowledge ain't
professional compiler writers either (that requires a mathematician),
but they do know a thing or two about some addresses, memories, caches
& hashes that type of hum. Therefore it is these folks, who confound
debates, on to hashes and speeds and whatnot second-nature
vocabularies and all the while not able to understand aspects and
properties of algorithms in any mathematical way.
A more stringent measure, is to drop dead all low-level programers too,
so that the only people around for language merit discussions are
those who have no knowledge of irrevalent things. Languages becomes
looks along, and that is the heart of denotational semantics.
Erran, i can tell you, this low-level inpurity phenomenon are readily
observed in unix, C, and Perl communities. It is in the heritage of
all C-style tumors. You see it in their talk, in ther doc, and in
their unthinking eyes. Even the super modern Java language has
Interface only as a facade. I hesitate to make hasty judgements, but
i'm thinking recently you gained some low knowledge of the C++ ilk, as
can be observed in your hash-murmur.
--
Any computer language, that is not so-called denotational semantics,
are utterly and fantastically gravely fucking stupid languages.
Witness their programing to people, who know nothing of what they
are doing or talking about.
--Xah Lee
--
I came to this thread late, because these days i do not have a news
feed except google.com. I noticed the nature of this thread only when
Pitman called my name. This thread has now become regarding Naggum
again. I'm so delighted for such opportunity and justification for my
own abuse of this newsgroup. Regarding Erik, i would like to tell my
readers, that the proper attitude is to forgive him. Treat him like a
cute tyke. Listen to his wild ramblings and demands. (he makes little
to no demands, actually.) When horns lock, give ways to his
fantasies. You wouldn't lose money or face, really. Play conservative
and polite in an earnest way, learn from his learned innocence, gloss
over his overly mystifying posts. When Erik don't agree with you, try
to be dogged in your ways, but not in an Erik-pissing way. Be
straightforward and inpersonal. If you are the devious type, you can
even milk him dry. Have him answer some of your technical questions
about Comon Lisp. Use him properly.
It is really no news. We are all here together to make use of each
other. I think there are two keys here: One is the _art of using
people_. Different people are skilled at this in different levels. You
use your wife's body to make babe, use your friends to make merry, use
your dad for advice, use your mom for milk, use the government for
protection, use your boss for employment, use the cops for safty, and
so on. The trick here is to not be morally philosophical about
it. Play it nice, play it well, play it to your advantage, and make
everyone else happy too. Many leaders are masters of using people. It
is in fact how they become trusted leaders.
The other key, is to realize that this is the nature of things. When
we speak of using people, we are sometimes taught to feel
uneasy. Think of it as God's demand. Those who do not use other
people, will perish and die. Using people do not mean abusing
people. Remember, the goal is to maximize your benefits, gingerly on
the balance of things. If you push too hard, played foul, than you
will get kicked because in the same way other people are also trying
to milk you dry. Together, we all milk each other dry, bringing the
most harmony to the world.
--
Kent Pitman wrote:
> I find my own post here on this to be unreasonably long and
> off-topic, and am sorry you dragged me into it. I respect your
> opinion, Pekka, but would rather have discussed it with you
> privately. I'll therefore voluntarily decline to post for the rest
> of the month in penalty. I keep hoping this will teach me to just
> let these things go by without response. Which is what I think
> others should do, too.
my gosh, there is this Pitman meta-saint again. Looming in and out of
this group with portent prognostication.
--
dick & pussy; Love & Knowledge,
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
From: Geoff Summerhayes
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3_6f8.11169$kb.590241@news1.calgary.shaw.ca>
"Xah Lee" <···@xahlee.org> wrote in message
·································@posting.google.com...
>
> Even the super modern Java language has Interface only as a facade.
>
ROTFLMAO!! What an exquisite statement, thanks Xah, made my day.
-------
Geoff
From: Pekka P. Pirinen
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <un0xuj0vs.fsf@globalgraphics.com>
Kent M Pitman <······@world.std.com> writes:
> I find my own post here on this to be unreasonably long and off-topic,
> and am sorry you dragged me into it. I respect your opinion, Pekka,
> but would rather have discussed it with you privately. I'll therefore
> voluntarily decline to post for the rest of the month in penalty.
> I keep hoping this will teach me to just let these things go by without
> response. Which is what I think others should do, too.
I probably shouldn't have ignored the adage that says that if you feel
you have to apologize for something in advance, then you probably
ought to just not do it. At least it's the end of the month. I'll
try to contribute something on-topic myself, even if I can't make up
for Kent.
A little meta-discussion is probably as inevitable on Usenet as a
little flaming. Shouldn't let it get out of hand, though.
--
Pekka P. Pirinen
If you don't succeed at first, try again. Then quit. No use of being a
damn fool about it. - W. C. Fields
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223355152514789@naggum.net>
* Erik Naggum
> To assume that what someone says is correct does _not_ mean to believe
> it, _not_ agree with it, and _not_ use it without establishing that it is
> in fact correct.
* Erann Gat
| Ah, yes, I just remembered another one of Erik's Rules: he subscribes to
| the Humpty-Dumpty theory of langauge: when Erik uses a word it means
| precisely what Erik wants it to mean, neither more nor less.
This is another fine example of what happens when a reader does _not_
assume that what another poster wrote is correct or intended to impart
some useful point of view.
The lack of willingness to understand is just _staggering_ in Erann Gat,
and his ability to find unreasonable things to attack is equally strong.
He has found the Truth about me, and god damn me if I disagree with him
or try to explain something that runs counter to this Truth.
Somebody should come pick him up and cart him off to a mental institution.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Kenny Tilton
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C73D97C.48BD358@nyc.rr.com>
Erik Naggum wrote:
>
> Let me quote from The Penguin Dictionary of Psychology to put this in a
> context I hope few others have thought of:
>
> bereavement: The emotional reactions felt following the death
> of a loved one. A full depressive syndrome is considered
> normal in such a loss and is often accompanied by poor
> apetite, insomnia, and preoccupations with a sense of
> worthlessness.
>
> It appears to me that Erann's loss of faith is akin to the death of a
> loved _idea_
I was thinking Stockholm Syndrome:
> The Stockholm Syndrome comes into play when a captive cannot escape, is
> isolated and threatened with death, but is shown token acts of kindness by the
> captor. It typically takes about three or four days for the psychological shift to
> take hold.
>
> A strategy of trying to keep your captor happy in order to stay alive becomes
> an obsessive identification with the likes and dislikes of the captor which has
> the result of warping your own psyche in such a way that you come to
> sympathize with your tormenter!
>
> The syndrome explains what happens in hostage-taking situations, but can
> also be used to understand the behavior of battered spouses, members of
> religious cults, Holocaust victims, household pets, and perhaps even users of
> Internet Explorer.
...also...
> Crew Training
> Many airlines include as part of training a briefing or
> provide reading materials to crew regarding the
> Stockholm Syndrome. To understand the Stockholm
> Syndrome, you must understand the effects of
> sensory deprivation. Imagine if you can, being
> forcibly removed from your daily life (with all its
> familiar environments, routines and social
> interactions) and put in a strange place from which
> you cannot escape. Your only interactions are with
> your captors, whose behavior can be capricious -
> that is, beyond your ability to understand why or
> when they may choose to do something for you, with
> you or to you. They may withhold food and/or water,
> in order to raise its value to you in order to receive
> your compliance with their demands. You may be
> left in complete silence or darkness with nothing to
> do, nowhere to go. You may not be allowed to talk or
> interact with other prisoners.
The above sure sounds like a Lisper stuck in a C++ shop.
I think Lisp is being sacrificed as a sop to the C++ "masters". The
praise of those guys is way too groveling. I wager these Lisp slams are
meant for their eyes.
kt
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2102020941040001@192.168.1.50>
In article <············@rznews2.rrze.uni-erlangen.de>, Jochen Schmidt
<···@dataheaven.de> wrote:
> Why don't you simply write the draft and put it on CLiki.
Yes, I should do that. Thanks for reminding me.
> If you really want to help enhancing Common Lisp you should try to reduce
> complaining to a minimum and better spend this time for writing some code.
So one of the reasons I seem to do a lot more "complaining" than writing
code is that I once presented a suggestion for a change to the language
together with working code. The reaction was almost uniformly negative,
bordering on hostile. Since I don't like wasting time, I now try to get a
read on whether an idea will fly or not before I spend a lot of time on
it. What you call "complaining" I think of more as "market research."
E.
From: Thomas F. Burdick
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <xcv4rkau21m.fsf@famine.OCF.Berkeley.EDU>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <············@rznews2.rrze.uni-erlangen.de>, Jochen Schmidt
> <···@dataheaven.de> wrote:
>
> > Why don't you simply write the draft and put it on CLiki.
>
> Yes, I should do that. Thanks for reminding me.
I think that's a terrible idea. People shouldn't propose specs for
utilities they don't use. You can't always tell whether or not
something's a good idea if you've never used it, and it's particularly
hard to tell if there are design flaws. I thought that page was
supposed to be for utilities that people used that they wanted a
common design for. Maybe a seperate "request for a feature" page
would be more appropriate. Hell, it's a wiki, I'll go add one myself.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2102021058060001@eglaptop.jpl.nasa.gov>
In article <···············@famine.OCF.Berkeley.EDU>,
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <············@rznews2.rrze.uni-erlangen.de>, Jochen Schmidt
> > <···@dataheaven.de> wrote:
> >
> > > Why don't you simply write the draft and put it on CLiki.
> >
> > Yes, I should do that. Thanks for reminding me.
>
> I think that's a terrible idea.
OK, then I won't do it. You people figure out how folks are supposed to
make contributions around here and then let me know.
E.
From: Marc Spitzer
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <slrna7ap00.2b7j.marc@oscar.eng.cv.net>
In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> In article <···············@famine.OCF.Berkeley.EDU>,
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
>> ···@jpl.nasa.gov (Erann Gat) writes:
>>
>> > In article <············@rznews2.rrze.uni-erlangen.de>, Jochen Schmidt
>> > <···@dataheaven.de> wrote:
>> >
>> > > Why don't you simply write the draft and put it on CLiki.
>> >
>> > Yes, I should do that. Thanks for reminding me.
>>
>> I think that's a terrible idea.
>
> OK, then I won't do it. You people figure out how folks are supposed to
> make contributions around here and then let me know.
>
> E.
here is one way to do it:
1: write something you believe is useful or needed by you
2: make a tar ball
3: post an announcement to Comp.lang.lisp telling us what it does
and what is the license etc. put in a URL where the package
can be found.
Does that sound fair to the rest of 'us people' out there?
marc
From: Jochen Schmidt
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a53efj$7f7$1@rznews2.rrze.uni-erlangen.de>
Erann Gat wrote:
> In article <············@rznews2.rrze.uni-erlangen.de>, Jochen Schmidt
> <···@dataheaven.de> wrote:
>
>> Why don't you simply write the draft and put it on CLiki.
>
> Yes, I should do that. Thanks for reminding me.
>
>> If you really want to help enhancing Common Lisp you should try to reduce
>> complaining to a minimum and better spend this time for writing some
>> code.
>
> So one of the reasons I seem to do a lot more "complaining" than writing
> code is that I once presented a suggestion for a change to the language
> together with working code. The reaction was almost uniformly negative,
> bordering on hostile. Since I don't like wasting time, I now try to get a
> read on whether an idea will fly or not before I spend a lot of time on
> it. What you call "complaining" I think of more as "market research."
Not all ideas have to get adapted - but if you do not try nothing happens.
If your proposal is simply an add-on then nothing can be said against it.
The time will show if it then gets used or not.
I think there were enough people who said that an extensible associative
map facility is probably a good idea.
I know of at least one (Rahul Jain) who tries to build such a thing as a
library.
I don't think that you can get any more insight trough further "market
research". We already know now the problem and it is time to talk upon
solutions.
The CLiki page I mentioned in an earlier posting is editable (like any
Wiki). If you take a look at it you will see that the different proposals
are in a much differing state. Hacking a little page together with a clear
problem description and some thoughts on how to solve it should be less work
than posting lenghtly articles to c.l.l ;-)
Interested parties can then post their opinions and suggestions to that
page too.
ciao,
Jochen
--
http://www.dataheaven.de
From: Thomas A. Russ
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ymiadu4f2hc.fsf@sevak.isi.edu>
···@jpl.nasa.gov (Erann Gat) writes:
> Not at all. I'd be happy to write a draft proposal, but before I do I'd
> like some indication that someone besides me thinks this is worth doing.
> Unlike Erik, I'm not always sure that I'm right about everything. I'd
> also like some indication that even those who don't think it's worth doing
> at least think it's not doing any harm. At the moment the feedback I'm
> getting is pretty much the opposite.
>
> E.
Well, I think it would be worth doing. If one could have a common
interface, that would be all to the good, since it would make modifying
the underlying implementation without disturbing the code that uses it
easier. The fact that some things are easier with ALists shouldn't be a
deterent to providing an interface that doesn't allow those things.
After all, not all uses of ALists rely on those properties, and for the
cases where it does, you can just use them directly.
I'm just not sure how easy it would really be to integrate hash tables
and ALists. The fundamental problem that I see is that hash tables are
clearly mutable objects, but lists are not. At the very least, you have
problems with the empty list, so that would seem to require there to be
some additional (perhaps small) overhead for ALists. In particular, it
would seem to mean that one could not replace ALists with the new
interface in existing code.
Nevertheless, having an abstract "Map" or "Dictionary" interface would
be progress.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a51fj3$3p142$1@ID-125440.news.dfncis.de>
In article <···············@sevak.isi.edu>, Thomas A. Russ wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
>> Not at all. I'd be happy to write a draft proposal, but before I do I'd
>> like some indication that someone besides me thinks this is worth doing.
>> Unlike Erik, I'm not always sure that I'm right about everything. I'd
>> also like some indication that even those who don't think it's worth doing
>> at least think it's not doing any harm. At the moment the feedback I'm
>> getting is pretty much the opposite.
>>
>> E.
>
> Well, I think it would be worth doing. If one could have a common
> interface, that would be all to the good, since it would make modifying
> the underlying implementation without disturbing the code that uses it
> easier. The fact that some things are easier with ALists shouldn't be a
> deterent to providing an interface that doesn't allow those things.
> After all, not all uses of ALists rely on those properties, and for the
> cases where it does, you can just use them directly.
Does that mean that you would be happy with
(make-hash-table :i-am-an-alist-internally t)
?
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Will Deakin
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C72757A.8040302@hotmail.com>
Christophe Rhodes wrote:
> No, I'm not bitter :-)
So you're a *lager*!
;)w
> >> Also, alists and plists don't suffer from rehash problems upon garbage
> >> collection.
> >
> > Now this is something I'm not familiar with. Could you elaborate?
>
> I suspect that if you have an 'eq hashtable and the obvious (at least to
> this non-implementor) implementation of eq, if GC moves the objects in the
> hashtable, it will need to be rehashed. (Since the representation of
> non-immediate objects will have changed.)
You're right that if you use the object's address (maybe including tag
bits,
depending on implementation) as the hash value that non-atomic keys will
need
to be rehashed every time they're moved.
But another way to do it is to reserve a hash slot in each composite
object,
and generate a random number as its hash value. This may have the side
affect
of giving you a better distribution, since addresses (esp on
newly-consed
objects) may be tightly clustered in eden.
It is also possible (though not quite so simple) to reserve the hash
slot
lazily. This is of more use for things like cons cells. The idea is
that
you have a flag somewhere (header) that indicates if the object has been
hashed. At GC time if you hit a hashed cons cell you go look up his
hash
wherever it is, and copy the cells contents into a new hashed-cons
object
that contains the header. Calculating the hash value of a non hash-cons
may take a little longer, but it's usually better than rehashing the
world
on a GC, and it saves the extra slot for every cons cell.
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222880518268721@naggum.net>
* Erann Gat
| What I'm saying is that when it comes to associative maps -- an extremely
| important abstraction (arguably the most important in all of computer
| science, but that's another discussion) -- this philosophy of deferring
| decisions breaks down, at least within the bounds of the current standard.
Not so. If you are at all uncertain about how to deal with these things,
you either write macros or functions to hide the implementation technique
you (need to) use, and those macros would be named after the particular
association mapping needed, not afte the functionality alone.
| I can't say "I want an associative map, and I want to defer the decision
| of whether the underlying implementation will be an alist, a plist, a
| hash-table, a binary-tree, a trie, or something else."
Of course you can. Why have you turned into such a mindless troll?
Lest you have forgotten because of your C++ exposure of late, over here
in Common Lisp land, we shape the language to suit our needs, we do not
only used the lowest-level built-in functionality without modification or
reflection upon our needs.
> Also, alists and plists don't suffer from rehash problems upon garbage
> collection.
| Now this is something I'm not familiar with. Could you elaborate?
Is it not obvious? If an eq or eql hashtable hashes on the machine
address of the object, which is a pretty obvious thing to do, those
machine addresses will change if garbage collection moves live objects,
such as many GC algorithms do. Therefore, such a hashtable will need to
survive those object movements, somehow. This may not be a trivial task.
For instance, symbols, which are very useful in eq hashtables, have their
own hashing code as part of the symbol structure in Allegro CL to avoid
this high cost. Something similar to this can obviously not be done for
a lot of other useful hashing keys.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Tim Bradshaw
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ey37kpd401y.fsf@cley.com>
* Erann Gat wrote:
> What I'm saying is that when it comes to associative maps -- an extremely
> important abstraction (arguably the most important in all of computer
> science, but that's another discussion) -- this philosophy of deferring
> decisions breaks down, at least within the bounds of the current
> standard.
I'm not averse to a standard (or de-facto standard) common interface
to associative maps. However in my code I find that in all the cases
where I would have problems because of the differing interfaces the
usage is either very local indeed (for instance within a little
collection of functions to implement a binding scheme or occurs
check), or it sits behind some other interface (FIND-CHILD-NAMED /
ADD-CHILD-NAMED or something, where the implementation can (and
sometimes does) change. The only places where I globally expose an
implementation are where I care about fast binding (and the
implementation is then an alist). So *for me* (italics intentional)
the gain would be very small.
--tim
From: Christopher C. Stacy
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <u7kpb96h7.fsf@theworld.com>
>>>>> On Sun, 17 Feb 2002 07:45:18 -0800, Erann Gat ("Erann") writes:
Erann> All I'm saying is that IMO converging on a de facto standard
Erann> for an abstract associative map not tied to any particular
Erann> implementation would be worthwhile.
If you want an abstract associative map, I think that's what the
MAKE-HASH-TABLE and GETHASH are supposed to be. ASSOC and MEMBER
and stuff are for when you also need the data to be in a list.
If you need to get inside to mess with the implementation...
Lisp's "hash tables" do not need to actually be based on hash codes
and buckets. An implementation could provide "hash table" objects
that are really just alists (or whatever) under the covers.
The implementation of the object could change at run-time when
the system noticed that performance was not optimal for the current
implementation; sort of a "meta re-hash". (This was proposed for
the Symbolics implementation, but I am not sure it was implemented:
more trouble than worth it, or maybe it turned out that hashing was
faster even for small tables anyway.)
It would be nice if Common Lisp opened up the underlying protocol
for implementing new kinds of ("hash") tables based on CLOS.
The Lisp Machine provided some of that: PUT-HASH, GET-HASH, SWAP-HASH,
CLEAR-HASH, REM-HASH, MODIFY-HASH, MAP-HASH and NEXT-ELEMENT (for LOOP
interation paths); and some internal ones CHOSE-NEW-SIZE, GROW,
COPY-HASH, NEW-ARRAY.
The Lisp Machine also had the HEAP (prioritized list) data type
that provided similar table functionality.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1602021140360001@192.168.1.50>
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> * ···@jpl.nasa.gov (Erann Gat)
> | 2. Having "all those nice list functions" is only an advantage insofar as
> | they let you do something useful. Being able to operate on an alist as a
> | list is not in and of itself a feature, and can lead to problems if you're
> | not careful. I can't offhand think of anything useful you can do with an
> | alist that is fundamentally more difficult with a hashmap.
>
> Suppose it is a special variable. (let ((*alist* *alist*)) ...) allows
> you to push key-value pairs on the list and have them work in a manner
> very similar to scoping. You may temporarily push a single key-value
> element to shadow another and then delete it when you are done, with a
> simple (delete <key> <alist> :key #'car).
Two comments.
First, the special variable is a red herring. What you say is equally
true whether or not *alist* is special.
Second, you can do exactly the same thing with a list of hash tables. In
fact, an alist is just a special case of this. You can think of a cons
cell as a brain-damaged hash table with a capacity of one entry and the
identity as the hash function.
> Alists are also just as efficient from key to value as from value to key.
If you really need a bidirectional mapping you can get one easily with a
pair of hash tables. And the runtime efficiency will be O(1) instead of
O(N).
E.
From: Tim Bradshaw
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ey3bsep40cd.fsf@cley.com>
* Erann Gat wrote:
> Second, you can do exactly the same thing with a list of hash tables. In
> fact, an alist is just a special case of this. You can think of a cons
> cell as a brain-damaged hash table with a capacity of one entry and the
> identity as the hash function.
You can do the same thing, but it's several hundred times more
expensive to do.
--tim
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1702020716040001@192.168.1.50>
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> * Erann Gat wrote:
>
> > Second, you can do exactly the same thing with a list of hash tables. In
> > fact, an alist is just a special case of this. You can think of a cons
> > cell as a brain-damaged hash table with a capacity of one entry and the
> > identity as the hash function.
>
> You can do the same thing, but it's several hundred times more
> expensive to do.
That depends. If you store only one item per hash table, then yes, that
would be pretty stupid. But if you store a whole frame in each hash table
and your frames are large then hash tables can be significantly more
efficient.
E.
From: Tim Bradshaw
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ey3k7tb3me7.fsf@cley.com>
* Erann Gat wrote:
> That depends. If you store only one item per hash table, then yes, that
> would be pretty stupid. But if you store a whole frame in each hash table
> and your frames are large then hash tables can be significantly more
> efficient.
Erik specifically said `push a single value'.
--tim
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1802022158290001@192.168.1.50>
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> * Erann Gat wrote:
>
> > That depends. If you store only one item per hash table, then yes, that
> > would be pretty stupid. But if you store a whole frame in each hash table
> > and your frames are large then hash tables can be significantly more
> > efficient.
>
> Erik specifically said `push a single value'.
Yes, and I extrapolated to the more difficult case of a large number of
values. But fine, we'll do it your way.
(defun hassoc (key loh) ; loh = list-or-hashtable
(acond ( (null loh) nil )
( (hash-table-p loh) (gethash key loh) )
( (consp (car loh))
(if (eq key (caar loh))
(car loh)
(hassoc key (cdr loh))) )
; And while we're at it...
( (and (hash-table-p (car loh)) (gethash key (car loh)))
(cons key it) )
(t (hassoc key (cdr list)))))
(This code is untested.)
Remember, the topic under discussion was my claim that there's nothing you
can do with alists that would be fundamentally more difficult to do with
hash tables.
Now, what was the point you were trying to make?
E.
From: Tim Bradshaw
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ey37kp9ztqx.fsf@cley.com>
* Erann Gat wrote:
> Now, what was the point you were trying to make?
That binding a single value is expensive if you use hashtables.
I can't read your code because it's weirdly formatted and uses what is
obviously some special conditional macro which it fails to
define. However as far as I can see it does not solve this problem,
but instead clumsily defines a `generic function' for lookup which has
a couple of fixed cases to deal with hashtables and alists. I suppose
your argument is that you can make hashtables cheap by, erm, using
alists instead. Well, OK, I agree with that.
I wish I was Erik and could think of some really blistering abuse at
this point. Perhaps if enough people scream at you you'll go away for
good.
--tim
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1902021055150001@eglaptop.jpl.nasa.gov>
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> * Erann Gat wrote:
>
> > Now, what was the point you were trying to make?
>
> That binding a single value is expensive if you use hashtables.
>
> I can't read your code because it's weirdly formatted and uses what is
> obviously some special conditional macro which it fails to
> define.
Sorry. You present yourself as a knowledgeable person and I was trying to
treat you that way.
ACOND is from Paul Graham's "On Lisp". It's like "COND" but it binds the
variable "IT" to the result of the condition in the consequent clause.
(defmacro acond (&rest clauses)
(if (null clauses)
nil
(let ((cl1 (car clauses))
(sym (gensym)))
`(let ((,sym ,(car cl1)))
(if ,sym
(let ((it ,sym)) ,@(cdr cl1))
(acond ,@(cdr clauses)))))))
And sorry about the werd formatting. I was writing that message on a
non-paren-balancing editor.
> However as far as I can see it does not solve this problem,
> but instead clumsily defines a `generic function' for lookup which has
> a couple of fixed cases to deal with hashtables and alists. I suppose
> your argument is that you can make hashtables cheap by, erm, using
> alists instead. Well, OK, I agree with that.
I'm glad you agree, but that's not the point I was trying to make. Let me
be very clear. You say your point was:
> That binding a single value is expensive if you use hashtables.
My point is: you are wrong. Binding a single value is *not* expensive
even if you use hash tables, as my code, clumsy and unrefined though it
may be, clearly shows. The cost of the binding is exactly the same in
both cases. There is an extra call to hash-table-p in my version, but a
good compiler should be able to optimize the call to gethash to get rid of
the redundant call, so the net cost in a good implementation is actually
zero, and even in a not-so-good implementation is very small.
Note that "making hashtables cheap" is a completely different issue, a
non-sequitur, and one which you injected into this conversation, not me.
> I wish I was Erik and could think of some really blistering abuse at
> this point.
Work like that is better left to the master.
> Perhaps if enough people scream at you you'll go away for good.
You really think that will help?
E.
From: Tim Bradshaw
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ey3bselxgyp.fsf@cley.com>
* Erann Gat wrote:
> Sorry. You present yourself as a knowledgeable person and I was trying to
> treat you that way.
I don't present myself in any way at all. *You* or others may make
assumptions based on what I write (such as: I've read and remember On
Lisp).
> You really think that will help?
Yes, I do think it would help if you went away.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1902021653200001@eglaptop.jpl.nasa.gov>
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> * Erann Gat wrote:
>
> > Sorry. You present yourself as a knowledgeable person and I was trying to
> > treat you that way.
>
> I don't present myself in any way at all. *You* or others may make
> assumptions based on what I write (such as: I've read and remember On
> Lisp).
Right. My bad. I apologize for assuming you had read Graham. And I
apologize for thinking that if you hadn't read Graham that you might know
how to use a search engine, or that you might even have the intelligence
to figure out what ACOND does all by yourself (it isn't that hard). And I
aplogize for assuming that if you didn't know how to do any of these
things that you might just ask. In fact, I apologize for assuming you
know anything at all. I am really truly sorry. It won't happen again.
E.
From: Tim Bradshaw
Subject: Posting code samples (was Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).)
Date:
Message-ID: <ey3u1scwh4x.fsf_-_@cley.com>
* Erann Gat wrote:
> Right. My bad. I apologize for assuming you had read Graham. And I
> apologize for thinking that if you hadn't read Graham that you might know
> how to use a search engine, or that you might even have the intelligence
> to figure out what ACOND does all by yourself (it isn't that hard). And I
> aplogize for assuming that if you didn't know how to do any of these
> things that you might just ask. In fact, I apologize for assuming you
> know anything at all. I am really truly sorry. It won't happen again.
Nice sarcasm (or is it irony? I get them mixed up).
However there's a point here which I think is worth making. *I* find
it much easier if people post code snippets that they do one of two
things:
1. Post portable CL - including any macro sources in
particular, and avoiding gratuitous minor variants on
standard facilities.
2. Comment clearly that there are non-included macros, either
giving a pointer to the definition, or explaining what the
macro does.
This applies particularly to macros (and readmacros &c) as they can
change the syntax of the language significantly in a way that
functions can't.
Of course, as you so elaborately pointed out, it's possible to search
for definitions or spend time working out what they might be, but it
makes life harder, especially when the macros are really minor
variants on standard facilities. If your macro is something like
(with-html-output (s)
(:html ...))
then it's fairly clear that this actually does something substantive
which can't usefully be replaced with standard CL facilities (and even
here - especially here - I think that pointers to sources should be
posted), but it it's
(if* ...)
or
(acond ...)
then it obviously can, and for small examples there is really only a
tiny gain to be had, and the cost is that the code sample is harder
to read for many times as many people as the one for whom it was,
presumably, slightly easier to write.
Doing this would, I think, make communication easier. I'd like to
encourage people to do this (of course this is just my opinion: I'm
just a random hacker who makes his living from Lisp and I don't
pretend to present myself as any kind of authority on anything, let
alone CL).
--tim
[Of course one of the features of the CL community (at least as
represented in CLL) is that there are a fair number of people who get
very wound up about minor variants on standard facilities and make a
lot of noise about this, frequently to the extent of dismissing those
who do not obsess about these (either because they are happy with the
standard facilities, or because they quietly implement their own
variants without treating them as religious issues) as
`traditionalists' who are somehow resisting change. I don't
understand why this happens: if I was a psychologist I'd probably have
some bogus theories.
There's another set of people on CLL who are upset about the lack of
some facility in CL, often more substantive than the trivial issues
above, and rather than just producing proposals for such facilities
they stress in public about how the lack is holding CL back, often
either implicitly or explicitly accusing others of being
traditionalists Again, I don't understand this: why not just produce a
proposal and/or an implementation? I find all this behaviour very
strange.]
From: Duane Rettig
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <43czx4vv1.fsf@beta.franz.com>
···@jpl.nasa.gov (Erann Gat) writes:
> Remember, the topic under discussion was my claim that there's nothing you
> can do with alists that would be fundamentally more difficult to do with
> hash tables.
How about POP?
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1902021018030001@eglaptop.jpl.nasa.gov>
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Remember, the topic under discussion was my claim that there's nothing you
> > can do with alists that would be fundamentally more difficult to do with
> > hash tables.
>
> How about POP?
I guess it depends on what you consider fundamentally more difficult.
Popping an alist costs you esssentially nothing because this capability is
built into the language, whereas to "pop" a hash table you'd need to write
probably 10-20 lines of code. If you consider that "fundamentally more
difficult" then I concede the point (but would also point out that Erik
wrote much more than that for his apparently throwaway "proof of concept"
that led to this discussion.)
E.
From: Duane Rettig
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <4d6z1ussu.fsf@beta.franz.com>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > Remember, the topic under discussion was my claim that there's nothing you
> > > can do with alists that would be fundamentally more difficult to do with
> > > hash tables.
> >
> > How about POP?
>
> I guess it depends on what you consider fundamentally more difficult.
Well, "fundamentally more difficult" is your own phrase, so you'll
have to define it. The word "difficult" has several usages (especially
as an antonym), and it also has several dictionary meanings, including
the one I settled on (because the others didn't seem to fit) which defines
difficult as "presenting obstacles or trouble" (World Book). Thus the
fact that hash-tables don't give you POP without having to code something
makes it fundamentally more difficult than alists (which give you POP
for free) according to this definition.
> Popping an alist costs you esssentially nothing because this capability is
> built into the language, whereas to "pop" a hash table you'd need to write
> probably 10-20 lines of code. If you consider that "fundamentally more
> difficult" then I concede the point (but would also point out that Erik
> wrote much more than that for his apparently throwaway "proof of concept"
> that led to this discussion.)
If maps were the only thing that alists provided, then I would have
no argument with you. But alists can also serve as stacks, and it is
fundamentally more difficult (according to my own interpretation) to
implement a stack concept using hash-tables than with alists.
Consider the implementation of a lisp interpreter, which might implement
execution environments using an association between names and values
along several namespace axes. An easy design using either alists or
hash-tables. But wait; these mappings must also have stack-like qualities,
in that they must be able to be peeled back as well as augmented, so that
they retain correct mappings for variables, etc. as they leave the scope
of their lexical lifetimes (hence my issue about POP). In addition,
in order for a debugger to see within such a stack to show the user
internal states, handles must be able to be captured which show the
environment in its peeled back state, even without having been
actually peeled back. Alists provide for all of these requirements
trivially, but some clever coding is required in order for hash-tables to
be used in the same way.
Note that I actually did implement this, and our interpreter actually
uses first-class environments that are based on hash-tables instead of
alists since version 6.0. So why am I disagreeing with you? I actually
do agree that hash-tables are underutilized and are at least as useful as
alists, but I only disagree about whether all of the requirements which
alsist can satisfy can also be satisfied by hash-tables trivially.
My environments implementation is considerably more than 10-20 loc.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1902021417050001@eglaptop.jpl.nasa.gov>
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> Note that I actually did implement this, and our interpreter actually
> uses first-class environments that are based on hash-tables instead of
> alists since version 6.0. So why am I disagreeing with you? I actually
> do agree that hash-tables are underutilized and are at least as useful as
> alists, but I only disagree about whether all of the requirements which
> alsist can satisfy can also be satisfied by hash-tables trivially.
> My environments implementation is considerably more than 10-20 loc.
So I provided an existence proof of what you describe in less than 10
lines of code (using Paul Graham's ACOND macro, but it's probably still
<20 LOC using just standard CL), though I have no doubt that your
implementation does all kinds of wizzy things that mine doesn't.
I think we actually agree more than we disagree here. Remember, this
discussion started with Erik arguing against a generic dictionary syntax
on the grounds that alist syntax served the same purpose.
(http://groups.google.com/groups?selm=3222747467111424%40naggum.net&output=gplain)
Erik wrote:
> I mean, if { "foo" => "bar", "baz" => "zot" } is so great, why is not
> (("foo" . "bar") ("baz" . "zot"))? Is it _only_ the sugar-coated syntax
> that is so visually appealing to some?
My point is simply that no, it's not just the visual appeal. It's also
the fact that the first syntax is implementation-neutral while the second
syntax is not, and IMO that's an advantage. Erik hinted that he agreed
with this:
> Common Lisp has the disadvantage compared to the one-trick languages that
^^^^^^^^^^^^^^^^^^^^
> the different access functions for various kinds of mappings between key
> and value are precisely that -- different.
although with Erik it's sometimes hard to tell when he's being ironic and
when he's not.
I also just thought of another advantage: the first syntax lets you catch
certain errors at read time that the second syntax does not, e.g. (("foo"
. "bar") ("baz" . "zot") . bing)
Then Nils Goesche replied that alists are better *because* they are lists,
I asked why, and Erik responded with the shadowing argument, to which I
responded that you can do shadowing with hash tables too. I didn't spend
a lot of effort developing this argument because in trying to give people
the benefit of the doubt about what they already understood I assumed it
would be self-evidently true. I suppose it's not altogether inconceivable
that I have stumbled across something entirely new to the Lisp community
in my little code snippet. But I really doubt it.
E.
From: Rahul Jain
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <87u1sd57g0.fsf@photino.sid.rice.edu>
···@jpl.nasa.gov (Erann Gat) writes:
> Then Nils Goesche replied that alists are better *because* they are lists,
> I asked why, and Erik responded with the shadowing argument, to which I
> responded that you can do shadowing with hash tables too.
What's that Perlis said about lisp programmers, cost, and value?
I guess you still are a lisper at heart. :)
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ············@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
From: Nils Goesche
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <a50u4d$3phvs$1@ID-125440.news.dfncis.de>
In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> Then Nils Goesche replied that alists are better *because* they are lists,
> I asked why, and Erik responded with the shadowing argument, to which I
> responded that you can do shadowing with hash tables too. I didn't spend
> a lot of effort developing this argument because in trying to give people
> the benefit of the doubt about what they already understood I assumed it
> would be self-evidently true. I suppose it's not altogether inconceivable
> that I have stumbled across something entirely new to the Lisp community
> in my little code snippet. But I really doubt it.
The more often you claim you doubt it the less I believe it ;-)
Sure: Define a cons cell to be a hashtable with one entry. Since normal
lists are made of cons cells you can even simulate list functionality
with hash tables. You could as well do it this way:
(defun mycons (a b)
(lambda (x)
(ecase x
(car a)
(cdr b))))
(defun mycar (c)
(funcall c 'car))
(defun mycdr (c)
(funcall c 'cdr))
CL-USER 9 > (let ((cell (mycons 'foo 'bar)))
(values (mycar cell) (mycdr cell)))
FOO
BAR
CL-USER 10 >
So, we can do everything with hashtables what we can do with alists
or even lambda. Duh. But the question is: Do we *want* to? Well,
I certainly don't. Still doubting I understand what you mean?
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2002021351120001@eglaptop.jpl.nasa.gov>
In article <··············@ID-125440.news.dfncis.de>, Nils Goesche
<······@cartan.de> wrote:
> In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
>
> > Then Nils Goesche replied that alists are better *because* they are lists,
> > I asked why, and Erik responded with the shadowing argument, to which I
> > responded that you can do shadowing with hash tables too. I didn't spend
> > a lot of effort developing this argument because in trying to give people
> > the benefit of the doubt about what they already understood I assumed it
> > would be self-evidently true. I suppose it's not altogether inconceivable
> > that I have stumbled across something entirely new to the Lisp community
> > in my little code snippet. But I really doubt it.
>
> The more often you claim you doubt it the less I believe it ;-)
Why, thank you! ;-)
> So, we can do everything with hashtables what we can do with alists
> or even lambda. Duh. But the question is: Do we *want* to? Well,
> I certainly don't. Still doubting I understand what you mean?
So one of the things we do with alists is make chains of environments. We
cons additional associations onto the beginning of the alist and they
shadow bindings later in the alist. Nice. But searching an alist is of
time complexity O(N) so this doesn't scale very well if we have large
environments. If the size of a frame (the set of bindings pushed as a set
onto the beginning of an alist) is large then alists can be inefficient.
You can make searching for bindings more efficient by taking a single
(large) frame and instead of storing it as a (large) head of an alist
store the whole frame in a single hash table (or binary tree or some other
structure with better then O(N) search performance) and push *that* onto
the beginning of your alist instead. Now you have to rewrite ASSOC to
search this "augmented alist" structure. I posted such code earlier in
this discussion, but I'd consider it a pretty elementary excercise.
My point is that the emphasis on alists enshrined in the standard and in
the textbooks tends to steer people away from considering solutions like
this. (I programmed in Lisp for fifteen years before I even realized that
there was such a thing as a hash table.) By contrast, an
implementation-neutral dictionary will not (n fact by definition cannot)
steer you away from or towards any particular implementation.
E.
From: Thomas F. Burdick
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <xcv7kp74w4k.fsf@monsoon.OCF.Berkeley.EDU>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@ID-125440.news.dfncis.de>, Nils Goesche
> <······@cartan.de> wrote:
>
> > In article <····················@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> >
> > > Then Nils Goesche replied that alists are better *because* they are lists,
> > > I asked why, and Erik responded with the shadowing argument, to which I
> > > responded that you can do shadowing with hash tables too. I didn't spend
> > > a lot of effort developing this argument because in trying to give people
> > > the benefit of the doubt about what they already understood I assumed it
> > > would be self-evidently true. I suppose it's not altogether inconceivable
> > > that I have stumbled across something entirely new to the Lisp community
> > > in my little code snippet. But I really doubt it.
> >
> > The more often you claim you doubt it the less I believe it ;-)
>
> Why, thank you! ;-)
>
> > So, we can do everything with hashtables what we can do with alists
> > or even lambda. Duh. But the question is: Do we *want* to? Well,
> > I certainly don't. Still doubting I understand what you mean?
>
> So one of the things we do with alists is make chains of environments. We
> cons additional associations onto the beginning of the alist and they
> shadow bindings later in the alist. Nice. But searching an alist is of
> time complexity O(N) so this doesn't scale very well if we have large
> environments. If the size of a frame (the set of bindings pushed as a set
> onto the beginning of an alist) is large then alists can be inefficient.
Well, if we're talking about Lisp environments, think about what you
just said again. "If the size of a freame is large". How many times
have you seen a single form bind, say, 50 variables? Because
somewhere around 30-50 bindings per frame is what you'll need for it
to be a good idea to use a list of hashes. Think about searching a
list of hashes -- you hash your object, check in a table with like 5
entries, and repeat a few times until you find it. Bleah! My
compile, which has first-class environment objects, uses alists for
the variable and fucntion binding slots, for this reason. (I suppose
I could design something where the object gets hashed once, then a
list of vectors is searched using that single hash code, but I've yet
to see a reason to bother; not to mention I'm writing a compiler, not
an interpreter, so I *really* don't think it's worth bothering :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2102020936360001@192.168.1.50>
In article <···············@monsoon.OCF.Berkeley.EDU>,
···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> Well, if we're talking about Lisp environments, think about what you
> just said again. "If the size of a freame is large". How many times
> have you seen a single form bind, say, 50 variables? Because
> somewhere around 30-50 bindings per frame is what you'll need for it
> to be a good idea to use a list of hashes.
First, *if* we're talking about Lisp environments then you may be
correct. But one might want to do something with Lisp other than write
yet another Lisp interpreter.
Second, I find this 30-50 bindings breakeven number implausible.
Traversing 50 bindings of an alist involves something like 150 memory
dereferences (two calls to car and one to cdr for each binding) which
would be something like 1500 machine instructions. On theoretical grounds
it seems to me that the breakeven ought to be more like half a dozen
bindings or so. But I haven't done any experiments so I could be wrong.
E.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-2102021110270001@eglaptop.jpl.nasa.gov>
In article <····················@192.168.1.50>, ···@jpl.nasa.gov (Erann
Gat) wrote:
> In article <···············@monsoon.OCF.Berkeley.EDU>,
> ···@monsoon.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > Well, if we're talking about Lisp environments, think about what you
> > just said again. "If the size of a freame is large". How many times
> > have you seen a single form bind, say, 50 variables? Because
> > somewhere around 30-50 bindings per frame is what you'll need for it
> > to be a good idea to use a list of hashes.
>
> First, *if* we're talking about Lisp environments then you may be
> correct. But one might want to do something with Lisp other than write
> yet another Lisp interpreter.
>
> Second, I find this 30-50 bindings breakeven number implausible.
> Traversing 50 bindings of an alist involves something like 150 memory
> dereferences (two calls to car and one to cdr for each binding) which
> would be something like 1500 machine instructions. On theoretical grounds
> it seems to me that the breakeven ought to be more like half a dozen
> bindings or so. But I haven't done any experiments so I could be wrong.
Now I have done some experiments. The breakeven number on MCL is about 15
bindings. The breakeven number in CLISP is ... ZERO! Yes, amazingly,
doing a hashtable lookup in CLISP is faster (by almost a factor of 2) than
assoc where the key is found in the first element of the alist!
Personally, I find this result almost as implausible as the 50-binding
breakeven, so I've attached a transcript for anyone who wants to check my
work.
E.
-----
[···@alvin gat]$ clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2001
[1]>
(setf h (make-hash-table :test 'eq))
#S(HASH-TABLE EQ)
[2]> (loop for i to 100 do (setf (gethash i h) i))
NIL
[3]> (setf a (loop for i to 100 collect (list i)))
((0) (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16)
(17) (18) (19) (20) (21) (22) (23) (24) (25) (26) (27) (28) (29) (30) (31)
(32) (33) (34) (35) (36) (37) (38) (39) (40) (41) (42) (43) (44) (45) (46)
(47) (48) (49) (50) (51) (52) (53) (54) (55) (56) (57) (58) (59) (60) (61)
(62) (63) (64) (65) (66) (67) (68) (69) (70) (71) (72) (73) (74) (75) (76)
(77) (78) (79) (80) (81) (82) (83) (84) (85) (86) (87) (88) (89) (90) (91)
(92) (93) (94) (95) (96) (97) (98) (99) (100))
[4]>
(defun a-test (n) (dotimes (i 100000) (assoc n a)))
A-TEST
[5]> (defun h-test (n) (dotimes (i 100000) (gethash n h)))
H-TEST
[6]>
(compile 'a-test)
WARNING in function A-TEST :
A is neither declared nor bound,
it will be treated as if it were declared SPECIAL.
A-TEST ;
1 ;
1
[7]> (compile 'h-test)
WARNING in function H-TEST :
H is neither declared nor bound,
it will be treated as if it were declared SPECIAL.
H-TEST ;
1 ;
1
[8]> (time (a-test 0))
Real time: 0.02973 sec.
Run time: 0.03 sec.
Space: 0 Bytes
NIL
[9]> (time (h-test 50))
Real time: 0.016822 sec.
Run time: 0.01 sec.
Space: 0 Bytes
NIL
[10]> (time (a-test 10))
Real time: 0.076064 sec.
Run time: 0.08 sec.
Space: 0 Bytes
NIL
[11]>
From: Nicolas Neuss
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <87u1s9ltbj.fsf@ortler.iwr.uni-heidelberg.de>
···@jpl.nasa.gov (Erann Gat) writes:
> Now I have done some experiments. The breakeven number on MCL is about 15
> bindings. The breakeven number in CLISP is ... ZERO! Yes, amazingly,
> doing a hashtable lookup in CLISP is faster (by almost a factor of 2) than
> assoc where the key is found in the first element of the alist!
>
> Personally, I find this result almost as implausible as the 50-binding
> breakeven, so I've attached a transcript for anyone who wants to check my
> work.
>
> E.
>
> ...
>
> [2]> (loop for i to 100 do (setf (gethash i h) i))
Mapping consecutive integers in a hash-table usually ensures a uniform
distribution of key in the buckets (probably even one per bucket).
Therefore a hash access is equivalent to an array access with some
small computational overhead for computing the key (an easy hash
function is simply taking the rest of an integer division with the
number of buckets which is chosen to be a larger prime number).
This is not the typical case. Usually, there is no uniform
distribution of entries in buckets, and implementations use also
better (?) and more complicated hash-functions.
Nicolas.
P.S.: That said I also think that the breakeven of 50 is probably too
large, at least if the alist is not already completely inside the
cache (which may be the case if you have lots of such alists).
From: Thomas F. Burdick
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <xcvlmdlp6xn.fsf@conquest.OCF.Berkeley.EDU>
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> P.S.: That said I also think that the breakeven of 50 is probably too
> large, at least if the alist is not already completely inside the
> cache (which may be the case if you have lots of such alists).
Well, since I threw out the range of 30-50, I'll explain why. I've
empirically found CMUCL to break even at around 30, in a real
application using symbols. I don't know if it was typical, but I have
no reason to think it wasn't :). Now, when talking about the way in
which to represent a binding stack, lookup isn't the only thing to
consider. LET forms that introduce a single variable, for example,
require a single cons cell for alists, but an entire hash table when
using them. There's also GC time, which is obviously going to be a
bit longer when collecting a hash table than when collecting a cons
cell. And of course rehashing after GC might come into play (although
hopefully it won't if your keys are symbols). So I estimated all the
other costs as an additional 0-20 entries.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Tim Bradshaw
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ey3n0y2vfof.fsf@cley.com>
* Erann Gat wrote:
> Second, I find this 30-50 bindings breakeven number implausible.
> Traversing 50 bindings of an alist involves something like 150 memory
> dereferences (two calls to car and one to cdr for each binding) which
> would be something like 1500 machine instructions. On theoretical grounds
> it seems to me that the breakeven ought to be more like half a dozen
> bindings or so. But I haven't done any experiments so I could be wrong.
I think you can mostly ignore the machine instructions and count the
memory references, although if everything is in cache then
instructions may count too. However this sum isn't right in one
important case: a dictionary that compares on EQL. In that case, you
don't need to dereference the cars of the alist, you merely need to
compare pointers. So traversing 50 bindings is only 100 references in
this case. This is also the worst case - assuming evenly-distributed
lookups you actually average only 50 references.
Finally, this only considers lookup cost. If you push and pop a lot
of frames you also need to consider allocation and initialization
cost, which is likely to be higher for hashtables than it is for
alists.
The only way you (or I, anyway) can know which is better is profiling.
In my case (not writing lisp systems or AI programs) I find that
alists win remarkably often when profiled, often because of the much
lower allocation cost. On the other hand I tend not to use
straightforward dictionaries but more elaborate tree or DAG-structured
things because I'm interested in disambiguating things on prefixes and
implementing multiply-inheriting structures and so on. The average
size of a node in one of these things tends to be about 4.
--tim
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3223114426294576@naggum.net>
* Erann Gat
| Now, what was the point you were trying to make?
What _really_ happened when you lost your faith in Lisp?
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> * Erann Gat
> | Now, what was the point you were trying to make?
>
> What _really_ happened when you lost your faith in Lisp?
Glad you asked!
Let me first tell you how I acquired my faith in Lisp, because my
experience was very different from yours (as told in
http://groups.google.com/groups?selm=3208226254834485%40naggum.net&output=gplain)
I started using Lisp in high school, in 1979, on an Apple II. It was my
third (computer) language, after Basic and Pascal. I fell in love with it
almost right away even though in retrospect I really didn't "get it" for a
very long time. (Maybe I still don't.)
In those days I was growing up in Oak Ridge, Tennessee, a town of about
30,000 people, whose main industry is a nuclear research facility, so I
had the good fortune of being around a lot of really smart people, but
they were mostly nuclear engineers and physicists, not computer
scientists. They knew a lot about fortran and how to solve differential
equations, but I was interested in AI. I wanted to build autonomous
robots.
I was drawn to Lisp for three reasons. First, it was the language of
choice for the area of work I wanted to get into. Second, it struck me
right away as more aesthetic than Pascal or Fortran, and aesthetics are
important to me. Finally, it was just so much easier to get things done
in Lisp than in any other language. And not just by a little bit.
This was really driven home in college, where I used Lisp while my
colleagues used Pascal and C (and sometimes PL/I or Fortran). What took
them days and weeks to do took me hours or minutes, and not because I was
that much smarter than they were, because when I wrote code in Pascal my
performance was actually much worse than theirs. I particularly remember
my first graduate course in compilers. I did my work in Lisp while my
colleagues all used Pascal. They turned in reams of printouts (some were
literally a foot high), while my entire output for the term was maybe
twenty pages of code (including comments).
That experience convinced me of two things. First, using Lisp was the
Right Thing and second, many things (perhaps most things, perhaps all
things) that appear to be hard are actually easy. (I have since changed
my mind on both points, but I'm getting ahead of myself.)
The next ten years pretty much confirmed these lessons. Around 1986
Macintosh Common Lisp (then called Coral Common Lisp) came along, and I
never looked back. As a programming environment it is still in class by
itself even after fifteen years.
<tangent>
I used a Symbolics Lisp machine for a few years in the late eighties and
my experience with it was very unfortunate. I found the LispM to be
horrifically complicated and badly underpowered for what it was trying to
do. I often got myself into situations where the machine was many, many
seconds, sometimes minutes, behind my keystrokes. It was so frustrating I
eventually just gave up on it and went back to my Macintosh.
</tangent>
In 1988 I went to work at JPL, and again I found myself running rings
around other programmers by using Lisp. I did things (like write
compilers for little mini-languages) that people using C (there was no C++
at the time) wouldn't even contemplate attempting.
At JPL I encountered an interesting phenomenon. I would have proposals
rejected on the grounds that what I was proposing was too hard and
couldn't be done, when in fact I knew that what I was proposing was
actually quite easy (if one used Lisp). It got so bad that I would
actually develop prototypes as part of the proposal writing process just
so that I could say, "Not only is this not hard, it has already been
done." (It actually got even worse than that, but putting the details on
the record would not be healthy for my career.)
I also encountered an astonishing prejudice against Lisp and towards C.
Between 1988 and 1991 I worked on the research program that led to the
Mars Pathfinder rover. We built three prototype rovers during that time,
and I either wrote the code or supervised the person who did on all of
them. All three of them were programmed not in Lisp, but in little
mini-languages whose compilers were written in Lisp. (The rovers
themselves only had 8 bit processors with a few hundred or a few thousand
bytes of memory so we couldn't run Lisp directly.)
But when it came time to write the code for Sojourner they wrote it in C.
As far as I know the possibility of using the work we had done on the
prototypes was never even considered. All I know is that I was never
approached about it.
A similar thing happened many years later on a project called Remote Agent
(RA), which was a flight experiment to demonstrate an autonomous control
system for a spacecraft.
(http://ic.arc.nasa.gov/ic/projects/remote-agent/) At the beginning of
the project we had a lot of prototype code written in Lisp, so it seemed
natural to me to just fly Lisp aborad the spacecraft. The resistance to
this idea was tremendous and unrelenting. Fortunately, we resisted
successfully. I say fortunately, because at one point an attempt was made
to port part of the code (the planner) to C++. Afer a year that effort
had to be abandoned. On the basis of that experience I think it's safe to
say that if we hadn't used Lisp the Remote Agent would not have happend.
Nonetheless, it was not an unconditional victory. RA was part of the
first New Millennium mission, which was the flagship for Dan Goldin's new
"better, faster, cheaper" initiative. As a result we were given a budget
and schedule that everyone knew up front was impossibly tight. When the
inevitable schedule and budget slips hit the fan, Lisp became the
scapegoat. The software integration engineer was asked at a very
prominent review board hearing (attended by over 100 people) what was the
most significant factor causing the schedule slips. His reply: Lisp. As
a result, RA was down-graded from the mainline flight software to a
two-day flight experiment.
That was pretty much the end of Lisp at JPL. On my next project I tried
again to sell it, but the political damage done by the Remote Agent
experience was insurmountable. Finally, out of frustration, I quit JPL
and went to work for Google.
I went to Google with my faith fully intact. Let me be more specific
about what I mean by that. I had the following mindset, cemented by
twenty years of experience: first, Lisp is great. It lets you be orders
of magnitude more productive than C, and it's much more reliable (no core
dumps!). Second, because Lisp is so great, the only reason a rational
person would choose not to use it is if they were ignorant. There
certainly were an awful lot of ignorant objections to Lisp at JPL. (BTW,
ignorant is not a pejorative term. If you think it is you are ignorant
and you need to go look the word up in a dictionary.) Third, I thought
that this ignorance could survive at JPL because it was not subject to
market forces.
There was always some niggling doubt in my mind about this last point.
Over the course of twenty years the following question had begun to bother
me more and more: if Lisp is such a massive productivity gain over C, why
doesn't it win in the market? At JPL suboptimal strategies can survive
because we're an FFRDC (federally funded research and development center)
and therefore somewhat insulated from market forces. But out there in the
real world there ought to be some people using Lisp to whomp the pants off
the C-using competition, and it just didn't seem to be happening. I came
up with the following theory: lots of people are using Lisp, but they
don't want the competition to know because they want the competition to
keep using C.
It was a plausible enough theory, except for two things. First, a secret
of this magnitude would be awfully hard to keep, and second, my own
experience in trying to hire Lisp programmers demonstrated to me that they
are very hard to find. I was reasonably well known in the Lisp
community. If there really were lots of people out there secretly using
Lisp and programmers were scarce I would have expected to find myself
being recruited, but I was not. At this point I was seriously considering
the possibility that there really was a thriving Lisp economy out there
somewhere, and that I was being excluded from it for some reason, like
maybe my reputation for being obnoxious. (But even that theory came
unraveled when you showed up, Erik.)
So I can't really go into many specifics about what happened at Google
because of confidentiality, but the upshot was this: I saw, pretty much
for the first time in my life, people being as productive and more in
other languages as I was in Lisp. What's more, once I got knocked off my
high horse (they had to knock me more than once -- if anyone from Google
is reading this, I'm sorry) and actually bothered to really study some of
these other languges I found *myself* suddenly becoming more productive in
other languages than I was in Lisp. For example, my language of choice
for doing Web development now is Python.
I also saw Peter Norvig come to Google and leave Lisp behind with no
apparent regrets. (Actually, Peter and I had talked about this while we
were both still at NASA, and he was already leaving Lisp behind, which I
found very distressing at the time.)
Finally, I read Paul Graham's recent writings. He's the only person I
know of who has actually gotten wealthy using Lisp. That doesn't make him
infallible, but I think it does make it prudent to pay attention to what
he has to say. At least when Paul says, "That's how I got to where I am,"
I don't have to wonder where that is.
That's the story in a very large nutshell. What happened when I lost my
faith was that I could no longer sustain it in the face of mounting
evidence to the contrary.
Let me just make two comments to those of you who have had the patience to
read this far: 1) thanks, and 2) my aim here is not to diss Lisp. My goal
is honestly constructive. I think that if Lisp does not evolve it will
die, and I don't want to see that happen. I still think Lisp is great. I
also think it can be, and should be, improved.
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@eglaptop.jpl.nasa.gov...
> In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
>
> So I can't really go into many specifics about what happened at Google
> because of confidentiality, but the upshot was this: I saw, pretty much
> for the first time in my life, people being as productive and more in
> other languages as I was in Lisp. What's more, once I got knocked off my
> high horse (they had to knock me more than once -- if anyone from Google
> is reading this, I'm sorry) and actually bothered to really study some of
> these other languges I found *myself* suddenly becoming more productive in
> other languages than I was in Lisp. For example, my language of choice
> for doing Web development now is Python.
>
> I also saw Peter Norvig come to Google and leave Lisp behind with no
> apparent regrets. (Actually, Peter and I had talked about this while we
> were both still at NASA, and he was already leaving Lisp behind, which I
> found very distressing at the time.)
>
> Finally, I read Paul Graham's recent writings. He's the only person I
> know of who has actually gotten wealthy using Lisp. That doesn't make him
> infallible, but I think it does make it prudent to pay attention to what
> he has to say. At least when Paul says, "That's how I got to where I am,"
> I don't have to wonder where that is.
I do not know all the details of what happened at Google. But I would like
to propose a few hypotheses.
Google was doing something that was already a solved problem. Web search
engines had already been done at Altavista and others. This problem was
already well understood. If Google had gotten people that had already
worked on those types of systems, they already had a understanding of the
structure of the system, in essence they understood the 'Pattern' of the
implementation. It is my experience that specific domain knowledge is a
huge leg up.
Your work at JPL were one of a kinds. Each had new things to understand and
things that were being done for the first time.
4GLs are more powerful (even than Lisp) in domain specific applications.
Did Google have any of those? Understanding the problem is 90% of the work.
You might have started to become more productive in Python because you were
catching on how to write the systems, interacting with others doing the same
thing, sharing your work with others and getting used to the language. Its
good to be adaptable, I am sure many here could also adapt if needed. You
also might have just become a better progammer when you were there. :)
It might very well be that other languages have caught up to Lisp in many
respects. That is a good thing.
Wade
In article <············@news3.cadvision.com>, "Wade Humeniuk"
<········@cadvision.com> wrote:
> Google was doing something that was already a solved problem. Web search
> engines had already been done at Altavista and others. This problem was
> already well understood. If Google had gotten people that had already
> worked on those types of systems, they already had a understanding of the
> structure of the system, in essence they understood the 'Pattern' of the
> implementation. It is my experience that specific domain knowledge is a
> huge leg up.
>
> Your work at JPL were one of a kinds. Each had new things to understand and
> things that were being done for the first time.
>
> 4GLs are more powerful (even than Lisp) in domain specific applications.
> Did Google have any of those? Understanding the problem is 90% of the work.
So at Google I didn't work on the search engine at all, but I would
nonetheless say with some authority that it's far from a "solved
problem". The things I did work on were in many ways one-of-a-kind
applications.
> You might have started to become more productive in Python because you were
> catching on how to write the systems, interacting with others doing the same
> thing, sharing your work with others and getting used to the language. Its
> good to be adaptable, I am sure many here could also adapt if needed. You
> also might have just become a better progammer when you were there. :)
Maybe, but here's some data that suggest otherwise. While at Google I
used Python, Java, C++, and even snuck a little Lisp in (I wrote a tiny
little revision control system in Lisp for my own use). I was working
with other people on the Java and C++ projects. On the Python project I
pretty much worked alone. My performance on the Java project was quite
poor, and my C++ work was a complete, unmitigated disaster. So I don't
think that I can attribute my successes entirely to simply being a bright
guy. ;-) I really think the language(s) have had something to do with
it.
E.
Erann Gat wrote:
> My performance on the Java project was quite
> poor, and my C++ work was a complete, unmitigated disaster.....I really think the language(s) have had something to do with
> it.
Right. We are controlling the programmer variable, so the language
variable is isolated and we learn:
C++ is a complete, unmitigated disaster
Java is quite poor
Lisp is out of this world (Mars, to be specific)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"We have a pond and a pool. The pond would be good for you."
- Ty to Carl, Caddy Shack
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Right. We are controlling the programmer variable, so the language
> variable is isolated and we learn:
>
> C++ is a complete, unmitigated disaster
In the hands of a mediocre programmer like myself. In the hands of a
master (and there were many at Google) the results can be astonishingly
good. But masters of any stripe are rare.
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@192.168.1.50...
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
> > Right. We are controlling the programmer variable, so the language
> > variable is isolated and we learn:
> >
> > C++ is a complete, unmitigated disaster
>
> In the hands of a mediocre programmer like myself. In the hands of a
> master (and there were many at Google) the results can be astonishingly
> good. But masters of any stripe are rare.
I'm stunned Erann. Since you considered yourself a better programmer at JPL
and now consider yourself a mediocre programmer, you must think the other
programmers at JPL are absolutely dismal. That reality hardly seems likely.
You have taken a big ego deflating blow and sound terribly burnt out. What
really is happening?
Wade
In article <············@news3.cadvision.com>, "Wade Humeniuk"
<········@cadvision.com> wrote:
> "Erann Gat" <···@jpl.nasa.gov> wrote in message
> ·························@192.168.1.50...
> > In article <·················@nyc.rr.com>, Kenny Tilton
> > <·······@nyc.rr.com> wrote:
> >
> > > Right. We are controlling the programmer variable, so the language
> > > variable is isolated and we learn:
> > >
> > > C++ is a complete, unmitigated disaster
> >
> > In the hands of a mediocre programmer like myself. In the hands of a
> > master (and there were many at Google) the results can be astonishingly
> > good. But masters of any stripe are rare.
>
> I'm stunned Erann. Since you considered yourself a better programmer at JPL
> and now consider yourself a mediocre programmer, you must think the other
> programmers at JPL are absolutely dismal. That reality hardly seems likely.
> You have taken a big ego deflating blow and sound terribly burnt out. What
> really is happening?
I didn't say I was a better programmer at JPL. I said I achieved better
results. Maybe that's because I was a better programmer, but I don't
think so. I think it's because I was using a good tool that allowed even
a mediocre programmer (like me) to get good results.
There are three reasons I think that I owe my programming successes to
Lisp and not to my programming abilities:
1. I got good results almost from the very beginning of my programming
career, back in college and even back to high school, without any formal
training whatsoever.
2. My performance was heavily language dependent. Using Lisp I performed
well, any other language I did pretty badly. At one point in college I
remember trying to write a Lisp interpreter in Pascal. I couldn't even
get the reader to work.
3. When I go back and look at some of the code I wrote some of it looks
pretty bad.
So, no, I don't think the other programmers at JPL are dismal. Quite the
contrary. Many of them are very good, and a few are masters. I sometimes
wonder what they could achieve if they didn't shackle themselves to the
C++ ball-and-chain (but when I do that I tend to get depressed, so I try
not to think about that too much).
As for taking a big ego-deflating blow, I'm not sure what you mean.
Admitting that I'm not a good programmer is not ego-deflating for me
because I'm not really a programmer. I'm a scientist who sometimes writes
code. As for being burned out, I was. That's why I quit JPL and went to
work for Google for a while.
E.
>>>>> "Erann" == Erann Gat <···@jpl.nasa.gov> writes:
Erann> So, no, I don't think the other programmers at JPL are dismal.
Erann> Quite the contrary. Many of them are very good, and a few are
Erann> masters. I sometimes wonder what they could achieve if they
Erann> didn't shackle themselves to the C++ ball-and-chain (but when I
Erann> do that I tend to get depressed, so I try not to think about
Erann> that too much).
I am a bit confused.
As I understand your argument, you went to Google and saw non-lisp
languages put to so wonderful use that it convinced you that CL is no
longer better than the competition. I also understand you encountered
C++, Java and Python and I assume you change of faith is based on
those said encounters.
So how should I then understand the above quote?
- C++ is a poor choice anytime, also at Google
- C++ success demands extraordinary skills, found at Google but not JPL
I think I have only seen you speak favouritely about python. Did you
see C++ and/or Java work at Google that make those languages seem
better (for your choice of "better") than CL? If so, what did they
have that Lisp is missing (I am hoping that you will be able to be
more specific than just saying "libraries").
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.se
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
In article <··············@chl.ted.dk.eu.ericsson.se>, Christian Lynbech
<·················@ted.ericsson.se> wrote:
> >>>>> "Erann" == Erann Gat <···@jpl.nasa.gov> writes:
>
> Erann> So, no, I don't think the other programmers at JPL are dismal.
> Erann> Quite the contrary. Many of them are very good, and a few are
> Erann> masters. I sometimes wonder what they could achieve if they
> Erann> didn't shackle themselves to the C++ ball-and-chain (but when I
> Erann> do that I tend to get depressed, so I try not to think about
> Erann> that too much).
>
> I am a bit confused.
>
> As I understand your argument,
First of all let me say that the only argument I'm making is that Lisp
needs to change. I'm not arguing about how or why, just that it does.
Erik's recent suggestion of a standardized virtual Lisp machine seems like
an excellent idea to me (as contrasted, say, with any changes to the
language. Erik, are you listening?)
> you went to Google and saw non-lisp
> languages put to so wonderful use that it convinced you that CL is no
> longer better than the competition. I also understand you encountered
> C++, Java and Python and I assume you change of faith is based on
> those said encounters.
>
> So how should I then understand the above quote?
>
> - C++ is a poor choice anytime, also at Google
I think (and this is just my opinion, I speak with absolutely no authority
here) that there might be some circumstances under which C++ is a good
choice. The circumstances at Google were such circumstances (lots of
wizards around, need for maximum performance). The circumstances at JPL
(at least in the area I work in, autonomous control software) it seems to
me to be a poor choice. This position is modified from my pre-Google
position which was that C++ is a poor choice, period, end of story.
> - C++ success demands extraordinary skills, found at Google but not JPL
>
I'd say more common at Google than at JPL. JPL is not in the software
business, it's in the space business. We've got some really bright
software people. We may even have as many bright software people as
Google does. But Google only has 200 people while JPL has 6000. A dozen
wizards goes a lot further at Google than JPL.
> I think I have only seen you speak favouritely about python. Did you
> see C++ and/or Java work at Google that make those languages seem
> better (for your choice of "better") than CL? If so, what did they
> have that Lisp is missing (I am hoping that you will be able to be
> more specific than just saying "libraries").
Sorry, but I can't. On a purely technical level as a language Lisp still
wins IMO. But the technical gap between Lisp and Python is small enough
that other factors start to become significant, like politics. If I want
to use Lisp I have to fight with my colleagues. When I use Python I
don't. When I use Python I get regular expressions and database
connectivity with zero effort -- it's already there. When I use Lisp I
use MCL, and it doesn't come with regexps or database connectivity, so I
have to put in some effort. At the very least I have to download a
library, install it, evaluate it. With Python I don't have to do any of
these things. I can just get to work.
Make no mistake, all else being equal I would still be using Lisp. But
all else is not equal, at least not for me. I wish it were otherwise.
E.
>>>>> "EG" == Erann Gat <···@jpl.nasa.gov> writes:
[...]
EG> Sorry, but I can't. On a purely technical level as a language
EG> Lisp still wins IMO. But the technical gap between Lisp and
EG> Python is small enough that other factors start to become
EG> significant, like politics.
This depends on what you do, I would think. I doubt Python can match
Common Lisp in performance even if expressiveness and such were close
enough as you claim. Given that the above is true for your purposes:
EG> If I want to use Lisp I have to
EG> fight with my colleagues. When I use Python I don't.
This is fine. No arguments. This is no different than some of us having
to edit stuff in MS Word because the client is too valuable to risk
offending by fussing about these things. If, say, you were paid to
work with Erik, the situation would be different.
EG> When I
EG> use Python I get regular expressions and database connectivity
EG> with zero effort -- it's already there. When I use Lisp I use
EG> MCL, and it doesn't come with regexps or database
EG> connectivity, so I have to put in some effort.
Is what you are saying true on the Mac for Python?
EG> At the very
EG> least I have to download a library, install it, evaluate it. [...]
This is no big deal if you are assured that once you do get it and get
it work it will perform adequately. I think the hassle is no big deal
if you are sure you need to do it once. What seems to bother people more
is that it might not be just getting one library getting it to work and
being happpy ever after but getting library A sinking time into getting
it to work, being failed by it, and going through the same thing with B.
Now, I can see this happening with random pieces of code off the net but
does it also happen with vendor supplied libraries?
BM
In article <··············@nkapi.internal>, Bulent Murtezaoglu
<··@acm.org> wrote:
> >>>>> "EG" == Erann Gat <···@jpl.nasa.gov> writes:
> [...]
> EG> Sorry, but I can't. On a purely technical level as a language
> EG> Lisp still wins IMO. But the technical gap between Lisp and
> EG> Python is small enough that other factors start to become
> EG> significant, like politics.
>
> This depends on what you do, I would think. I doubt Python can match
> Common Lisp in performance even if expressiveness and such were close
> enough as you claim. Given that the above is true for your purposes:
Yes, you are righ of course. I'm using Python for writing low-volume Web
applications. Nothing else. Actually, I don't really do a lot of
programming nowadays.
> EG> If I want to use Lisp I have to
> EG> fight with my colleagues. When I use Python I don't.
>
> This is fine. No arguments. This is no different than some of us having
> to edit stuff in MS Word because the client is too valuable to risk
> offending by fussing about these things. If, say, you were paid to
> work with Erik, the situation would be different.
Now there's a concept. How about it, Erik? Will you hire me?
> EG> When I
> EG> use Python I get regular expressions and database connectivity
> EG> with zero effort -- it's already there. When I use Lisp I use
> EG> MCL, and it doesn't come with regexps or database
> EG> connectivity, so I have to put in some effort.
>
> Is what you are saying true on the Mac for Python?
Well, I do my server programming on Linux so I don't really know, but
here's a data point:
Python 2.1.1 (#97, Aug 2 2001, 21:53:31) [CW PPC GUSI2 THREADS] on mac
Type "copyright", "credits" or "license" for more information.
>>> import re
>>> import cgi
>>> import MySQL
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: No module named MySQL
>>> import MySQLdb
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: No module named MySQLdb
>>>
> EG> At the very
> EG> least I have to download a library, install it, evaluate it. [...]
>
> This is no big deal if you are assured that once you do get it and get
> it work it will perform adequately. I think the hassle is no big deal
> if you are sure you need to do it once. What seems to bother people more
> is that it might not be just getting one library getting it to work and
> being happpy ever after but getting library A sinking time into getting
> it to work, being failed by it, and going through the same thing with B.
> Now, I can see this happening with random pieces of code off the net but
> does it also happen with vendor supplied libraries?
The only experience I've had with vendor libraries is WOOD, which is
explicitly labelled as unsupported. It seemed to work fine in light
testing, but failed under load after the application was deployed, which
turned into a really serious problem. The poor guy who inherited the code
from me and had to clean up the resulting mess spent months on it.
E.
>>>>> "EG" == Erann Gat <···@jpl.nasa.gov> writes:
[...]
EG> Yes, you are righ of course. I'm using Python for writing
EG> low-volume Web applications. Nothing else. Actually, I don't
EG> really do a lot of programming nowadays.
Hmmm. By that token I could prolly claim I lost my faith in CL in
favor of Tcl/Tk! At the moment I use Tcl/Tk to quickly write GUI
stuff for debugging specs for networked services by clients (eg they
get to sit on their windows machines and point and shoot and send
stuff back to me by cutting and pasting a GUI log into outlook).
Works beautifully out of the box for that stuff. You can even develop
on Linux and turn it into an .exe on Windows with next to no effort.
I wouldn't dream of doing anything interesting (that I'd need to
explore first) with Tcl though. Nor would I say I'd lost my faith in
lisp. It it just that for that particular application, more
convenience can be had at no cost with Tcl/Tk (CL+CLIM is $1800 with
LW for this functionality with no real second source, and $900 more
per seat if I just push programs off to someone for beutification.
Not worth it for these kinds of apps).
Why am I telling you all this? Because had you said right from the
outset that you were writing low volume web applications and found
python to be more convenient, the ensuing thread would be shorter.
I suspect people would have pinted you to the sql connectivity
packages (maisql and uncommonsql I suspect) and things like
allegroserve, aranedia (runs cliki), or cl-httpd. Then you would
have said "politically infeasible" and that would have been that.
EG> If I want to use Lisp I have to fight with my colleagues.
EG> When I use Python I don't.
>> This is fine. No arguments. This is no different than some
>> of us having to edit stuff in MS Word because the client is too
>> valuable to risk offending by fussing about these things. If,
>> say, you were paid to work with Erik, the situation would be
>> different.
EG> Now there's a concept. How about it, Erik? Will you hire me?
If he does, I want food and coffee from either or both of you.
[...]
>> Is what you are saying true on the Mac for Python?
EG> Well, I do my server programming on Linux so I don't really
EG> know, but here's a data point:
EG> Python 2.1.1 (#97, Aug 2 2001, 21:53:31) [CW PPC GUSI2
EG> THREADS] on mac Type "copyright", "credits" or "license" for
EG> more information.
>>>> import re import cgi import MySQL
EG> Traceback (most recent call last): File "<stdin>", line 1, in
EG> ? ImportError: No module named MySQL
>>>> import MySQLdb
EG> Traceback (most recent call last): File "<stdin>", line 1, in
EG> ? ImportError: No module named MySQLdb
>>>>
Hmm. So it seems using that particular Mac is the problem.
Under Debian+CMUCL some if not all of these would boild fown
to (:require :foo) (after apt-get had been done from cCLan. See
http://ww.telent.net/cliki/Debian
which is a web service running under Linux/CMUCL!
cheers,
BM
In article <··············@nkapi.internal>, Bulent Murtezaoglu
<··@acm.org> wrote:
> Why am I telling you all this? Because had you said right from the
> outset that you were writing low volume web applications and found
> python to be more convenient, the ensuing thread would be shorter.
I believe I did say that at the outset:
http://groups.google.com/groups?selm=gat-1902021257120001%40eglaptop.jpl.nasa.gov
> For example, my language of choice for doing Web development now is Python.
^^^^^^^^^^^^^^^^^^^^^^^^^
Perhaps if people read what I wrote a lot of these threads would be shorter.
E.
>>>>> "EG" == Erann Gat <···@jpl.nasa.gov> writes:
[...]
>> Why am I telling you all this? Because had you said right from
>> the outset that you were writing low volume web applications
>> and found python to be more convenient, the ensuing thread
>> would be shorter.
EG> I believe I did say that at the outset:
EG> http://groups.google.com/groups?selm=gat-1902021257120001%40eglaptop.jpl.nasa.gov
[...]
When I first read the abov I went "oh no this is my second mistake in
two days, now Nils won't want to believe anything I say." But then I
looked at it, and it turns out I had read it. I recall wanting to get
coffee before I read it even -- because I like reading good stories
with coffee. Yes indeed you did say what you say you said where you
say you have said it. As far as that sentence goes. But I think Nils
will still believe me.
cheers,
BM
>>>>> "Erann" == Erann Gat <···@jpl.nasa.gov> writes:
Erann> When I use Lisp I use MCL, and it doesn't come with regexps or
Erann> database connectivity
But isn't that being a tiny bit unfair to blaim Lisp in general for
the missing features of a single implementation?
ACL comes with regexps and they have (although as a separate product)
an OO database extension (AllegroStore I think it is called). I know it
isn't in the standard and AllegroStore does not (I think) plug and play
with the relational database of your choice, but stil it is there.
Erann> At the very least I have to download a library, install it,
Erann> evaluate it.
But then again, libraries do exist (for instance MaiSQL and
unCommonSQL). It obviously would be easier if the vendor was supplying
and maintaining such libraries, or even was in a standard, but they
are there. Since you cannot be more specific about the libraries that
made such a difference at Google, I guess that these libraries aren't
in the public domain, ie. they too have needed some exra effort at
some point.
I am honestly trying to understand what is missing for Lisp. If it is
libraries of usefull functionality, it is at an order of magnitude
more easy to attack the problem. Designing *and* implementing *and*
attracting a user community with a new language is much harder.
I am also personally quite optimistic, even though I do not really
think that Lisp will ever achieve world dominance. Even with ist small
marketshare we still have at least 4 commercial vendors making a
living out of lisp.
The library situation is also steadily being improved. If you search
for lisp on sourceforge, you get 4 pages of links (not all CL of
course, but still). You have projects such as CLOCC and cCLan that are
providing pacage and infrastructure that enable even more to deliver
functionality without it requiring a phD in configuration science just
to try something out.
In fact, to me, Lisp has not looked so alive for a long time as it
does today.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
In article <··············@baguette.webspeed.dk>, Christian Lynbech
<·······@get2net.dk> wrote:
> >>>>> "Erann" == Erann Gat <···@jpl.nasa.gov> writes:
>
> Erann> When I use Lisp I use MCL, and it doesn't come with regexps or
> Erann> database connectivity
>
> But isn't that being a tiny bit unfair to blaim Lisp in general for
> the missing features of a single implementation?
I'm not blaming anyone (f)or anything, I'm just describing my own thought
process.
That said, it is often hard to distinguish between a feature of the
language and a feature of the implementation. What ultimately counts is
whether the implementations that you use have the features that you need.
When I program in Lisp I use MCL because 1) I like Macs, 2) I've used MCL
for fifteeen years and I like it (a lot) and 3) it's very, very
inexpensive.
When I program in Python or C++ I use Linux because my Linux box comes
with them built in, and because that's the environment where I learned to
use them. Also, for a server I prefer Linux to MacOS because Linux boxes
are cheaper and Linux is more stable.
> ACL comes with regexps and they have (although as a separate product)
> an OO database extension (AllegroStore I think it is called). I know it
> isn't in the standard and AllegroStore does not (I think) plug and play
> with the relational database of your choice, but stil it is there.
True, but ACL doesn't run on Macs. So for me to use ACL I have the
following choices:
1. Run ACL on my Linux box. But my Mac is a laptop and my linux box is a
tower, so I give up the ability to program when I'm on the road.
2. Buy a PC laptop and run ACL on that. $$$, hassle. Blech.
> Erann> At the very least I have to download a library, install it,
> Erann> evaluate it.
>
> But then again, libraries do exist (for instance MaiSQL and
> unCommonSQL). It obviously would be easier if the vendor was supplying
> and maintaining such libraries, or even was in a standard, but they
> are there. Since you cannot be more specific about the libraries that
> made such a difference at Google, I guess that these libraries aren't
> in the public domain, ie. they too have needed some exra effort at
> some point.
Hm, I thought I was very specific: database connectivity and regexps.
(The CGI module is also very handy.) I tried several open-source database
packages, but none of them run on MCL. I also, as I recounted earlier,
tried the MCL-supplied database, to very unhappy results. So when I need
to get something done I have the following choices: try to fix one of
these libraries, or write my own, or use Python where they already work
(in my environment). I spend time doing all three, and find at the end of
the day I've gotten more done in Python.
> I am honestly trying to understand what is missing for Lisp. If it is
> libraries of usefull functionality, it is at an order of magnitude
> more easy to attack the problem. Designing *and* implementing *and*
> attracting a user community with a new language is much harder.
True, but unfortunately one of the things I've learned is that it's more
complicated than that. The fact of the matter is that (a large part of)
the world has already made up its mind about Lisp and no amount of reality
is going to change that. A "new" language (and it doesn't actually have
to *be* new, it just has to *seem* new) has a chance to get the attention
of people that Lisp has no hope of reaching. Opinions differ over whether
or not this is a good thing. If you find yourself in a position where
this is not an issue for you then I envy you. It is an issue for me.
> I am also personally quite optimistic, even though I do not really
> think that Lisp will ever achieve world dominance. Even with ist small
> marketshare we still have at least 4 commercial vendors making a
> living out of lisp.
While there are four commercial Lisp vendors, the truth is that not all of
them are making a living.
> The library situation is also steadily being improved. If you search
> for lisp on sourceforge, you get 4 pages of links (not all CL of
> course, but still). You have projects such as CLOCC and cCLan that are
> providing pacage and infrastructure that enable even more to deliver
> functionality without it requiring a phD in configuration science just
> to try something out.
>
> In fact, to me, Lisp has not looked so alive for a long time as it
> does today.
My intention in writing "How I lost my faith" was not to dissuade anyone
from using Lisp. If it works for you, great, use it! But it doesn't work
for me any more, and if you look at the world it apparently doesn't work
for an awful lot of people. You can take the stance (as some here do)
that Lisp is for the select few and not for the common rabble. But I once
counted myself among the select few, and I found I had much to learn from
the common rabble. I thought the community would benefit if I tried to
bring some of those lessons back here.
E.
From: Christian Nyb�
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <871yfchz1l.fsf@nybo.no>
···@jpl.nasa.gov (Erann Gat) writes:
> True, but ACL doesn't run on Macs.
<URL: http://www.franz.com/products/allegrocl/> lists Mac OS X among its
supported platforms.
--
chr
···@jpl.nasa.gov (Erann Gat) writes:
> > ACL comes with regexps and they have (although as a separate product)
> > an OO database extension (AllegroStore I think it is called). I know it
> > isn't in the standard and AllegroStore does not (I think) plug and play
> > with the relational database of your choice, but stil it is there.
>
> True, but ACL doesn't run on Macs. So for me to use ACL I have the
> following choices:
As far as I can tell, ACL is available for Mac OS X, which runs on
Macs (G3 + G4 PowerPC boxes, and with some hacks on (some) earlier
PowerPC Macs, too).
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
<····@acm.org> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > > ACL comes with regexps and they have (although as a separate product)
> > > an OO database extension (AllegroStore I think it is called). I know it
> > > isn't in the standard and AllegroStore does not (I think) plug and play
> > > with the relational database of your choice, but stil it is there.
> >
> > True, but ACL doesn't run on Macs. So for me to use ACL I have the
> > following choices:
>
> As far as I can tell, ACL is available for Mac OS X, which runs on
> Macs (G3 + G4 PowerPC boxes, and with some hacks on (some) earlier
> PowerPC Macs, too).
>
> Regs, Pierre.
Hm, that's (pleasant) news to me. This seems to be a well kept secret.
I'm on Franz's mailing list, but I saw no announcement. Nor did I see it
on my periodic visits to the "What's new" section of the Franz Web page.
Thanks to everyone who pointed this out. (BTW, Rainer Joswig, my email to
you bounced.)
E.
>>>>> "Erann" == Erann Gat <···@jpl.nasa.gov> writes:
Erann> In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
Erann> <····@acm.org> wrote:
>> ···@jpl.nasa.gov (Erann Gat) writes:
>>
>> > > ACL comes with regexps and they have (although as a separate product)
>> > > an OO database extension (AllegroStore I think it is called). I know it
>> > > isn't in the standard and AllegroStore does not (I think) plug and play
>> > > with the relational database of your choice, but stil it is there.
>> >
>> > True, but ACL doesn't run on Macs. So for me to use ACL I have the
>> > following choices:
>>
>> As far as I can tell, ACL is available for Mac OS X, which runs on
>> Macs (G3 + G4 PowerPC boxes, and with some hacks on (some) earlier
>> PowerPC Macs, too).
>>
>> Regs, Pierre.
Erann> Hm, that's (pleasant) news to me. This seems to be a well kept secret.
I believe it is new with ACL 6.1.
ACL also supports LinuxPPC, and this is actually what we use at work
(it isn't very hard to convert a Mac to a linux box). You will loose
the Mac GUI though, so the choice probably boils down to what part of
the Mac you like the most.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
···@jpl.nasa.gov (Erann Gat) writes:
[...]
> When I program in Lisp I use MCL because 1) I like Macs, 2) I've used MCL
> for fifteeen years and I like it (a lot) and 3) it's very, very
> inexpensive.
>
> When I program in Python or C++ I use Linux because my Linux box comes
> with them built in, and because that's the environment where I learned to
> use them. Also, for a server I prefer Linux to MacOS because Linux boxes
> are cheaper and Linux is more stable.
>
> > ACL comes with regexps and they have (although as a separate product)
> > an OO database extension (AllegroStore I think it is called). I know it
> > isn't in the standard and AllegroStore does not (I think) plug and play
> > with the relational database of your choice, but stil it is there.
>
> True, but ACL doesn't run on Macs. So for me to use ACL I have the
> following choices:
>
> 1. Run ACL on my Linux box. But my Mac is a laptop and my linux box is a
> tower, so I give up the ability to program when I'm on the road.
>
> 2. Buy a PC laptop and run ACL on that. $$$, hassle. Blech.
I'm probably missing something, but you appear to prefer changing
machine + language (Mac -> PC, CL -> Python) to changing just machine.
[...]
> Hm, I thought I was very specific: database connectivity and regexps.
> (The CGI module is also very handy.) I tried several open-source database
> packages, but none of them run on MCL. I also, as I recounted earlier,
Paul Meurer's sql-odbc works with MCL (at least according to the
release notes).
Andras
···@jpl.nasa.gov (Erann Gat) writes:
> When I program in Lisp I use MCL because 1) I like Macs, 2) I've used MCL
> for fifteeen years and I like it (a lot) and 3) it's very, very
> inexpensive.
>
> When I program in Python or C++ I use Linux because my Linux box comes
> with them built in, and because that's the environment where I learned to
> use them. Also, for a server I prefer Linux to MacOS because Linux boxes
> are cheaper and Linux is more stable.
With Mac OS X you get both a bsd-flavor *nix and MCL on the same box.
If you use "fink", you can even use apt-get to fetch your tools :-)
MCL is still Classic-mode-only, but while I wait for the OS X native
version, v. 4.3.1 is a great interim solution. In addition, OpenMCL now
also works with OS X.
--
(espen)
[Note: I have moved the stuff I am responding to around a bit]
>>>>> "Erann" == Erann Gat <···@jpl.nasa.gov> writes:
Erann> While there are four commercial Lisp vendors, the truth is that
Erann> not all of them are making a living.
Out of curiosity: I was thinking of Franz, Xanalys, Corman and
Digitool. Who isn't making a living?
Erann> I thought the community would benefit if I tried to bring some
Erann> of those lessons back here.
I for one thinks of it as very beneficial. I am also quite fond of the
insights that keeps falling out of such philosophical discussions
(unproductive as it may be).
Erann> A "new" language (and it doesn't actually have to *be* new, it
Erann> just has to *seem* new) has a chance to get the attention of
Erann> people that Lisp has no hope of reaching.
This is one of the points where we disagree. I do not believe that
lisp as such has the potential of reaching new audiences on a large
scale. It is too different, too odd, too far from the main stream.
The syntax alone, with all the parentheses, will drive away the
masses.
In fact, I have gotten the thought that the schism boils down
to an existencial fight between the Ancient Languages, in our case
between Lisp and Fortran. Fortran became the ancestor of a line of
"algebraic" languages through Algol, C and now Java (I know, I am
stretching the concepts beyond any reasonable limits :-) and for some
strange and incredible reason, this line also has come to define the
mainstream. Lisp, being outside of the mainstream, is not likely to
gain large strongholds outside of specific niches.
This could change with the advent of some killer application that is
able to make lisp sexy to new generations of programmers, just as Java
owes much of its success to the appeal it gained on the current
generations of programmers through the rise of WWW.
Unfortunately, such a killer application is in general impossible to
predict, plan or construct. We can try and try and try, but when it
comes, it will come almost out of the blue due to a completely
inplausible coincindence of events and circumstances.
To me, this is not a big problem. I can live with the fact that Lisp
is not a dominant language, especially as long as I can keep
programing in it. I know that a corollary to the situation is that I
am in great danger of not being able to keep programming in Lisp as I
do now, but I will deal with that when it happens.
------------------------+-----------------------------------------------------
Christian Lynbech |
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
> > Right. We are controlling the programmer variable, so the language
> > variable is isolated and we learn:
> >
> > C++ is a complete, unmitigated disaster
>
> In the hands of a mediocre programmer like myself.
In the hands of someone much short of a C++ wizard, C++ often turns
into an unmitigated disaster. I'm pretty good at controlling the
disasters I produce in C++, but I've been known to hack the compiler
to achieve this. C++ is a very very powerful gun, but one which takes
a lot of skill to not shoot your self with, at least a little.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
> > Right. We are controlling the programmer variable, so the language
> > variable is isolated and we learn:
> >
> > C++ is a complete, unmitigated disaster
>
> In the hands of a mediocre programmer like myself. In the hands of a
> master (and there were many at Google) the results can be astonishingly
> good. But masters of any stripe are rare.
The problem is: I spent the last months learning Common Lisp and I
really got used to some kind of functional programming. Yesterday I
was confronted with some old code of mine (PASCAL, my favourite
language before Lisp). I realized that I would never want to write
code like this again. It was quite obviuos how I worked around some
PASCAL limitations. (e.g. repeat .. until should have a return value
*g*).
The last time whenever I started a new program in anything other than
Lisp I gave up some minutes later and started coding in Lisp.
It is not the question whether you are a master at a specific
language, but whatever language you feel comfortable writing. I
consider my PASCAL and x86 Assembler skills to be much better than my
Lisp skills. But real projects _I_ would (now) start with
Lisp. (Perhaps rewrite it later)
Just my two cents... :)
Regards,
Julian
--
Um meinen oeffentlichen Schluessel zu erhalten:
To get my public key:
http://math-www.uni-paderborn.de/pgp/
"Wade Humeniuk" <········@cadvision.com> wrote in message
·················@news3.cadvision.com...
>
> I do not know all the details of what happened at Google. But I would
like
> to propose a few hypotheses.
>
> Google was doing something that was already a solved problem. Web search
> engines had already been done at Altavista and others. This problem was
> already well understood. If Google had gotten people that had already
> worked on those types of systems, they already had a understanding of the
> structure of the system, in essence they understood the 'Pattern' of the
> implementation. It is my experience that specific domain knowledge is a
> huge leg up.
>
I think this is false on the face of it. First of all, web search wasn't
(and still isn't) a "solved problem." It's neither "solved" nor just one
problem. Second, the basic Google insight of page ranking was, in fact, a
new and wonderful idea.
[other hypotheses snipped]
Will Fitzgerald
"Will Fitzgerald" <···············@worldnet.att.net.no.spam.please> wrote in
message ···························@bgtnsc04-news.ops.worldnet.att.net...
>
> > Google was doing something that was already a solved problem. Web
search
> > engines had already been done at Altavista and others. This problem was
> > already well understood. If Google had gotten people that had already
> > worked on those types of systems, they already had a understanding of
the
> > structure of the system, in essence they understood the 'Pattern' of the
> > implementation. It is my experience that specific domain knowledge is a
> > huge leg up.
> >
>
> I think this is false on the face of it. First of all, web search wasn't
> (and still isn't) a "solved problem." It's neither "solved" nor just one
> problem. Second, the basic Google insight of page ranking was, in fact, a
> new and wonderful idea.
Perhaps you could specify which part of it is not "solved"? You might be
using the term solved akin to the mathematical concept of "proof" or as in
the case of the "provably best solution". Web search exists, it is working
and it does not matter whether it is optimally done. Wonderful ideas are
not specifically "Google's page ranking" but the concept and idea of
"Ranking" anything. Who thought that one up? Wonderful ideas are concepts
like Language, the Wheel, Mathematics, ... It is not "Google page
ranking".
Bringing it back to Lisp. I wonder if there are some people who think that
we have to "solve" the solution to finding a better Lisp. There have been
no computer language innovations for a LONG time, Common Lisp pretty well
has them all. Improving Lisp by creating an abstraction of Key/Value
storage (like has been discussed) will not "solve" Lisp (whatever people
think the problem is).
Wade
Wade Humeniuk wrote:
> Bringing it back to Lisp. I wonder if there are some people who think that
> we have to "solve" the solution to finding a better Lisp. There have been
> no computer language innovations for a LONG time, Common Lisp pretty well
> has them all.
This is nonsense.
David Feuer
OK, I'll bite. What programming language construct/technique/style can I
use today that I did not have 10 or 20 years ago?
Wade
"David Feuer" <···········@brown.edu> wrote in message
······················@brown.edu...
> Wade Humeniuk wrote:
>
> > Bringing it back to Lisp. I wonder if there are some people who think
that
> > we have to "solve" the solution to finding a better Lisp. There have
been
> > no computer language innovations for a LONG time, Common Lisp pretty
well
> > has them all.
>
> This is nonsense.
>
> David Feuer
>
Wade Humeniuk wrote:
> OK, I'll bite. What programming language construct/technique/style can I
> use today that I did not have 10 or 20 years ago?
Monadic programming (came up around 1990, I think, but perhaps a bit
earlier).
http://www.research.avayalabs.com/user/wadler/topics/monads.html
Higher-ranked polymorphism and existential types in decidable type systems.
Don't know when invented, but I don't think they've been used much until
relatively recently.
See for example http://www.cs.columbia.edu/~cdo/papers.html#icfp99
and http://haskell.cs.yale.edu/ghc/docs/latest/set/ghc-language-features.html
I don't know how long Generic Programming has been around, but it does not
seem to
be particularly long.
Arrows-based programming. 2000. Associated Functional Reactive Programming:
not sure when, but probably not all that long.
http://www.soi.city.ac.uk/~ross/arrows/index.html
http://www.haskell.org/frp
Type classes. Created for Haskell. Extended by Gopher to type constructor
classes.
Merged back to Haskell. Extended by GHC to multi-parameter type classes.
(these provide wonderful abstraction cababilities).
Aspect-Oriented Programming. May it die very young.
Of course, these are just a very few examples, from my limited sphere of
knowledge.
David Feuer
In article <·················@brown.edu>, David Feuer wrote:
> Wade Humeniuk wrote:
>
>> OK, I'll bite. What programming language construct/technique/style can I
>> use today that I did not have 10 or 20 years ago?
[snipped examples]
> Of course, these are just a very few examples, from my limited sphere of
> knowledge.
I was aware of only some among that collection; however the ones I knew
aren't things I would like Lisp to adopt, even when they are
very interesting from a mathematical point of view. If I want Haskell,
I know where to find it. Unfortunately I already had found it, and
the time I spent with it is probably totally wasted.
Is there anything in that list you would like to see in Lisp?
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche wrote:
> I was aware of only some among that collection; however the ones I knew
> aren't things I would like Lisp to adopt, even when they are
> very interesting from a mathematical point of view. If I want Haskell,
> I know where to find it. Unfortunately I already had found it, and
> the time I spent with it is probably totally wasted.
>
> Is there anything in that list you would like to see in Lisp?
That wasn't the question. The question was whether they were new, not whether
they should be in Lisp (monads and arrows can be useful in Lisp just as they
are in Haskell (for structuring libraries), though Lisp would probably never
want to
adopt monadic I/O). I do not claim to know enough to say what should be
changed
about Common Lisp. Why do you consider your time with Haskell wasted?
David Feuer
In article <·················@brown.edu>, David Feuer wrote:
> Nils Goesche wrote:
>
>> Is there anything in that list you would like to see in Lisp?
>
> That wasn't the question. The question was whether they were new,
> not whether they should be in Lisp (monads and arrows can be useful
> in Lisp just as they are in Haskell (for structuring libraries),
> though Lisp would probably never want to adopt monadic I/O).
Hopefully not :-)
> Why do you consider your time with Haskell wasted?
From a practical point of view. I saw very competent people arguing
that things like Haskell, OCaml or SML are the way to go. So I went
there to find out. I learned many new and interesting things, so,
maybe the time wasn't totally wasted. But it also cost me a lot
of time which I could have spent with Lisp instead, if I had known
beforehand that I would conclude that those languages are in fact
/not/ as great as many CS people believe. A strong indication should
have been that those very same people, although very knowledgable
otherwise, sometimes make totally wrong and silly claims about Lisp,
but for some strange reason I didn't think about that much at the time.
That's why I am still having a little grudge against those languages :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche wrote:
> From a practical point of view. I saw very competent people arguing
> that things like Haskell, OCaml or SML are the way to go. So I went
> there to find out. I learned many new and interesting things, so,
> maybe the time wasn't totally wasted. But it also cost me a lot
> of time which I could have spent with Lisp instead, if I had known
> beforehand that I would conclude that those languages are in fact
> /not/ as great as many CS people believe. A strong indication should
> have been that those very same people, although very knowledgable
> otherwise, sometimes make totally wrong and silly claims about Lisp,
> but for some strange reason I didn't think about that much at the time.
> That's why I am still having a little grudge against those languages :-)
I think that's a bad way to judge a language. I doubt very much that
there's
any one "way to go".
Lisp: Do it with macros
ML: Do it with modules
Haskell: Do it with types/type classes
Fortunately, these languages are not rigidly locked in to their
specialties:
you can do OO with ML and Lisp, generic (and even stateful) programming
with Haskell, etc. It's all about personal style and individual
application.
David Feuer
David Feuer wrote:
> Fortunately, these languages are not rigidly locked in to their
> specialties:
> you can do OO with ML and Lisp, generic (and even stateful) programming
> with Haskell, etc. It's all about personal style and individual
> application.
This message and your last one implies that generic programming is a rather
new technique and not available in Lisp. AFAIU Lisp supported generic
programming from the very beginning on.
Did you mean something different?
ciao,
Jochen
--
http://www.dataheaven.de
In article <·················@brown.edu>, David Feuer wrote:
>I think that's a bad way to judge a language. I doubt very much that
>there's
>any one "way to go".
>
>Lisp: Do it with macros
>ML: Do it with modules
>Haskell: Do it with types/type classes
Lisp: do it an ANSI standard language, using a quality, mature language
implementation chosen from among several capable proprietary as well as
free alternatives.
>>>>> "David" == David Feuer <···········@brown.edu> writes:
David> Aspect-Oriented Programming. May it die very young.
I read the ACM Communications special issue on Aspect Oriented
Programming and saw a bunch of things reinvented that Lisp has been
doing for a long time.
See
http://groups.google.com/groups?hl=en&frame=right&th=b739290c5074d88b&seekm=871yix4h72.fsf%40baguette.webspeed.dk#link2
for more information.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.se
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
On Fri, 22 Feb 2002 12:58:55 +0100, Christian Lynbech
<·················@ted.ericsson.se> wrote:
>
>I read the ACM Communications special issue on Aspect Oriented
>Programming and saw a bunch of things reinvented that Lisp has been
>doing for a long time.
Yes and given that Gregor Kiczales was the principle "architect" ( not
meant in the software development sense ) and invented those things
in Lisp, it indicates that he does not think Lisp to grow much.
One of the "design" principles he has mentioned as guiding AspectJ is
that it be a popular system. In fact that was reiterated a few weeks
ago in a presentation a couple of members of the AspectJ Team gave.
When asked if AOP ala AspectJ was going to be the technique that
survived ( as opposed to say composition filters, intentional
programming etc. ), their reply was that AspectJ had the strongest
user community and was the most viable system ( come to think of
it people could have had a whole lot more-- via OpenC++ and OpenJava,
but they never took off ).
This is all kind of telling considering the first ( recorded ) AOP
project was done in Lisp ( and could handle pointcuts that AspectJ
still can't handle ie pointcuts in data flows ).
* Thaddeus L Olczyk
| Yes and given that Gregor Kiczales was the principle "architect" ( not
| meant in the software development sense ) and invented those things
| in Lisp, it indicates that he does not think Lisp to grow much.
This does not follow. All we can conclude from his choice of vehicle for
his ideas is that he found it the locally optimal choice at the time.
There is no reason to maximize any crises, here.
Common Lisp is _not_ "popular". This fact is never going to change.
What we want to do with Common Lisp is not going to be stuff that can be
done with a random selection of people off the streat.
However, it _is_ getting increasingly harder to start using Common Lisp
in a project -- because the path of least resistance goes through a more
specialized tool for the kinds of tasks people are now generally starting
new projects. Optimizing for popularity is one way to avoid Common Lisp.
Optimizing for extensibility, building systems that can themselves be
used to build applications, _without_ the annoying Open Source thing, is
Common Lisp's fort�. The ability to think "system" is not very common
with today's crop of programmers who are mostly building inside somebody
else's systems (be they Windows or something like KDE or GNOME, or the
whole Java system), and Common Lisp programmers have someone gotten into
the mindset that they must fit into other systems, and this is where it
is least likely to win in the short term.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Please excuse my ignorance. I'm a total Lisp newbie and
consequently normally treat CLL as a read-only forum. I am hopeful
that the more experienced people here can help me educate myself. I
have what seems likely to be considered the disadvantage of having
been trained to program in the New Jersey style. As a possible
further handicap, I have also been a Unix systems administrator for
the last 11+ years. I have been thoroughly brain-washed into the
"build small tools" mentality. :-(
Let me add, though, that I *like* Lisp - at least, I like what I've
learned about it so far. I prefer to think about programming problems
more abstractly than it is convenient to do in C/Perl, and Lisp seems
to make this easier. I have been attempting to take the advice
offered here many times and empty my mind of the ideas I had about
"Lisp" learned from Scheme-based classroom instruction.
That being said, Erik's comment really struck a chord with me.
Erik Naggum <····@naggum.net> writes:
> Optimizing for extensibility, building systems that can themselves
> be used to build applications, _without_ the annoying Open Source
> thing, is Common Lisp's fort�. The ability to think "system" is not
> very common with today's crop of programmers who are mostly building
> inside somebody else's systems (be they Windows or something like
> KDE or GNOME, or the whole Java system)
I have read that Lisp is good for building systems. However, since
all of my programming training is *exactly* of the sort that Erik
describes, I have a hard time understanding what type of "system" Lisp
is good for building.
Here are some things that I think of when I hear "system":
* Computer Operating System
* Air Traffic Control System
* Civilian Emergency Response System [aka 911]
* Embedded Control Systems
Where can I find out more details about what types of "systems" Lisp
is good for building? I have read Erann Gat's post about what he used
Lisp for at JPL, but I am desperately seeking pointers to more info.
Until I can figure out what kind of systems Lisp is good for, I
intend to try writing the only kind of software I really am suited to
write: small tools.
-jon
--
------------------
Jon Allen Boone
········@delamancha.org
* Jon Allen Boone <········@delamancha.org>
| I have read that Lisp is good for building systems. However, since all
| of my programming training is *exactly* of the sort that Erik describes,
| I have a hard time understanding what type of "system" Lisp is good for
| building.
Well, I think using Frederick P. Brooks' terminology is the simplest way
to answer this. He ditinguished between a product (1), a programming
product (3), a programming system (3), and a programming systems product
(9), with his estimated factor of increased cost in parentheses. For a
particular product, you can probably do one version cheaper in some other
language than Lisp, but add generalization and adaptability to future
needs, and Lisp wins. Add testing costs, and Lisp wins. Add maintenance
costs, and Lisp wins. Add systems integration, and Lisp wins. I also
want to add correctness and cost of failures, because that is where it
really takes resources to achive excellent results in most other
languages. Effectively, the Common Lisp environments are precisely the
kind of programming systems product that Brooks talks about, and they
cost at least two orders of magnitude less to develop than similar
systems for C++. Borland nearly croaked under the financial burden of
its C++ environment, Lotus died, and similar stories abound. A larger
proportion of fairly small companies have over time been able to build
and survive building Common Lisp environments than other languages have
supported. (Those that have died, such as Lotus, died not because of
their Lisp operation, but because it was so successful that it could be
milked to keep loss-making operations afloat too long. Xanalys was the
result of Harlequin's bankruptcy reorganization, but that was not due to
losses in its Common Lisp business, which has thrived afterwards.)
Of course, the cost of building Common Lisp environments is not a good
metric of how useful the language is to build systems by itself, but the
fact that you can do this with relatively little effort (even compared to
such stunts as Perl, which I venture has cost much more development time
than CMUCL, CLISP, or even Allegro CL), means that building something new
on top of it should be equally productive, and a system for large CAD
applications has been built with Allegro CL that is effectively a
programmable CAD system. There are number of such large applications
that are not merely applicatiosn, but domain-specific programming systems
products. Of course, they cost hundreds of millions of dollars to build,
and take whole herds of programmers to complete, but the success of these
large things and their costs really show that Common Lisp has an edge.
Also, the failure rate of such projects in Common Lisp is much lower
than, e.g., C++.
| Until I can figure out what kind of systems Lisp is good for, I intend to
| try writing the only kind of software I really am suited to write: small
| tools.
There is nothing wrong in that. Quite the contrary, but you do not
generally get into maintenance issues, documentation and tutorials,
systems integration (except to integrate your tools in some other system,
which is quite the reverse problem) in small tools. Try to work on Emacs
for a while, but do not get too influenced by the bad Lisp it uses.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Erik,
Please accept my apologies for not replying sooner.
I want to take this opportunity to thank you for responding is a
very informative and thought-provoking manner. Although I had read
_The Mythical Man Month_ previously, I found that your references
didn't provoke me to recall the actual context. So, I took your
response as an opportunity to purchase and read the 20th Anniversary
Edition of _TMMM_, which I've been meaning to do for some time. Thank
you for prodding me. :-)
[After having re-read _TMMM_] I found your comments to be very
insightful. As a person who is fascinated with history, I also
appreciated your insight into the fate of certain language environment
vendors.
In response to my indication that I intended to write small tools in
Lisp, you wrote:
>
> There is nothing wrong in that. Quite the contrary, but you do not
> generally get into maintenance issues, documentation and tutorials,
> systems integration (except to integrate your tools in some other
> system, which is quite the reverse problem) in small tools. Try to
> work on Emacs for a while, but do not get too influenced by the bad
> Lisp it uses.
Thank you for your suggestion, which I will attempt to implement.
:-) I am a big fan of Emacs (I currently use XEmacs) and am
disappointed to learn that Elisp is not an ANSI Common Lisp.
I have done some background research and have obtained what I
believe to be at least a vaguely correct idea of some of the
challenges (i.e. finding/writing a suitable ANSI Common Lisp
implementation, providing Elisp compatibility). In your opinion, is
there any hope for an Emacs that uses a Common Lisp engine?
Thanks again for your thoughtful and through-provoking response.
-jon
--
------------------
Jon Allen Boone
········@delamancha.org
Jon Allen Boone <········@delamancha.org> wrote in message news:<··············@cornelius.delamancha.org>...
> [...] Erik's comment really struck a chord with me.
>
> Erik Naggum <····@naggum.net> writes:
>
> > Optimizing for extensibility, building systems that can themselves
> > be used to build applications, _without_ the annoying Open Source
> > thing, is Common Lisp's fort�. The ability to think "system" is not
> > very common with today's crop of programmers who are mostly building
> > inside somebody else's systems (be they Windows or something like
> > KDE or GNOME, or the whole Java system)
>
> I have read that Lisp is good for building systems. However, since
> all of my programming training is *exactly* of the sort that Erik
> describes, I have a hard time understanding what type of "system" Lisp
> is good for building.
>
> Here are some things that I think of when I hear "system":
>
> * Computer Operating System
>
> * Air Traffic Control System
>
> * Civilian Emergency Response System [aka 911]
>
> * Embedded Control Systems
>
> Where can I find out more details about what types of "systems" Lisp
> is good for building? I have read Erann Gat's post about what he used
> Lisp for at JPL, but I am desperately seeking pointers to more info.
>
> Until I can figure out what kind of systems Lisp is good for, I
> intend to try writing the only kind of software I really am suited to
> write: small tools.
There are Lispy small tools, too.
Perhaps the most convincing type of small Lisp tool is a program which
benefits from Lisp's support for functional programming and
interactivity, and the hooks it gives you into the reader and printer.
The single problem that was most influential in converting me to Lisp
was a calculator for combinatorial game theory. The original is a C
program,
<http://www.gac.edu/~wolfe/papers-games/games.tar.gz>
I tried experimenting with it, found it frustrating and confusing, and
realized how easy it would be in Lisp. And it was, so much so that I
started looking to Lisp to solve other interesting problems.
Any sort of interactive experimental program where you're allowed to
use Lispy syntax tends to be very easy in Common Lisp, and tends to be
very powerful too, because all the rest of Common Lisp can be
available at the same command line. (Since you said you're a Unix guy,
I'll draw an analogy to the way that text-mangling programs work well
together in Unix shell scripts. It's a similar effect.)
Another kind of small Lisp tool is a macro. In other languages, if you
want to add new syntax or semantics, it's a major problem. In Lisp,
it's often easy. (Not always easy, of course, or good for that matter:
I wouldn't want to try to use macros to add static typing to Lisp, and
using them to add (inefficient) multithreading would be possible but
pretty perverse.) Other Lispers will tell you that this is a huge
advantage, and I agree, but unfortunately it's usually not as
convincing to non-Lispers as it might be. I suspect the reason is that
when the language designer has already anticipated your needs, you
don't need this power, and for small problems you can often choose a
language where the designer has anticipated your needs. But as you get
to larger problems, it becomes more likely that you will want a
combination of features which the language designer hasn't anticipated
(things at the level of nondeterministic choice, continuations, OO
inheritance, object persistence, and functors) and you have a choice
of hand-compiling these abstractions into a lower-level language,
writing a standalone preprocessor to add these abstractions to your
lower-level language (the way people wrote preprocessors to add
inheritance to C), or writing in Lisp the way that God intended.:-| In
my experience this happens more and more often as programs doing new
and interesting things exceed a thousand lines or so. For smaller
programs, and for programs doing what everyone else is doing, it's
fairly likely that you can find a happy choice of programming language
which supports the things you really need, and hand-compile the rest
into something less abstract, so that Lispy macros seem like a frill.
For bigger more adventurous programs, some carefully chosen macrology
can save you so much redundancy and confusion that macros change from
frill to lifesaver.
Note that this kind of scaling is typical for deep language features:
for sufficiently small problems, their advantages seem contrived. It's
hard, perhaps impossible, to convince someone who's only worked on
50-line programs that the deep differences Java, Pascal, Fortran, C,
C++, Ada, or Perl are important. It's easy, even for 50-line programs,
to convince someone that a language specialized to the problem domain
is a win, so you can probably convince someone to use Perl instead of
Fortran for text munging. And even for small programs, the importance
of runtime efficiency can be clear. But trying to convey the
importance of deeper language features is hard. Pascal was limited to
fixed-size arrays in function arguments. Fortran 77 had no recursive
function calls. Perl doesn't have true GC, only reference counting,
and most of the other languages listed don't have even that. But for
almost any 50-line program, abstractions at that level aren't vital,
and it's an easy matter to work around their absence. My thesis is
that macros are like that, except further out. You can probably
demonstrate the advantages of GC or recursion in a 100-line program
without it seeming too contrived, and it tends to demonstrate itself
naturally in 1000-line programs in the appropriate domain. For macros
I suspect that the cutoff is more like 1000 lines and 10000 lines.
Macros have a lot of power in the 100-1000 line regime too, but they
compete with things designed into the language. Thus, people with a
more conventional language background can react to examples of 100
lines by thinking that it'd be better just to use a language which
happens to have, designed in by the language architect, exactly the
combination of features that you as an application programmer
implemented as macros in Lisp. Somewhere on the way to 1000 lines,
though, that attitude should give way to an appreciation of the power
of tailoring your own abstractions to the problem at hand...
It may also be worth to point out that lesser languages can regain
quite a lot of ground wrt. lisp by writing the necessary extensions
into the application, this is after all what Greenspuns 10. rule is
saying.
Suppose you are writing an application in C and the problem is crying
out for closures. Of course you can add such an abstraction to your
application. It probably won't be neither pretty, efficient nor
correct, but it can be done (significant parts of most lisps runtime
environment is probably written in C and/or assembler).
The deep question is of course whether you want to do that or rather
go with something that has such extension build in from the start.
One can think of lisp programmers as "first movers" in software
engineering. Think of all the features that move from lisp to other
languages (GC and sophisticated OO are some of the examples).
------------------------+-----------------------------------------------------
Christian Lynbech |
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
William Newman wrote:
> The single problem that was most influential in converting me to Lisp
> was a calculator for combinatorial game theory. The original is a C
> program,
> <http://www.gac.edu/~wolfe/papers-games/games.tar.gz>
> I tried experimenting with it, found it frustrating and confusing, and
> realized how easy it would be in Lisp. And it was, so much so that I
> started looking to Lisp to solve other interesting problems.
You wrote one too, huh? I bet it's better than mine. :-)
(It's interesting, though not really surprising, how many
Lispers are mathematicians.)
Is your combinatorial game code available for people other
than you to use?
--
Gareth McCaughan ················@pobox.com
.sig under construc
······@interaccess.com (Thaddeus L Olczyk) writes:
> On Fri, 22 Feb 2002 12:58:55 +0100, Christian Lynbech
> <·················@ted.ericsson.se> wrote:
>
> >I read the ACM Communications special issue on Aspect Oriented
> >Programming and saw a bunch of things reinvented that Lisp has been
> >doing for a long time.
>
> Yes and given that Gregor Kiczales was the principle "architect" ( not
> meant in the software development sense ) and invented those things
> in Lisp, it indicates that he does not think Lisp to grow much.
No. It _might_ indicate that. It might also indicate that he works for
people who, for whatever reason, either _don't_ want to fund the relevant
work in Lisp or _do_ want to fund it in some other language. It might also
mean that Gregor, in order to get new research funding, has to package up
an old idea in a new container so that it looks cutting edge. That's not
to say he has no interesting ideas--but it is to say that the people who
make funding decisions for research are often looking for "latest and
greatest" not "tried and true" so dismissing something "tried and true" in
a research proposal is not the same as saying "it didn't work". Sometimes
you even have to bend the truth some and put down something you want to
build on. All of this contributes to a distorted sense of what is good and
what's not if all you do is see who's researching what.
Don't look to the research world to find out what works from a technical
standpoint.
From: Tim Bradshaw
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <ey3n0y4w0b9.fsf@cley.com>
* Wade Humeniuk wrote:
> Perhaps you could specify which part of it is not "solved"? You might be
> using the term solved akin to the mathematical concept of "proof" or as in
> the case of the "provably best solution". Web search exists, it is working
> and it does not matter whether it is optimally done. Wonderful ideas are
> not specifically "Google's page ranking" but the concept and idea of
> "Ranking" anything. Who thought that one up? Wonderful ideas are concepts
> like Language, the Wheel, Mathematics, ... It is not "Google page
> ranking".
This seems to me to be completely wrong. The google people either had
or borrowed the idea of looking at the web in terms of connectivity
(link count) rather than, or in addition to, in terms of content.
That's much more than just `ranking', and I think it's a pretty
important idea.
And, despite google, web search still isn't working very well: there's
a lot more to do.
--tim
···@jpl.nasa.gov (Erann Gat) eventually writes:
...
> Let me just make two comments to those of you who have had the patience to
> read this far: 1) thanks, and 2) my aim here is not to diss Lisp. My goal
> is honestly constructive. I think that if Lisp does not evolve it will
> die, and I don't want to see that happen. I still think Lisp is great. I
> also think it can be, and should be, improved.
I believe it is hard to disagree with the above. However, IMHO there
are at least two schools of thought that seem at odds.
1 - CL must be junked and something new must be "evolved" in its place.
2 - CL can evolve by incorporating things that are "out there".
It seems to me that most of the debate is whether (1) is better than
(2) and viceversa. Graham has obviously chosen (1). Other people
have simply left CL behind.
I prefer to stay in the (2) camp. Not that I believe that CL will get
anywhere. I just like it and I accept that working with CL is a
personal luxury. At the same time, as long as I will be able to, I
will consider CL my favourite hobby and participate in any effort that
can evolve it into a more usable environment.
Having said so, I'd bettr stop writing on C.L.L. and hack a little bit.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@eglaptop.jpl.nasa.gov>...
> these other languges I found *myself* suddenly becoming more productive in
> other languages than I was in Lisp. For example, my language of choice
> for doing Web development now is Python.
If you decided to write a Common Lisp library of web functionality
etc., to make it better than Python, would it take a long time? Where
would most of that time be spent? Can you think of any major
obstacles making it more difficult than it seems? Is your usage of
Python a shortcut, to bypass the need to work on any such library? If
such a library existed, would you prefer it to Python?
In article <····························@posting.google.com>,
··········@mailandnews.com (Software Scavenger) wrote:
> ···@jpl.nasa.gov (Erann Gat) wrote in message
news:<····················@eglaptop.jpl.nasa.gov>...
>
> > these other languges I found *myself* suddenly becoming more productive in
> > other languages than I was in Lisp. For example, my language of choice
> > for doing Web development now is Python.
>
> If you decided to write a Common Lisp library of web functionality
> etc., to make it better than Python, would it take a long time?
One of the last things I did before I left JPL was to write a Web server
in Lisp (and write an application on top of that infrastructure). It took
me about two months of full time work to build the infrastructure, but
someone who actually knew what they were doing could certainly do what I
did in less time.
What I built in two months had a significant problem: I wrote it in MCL,
so I used WOOD, the object database that comes with MCL. WOOD turns out
to be pretty unreliable when stressed. I'm still looking for a suitable
replacement.
> Where would most of that time be spent?
That probably depends on who you are. If you were me you'd be spending
most of your time (at this point) working on the database. YMMV. (BTW,
in Python I use MySQL. It took me less time to build an object layer on
top of the relational DB than I've spent looking for a reliable DB,
relational or otherwise, that works with MCL.)
> Can you think of any major
> obstacles making it more difficult than it seems?
That's hard to say. How difficult does it seem? Writing a basic Web
server is pretty easy. At this point the hardest part seems to be
managing non-volatile storage. A good regexp library would also be very
handy, but the parsing involved in serving HTTP is pretty minimal, so it's
not too hard to manage without one. Not so for the DB.
> Is your usage of
> Python a shortcut, to bypass the need to work on any such library?
Nope. :-)
> If such a library existed, would you prefer it to Python?
Probably not. :-)
E.
···@jpl.nasa.gov (Erann Gat) writes:
> That probably depends on who you are. If you were me you'd be spending
> most of your time (at this point) working on the database. YMMV. (BTW,
> in Python I use MySQL. It took me less time to build an object layer on
> top of the relational DB than I've spent looking for a reliable DB,
> relational or otherwise, that works with MCL.)
If you decide to use LW or CMUCL, you can get UncommonSQL for free,
which is probably exactly what you want: an object layer and a
funtional layer atop a relational database such as postgresql or
oracle (mysql support isn't used much, so it's in a bit of
disrepair). The package is made by OnShoreD, so look at their web site
http://alpha.onshored.com for the code.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ············@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
···@jpl.nasa.gov (Erann Gat) writes:
> That probably depends on who you are. If you were me you'd be spending
> most of your time (at this point) working on the database. YMMV. (BTW,
> in Python I use MySQL. It took me less time to build an object layer on
> top of the relational DB than I've spent looking for a reliable DB,
> relational or otherwise, that works with MCL.)
But, comparatively, MySQL is also just a toy. The applications I was
working on for the last 5 years always used Oracle, running on big fat
Solaris servers, as their database engine. The connection to lisp was
through our own little layer of C code running as a separate server
layer between the lisp programs and the database. These three layers
could run on different machines (and in fact, at one point in the
development process, I tested one of the lisp layers on a mac with MCL
while the DB and the C-layer were still running on Solaris. No need
to write any big libraries to make that work, I only had to make the
basic code for making tcp connections portable).
--
(espen)
In article <··············@merced.netfonds.no>, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > That probably depends on who you are. If you were me you'd be spending
> > most of your time (at this point) working on the database. YMMV. (BTW,
> > in Python I use MySQL. It took me less time to build an object layer on
> > top of the relational DB than I've spent looking for a reliable DB,
> > relational or otherwise, that works with MCL.)
>
> But, comparatively, MySQL is also just a toy.
I assure you from firsthand experience, it is not. I've seen serious
industrial applications run reliably using MySQL. And I've seen an
attempt to move an application from MySQL to Sybase. By the time it was
over there was unanimity among a team of over half a dozen engineers that
the move had been a mistake and they should have stuck with MySQL.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@merced.netfonds.no>, Espen Vestre
> <·····@*do-not-spam-me*.vestre.net> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > That probably depends on who you are. If you were me you'd be spending
> > > most of your time (at this point) working on the database. YMMV. (BTW,
> > > in Python I use MySQL. It took me less time to build an object layer on
> > > top of the relational DB than I've spent looking for a reliable DB,
> > > relational or otherwise, that works with MCL.)
> >
> > But, comparatively, MySQL is also just a toy.
>
> I assure you from firsthand experience, it is not. I've seen serious
> industrial applications run reliably using MySQL. And I've seen an
> attempt to move an application from MySQL to Sybase. By the time it was
> over there was unanimity among a team of over half a dozen engineers that
> the move had been a mistake and they should have stuck with MySQL.
It must be making fairly unsophisticated use of the database, then (in
which case, it's probably an appropriate DB system). I spent an
absurd amount of time writing a system to get around the fact that
MySQL doesn't have transactions, and that when it gets heavily loaded,
it sometimes irrecoverably (AFAICT) corrupts all the data in its
databases. It was fun, but the less stupid solution would have been
to use a real database system.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Richard Fateman
Subject: Re: How I lost my faith (very long) / lisp and python
Date:
Message-ID: <3C74462D.7040103@cs.berkeley.edu>
I had some curiosity (still do..) about the relative merits
(mostly speed) between Gnu Multi Precision (GMP) and the
bignum package I was using (in Allegro Common Lisp). I thought
I would have to build a GMP library. Not so. I found it
in a PYTHON library, all compiled to a dll.
http://www.lemburg.com/files/python/
To use it from ACL, I downloaded it and did
:load gmp31.dll
and then a few foreign function entry point declarations
later, I was all set to test.
If the rest of python libraries are as easy to integrate
into lisp as gmp, that suggests progress in python is
relatively easily transferred to lisp via FF.
A whole bunch of people who are supporting python may
also be supporting CL.
My faith in lisp as the ultimate eclectic environment
continues.
(I did a similar thing with MPFUN, another library,
this time written in Fortran. Though an alternative
has emerged: f2cl can compile this 10,000 card ( :))
fortran program into lisp; there is current a speed
penalty of perhaps 3X for doing it this way.
)
Richard Fateman
Richard Fateman <·······@cs.berkeley.edu> writes:
> If the rest of python libraries are as easy to integrate
> into lisp as gmp, that suggests progress in python is
> relatively easily transferred to lisp via FF.
I think an important issue here is that lisp's concepts of what
datatypes exist is very different from what C uses, typically. Even
strings can be very different, e.g. when you have an adjustable string
with a fill-pointer. How do you give that to a C function and have it
do what you'd expect a lisp function to do? Also, there's the issue of
passing objects to the C function and the function then keeps a
reference to that object. I suppose some sort of "indirection" object
might help here, but figuring out semantics for such a type that are
consistent with both what lisp programmers and C programmers expect
won't be easy, afaict.
Python doesn't have this problem because its ``native'' datatypes are
essentially the same as C's, so python programmers don't expect what
lisp programmers expect out of their libraries. :)
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ············@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>> That probably depends on who you are. If you were me you'd be
>> spending most of your time (at this point) working on the database.
>> YMMV. (BTW, in Python I use MySQL. It took me less time to build
>> an object layer on top of the relational DB than I've spent looking
>> for a reliable DB, relational or otherwise, that works with MCL.)
> But, comparatively, MySQL is also just a toy. The applications I was
> working on for the last 5 years always used Oracle, running on big
> fat Solaris servers, as their database engine. The connection to
> lisp was through our own little layer of C code running as a
> separate server layer between the lisp programs and the
> database. These three layers could run on different machines (and in
> fact, at one point in the development process, I tested one of the
> lisp layers on a mac with MCL while the DB and the C-layer were
> still running on Solaris. No need to write any big libraries to make
> that work, I only had to make the basic code for making tcp
> connections portable).
Mind you, if the intelligence in the system resides in the Lisp code
that's controlling access to the DB, the fact that MySQL isn't
terribly sophisticated may be no problem at all.
Indeed, there's a package out there that provides a fairly intimate
interface between CMU/CL and Berkeley DB, supporting a pretty
sophisticated set of transactional behaviour.
If you built a "persistent CLOS object" class on top of that, you
could have considerable sophistication (and good reliability) for code
written in CL.
The absence of the "Oracle Seal of Approval" means you're paying less,
but doesn't forcibly imply a whole lot more than that, if the
application is sitting all on the CL side.
Mind you, if the goal is to interface to (let's say) an existing
General Ledger sitting in Oracle, well, I guess Oracle's the mandatory
answer! But if there's not some external need to care about what's
underneath, well-disciplined use of the DBMS may obviate some of the
demerits that just looking at which DBMS is in use might _suggest_.
[All that being said, given tabula rosa, I'd rather use PostgreSQL
than MySQL, and would further prefer to consider something More
Industrial Grade, given the choice.]
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
"One often contradicts an opinion when what is uncongenial is really
the tone in which it was conveyed." -- Nietzsche
Christopher Browne <········@acm.org> writes:
> The absence of the "Oracle Seal of Approval" means you're paying less,
> but doesn't forcibly imply a whole lot more than that, if the
> application is sitting all on the CL side.
one of the applications I'm talking about was updating an Oracle
database doing up to 100 inserts/updates per second (and additional
read operations) into tables with sizes of up to 200 million rows,
indexed on several columns. I actually do think that it would be
possible to recreate the essential functionality with some really
smart use of Berkeley DB, but I do *not* think that MySQL or Postgres
would be even worth a try.
--
(espen)
> So I can't really go into many specifics about what happened at Google
> because of confidentiality, but the upshot was this: I saw, pretty much
> for the first time in my life, people being as productive and more in
> other languages as I was in Lisp. What's more, once I got knocked off my
> high horse (they had to knock me more than once -- if anyone from Google
> is reading this, I'm sorry) and actually bothered to really study some of
> these other languges I found *myself* suddenly becoming more productive in
> other languages than I was in Lisp. For example, my language of choice
> for doing Web development now is Python.
Nice post, if depressing.
I started programming in lisp fairly late, '87 or thereabouts. Spent a
few years on lispms, but by the time I graduated the A.I. winter had
hit so I wound up doing C, and C++ for the last 8 yrs or so.
As much as I gripe about C++'s lack of expressiveness and quirkiness,
it is nonetheless a surprisingly productive language. The program I'm
working on has at last count just under 2 million lines of C++, and
has taken something like 30 man-years to get to this state. Despite
its size and complexity and the oft-touted "unreliability" of C code
and manual memory management, the servers stay up for months at a time;
the most common reason for downing the servers is to apply an OS patch.
We've had two memory leaks in released systems in the last three years,
each took a couple of hours to find and fix -- hardly the disaster that
is Lisp/Java/ML fans' image of C.
I think Gabriel mentioned that when Lucid started working in C++, they
found that they were only 10-15% more efficient in Lisp than C++. My
lisp skills are no longer as sharp as my C++ skills, but that sounds
about right to me. So lisp is nice, but not compelling in that regard.
And had Stroustrup put closures in C++ a lot of that advantage would
have evaporated.
Unfortunately I don't know what's to be done about Lisp. I think
"Worse is Better" is still its prime enemy. MSVC (for example) has
an impressive IDE and a debugger that is easily on par with the best
of the Lisp debuggers. Python is coming on strong, and if it gets
some real compilers and a decent IDE it could be the final nail.
* Erann Gat
| Glad you asked!
Sigh. Will you _ever_ get a clue? (For full credit, your answer must be
2000 words or longer.)
A free hint for you: Cut your losses and just _move_on_. If Python is so
great, enjoy it for what it is, and make it your new community. Pursue
your happiness -- if it is to be found elsewhere, move accordingly.
Hanging around here apparently makes you progressively more unhappy.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> * Erann Gat
> | Glad you asked!
>
> Sigh. Will you _ever_ get a clue? (For full credit, your answer must be
> 2000 words or longer.)
>
> A free hint for you: Cut your losses and just _move_on_. If Python is so
> great, enjoy it for what it is, and make it your new community. Pursue
> your happiness -- if it is to be found elsewhere, move accordingly.
> Hanging around here apparently makes you progressively more unhappy.
Actually, I'm not at all unhappy. But thanks for your concern.
E.
"Erann Gat" <···@jpl.nasa.gov> wrote
[long story omitted]
> I found *myself* suddenly becoming more productive in
> other languages than I was in Lisp. For example, my language of choice
> for doing Web development now is Python.
Could you be more specific on that point? I have seen Norvig's stuff on
Python and looked at it. For me the language is much less powerful and slow
than Lisp except for the library which is big with lots of "modern" stuff. I
don't see how you can be more productive in Python than in Lisp for web
development.
> I also saw Peter Norvig come to Google and leave Lisp behind with no
> apparent regrets. (Actually, Peter and I had talked about this while we
> were both still at NASA, and he was already leaving Lisp behind, which I
> found very distressing at the time.)
>
> Finally, I read Paul Graham's recent writings. He's the only person I
> know of who has actually gotten wealthy using Lisp. That doesn't make him
> infallible, but I think it does make it prudent to pay attention to what
> he has to say. At least when Paul says, "That's how I got to where I am,"
> I don't have to wonder where that is.
>
> That's the story in a very large nutshell. What happened when I lost my
> faith was that I could no longer sustain it in the face of mounting
> evidence to the contrary.
>
> Let me just make two comments to those of you who have had the patience to
> read this far: 1) thanks, and 2) my aim here is not to diss Lisp. My goal
> is honestly constructive. I think that if Lisp does not evolve it will
> die, and I don't want to see that happen. I still think Lisp is great. I
> also think it can be, and should be, improved.
Yes, but why do you stick to minor points like (syntax, uniform container
access, etc.) instead of the library part ? Do you really thing that using
hashtables instead of alist will make Lisp better than Python ? (maybe this
will be clearer when you tell us why is Python better than Lisp).
Marc
In article
<··················································@lp.airnews.net>, "Marc
Battyani" <·············@fractalconcept.com> wrote:
> "Erann Gat" <···@jpl.nasa.gov> wrote
>
> [long story omitted]
>
> > I found *myself* suddenly becoming more productive in
> > other languages than I was in Lisp. For example, my language of choice
> > for doing Web development now is Python.
>
> Could you be more specific on that point? I have seen Norvig's stuff on
> Python and looked at it. For me the language is much less powerful and slow
> than Lisp except for the library which is big with lots of "modern" stuff. I
> don't see how you can be more productive in Python than in Lisp for web
> development.
You said it yourself: it's the library: regexps and database connectivity
in particular. I also have come to like some of the notational
conveniences, like triple-quoted strings and being able to do array
references (and other things, see below*) without having to type 'aref'.
Standard reader and print syntax for dictionaries is handy too. Mainly I
like it because I don't have to fight with my coworkers about it nearly as
much.
> > Let me just make two comments to those of you who have had the patience to
> > read this far: 1) thanks, and 2) my aim here is not to diss Lisp. My goal
> > is honestly constructive. I think that if Lisp does not evolve it will
> > die, and I don't want to see that happen. I still think Lisp is great. I
> > also think it can be, and should be, improved.
>
> Yes, but why do you stick to minor points like (syntax, uniform container
> access, etc.) instead of the library part ?
I'm not convinced that uniform container access is such a minor point, but
I'm making so little progress on the "minor points" that I'm a little
discouraged about tackling anything major.
> Do you really thing that using hashtables instead of alist
> will make Lisp better than Python ?
No, of course not.
I didn't say that Lisp should (unconditionally) use hashtables instead of
alists. I said that Lisp should have better support for abstract
dictionaries that don't commit to any underlying representation. (And if
hash tables are supposed to be that, then the functions make-hashtable and
gethash should be renamed, and the major implementations rewritten.)
E.
----
* So one of the things I like about Python is that I can overload the
square bracket operator. In native Python, square brackets can be used to
do both array references and dictionary lookup, which makes sense to me
because you can think of an array reference as a special case of a
dictionary lookup where the indices are integers. But I can also create
objects that look like arrays or dictionaries but whose contents are
stored on disk rather than in core. Now, of course I can do all that in
Lisp too, but I have to be much more forsightful in Lisp than I do in
Python. In Lisp, as soon as I type "aref" or "assoc" or "gethash" I have
committed not just to in-core represention, but to a particular kind of
in-core representation. In Python I naturally type x[y] to mean an array
reference, and later I can change that to mean a database lookup or a
binary tree search or something else without having to change the client
code.
Erann Gat wrote:
> * So one of the things I like about Python is that I can overload the
> square bracket operator. In native Python, square brackets can be used to
> do both array references and dictionary lookup, which makes sense to me
> because you can think of an array reference as a special case of a
> dictionary lookup where the indices are integers. But I can also create
> objects that look like arrays or dictionaries but whose contents are
> stored on disk rather than in core. Now, of course I can do all that in
> Lisp too, but I have to be much more forsightful in Lisp than I do in
> Python. In Lisp, as soon as I type "aref" or "assoc" or "gethash" I have
> committed not just to in-core represention, but to a particular kind of
> in-core representation. In Python I naturally type x[y] to mean an array
> reference, and later I can change that to mean a database lookup or a
> binary tree search or something else without having to change the client
> code.
I'd like to expand on this very slightly, because there's an
aspect of it that I've overlooked a bit when trying to explain
why I like this feature of Python. The point is that in a
language like Python or CL that offers interactive development
and a decent way of reading and printing non-trivial objects,
it's very natural to begin working on something using the
built-in data types. Once you've figured out exactly what
you need, you can then switch to using your own. That switch
is much less of a wrench if you can arrange that diddling
your own objects looks just like diddling arrays or lists
or dictionaries or whatever.
"But you should always do all that diddling through an
abstraction layer; that's good design." Kind of. It's
good design because it makes it easier to change the
underlying representation. In a language like Python
where you can keep the syntax and change the representation,
there isn't so much reason to write an abstraction layer.
And in the early exploratory phases it can be awfully
tempting not to bother, even in CL.
The uncharitable way to say this is that uniform access
makes life easier for sloppy developers. I'd prefer to
say that it enables you to engage in some practices that
would usually be sloppy without actually *being* sloppy.
--
Gareth McCaughan ················@pobox.com
.sig under construc
················@pobox.com (Gareth McCaughan) writes:
> I'd like to expand on this very slightly, because there's an
> aspect of it that I've overlooked a bit when trying to explain
> why I like this feature of Python. The point is that in a
> language like Python or CL that offers interactive development
> and a decent way of reading and printing non-trivial objects,
> it's very natural to begin working on something using the
> built-in data types. Once you've figured out exactly what
> you need, you can then switch to using your own. That switch
> is much less of a wrench if you can arrange that diddling
> your own objects looks just like diddling arrays or lists
> or dictionaries or whatever.
I agree completely, and here's why I don't think it matters. Even in
my sloppiest code, I don't write more than 50-100 lines that need to
be changed when switching data structures[*]; maybe I'm unusually
disciplined about writing interface functions, but from my experience
with others, I'm not. So in the worst case scenario, I need to go
hunting through 50-100 lines for (setf (cdar assoc))[**], etc. So, yes,
something more like
alist[key] := new-val;
would mean I wouldn't need to change my code as much, but the savings
really isn't that much. Where it is more useful to have generic
dereferencing is when passing objects across module boundaries. This
is a time when I like having my little REF gf utility. However, I'm
still in the experimental-use stage with it, and I'm not convinced
that that particular use of it is good style. The other approach I've
used is for the recieving module to define gf's, and for the calling
module to define the methods it needs. Of course, I still use that,
because not everything a module does is (ref ...) and (setf (ref ...) ...)
:)
[*] Assuming the data structures are semantically interchangable. But
if they're not, no amount of syntactic sugar will change that.
[**] I have a very un-schemely habit of writing things like
(let ((assoc (assoc ...)))
(if assoc ...))
it drives some people up the wall, but I find it nicer to read.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Dorai Sitaram
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <a50v1a$am6$1@news.gte.com>
In article <···············@conquest.OCF.Berkeley.EDU>,
Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
>
>[**] I have a very un-schemely habit of writing things like
> (let ((assoc (assoc ...)))
> (if assoc ...))
> it drives some people up the wall, but I find it nicer to read.
Your code is being reviewed by Scheme users? Or
is it fellow Common Lisp users that are being so
affected?
--d
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <···············@conquest.OCF.Berkeley.EDU>,
> Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
> >
> >[**] I have a very un-schemely habit of writing things like
> > (let ((assoc (assoc ...)))
> > (if assoc ...))
> > it drives some people up the wall, but I find it nicer to read.
>
> Your code is being reviewed by Scheme users? Or
> is it fellow Common Lisp users that are being so
> affected?
People who primarily live in another language (C++ or Java), but use
Lisp sometimes. It takes some getting used to, but I've yet to meet
someone who can't get used to it. [BTW, that was a word play,
"un-schemely" -- I think maybe my sense of humor is broken]
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
I do agree that uniform container access is a major thing which i find
lacking in lisp.
Yes, you could do something like this following
(defgeneric element( container index ) )
(defmethod element( (c cons) index )
(elt index c))
[.....]
But that doesn't help much for things like shared libraries. What if
i want to use frobnicate with a hash, instead of an array, like the
author intended?
I have thought of doing an "updated" lisp with this and other features
in it, but i'm sure we don't need even more fragmentation. :)
dave
···········@yahoo.com (David Hanley) writes:
> I have thought of doing an "updated" lisp with this and other features
> in it, but i'm sure we don't need even more fragmentation. :)
CLOS isn't enough to implement this? Seems contradictory to my
experience :)
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ············@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
"Erann Gat" <···@jpl.nasa.gov> wrote
> "Marc Battyani" <·············@fractalconcept.com> wrote:
[...]
>> Could you be more specific on that point? I have seen Norvig's stuff on
>> Python and looked at it. For me the language is much less powerful and
slow
>> than Lisp except for the library which is big with lots of "modern"
stuff. I
>> don't see how you can be more productive in Python than in Lisp for web
>> development.
>
> You said it yourself: it's the library: regexps and database connectivity
> in particular.
Good news: There are several libraries available for regexps and database
connectivity. The latest regexp library has been announced here a few days
ago. You even have the choice between commercially supported and open source
ones.
> I also have come to like some of the notational
> conveniences, like triple-quoted strings
OK this one is a good one. why don't you write and publish it ?
> and being able to do array
> references (and other things, see below*) without having to type 'aref'.
> Standard reader and print syntax for dictionaries is handy too. Mainly I
> like it because I don't have to fight with my coworkers about it nearly as
> much.
[...]
> * So one of the things I like about Python is that I can overload the
> square bracket operator. In native Python, square brackets can be used to
> do both array references and dictionary lookup, which makes sense to me
> because you can think of an array reference as a special case of a
> dictionary lookup where the indices are integers. But I can also create
> objects that look like arrays or dictionaries but whose contents are
> stored on disk rather than in core. Now, of course I can do all that in
> Lisp too, but I have to be much more forsightful in Lisp than I do in
> Python. In Lisp, as soon as I type "aref" or "assoc" or "gethash" I have
> committed not just to in-core represention, but to a particular kind of
> in-core representation. In Python I naturally type x[y] to mean an array
> reference, and later I can change that to mean a database lookup or a
> binary tree search or something else without having to change the client
> code.
Again : Why don't you write and publish it ?
Your technical arguments against Common Lisp look pretty weak for me. Most
of them could be wiped with a few lines of code.
Marc
From: Dorai Sitaram
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <a53bdk$c76$1@news.gte.com>
In article <··················································@lp.airnews.net>,
Marc Battyani <·············@fractalconcept.com> wrote:
>
>Good news: There are several libraries available for regexps and database
>connectivity. The latest regexp library has been announced here a few days
>ago.
Which one is that? I can't get Google to ferret
out the announcement you are referring to.
My take, based on negative feedback I've gotten for my
own regexp library for Common Lisp, is that Common
Lispers are holding out for regexps "done right", or
even want to avoid having to deal with regexps
altogether and do something more fundamentally and
structurally pleasing with string manipulation.
--d
> My take, based on negative feedback I've gotten for my
> own regexp library for Common Lisp, is that Common
> Lispers are holding out for regexps "done right", or
> even want to avoid having to deal with regexps
> altogether and do something more fundamentally and
> structurally pleasing with string manipulation.
Well, I cannot speak for anyone else, but yes, I do not want to use regexps.
It is not "avoiding" them as if they some kind of fundamental programming
construct. Why should I use them when the emphasis in Lisp is not on
strings but more on symbols? (I do not think I even need better string
manipulation). Regexps could be used when Lisp has to deal with external
data formatted in non-Lisp syntaxes. Perhaps one should not give in to
other languages dictating how external data is formatted? If I need to
translate is easier to write more pliant and error resistent things like
parsers.
Wade
"The quick red fox jumped over the lazy brown dog"
'(the quick red fox jumped over the lazy brown dog)
"12:02:59"
#s(time :hour 12 :minute 2 :second 59)
"<b>Some Text</b>"
'(<b> |Some Text| </b>)
From: Dorai Sitaram
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <a53orv$ccp$1@news.gte.com>
In article <············@news3.cadvision.com>,
Wade Humeniuk <········@cadvision.com> wrote:
>
>Well, I cannot speak for anyone else, but yes, I do not want to use regexps.
>It is not "avoiding" them as if they some kind of fundamental programming
>construct. Why should I use them when the emphasis in Lisp is not on
>strings but more on symbols? (I do not think I even need better string
>manipulation). Regexps could be used when Lisp has to deal with external
>data formatted in non-Lisp syntaxes.
You say it like this is some rare thing! For all my
fondness for s-exps and structured data, I am not even
sure this _should_ be a rare thing. For an
example: One may be dealing with natural-language text.
For another: Unstructured subunits within otherwise
structured data.
>Perhaps one should not give in to
>other languages dictating how external data is formatted?
Such data isn't necessarily or even mostly because of
taintage from some "other", presumably much reviled
programming languages. So this tension between loyalty
vs betrayal doesn't arise.
>If I need to
>translate is easier to write more pliant and error resistent things like
>parsers.
Writing ad hoc, fully fledged parsers for every little
thing is a great way to break one's back pretty
quickly. No one's suggesting that one should use
regexps to read structured data (only a masochist would
(and can :-) use regexps to read s-exps); however
they can be pretty useful to deal with unstructured
textual data, whether they occur in bulk or as
unstructured splashes of color dotting a structured
landscape. I wouldn't paint myself into an ideological
corner thinking of regexps as displacing beloved Lisp
staples.
(BTW, IIRC, Kleene had a hand in the birthing of both
regexps and the lambda calculus. Maybe the math buffs
here can weigh in.)
--d
····@goldshoe.gte.com (Dorai Sitaram) writes:
> You say it like this is some rare thing! For all my fondness for
> s-exps and structured data, I am not even sure this _should_ be a
> rare thing. For an example: One may be dealing with
> natural-language text. For another: Unstructured subunits within
> otherwise structured data.
How do regexps help you deal with data which doesn't have a "regular"
(ahem) structure? Regexps are merely simple state machines, how can
they manage to parse natural language text? I doubt any real natural
language parser just works with freeform text, munging it more and
more as it goes. Everything I've heard of breaks down the text into
locgical units along with meta-information about them. Now how is a
regex going to do this?
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ············@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
From: Tim Bradshaw
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <ey37kp5vh3b.fsf@cley.com>
* Rahul Jain wrote:
> How do regexps help you deal with data which doesn't have a "regular"
> (ahem) structure? Regexps are merely simple state machines, how can
> they manage to parse natural language text? I doubt any real natural
> language parser just works with freeform text, munging it more and
> more as it goes. Everything I've heard of breaks down the text into
> locgical units along with meta-information about them. Now how is a
> regex going to do this?
I think NLP systems typically do morphology using something equivalent
to regexps - finite state machines anyway. Morphology is pretty much
trying to work out that the plural of fish is fishes not fishs and the
reverse (given fishes parse as fish + plural). Presumably things like
basic tokenization and punctuation handling (which is kind of the same
as morphology, maybe) are finite state too. Beyond that I don't
there's any realistic argument that finite-state systems are any use.
--tim
Tim Bradshaw <···@cley.com> writes:
> I think NLP systems typically do morphology using something equivalent
> to regexps - finite state machines anyway.
Heh, I never thought to think of such an (almost) simple part of NLP. :)
> Morphology is pretty much
> trying to work out that the plural of fish is fishes not fishs and the
> reverse (given fishes parse as fish + plural).
But the plural of fish is fish! Now we add more cruft to our regex to
handle this special case...
> Presumably things like
> basic tokenization and punctuation handling (which is kind of the same
> as morphology, maybe) are finite state too. Beyond that I don't
> there's any realistic argument that finite-state systems are any use.
Yeah, I was thinking more of the grammatical parsing, not of the
low-level lexing.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ············@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
From: Tim Bradshaw
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <ey3adu1jq0p.fsf@cley.com>
* Rahul Jain wrote:
> Heh, I never thought to think of such an (almost) simple part of
> NLP. :)
I don't think it's very simple - nothing in NLP is simple!
>> Morphology is pretty much
>> trying to work out that the plural of fish is fishes not fishs and the
>> reverse (given fishes parse as fish + plural).
> But the plural of fish is fish! Now we add more cruft to our regex to
> handle this special case...
Well, finite state morphology doesn't specify things as regexps, but
in a much nicer formalism, which happens to be finite-state and
therefore equivalent. I think the real win is that because it's
finite-state you know there are good algorithms, which is a nice thing
to know.
--tim
From: Dorai Sitaram
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <a55t2g$dta$1@news.gte.com>
In article <··············@photino.sid.rice.edu>,
Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
>
>How do regexps help you deal with data which doesn't have a "regular"
>(ahem) structure? Regexps are merely simple state machines, how can
>they manage to parse natural language text? I doubt any real natural
>language parser just works with freeform text, munging it more and
>more as it goes. Everything I've heard of breaks down the text into
>locgical units along with meta-information about them. Now how is a
>regex going to do this?
"Natural-language" was probably a terrible choice of
word. I wasn't thinking of NLP in the AI sense at all.
I meant things that aren't already specified in some
sort of abstract tree already, but will need to be
converted to such before they can be worked with. And
it is my feeling that such data are not uncommon, nor
are they something that can be wished away by hoping
that as civilization progresses they will have been
migrated to s-exps or XML and thus save us all a
lot of bother.
For instance: The scads of data ("records") in the
telecom industry (but I don't think it is restricted to
this area) that are specified in some semblance of
order that humans can follow (mostly; and not without
drawing on a capacity for forgiveness). Regexps are
useful for helping convert this unruly stuff into an
s-expressive form. Once-and-for-all conversion into
s-exp format isn't an option, as different programs may
see different structural aspects of the unstructured
format. That is the latter's strength. It is easily
generated, is not hostage to a programmer's whim, can
be added to, and lends itself to usefully multiple
interpretations. A structured format would have fixed
things too early and too inflexibly.
--d
From: Christophe Rhodes
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <sq3czuzq8d.fsf@cam.ac.uk>
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <··················································@lp.airnews.net>,
> Marc Battyani <·············@fractalconcept.com> wrote:
> >
> >Good news: There are several libraries available for regexps and database
> >connectivity. The latest regexp library has been announced here a few days
> >ago.
>
> Which one is that? I can't get Google to ferret
> out the announcement you are referring to.
CL-AWK, at a guess.
<URL:http://groups.google.com/groups?q=cl-awk&hl=en&selm=038D36424A1C01F9.65E29BB8B196CA2C.A6955F3341EEC795%40lp.airnews.net&rnum=2>
> My take, based on negative feedback I've gotten for my
> own regexp library for Common Lisp, is that Common
> Lispers are holding out for regexps "done right", or
> even want to avoid having to deal with regexps
> altogether and do something more fundamentally and
> structurally pleasing with string manipulation.
... but hey, "Worse is better".
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
"Christophe Rhodes" <·····@cam.ac.uk> wrote
> ····@goldshoe.gte.com (Dorai Sitaram) writes:
>
> > Marc Battyani <·············@fractalconcept.com> wrote:
> > >
> > >Good news: There are several libraries available for regexps and
database
> > >connectivity. The latest regexp library has been announced here a few
days
> > >ago.
> >
> > Which one is that? I can't get Google to ferret
> > out the announcement you are referring to.
>
> CL-AWK, at a guess.
Good guess. The Awk package is based on a regex package.
>
<URL:http://groups.google.com/groups?q=cl-awk&hl=en&selm=038D36424A1C01F9.65
E29BB8B196CA2C.A6955F3341EEC795%40lp.airnews.net&rnum=2>
>
>
> > My take, based on negative feedback I've gotten for my
> > own regexp library for Common Lisp, is that Common
> > Lispers are holding out for regexps "done right", or
> > even want to avoid having to deal with regexps
> > altogether and do something more fundamentally and
> > structurally pleasing with string manipulation.
>
> ... but hey, "Worse is better".
And some days we are too tired to do the right thing... ;-)
Marc
Dorai Sitaram wrote:
>
> In article <··················································@lp.airnews.net>,
> Marc Battyani <·············@fractalconcept.com> wrote:
> >
> >Good news: There are several libraries available for regexps and database
> >connectivity. The latest regexp library has been announced here a few days
> >ago.
>
> Which one is that? I can't get Google to ferret
> out the announcement you are referring to.
That is probably my library, CL-AWK, which is an implementation of
much of the functionality of AWK. Obviously built on a regex core.
> My take, based on negative feedback I've gotten for my
> own regexp library for Common Lisp, is that Common
> Lispers are holding out for regexps "done right", or
> even want to avoid having to deal with regexps
> altogether and do something more fundamentally and
> structurally pleasing with string manipulation.
····@goldshoe.gte.com (Dorai Sitaram) writes:
> My take, based on negative feedback I've gotten for my
> own regexp library for Common Lisp, is that Common
> Lispers are holding out for regexps "done right", or
> even want to avoid having to deal with regexps
> altogether and do something more fundamentally and
> structurally pleasing with string manipulation.
Here's some positive feedback for your pregexp.scm which is included
in brl.
Thanks.
Chris
Hey, wait a minute, Dorai! I love you regexp library, and have been very
glad to have it around.
Will Fitzgerald
"Dorai Sitaram" <····@goldshoe.gte.com> wrote in message
·················@news.gte.com...
> In article
<··················································@lp.airnews.net>,
> Marc Battyani <·············@fractalconcept.com> wrote:
> >
> >Good news: There are several libraries available for regexps and database
> >connectivity. The latest regexp library has been announced here a few
days
> >ago.
>
> Which one is that? I can't get Google to ferret
> out the announcement you are referring to.
>
> My take, based on negative feedback I've gotten for my
> own regexp library for Common Lisp, is that Common
> Lispers are holding out for regexps "done right", or
> even want to avoid having to deal with regexps
> altogether and do something more fundamentally and
> structurally pleasing with string manipulation.
>
> --d
In article <··················································@lp.airnews.net>, "Marc Battyani" <·············@fractalconcept.com> wrote:
>
> "Erann Gat" <···@jpl.nasa.gov> wrote
>
> [long story omitted]
>
>> I found *myself* suddenly becoming more productive in
>> other languages than I was in Lisp. For example, my language of choice
>> for doing Web development now is Python.
>
> Could you be more specific on that point? I have seen Norvig's stuff on
> Python and looked at it. For me the language is much less powerful and slow
> than Lisp except for the library which is big with lots of "modern" stuff. I
> don't see how you can be more productive in Python than in Lisp for web
> development.
>
Hi-
Are you serious?
It's very simple to jerk up some working code in Python, anyone with two neurons can do it.
It's much better designed than Perl, for instance.
A lot of that "modern" stuff is what you need in "daily" life, and it's lacking in LISP, or it isn't out there on the web, in a CPAN-like place.
You know what I mean?
Larry Wall says that Perl development is "like an onion", with concentric rings. He is at the core. But a lot of things, with a wider radius are on the periphery.
Most people apporach Perl from the periphery. And Python. That's why those work.
Scheme community has been quicker in doing thins like the BRL, etc. Problem is there's no standard.
syn
"synthespian" <···········@uol.com.br> wrote
"Marc Battyani" <·············@fractalconcept.com> wrote:
> >
> > "Erann Gat" <···@jpl.nasa.gov> wrote
> >
> > [long story omitted]
> >
> >> I found *myself* suddenly becoming more productive in
> >> other languages than I was in Lisp. For example, my language of choice
> >> for doing Web development now is Python.
> >
> > Could you be more specific on that point? I have seen Norvig's stuff on
> > Python and looked at it. For me the language is much less powerful and
slow
> > than Lisp except for the library which is big with lots of "modern"
stuff. I
> > don't see how you can be more productive in Python than in Lisp for web
> > development.
>
> Hi-
> Are you serious?
> It's very simple to jerk up some working code in Python, anyone with two
neurons can do it.
Same for Lisp. Common Lisp is even usable by people with more neurons... ;-)
> It's much better designed than Perl, for instance.
Sure.
> A lot of that "modern" stuff is what you need in "daily" life, and it's
lacking in LISP, or it isn't out there on the web, in a CPAN-like place.
When I asked Erann Gat what was missing, he replied regexp and database
connectivity. We have both in Lisp. So what is lacking for you ?
> You know what I mean?
No. We are speaking web development and I still don't see what I am missing
by not using Python.
> Larry Wall says that Perl development is "like an onion", with concentric
rings. He is at the core. But a lot of things, with a wider radius are on
the periphery.
> Most people apporach Perl from the periphery. And Python. That's why those
work.
> Scheme community has been quicker in doing thins like the BRL, etc.
Problem is there's no standard.
The fact that there is no standard can be a good thing as you can choose
different ways for a same functionality.
I don't know if you are new to Lisp but I can assure you that the Lisp
community is growing again and more active each day. The only thing that is
needed is more people to contribute all those little libraries instead of
whining that lisp is lacking them.
Marc
* "Marc Battyani" <·············@fractalconcept.com>
| I don't know if you are new to Lisp but I can assure you that the Lisp
| community is growing again and more active each day. The only thing that
| is needed is more people to contribute all those little libraries instead
| of whining that lisp is lacking them.
Well... It would be really nice if it were possible to provide a Common
Lisp library for a virtual machine in a standard format that got compiled
to native machine code either upon execution or importation into the
system. In order to offer a Common Lisp library today, you either have
to have access to all Common Lisp implementations on all platforms you
think your customers might need (and pay licenses for them), or provide
source code. I think this choice _really_ sucks. From some of the
discussions I have had with others who would like to offer libraries for
Common Lisp environments that cost huge amounts of money to use, giving
away things for free when there are other operators in the market who
make a killing in license fees is unpalatable. I am far from alone in
this regard, and this is probably a much bigger "threat" to the market
that would sustain Common Lisp than anything else. That the same vendor
who charges the heftiest license fees suddenly and without warning kill
other commercial projects by offering something as Open Source, often
with dubious quality, does not help.
Open Source is in my view an overreaction to the evils of Microsoft and
it has some "stopping power" towards the progress of those bad people,
but I seriously doubt that it has lasting value in its own right. For
some cogent thinking on this topic, see this article: A New Paradigm in
Intellectual Property Law? The Case Against Open Sources.
http://stlr.stanford.edu/STLR/Articles/01_STLR_4/article.htm
As for what I would really like to see implemented with all the Common
Lisp implementations, I think Java got the virtual machine concept just
right. One may argue over the implementation and its many choices and
tradeoffs, but specifying the language in terms of this virtual machine
is a good thing, not the least because lots and lots of code can be
shared without having to share source code, including comments, internal
functionality, etc, which one would not like to share as such even though
it is necessary support functionality for the shared functionality.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
> Open Source is in my view an overreaction to the evils of Microsoft and
> it has some "stopping power" towards the progress of those bad people,
> but I seriously doubt that it has lasting value in its own right. For
> some cogent thinking on this topic, see this article: A New Paradigm in
> Intellectual Property Law? The Case Against Open Sources.
I think there are cases where open source makes a lot of sense. My
father's company sells fiberglass observatories to amateur astronomers
(http://www.homedome.com). As accessories, he also sells remote
control systems for them. The general architecture is a PC in the
observatory, talking to the controller via serial port. As part of
the package, he includes a Windows app that acts as a client; it
provides a control panel, hooks to telescope control programs,
logging, weather display, etc.. He has several customers that have
either modified the client software or found bugs & sent in fixes. It
has also earned a measure of goodwill with other customers.
Of course they're making money on the hardware and he does not release
the source to the controller firmware. So its not a fully open source
approach, though I suspect opening the firmware source still wouldn't
hurt their sales- principally because a competitor would also have to
build and sell the controller boards & there isn't enough volume or
markup to make that really pay.
I agree this approach does not bet the business on open source.
However, having an open source conceptual model handy was helpful in
convincing my parents to give it a try on their software, they had
never thought beyond the conventional binary-only approach and using
it has certainly benefited the company & its customers.
Greg Menke
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> * "Marc Battyani" <·············@fractalconcept.com>
> | I don't know if you are new to Lisp but I can assure you that the Lisp
> | community is growing again and more active each day. The only thing that
> | is needed is more people to contribute all those little libraries instead
> | of whining that lisp is lacking them.
>
> Well... It would be really nice if it were possible to provide a Common
> Lisp library for a virtual machine in a standard format that got compiled
> to native machine code either upon execution or importation into the
> system.
I think this is an excellent idea. Have you given any thought to a design?
E.
Erik Naggum <····@naggum.net> writes:
> * "Marc Battyani" <·············@fractalconcept.com>
> | I don't know if you are new to Lisp but I can assure you that the Lisp
> | community is growing again and more active each day. The only thing that
> | is needed is more people to contribute all those little libraries instead
> | of whining that lisp is lacking them.
>
> Well... It would be really nice if it were possible to provide a Common
> Lisp library for a virtual machine in a standard format that got compiled
> to native machine code either upon execution or importation into the
> system. In order to offer a Common Lisp library today, you either have
> to have access to all Common Lisp implementations on all platforms you
> think your customers might need (and pay licenses for them), or provide
> source code.
[...]
> As for what I would really like to see implemented with all the Common
> Lisp implementations, I think Java got the virtual machine concept just
> right.
For distributing libraries as binaries to protect your IP, I don't
think the JVM is a good model. I don't know if you've tried
disassembling JVM bytecodes before, but in my limited experience (and
from what I've heard from others, it's typical), it's pretty simple to
go from bytecodes back to Java. If you were concerned with your IP,
you could run the bytecodes through an obfuscater, but then you can do
that with source code, too.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
* Thomas F. Burdick
| For distributing libraries as binaries to protect your IP, I don't think
| the JVM is a good model. I don't know if you've tried disassembling JVM
| bytecodes before, but in my limited experience (and from what I've heard
| from others, it's typical), it's pretty simple to go from bytecodes back
| to Java. If you were concerned with your IP, you could run the bytecodes
| through an obfuscater, but then you can do that with source code, too.
I did not have JVM specifically in mind, but my code is rife with design
comments and the choice of lexically scoped variable namaes that capture
a lot of the meaning of the algorithm. If I use macros, I do so in order
to make the code easier to read. I spect comments and lexical variable
names to have vanished in the virtual machine "binary", and all macros to
have been expanded. Thus, whether it can be "restored" to source or not,
I do not believe it will be nearly as usable to another programmer as the
source code itself. In order to disassemble code back to readable source,
you need a tremendous amount of what is usually known as debug information
that I see no reason to impart to a purchaser of a particular library -- I
would instead expect the library to be thoroughly debugged before shipping
-- an expectation that generally does not hold for Open Source where the
vendor has bet on the free labor of its users to iron out its bugs.
//
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Tim Bradshaw
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <ey3y9hli1dl.fsf@cley.com>
* Erik Naggum wrote:
> I did not have JVM specifically in mind, but my code is rife with design
> comments and the choice of lexically scoped variable namaes that capture
> a lot of the meaning of the algorithm. If I use macros, I do so in order
> to make the code easier to read. I spect comments and lexical variable
> names to have vanished in the virtual machine "binary", and all macros to
> have been expanded. Thus, whether it can be "restored" to source or not,
> I do not believe it will be nearly as usable to another programmer as the
> source code itself. In order to disassemble code back to readable source,
> you need a tremendous amount of what is usually known as debug information
> that I see no reason to impart to a purchaser of a particular library -- I
> would instead expect the library to be thoroughly debugged before shipping
> -- an expectation that generally does not hold for Open Source where the
> vendor has bet on the free labor of its users to iron out its bugs.
Actually Lisp should be the king of self-obfuscating code. It should
be relatively plausible to distribute libraries as something which is
essentially Lisp *source* but where some huge macro-expansion and
rewriting process has gone on to make the whole thing as obfuscated as
the JVM is.
This can't quite work because the expansions of a lot of CL-defined
macros are implementation-dependent, but I suspect that something
along those lines could be made to work.
(this is not a completely serious suggestion).
--tim
Tim Bradshaw <···@cley.com> writes:
> * Erik Naggum wrote:
> > I did not have JVM specifically in mind, but my code is rife with design
> > comments and the choice of lexically scoped variable namaes that capture
> > a lot of the meaning of the algorithm. If I use macros, I do so in order
> > to make the code easier to read.
Wow, my brain had to have been pretty broken when I posted that not to
think of macros. Coming from a loop user, too...
> > I spect comments and lexical variable
> > names to have vanished in the virtual machine "binary", and all macros to
> > have been expanded. Thus, whether it can be "restored" to source or not,
> > I do not believe it will be nearly as usable to another programmer as the
> > source code itself. In order to disassemble code back to readable source,
> > you need a tremendous amount of what is usually known as debug information
> > that I see no reason to impart to a purchaser of a particular library -- I
> > would instead expect the library to be thoroughly debugged before shipping
> > -- an expectation that generally does not hold for Open Source where the
> > vendor has bet on the free labor of its users to iron out its bugs.
>
> Actually Lisp should be the king of self-obfuscating code. It should
> be relatively plausible to distribute libraries as something which is
> essentially Lisp *source* but where some huge macro-expansion and
> rewriting process has gone on to make the whole thing as obfuscated as
> the JVM is.
>
> This can't quite work because the expansions of a lot of CL-defined
> macros are implementation-dependent, but I suspect that something
> along those lines could be made to work.
>
> (this is not a completely serious suggestion).
Actually, macros themselves will probably be enough. Enough of CL
alone is specified in terms of macros, that even if the user didn't
use any of his/her own, the result would probably be quite different
than the source. Being able to disassemble something back into a loop
form, with the variables given useless names, wouldn't be very very
protective; but it's not going to give you a loop -- no names attached
to the mess you'd get back would make it useless...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Erik Naggum <····@naggum.net> writes:
> Well... It would be really nice if it were possible to provide a Common
> Lisp library for a virtual machine in a standard format that got compiled
> to native machine code either upon execution or importation into the
> system. In order to offer a Common Lisp library today, you either have
Kawa and Jscheme are on this track, I think:
Scheme/lisp -> Kawa/Jscheme -> java j2sdk compiler -> JVM bytecodes
Scheme/lisp -> Kawa/Jscheme -> gcj compiler -> native executable
http://www.gnu.org/software/kawa
http://www.sf.net/projects/silk
Chris
Chris Beggy <······@kippona.com> writes:
> Kawa and Jscheme are on this track, I think:
>
> Scheme/lisp -> Kawa/Jscheme -> java j2sdk compiler -> JVM bytecodes
> Scheme/lisp -> Kawa/Jscheme -> gcj compiler -> native executable
With Kawa you eliminate the j2sdk compiler step. It compiles s-exprs
directly to JVM bytecodes.
So much work has gone into optimizing JVMs that it's an alternative
worth investigating. One might get good performance without needing to
design a VM for lisp from the ground up and implement it on N platforms.
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
Bruce Lewis <·······@yahoo.com> writes:
> Chris Beggy <······@kippona.com> writes:
>
>> Kawa and Jscheme are on this track, I think:
>>
>> Scheme/lisp -> Kawa/Jscheme -> java j2sdk compiler -> JVM bytecodes
>> Scheme/lisp -> Kawa/Jscheme -> gcj compiler -> native executable
>
> With Kawa you eliminate the j2sdk compiler step. It compiles s-exprs
> directly to JVM bytecodes.
Oops. Thanks for correcting that.
Chris
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * "Marc Battyani" <·············@fractalconcept.com>
> | I don't know if you are new to Lisp but I can assure you that the Lisp
> | community is growing again and more active each day. The only thing that
> | is needed is more people to contribute all those little libraries instead
> | of whining that lisp is lacking them.
>
> Well... It would be really nice if it were possible to provide a Common
> Lisp library for a virtual machine in a standard format that got compiled
> to native machine code either upon execution or importation into the
> system. In order to offer a Common Lisp library today, you either have
> to have access to all Common Lisp implementations on all platforms you
> think your customers might need (and pay licenses for them), or provide
> source code. I think this choice _really_ sucks.
Has anyone looked into or actually attempted creating a JIT compiler for
Clisp bytecode? Can the bytecode be made portable between machines? It
strikes me that some of the work on a portable lisp may be done already.
---------------
Geoff
In the last exciting episode, Erik Naggum <····@naggum.net> wrote::
> * "Marc Battyani" <·············@fractalconcept.com>
> | I don't know if you are new to Lisp but I can assure you that the
> | Lisp community is growing again and more active each day. The
> | only thing that is needed is more people to contribute all those
> | little libraries instead of whining that lisp is lacking them.
> Well... It would be really nice if it were possible to provide a
> Common Lisp library for a virtual machine in a standard format
> that got compiled to native machine code either upon execution or
> importation into the system.
This is, in effect, what one of the three "prongs" of .NET is trying
to provide, and is the piece that some of the Linux/GNOME folks are
trying to emulate in the form of "MONO."
Java is _interesting_, but has the demerit that it really was designed
for use with just one language.
The "CLR" (Common Language Runtime) of .NET is particularly pointed
towards the kinda-Java-like C#, and and certainly doesn't support the
"type tree" of CL; its "type tree" is rather more like an OO view of
C. But it has the slight merit that there is the intent to allow it
to be usable with "more than just C#."
It's interesting that the Franz guys decided to pooh-pooh .NET.
While it may be too "weak" a foundation for them to build on,
construction of a more robust foundation of analagous kind strikes me
as being a big enough task to be problematic for any CL vendor to try
to take on.
--
(concatenate 'string "cbbrowne" ·@canada.com")
http://www3.sympatico.ca/cbbrowne/lsf.html
I've told you for the fifty-thousandth time, stop exaggerating.
Christopher Browne <········@acm.org> writes:
> In the last exciting episode, Erik Naggum <····@naggum.net> wrote::
> > * "Marc Battyani" <·············@fractalconcept.com>
> > | I don't know if you are new to Lisp but I can assure you that the
> > | Lisp community is growing again and more active each day. The
> > | only thing that is needed is more people to contribute all those
> > | little libraries instead of whining that lisp is lacking them.
>
> > Well... It would be really nice if it were possible to provide a
> > Common Lisp library for a virtual machine in a standard format
> > that got compiled to native machine code either upon execution or
> > importation into the system.
>
> This is, in effect, what one of the three "prongs" of .NET is trying
> to provide, and is the piece that some of the Linux/GNOME folks are
> trying to emulate in the form of "MONO."
Correct, and it is not a bad idea.
> Java is _interesting_, but has the demerit that it really was designed
> for use with just one language.
Specifically, not CL (though we do play in that sandbox sometimes,
anyway).
> The "CLR" (Common Language Runtime) of .NET is particularly pointed
> towards the kinda-Java-like C#, and and certainly doesn't support the
> "type tree" of CL; its "type tree" is rather more like an OO view of
> C. But it has the slight merit that there is the intent to allow it
> to be usable with "more than just C#."
More on this below.
> It's interesting that the Franz guys decided to pooh-pooh .NET.
No, we didn't "pooh-pooh" .NET, we rejected it, without prejudice.
Any other virtual machine proposals, or the enhancements to CRL
that we asked MS for, would likely allow us to change our minds.
I just got off the phone with the Franz developer who did the study.
There were three areas where CRL posed problems for us, all of which
we could work around at a loss of efficiency and/or security, and all
of which we asked MS for changes based on our needs. The MS developers
agreed with our needs in principle, but made no promises, and we don't
know if they made any changes to the CRL design. Please bear in mind
that these analyses were made over two years ago, and that the
descriptions may have changed for the better.
1. There was really no way to specify a varying number of arguments
in a call. This had ramifications for almost the entire CL calling
sequence, including &optionals, &rest, and &key arguments. We figured
that the most efficient way to get such operation is to cons up a "list"
of arguments for each call. There may now be ways to call with varying
arguments, but there was not at the time we did our analysis.
2. As you implied above, the type tree was more tree-like than net-like,
and didn't allow for multiple inheritance. We felt we would have to
consider all CL objects as being of the single type "object", which
really defeats the purpose of the object system.
3. Method dispatch was compile-time only. Good for static languages,
bad for Lisp.
On the plus side, it seemed to have a pretty good garbage-collector,
although it had high storage overhead per object, which would be
problematic for systems with huge numbers of cons cells...
> While it may be too "weak" a foundation for them to build on,
> construction of a more robust foundation of analagous kind strikes me
> as being a big enough task to be problematic for any CL vendor to try
> to take on.
But perhaps not a community...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Dear Erik Naggum,
you wrote
> Open Source is in my view an overreaction to the evils of Microsoft and
> it has some "stopping power" towards the progress of those bad people,
> but I seriously doubt that it has lasting value in its own right.
It is well known that you are an avid hater of Microsoft, from their
technologies to their leader to their business practices. I have now
and then seen your impassioned expression of this hatred, scattered
among your comp.lang.lisp posts.
Personally, i have an inherent distrust towards big organizations.
This applies to Microsoft. Since perhaps 1995, MS has become more and
more large,
and as well becoming a hate target especially among unix communities.
Of MS hatred there are two aspects: those who think MS products are
utterly incompetent, and those who think MS business practice are the
most evil.
I have always been an Apple Macintosh user. I have used a few MS
products such as MS Word word processor on the Mac since about 1990,
and Mac version of MS Internet Explorer web browser and Outlook
Express email program when they became available around 1997 or so
free of charge. My experiences has been that MS software on the Mac
are pretty good, if not usually better than competitors. In fact,
before the MS-hatred era of late 1990s, i recall that i was found of
MS Word and would say it was the software that never crashed, with the
richest (useful) features. I have not used MS Windows much until 1999,
so i cannot judge from my own experience whether people's complains
about MS's product's poor quality. By the time i used MS Windows daily
in 1999, it was MS Windows NT, and i have moved into industrial
programing field now called IT. At the time Apple's OS is around
version 8. Although Windows is not as aesthetic or intuitive as my
beloved Mac OS, but on the whole i think Windows NT beats the shit out
of Mac OS by far. Mac OS crashed daily if a info-collecting tech-head
like myself are careful, hourly if not, and among quite a few of other
reasons.
As the MS hatred is rolling like a snowball, i started to pay
attention. On one hand, i never cared for Microsoft. Their sole
impression on me before 1998 was that MS Word is good software, and i
hate Windows just because i'm a dedicated Apple fan just because Apple
had made many revolutionary innovations in both software and hardware
and MS was Apple's market enemy. Although i think the unix crowd are
tech morons of the world, but when it comes to political issues, i'm
inclined to side with their freedom loving and paranoia propensities.
I'm ashamed to admit, that i started to visit unix moron's mecca the
slashdot.org around 1999, and have read quite a lot of their MS hatred
verbiage, from drivel of sopho-morons to Eric Raymond's OpenSource
Jihad to Richard Stallman's Free Software Foundation. Perhaps due to
their propaganda, at times i shudder at the mind-numbing MS
juggernaut, and have felt ready to join their cause and kill
Microsoft.
Since 1999, my behavior have in fact been mildly anti-Microsoft. I
would, for example, mention FreeSoftware or OpenSource in meetings,
avoid using MS products myself and convert all my MS Word files i have
on my Mac to some standard format such as plain text, and also use the
Free Software Foundation's GNU Public License for my own software
dabblings. Still, i was never a MS hater. Some people i know are MS
haters, but i'm just a mild FreeSoftware proponent and was never sure
i should be a MS hater. I could have investigated the issue, by
studying the various lawsuits, check out MS history, exam and verify
MS hater's essays, but life is short and i have other interests so i
did not undertook such activities and never decided whether MS should
be hated. I just disliked big organizations, and thus Microsoft.
Since 1999 i entered the field of industrial programing known as Info
Technology. In particular, i'm a web application programer on the unix
platform. My daily office machines are PC running Windows (NT and
followings) and remote unix servers. I find NT quite usable and almost
never crashed at least as a desktop machine. I don't know much about
any MS-bred technologies, but i knew quite a lot about unix. My
attitude towards unixes is that it is the MOST incompetent thing in
the computing world. I am an outright unix HATER. I have becoming
increasingly nosy about unix MS-hater's claims technology-wise as most
readily found from slashdot.org, from User Interface design to
protocol embrace & extend to innovation to power & flexibility to
security considerations. In the past few years, i started to pay mild
attention to the question of wether from a technical or technological
point of view MS should be hated.
Even i don't know much Microsoft technologies except using their OS,
but in my personal judgment system among all things considered, i
think that if MS has done damage to society then unix has done hundred
times more. I believe that Microsoft Windows technologies is on the
whole FAR superior to unixes both as a PC and server, all things
considered. (this includes the fact that unix is more stable then
Windows NT, today.) Comparing to the other major desktop Operating
System the Mac OS (where unixes are so incompetent it is out of the
question), with intact conscience i think that MS's OS since about
1997 has left my beloved Mac OS in dust. If Windows 98 is poor
quality, then Mac OS of that year is crap.
(i plan to have book-length material on the reasons, but here for now
i can only briefly state my beliefs in a conclusive manner.)
The above is my beliefs on product or technological quality aspect of
Microsoft-hatred. I have much interest in technology than politics or
business, thus my know-how of social oriented issues pales in
comparison. I have never examined the accusations of MS's evil
business practices, other than news hearsay. To this day, i know
little of what is true or false regarding MS's business practices.
Although i have never undertook an interest of a topic, but as a
philosopher i have gathered opinions regarding a topic from great
variety of sources and experiences, and can form a personal judgment.
And from my observations of computing industry, and my little
knowledge of economics, all things and experiences lead me to believe
that there is little to no reason to hate MS for their business
practice either. Sometimes last year i read Thomas Sowell's Basic
Economics. Although he never talked about software in the book, but
that book made a major impression on my views of MS-hating issues.
Around 1994 i read the book _Steve Jobs and the NeXT big thing_ by
historian Randall E. Stross, and i was highly positively impressed by
him. I have then learned that he also wrote a book in 1997 on MS: _The
Microsoft Way : The Real Story of How the Company Outsmarts Its
Competition_. Although i have not read the book, but from amazon.com
reviews it indicated that he simply think that the success of MS is
due to being smart.
There are various lawsuits against the MS giant in the last few years,
from Sun Microsystem's Java lawsuit, to United States vs Microsoft
anti-trust lawsuit, to last month's AOL suit for Netscape browser. As
you know, Sun is a unix vendor, with its own greedy grip on Java. I
frankly don't buy any bullshit from the Sun Micro commercial turd. MS
may be devious with their own "standard"-breaking java, but no less
hanky-panky than Sun's Universal Java sham in the first fucking place.
Any commercial organizations do devious things for their own interest.
As to United State's claim that MS screwed innovation by bundling
browser, that itself is a fantastic fucking idea. Integrating browser
into OS is an innovation, and amid so great many claims that MS does
not innovate, i can think of quite a few cases where MS has in fact
been innovative or responsible for technological lead from my personal
computing experiences. (Microsoft Word accounts for great many
innovations in word processing along.) And, who needs the government
to meddle with industry? (as i have learned in Thomas's Sowell's book,
anti-trust cases are invariably all the same.) Lastly is the AOL's
bandwagon-hopping lawsuit in the name of fantastically incompetent
Netscape the-loser-browser. Fuck America On-Line.
I'm often ignorant when it comes to economics practicality, such as
stock market or personal finance. Since about 1999, i started to
become a stock holder, thus started to learn a bit of its nature. On
this process, one thing came to my attention is that Microsoft is a
public owned company. Public owned companies are directed by the
people who owns its stock, and any joe can purchase it. That means, if
Microsoft is an evil empire, then public shares a great blame. From
this aspect, i don't see any sense of Microsoft-hatred either. Blame
the public, such as your boss and neighbors and wife and friends and
community, or, blame the fantastic greed-oriented system called
capitalism that made USA so prosperous far beyond the moral-oriented
communist/socialist nations or sovereignly ruled kingdoms & queendoms.
Dear Nagg'm, among all i've seen, i think you are the most vehement
Microsoft hater by far. From your various rants i've gathered that you
think MS products are the most poor quality, their business practice
the most unethical, and Bill Gates one of the greatest criminal of
mankind. Though, i don't think i have came across a cogent detail of
why. Your rants tends to be mythically incendiary, and defensive in
nature when risen the challenge. I would really like to see you give a
plain account of why Microsoft is worthy of hatred.
Please put aside tones and grudges, and propound for the good of
humanity.
(
here is a relevant essay i've written regarding Mac OS X, unix, and
Windows.
http://xahlee.org/UnixResource_dir/20020105_macosx_rant.txt
)
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
> Newsgroups: comp.lang.lisp
> Subject: Re: How I lost my faith (very long)
> From: Erik Naggum <····@naggum.net>
> Date: Fri, 22 Feb 2002 11:55:19 GMT
···@xahlee.org (Xah Lee) writes:
> free of charge. My experiences has been that MS software on the Mac
> are pretty good, if not usually better than competitors. In fact,
> before the MS-hatred era of late 1990s, i recall that i was found of
> MS Word and would say it was the software that never crashed, with the
> richest (useful) features.
MS Word on the mac was a decent program as long as they kept the
code bases separate, i.e. up to and including version 5.1. From
then on, it became a monster, on both platforms.
--
(espen)
On Fri, 22 Feb 2002, Erik Naggum wrote:
> * "Marc Battyani" <·············@fractalconcept.com>
> | I don't know if you are new to Lisp but I can assure you that the Lisp
> | community is growing again and more active each day. The only thing that
> | is needed is more people to contribute all those little libraries instead
> | of whining that lisp is lacking them.
>
> Well... It would be really nice if it were possible to provide a Common
> Lisp library for a virtual machine in a standard format that got compiled
> to native machine code either upon execution or importation into the
> system.
[snip]
Hmm. Why so retrict it? It seems that there'd be benefit, even now, for a
bytecode interpreting or JITing system.
(I take it that this would be an *additional* feature, i.e., systems would
be free to compile as they like in ways perhaps incompatible with the
standard. It seems rather hard to predict what internal arrangements will
be useful and efficient for *all* uses. Hmm. Granted, it opens up a rather
different focus of research and competition. The Java analogy is *very*
interesting.)
One existing possible starting point is the SmallScript system
(http://www.smallscript.net/), which was designed to support multiple
"pluggable" object systems and be efficiently "JITable" (eek!). The
author, David Simmons, is fairly Lisp knowledgeable and has worked hard to
bring Lispy things like multimethods to Smallscript.
Cheers,
Bijan Parsia.
In article <··················································@lp.airnews.net>, "Marc Battyani" <·············@fractalconcept.com> wrote:
> "synthespian" <···········@uol.com.br> wrote
> "Marc Battyani" <·············@fractalconcept.com> wrote:
>> >
>> > "Erann Gat" <···@jpl.nasa.gov> wrote
>> >
>> > [long story omitted]
>> >
>> >> I found *myself* suddenly becoming more productive in
>> >> other languages than I was in Lisp. For example, my language of choice
>> >> for doing Web development now is Python.
>> >
>> > Could you be more specific on that point? I have seen Norvig's stuff on
>> > Python and looked at it. For me the language is much less powerful and
> slow
>> > than Lisp except for the library which is big with lots of "modern"
> stuff. I
>> > don't see how you can be more productive in Python than in Lisp for web
>> > development.
>>
>> Hi-
>> Are you serious?
>> It's very simple to jerk up some working code in Python, anyone with two
> neurons can do it.
>
> Same for Lisp. Common Lisp is even usable by people with more neurons... ;-)
>
>> It's much better designed than Perl, for instance.
>
> Sure.
>
>> A lot of that "modern" stuff is what you need in "daily" life, and it's
> lacking in LISP, or it isn't out there on the web, in a CPAN-like place.
(snip)
>
> I don't know if you are new to Lisp but I can assure you that the Lisp
> community is growing again and more active each day. The only thing that is
> needed is more people to contribute all those little libraries instead of
> whining that lisp is lacking them.
>
> Marc
Marc-
You got to see things from my perspective: a lisp newbie. I have trouble even opening files!
What about concepts like "orthogonality"?!!
The learning curve with LISP could be made easier if one could get one's hand on a "working" LISP.
Then move up to stuff like macros and "orthogonality" (whatever the hell that is).
The way thing are right now for a new comer is that there's a lot of material to read that doesn't make
you, for instance, read a text file, or write to it. You know, practical things.
In a way, it's kind of funny when you read comp.lang.lisp. You get these long threads that can go on for
miles, when the question that started it was a simple one. People debate the best algorithm for reading a
text file! Whereas in other languages, newcomers aren't exposed to that. Also, they are't usually exposed to
those snide comments we get so often here like "well, shooot, tough luck, huh? Don't like it my boy, go write
a library of your own!"
As if I could, right now...
But I'm not complaining, makes your skin grow though, sharpens your skills, makes you think about
things that looked simple on the surface, but only on the surface.
Well, long life to the Lispiness in all of you!
Cheers
henry
On Sat, 23 Feb 2002 23:22:52 -0300, synthespian <···········@uol.com.br>
wrote:
> You got to see things from my perspective: a lisp newbie. I have trouble even opening files!
> What about concepts like "orthogonality"?!!
[...]
> The way thing are right now for a new comer is that there's a lot of material to read that doesn't make
> you, for instance, read a text file, or write to it. You know, practical things.
Have you checked the Common Lisp Cookbook?
http://agharta.de/cookbook
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Erann Gat wrote:
> At the beginning of
> the project we had a lot of prototype code written in Lisp, so it seemed
> natural to me to just fly Lisp aborad the spacecraft. The resistance to
> this idea was tremendous and unrelenting. Fortunately, we resisted
> successfully. I say fortunately, because at one point an attempt was made
> to port part of the code (the planner) to C++. Afer a year that effort
> had to be abandoned. On the basis of that experience I think it's safe to
> say that if we hadn't used Lisp the Remote Agent would not have happend.
OK, a fully worked-out prototype could not even be /ported/ to C++, and
porting is an order of magnitude or two easier than developing, so C++
is approximately 95-99.5% less effective than Lisp.
Now tell us again how C++ is just 10% less effective than Lisp?
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"We have a pond and a pool. The pond would be good for you."
- Ty to Carl, Caddy Shack
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Erann Gat wrote:
> > At the beginning of
> > the project we had a lot of prototype code written in Lisp, so it seemed
> > natural to me to just fly Lisp aborad the spacecraft. The resistance to
> > this idea was tremendous and unrelenting. Fortunately, we resisted
> > successfully. I say fortunately, because at one point an attempt was made
> > to port part of the code (the planner) to C++. Afer a year that effort
> > had to be abandoned. On the basis of that experience I think it's safe to
> > say that if we hadn't used Lisp the Remote Agent would not have happend.
>
> OK, a fully worked-out prototype could not even be /ported/ to C++, and
> porting is an order of magnitude or two easier than developing, so C++
> is approximately 95-99.5% less effective than Lisp.
>
> Now tell us again how C++ is just 10% less effective than Lisp?
Don't forget, this was 1995. C++ has come a long way since then.
One of the things I'm working on nowadays is trying to learn C++. As an
excercise I am writing a little Lisp interpreter. GC and numeric code are
available as libraries (I'm using the Boehm GC and Bruno Haible's CLN
package). I was able to get a little Lisp up in about 500 LOC written
over two weeks. It's a toy (so far) but it has a lot of functionality: a
full numeric library including bignums, complex numbers, and even
arbitrary-precision floats, exceptions, and unwind-protect.
Make no mistake, C++ is a royal pain the ass. In order to keep from
getting unbearably frustrated I had to suspend my usual mindset that
programming tools are supposed to make life easier rather than harder.
(Some of the error messages you get from the compiler are truly fearsome,
particularly when you're dealing with templates.) But this time around it
does not appear to be an unmitigated disaster.
E.
> Make no mistake, C++ is a royal pain the ass. In order to keep from
> getting unbearably frustrated I had to suspend my usual mindset that
> programming tools are supposed to make life easier rather than harder.
> (Some of the error messages you get from the compiler are truly fearsome,
> particularly when you're dealing with templates.) But this time around it
> does not appear to be an unmitigated disaster.
Glad to hear it. I generally keep my mouth shut about such things, but
I seem to be one of the few people on the list that has a favorable
opinion of C++.
It's built around a very different mindset, and can be a real PITA
sometimes, but there are very few things about it that are so broken
that they can't be easily worked around. It can be effectively
used to write very large, complex and reliable systems, although
this does require a certain level of talent.
In article <··················································@lp.airnews.net>, Michael Parker wrote:
>> Make no mistake, C++ is a royal pain the ass. In order to keep from
>> getting unbearably frustrated I had to suspend my usual mindset that
>> programming tools are supposed to make life easier rather than harder.
>> (Some of the error messages you get from the compiler are truly fearsome,
>> particularly when you're dealing with templates.) But this time around it
>> does not appear to be an unmitigated disaster.
>
> Glad to hear it. I generally keep my mouth shut about such things, but
> I seem to be one of the few people on the list that has a favorable
> opinion of C++.
>
> It's built around a very different mindset, and can be a real PITA
> sometimes, but there are very few things about it that are so broken
> that they can't be easily worked around. It can be effectively
> used to write very large, complex and reliable systems, although
> this does require a certain level of talent.
You can say the same thing about C.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche wrote:
>
> In article <··················································@lp.airnews.net>, Michael Parker wrote:
> >> Make no mistake, C++ is a royal pain the ass. In order to keep from
> >> getting unbearably frustrated I had to suspend my usual mindset that
> >> programming tools are supposed to make life easier rather than harder.
> >> (Some of the error messages you get from the compiler are truly fearsome,
> >> particularly when you're dealing with templates.) But this time around it
> >> does not appear to be an unmitigated disaster.
> >
> > Glad to hear it. I generally keep my mouth shut about such things, but
> > I seem to be one of the few people on the list that has a favorable
> > opinion of C++.
> >
> > It's built around a very different mindset, and can be a real PITA
> > sometimes, but there are very few things about it that are so broken
> > that they can't be easily worked around. It can be effectively
> > used to write very large, complex and reliable systems, although
> > this does require a certain level of talent.
>
> You can say the same thing about C.
True. But I've found that C++ scales more readily. YMMV. Microsoft
apparently eschews C++ in favor of C, but I'm not sure if that's an
argument for or against C++ :-)
* Kenny Tilton <·······@nyc.rr.com>
| Now tell us again how C++ is just 10% less effective than Lisp?
This is easy, really: When you do things that can be done well in C++,
Lisp is 10-15% more efficient than doing it in C=+. When you do things
that can be done well in Lisp, using C++ instead fails completely. This
is no mystery at all.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> * Kenny Tilton <·······@nyc.rr.com>
> | Now tell us again how C++ is just 10% less effective than Lisp?
>
> This is easy, really: When you do things that can be done well in C++,
> Lisp is 10-15% more efficient than doing it in C=+. When you do things
> that can be done well in Lisp, using C++ instead fails completely. This
> is no mystery at all.
Not that I disagree with you, but what would you cite as an example of
something that can be done well in Lisp and not in C++?
E.
From: Brian P Templeton
Subject: Re: How I lost my faith (very long)
Date:
Message-ID: <87heobnhoz.fsf@tunes.org>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
>
>> * Kenny Tilton <·······@nyc.rr.com>
>> | Now tell us again how C++ is just 10% less effective than Lisp?
>>
>> This is easy, really: When you do things that can be done well in C++,
>> Lisp is 10-15% more efficient than doing it in C=+. When you do things
>> that can be done well in Lisp, using C++ instead fails completely. This
>> is no mystery at all.
>
> Not that I disagree with you, but what would you cite as an example of
> something that can be done well in Lisp and not in C++?
>
How about orthogonal persistance?
> E.
Regards,
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
···@jpl.nasa.gov (Erann Gat) writes:
> doesn't it win in the market? At JPL suboptimal strategies can survive
> because we're an FFRDC (federally funded research and development center)
But suboptimal strategies survive surprisingly well in almost any
sufficiently large organization. That's what made Dilbert so immensly
popular! (btw, I was just reading the Dilbert collection "When did
ignorance become a point of view?" yesterday, I think that title
summarizes a lot of the frustration intelligent people go through
working in suboptimalized big corporations)
> is honestly constructive. I think that if Lisp does not evolve it will
> die, and I don't want to see that happen. I still think Lisp is great. I
> also think it can be, and should be, improved.
I think some of reasons to chose Python before Lisp are already
diminishing: There are lots of lisp libraries being made public these
days, much more than just a few years ago. Back then the MCL community
seemed to be the only one which actively shared tools and libraries.
--
(espen)
On Tue, 19 Feb 2002, Erann Gat wrote:
> In article <················@naggum.net>, Erik Naggum
[snip]
> So I can't really go into many specifics about what happened at
> Google because of confidentiality, but the upshot was this: I saw,
> pretty much for the first time in my life, people being as
> productive and more in other languages as I was in Lisp.
Actually, I think your long story can in its entirety be reduced to
this small paragraph.
> Let me just make two comments to those of you who have had the
> patience to read this far: 1) thanks, and 2) my aim here is not to
> diss Lisp.
I've seen no dissing of Lisp whatsoever.
> My goal is honestly constructive. I think that if Lisp
> does not evolve it will die, and I don't want to see that happen. I
> still think Lisp is great. I also think it can be, and should be,
> improved.
That's certainly true, but I think it is very unrelated to your long
story and why you lost your faith in Lisp. At least, I have not read
one thing in your story which mentioned where exactly Lisp stopped
evolving which resulted in your lost of faith.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"I'm living in a land where Sex and Horror are the New Gods."
-- Frankie Goes To Hollywood, "Two tribes"
In article <··············@ipanema.coling.uni-freiburg.de>, Holger Schauer
<··············@gmx.de> wrote:
> > My goal is honestly constructive. I think that if Lisp
> > does not evolve it will die, and I don't want to see that happen. I
> > still think Lisp is great. I also think it can be, and should be,
> > improved.
>
> That's certainly true, but I think it is very unrelated to your long
> story and why you lost your faith in Lisp. At least, I have not read
> one thing in your story which mentioned where exactly Lisp stopped
> evolving which resulted in your lost of faith.
There's not really a strong connection. I have in the past on this
newsgroup been accused of trying to damage the language by saying negative
things about it. I simply wanted to forestall such criticism.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> There was always some niggling doubt in my mind about this last point.
> Over the course of twenty years the following question had begun to bother
> me more and more: if Lisp is such a massive productivity gain over C, why
> doesn't it win in the market?
There are many, many reasons for this.
* Technology is often (usually?) chosen by those who do not
use it, i.e. managers reading glossy ads.
* When the above is not true, it's chosen de-facto, by "what we've
used before"
* Choice of technology is not nearly as important as the quality of
the design and programming ability, and the teamwork of those doing it.
i.e. it's a second order effect.
So basically, I think your underlying assumptions are wrong: lisp
is _not_ a "massive productivity gain" for bringing a product out; it's
only a gain for one small aspect of the entire development. What I find
lisp mostly brings is an environment mostly free of pain. The cost for
this is having to learn it, recruit people for an unfamiliar language, yada
yada yada. Is it worth it? "It depends".
Lisp is not a panacea. "There is no silver bullet."
I don't see why one's "faith" in lisp should be shaken by its lack of mainstream
acceptance. Lisp seems to me successful on its own terms; certainly, as a language,
it'll outlive C++ and Java. Being able/allowed to use lisp from a business point
of view is a matter of convincing business people that it's in their own best
interest. Business people DON'T CARE about technology, they care about MONEY and RISK.
If the risk is high, or not perceived to be worth the extra money, then so be it.
It's a tired refrain by now, but there ARE many more implementations/vendors of lisp
than there are of Python, Perl, Visual Basic, etc. So *someone* must be using it.
What's important isn't that it isn't wildly successful, it's whether an organization
should use it, for what reasons, and what tradeoffs it brings.
And Erann, thank you for your post, I'm sure it's hard to bare your soul in
this manner.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
In article <··············@gondolin.local.net>, Alain Picard
<·······@optushome.com.au> wrote:
> So basically, I think your underlying assumptions are wrong: lisp
> is _not_ a "massive productivity gain" for bringing a product out; it's
> only a gain for one small aspect of the entire development.
Only for certin kinds of products. For some kinds of products Lisp is
clearly a massive productivity gain, as my personal experience
demonstrated time and time again. Maybe there is no market for the kinds
of products for which Lisp is a massive productivity gain, but that theory
is contradicted (though not disproven) by Paul Graham's experience.
> And Erann, thank you for your post, I'm sure it's hard to bare your soul in
> this manner.
Thanks for the positive feedback. Actually, I've been wanting to tell
that story for a while, but I needed Erik to provide the motivation :-)
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Only for certin kinds of products. For some kinds of products Lisp is
> clearly a massive productivity gain, as my personal experience
> demonstrated time and time again. Maybe there is no market for the kinds
> of products for which Lisp is a massive productivity gain, but that theory
> is contradicted (though not disproven) by Paul Graham's experience.
I think you have a too strong belief in the "market". The so-called
"free market" is to a large extent inhabitated by big corporations
which get even bigger through mergers (though it has been proven again
and again that in terms of efficiency 1+1 is a lot less than 2 when
corporations merge) and takeovers (*). The internal structure of these
corporations is closer to stalinism than to democracy, and shows a
suprising similarity to totalitarian states in many ways (except
perhaps the details of the punishing methods ;-)). Especially in the
way they make sub-optimal top-down decisions and in the lack of
overall responsibility and sense of quality of each employee.
Another and more optimistic way to put it is perhaps that this
"market" does not yet exist, and we're still quite far away from that
goal, but we're not necessarily going in the wrong direction. I'm not
quite sure what will get us closer to the goal, but I'm not one of the
guys who constantly whine about the power of big corporations. I think
that just as democracy has succeeded on large parts of the planet,
more reasonable business organizations will also succeed. Either we'll
see big corporations organized in new and much better ways or we'll
see a return to smaller and more efficient companies.
(*) I don't even want to think about how many great small companies
Microsoft and Cisco have killed in this way.
--
(espen)
Comrade Erann Gat:
your personal tale of lisp makes an interesting read. Thanks for the
write up. However, from an analytical point of view on the
implications and impact, i think it is quite dismal.
You wrote:
> That's the story in a very large nutshell. What happened when I lost my
> faith was that I could no longer sustain it in the face of mounting
> evidence to the contrary.
although nowhere to be found explicit, but you seems to suggest that
lisp is really not technically superior to other languages the likes
of C++, because we don't see popularity of lisp in the market place.
You see, when thoughts are stated formally and explicitly as in
mathematics,
any absurdity becomes eye-catching.
i would be very pleased if you try to re-think, and present your views
or conclusions (if any) in a formal and explicit manner, from which we
can then together access its validity and value, or sigh over the
sorrows of humanity for our pessimistic pleasure.
You many not agree but i'm certain of myself, that the C-style tumor
growth the likes of C, csh, tcsh, Perl, C++, Objective C, Java, and C#
are an intricate pestilence of the world, not unlike religion. They
are not like a candle flame where you can put out with a blow job. The
reason for their existence and popularity is not the generic simpleton
can surmise. Although mathematics and sound philosophies exists, they
will not be popular overnight. And, not unlike that of religion, the
nature and fashion and degree of C-tumor's tremendous harm is changing
and dwindling in proportion to the exponential prosperity of
information exchange around the world that fuels progress.
Xah readers may think that again fancy writing is at work here -- all
flower no roots. Please remember i'm not writing a thesis, nor getting
paid. I do not have time to debunk in detail every bits of fantastic
stupidity that are common place. You will believe me if i say that the
15th century is full of such. Or even 16th century, or even 20 century
has serious stupidities as we can see from hindsight. You will then
conceive that we have lots of fantastic stupidity today as well, just
that you don't know what. Xah knows.
The slew of C-style tumor growth is a fantastic stupidity in the
early computing history that is today, and they are destined to die
off, or gradually mutate into betterment. The Java language for
example, is a few magnitude better than the fantastic stupidity of its
ancestor C/C++, even though it is still utterly and fantastically
extremely stupid than functional languages in aspects from syntax to
implementation to methodology to perfectionism.
I'm not pro-lisp per se, but i share with lispers of anti-moron
mentality against imperative languages. This is why i must correct
bad vibes from lisp bigwigs.
If you support my ideas, please make an effort to keep info flowing
whenever you can. May it be in the form of teaching, argument, or
Xah's diatribe. The less ignoramus we have, the less brain-meat for
C-tumor to grow. As i can see, more and more school are teaching
functional programing, starting with Scheme, and the mathematics
prosperity and importance in the world is only increasing. As i have
said, one cannot expect pests like religion to disappear in a blink.
That itself has taken centuries and is still not dead but thank god
don't dictate our daily activities today. As for C-tumor, it will
happen in our life time, if we educated don't drop dead.
Think! Think what is that you are thinking. Make it mathematics, then
comes clarity.
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
--
From: ···@jpl.nasa.gov (Erann Gat)
Newsgroups: comp.lang.lisp
Subject: How I lost my faith (very long)
Date: Tue, 19 Feb 2002 12:57:12 -0800
On Tue, 19 Feb 2002 12:57:12 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
> I was drawn to Lisp for three reasons. First, it was the language of
> choice for the area of work I wanted to get into. Second, it struck me
> right away as more aesthetic than Pascal or Fortran, and aesthetics are
> important to me. Finally, it was just so much easier to get things done
This may explain why you are so concerned with minor syntactic
modifications to the core language.
> Over the course of twenty years the following question had begun to bother
> me more and more: if Lisp is such a massive productivity gain over C, why
> doesn't it win in the market? At JPL suboptimal strategies can survive
I would expect at least a basic awareness of Gabriel's `worse is better'
theory from someone who knows Lisp and even used a LispM.
> the C-using competition, and it just didn't seem to be happening. I came
> up with the following theory: lots of people are using Lisp, but they
> don't want the competition to know because they want the competition to
> keep using C.
>
> It was a plausible enough theory, except for two things. First, a secret
> of this magnitude would be awfully hard to keep, and second, my own
Since the Stealth jet fighter is based on a lot of cool technologies, I'm
wondering why information on them doesn't routinely leak from those who
designed or built it.
> community. If there really were lots of people out there secretly using
> Lisp and programmers were scarce I would have expected to find myself
> being recruited, but I was not. At this point I was seriously considering
> the possibility that there really was a thriving Lisp economy out there
Maybe you overlooked something? Let me summarize a few facts. There are at
least two Lisp vendors, Franz and Harlequin/Xanalys, which survived the AI
Winter (I wonder what fraction of the early dot-coms are still alive). They
put out new releases of their products on an almost regular basis. This
means that there's demand for such products, i.e. that someone uses them.
There are also hints of a growing, or more active, Lisp community. Here is
a _partial_ list of new projects started during the past few months:
- Common Lisp Cookbook
- CL-zlib
- CLAWK
- CL-PDF
- a new comp.lang.lisp FAQ
- asdf
- Common Lisp Controller
- FastIndex
- cCLan
- Free the X3J Thirteen!
- LISA
- BioLisp.org
- CLiki
- CLOCC
- SBCL
- OpenMCL
- McCLIM
- ECL-Spain/ECLS
- open-sourced PowerLisp
Incidentally, those who are concerned about the mainstream-ness of Lisp may
want to have a look at which language often comes before Perl and Python in
the Development/Programming Languages section of past issues of Linux
Weekly News :)
http://lwn.net
> other languages as I was in Lisp. What's more, once I got knocked off my
> high horse (they had to knock me more than once -- if anyone from Google
> is reading this, I'm sorry) and actually bothered to really study some of
> these other languges I found *myself* suddenly becoming more productive in
^^^^^^
This may be a hint that _you_ may have problems with Lisp.
> So I can't really go into many specifics about what happened at Google
> because of confidentiality, but the upshot was this: I saw, pretty much
Hmmm... what was your point about how awfully hard it is to keep secrets in
industry?
> other languages than I was in Lisp. For example, my language of choice
> for doing Web development now is Python.
In another article of this thread you said that you feel more productive
with Python because of its libraries. How did Python libraries got written
in the first place when the language was less known than it is today? I
guess that someone just sat down and wrote them. To me the above mentioned
projects look like hints that something similar is happening for Lisp.
Maybe we should create a new CLiki page to which those who whine about the
lack of Lisp libraries could be directed, asking them to contribute as many
lines of code as the lines in their articles complaining about missing
libraries.
> I also saw Peter Norvig come to Google and leave Lisp behind with no
> apparent regrets. (Actually, Peter and I had talked about this while we
You apparently forgot what another well known Lisp expert, Kent Pitman, has
done: he has recently started a new company that sells Lisp products and
services.
> Finally, I read Paul Graham's recent writings. He's the only person I
> know of who has actually gotten wealthy using Lisp. That doesn't make him
Note that he got wealthy using Common Lisp, not arc.
> That's the story in a very large nutshell. What happened when I lost my
> faith was that I could no longer sustain it in the face of mounting
> evidence to the contrary.
You apparently missed part of the positive evidence.
> Let me just make two comments to those of you who have had the patience to
> read this far: 1) thanks, and 2) my aim here is not to diss Lisp. My goal
> is honestly constructive. I think that if Lisp does not evolve it will
If your goal is constructive, you may for example create that new CLiki
page I mentioned above, and contribute as many lines of code as your
article contains (about 185).
> die, and I don't want to see that happen. I still think Lisp is great. I
> also think it can be, and should be, improved.
If you are concerned with libraries, as what you said about Python seems to
imply, then make Lisp evolve by contributing to projects for building
layered standards and libraries. Graham's way of improving Lisp, i.e.
rethinking its core functionality from the ground up, is not the only
option. You apparently can live with Python. Why can't you just accept Lisp
as is, even the parts you don't personally like, and help build the tools
you need?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
From: Will Deakin
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C7274B4.4080402@hotmail.com>
Erik Naggum wrote:
> What _really_ happened when you lost your faith in Lisp?
Maybe we need to set up a fund to pay for c++ deprogramming. I know
some nice people who have got some experience with deprogramming
moonies...then again, is it worth it?
;)w
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222885847439883@naggum.net>
* Erann Gat
| First, the special variable is a red herring. What you say is equally
| true whether or not *alist* is special.
Huh? I gave a couple examples that should be enlightening. I am sorry
that I do not have space to include the entire universe in every example
to make sure that is also true but not mentioned because it is probably
not useful in the process of _understanding_ the example. If you have to
get everything "just so", please let me know, and I will try to label my
examples "not suitable for Erann Gat", instead of trying to cope with
your "special needs" for you.
| Second, you can do exactly the same thing with a list of hash tables.
Really? gethash works on a list of hash tables? Are you same guy who
whined that you could not defer the choice of association type in the
standard language? Suddenly you are allowed to rewrite the whole
language in order to argue that you can do with gethash what you can do
with assoc, even though it is not actually supported in the language.
You have gone from knowledgable in Common Lisp to a foll and a troll.
| In fact, an alist is just a special case of this. You can think of a
| cons cell as a brain-damaged hash table with a capacity of one entry and
| the identity as the hash function.
Yeah, that is a certainly brain-damaged way to look at it.
> Alists are also just as efficient from key to value as from value to key.
| If you really need a bidirectional mapping you can get one easily with a
| pair of hash tables. And the runtime efficiency will be O(1) instead of
| O(N).
Great, so now I have two different hashtables that need to be syncronized
with some extraneous code and one accessor for both instead of one data
structure and two accessor functions. Or perhaps you have forgotten
about rassoc now that you have turned to C++ to get your performance fix?
I have, after spending about 3 months with relational databases and SQL,
started to miss support for independent indexing (via hashtables, say)
and relational algebra. I would like to have been able to do these
things in-memory without the need for a fully-fledged database engine,
and not have to change the language I used when I wanted such an engine.
Thinking and designing at such a high level, I could not care less how
things are implemented below the levels I am interested in.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1702020729210001@192.168.1.50>
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> * Erann Gat
> | First, the special variable is a red herring. What you say is equally
> | true whether or not *alist* is special.
>
> Huh? I gave a couple examples that should be enlightening.
Really? Where? I found only one code snippet from you in this thread
(http://groups.google.com/groups?selm=3222747467111424%40naggum.net), and
it had no special variables in it at all.
E.
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222969308458314@naggum.net>
* Erann Gat
| Really? Where? I found only one code snippet from you in this thread
| (http://groups.google.com/groups?selm=3222747467111424%40naggum.net), and
| it had no special variables in it at all.
Troll. No more food for you.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1802022244510001@192.168.1.50>
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> * Erann Gat
> | Really? Where? I found only one code snippet from you in this thread
> | (http://groups.google.com/groups?selm=3222747467111424%40naggum.net), and
> | it had no special variables in it at all.
>
> Troll. No more food for you.
Good! Except for one thing: I wasn't trolling. Let me show you what a
real troll looks like:
<troll>
On second thought, you're really not worth the effort.
</troll>
This has been a test of the emergency trolling system. If this had been
an actual troll no doubt Erik will be unable to refrain from having the
last word and letting us all know.
E.
From: Pierre R. Mai
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <87it8x4ke6.fsf@orion.bln.pmsf.de>
···@jpl.nasa.gov (Erann Gat) writes:
> 2. Having "all those nice list functions" is only an advantage insofar as
> they let you do something useful. Being able to operate on an alist as a
> list is not in and of itself a feature, and can lead to problems if you're
> not careful. I can't offhand think of anything useful you can do with an
> alist that is fundamentally more difficult with a hashmap.
Cheap cloning. One of the nicest things with alists is that under
certain circumstances, cloning them is as cheap as an assignment,
since they can just share tails, if you only modify the non-shared
structure part. While this sounds somewhat specialized, it often
comes up in the guise of alists as environment objects, where bindings
themselves are only ever removed when a complete environment is
destroyed (hence no need to modify structure), and assignment to the
bindings values is intended to propagate up/down the chain.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Gareth McCaughan
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <slrna6u36m.246a.Gareth.McCaughan@g.local>
Erann Gat wrote:
> (Hashmaps, by the way, are one of Common Lisp's best kept secrets, one of
> those "other" data types that doesn't get much attention among all the
> hoopla over lists, atoms, and symbols. Hashmaps are tremendously useful,
> and for a long time Common Lisp was the only language that had them.
> Today C is about the only language in common use that doesn't have them.)
C++ doesn't have them. A C++ "map" pretty much has to be
implemented with some kind of tree structure. Some versions
of the STL have "hashmap" classes, but they are not in the
standard.
I believe Visual Basic doesn't have hash tables. Nor,
so far as I know, does COBOL. Nor Fortran. Nor Scheme.
It is, however, true that Perl, Python, Ruby and Java
have hash tables. Is that what you meant? :-)
--
Gareth McCaughan ················@pobox.com
.sig under construc
From: Erann Gat
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <gat-1702020725450001@192.168.1.50>
In article <································@g.local>,
················@pobox.com wrote:
> Erann Gat wrote:
>
> > (Hashmaps, by the way, are one of Common Lisp's best kept secrets, one of
> > those "other" data types that doesn't get much attention among all the
> > hoopla over lists, atoms, and symbols. Hashmaps are tremendously useful,
> > and for a long time Common Lisp was the only language that had them.
> > Today C is about the only language in common use that doesn't have them.)
>
> C++ doesn't have them. A C++ "map" pretty much has to be
> implemented with some kind of tree structure. Some versions
> of the STL have "hashmap" classes, but they are not in the
> standard.
True, but the GNU STL has them. It's probably only a matter of time
before hashmaps are a de facto standard in C++ (if they aren't already).
> I believe Visual Basic doesn't have hash tables. Nor,
> so far as I know, does COBOL. Nor Fortran. Nor Scheme.
>
> It is, however, true that Perl, Python, Ruby and Java
> have hash tables. Is that what you meant? :-)
Yes. Of course.
E.
················@pobox.com (Gareth McCaughan) writes:
> Erann Gat wrote:
>
> > Hashmaps are tremendously useful, and for a long time Common Lisp
> > was the only language that had them. Today C is about the only
> > language in common use that doesn't have them.
>
> [...] I believe Visual Basic doesn't have hash tables. [...]
This is off-topic, and in no way meant as an endorsement, but Visual
Basic does have hash tables as of 6.0. (They call it dictionaries,
however.)
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbenlr98/html/vaobjdictionary.asp>
--
,------------------- Markus Bjartveit Kr�ger ---------------------.
' `
` E-mail: ·······@pvv.org WWW: http://www.pvv.org/~markusk/ '
)-------------------------------------------------------------------(
From: Thomas A. Russ
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ymiheodfbkl.fsf@sevak.isi.edu>
···@jpl.nasa.gov (Erann Gat) writes:
> 1. Alists can be more efficient than hash tables, particularly for small
> data sets.
Agreed. Many years ago we did some empirical tests and found that the
cross-over point on performance was for much larger alists than we would
have guessed. I recall it being somewhere around 50 items or so.
> 2. Having "all those nice list functions" is only an advantage insofar as
> they let you do something useful. Being able to operate on an alist as a
> list is not in and of itself a feature, and can lead to problems if you're
> not careful. I can't offhand think of anything useful you can do with an
> alist that is fundamentally more difficult with a hashmap.
Well, there is the shadowing of keys. This is much easier with a list
structure. In fact, one current application where this is handy is
dealing with XML namespaces, since those names can be shadowed.
5. Alists can use arbitrary comparison predicates, unlike hash tables.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
In article <···············@sevak.isi.edu>, ···@sevak.isi.edu (Thomas
A. Russ) wrote:
> 5. Alists can use arbitrary comparison predicates, unlike hash tables.
Surely that depends on the particular implementation of hash tables?
For example, in Dylan you can make user-defined hash tables merely by
using <table> as a base class and adding an appropriate method to the
table-protocol GF (which returns a key hashing function and a key
comparison predicate).
Anyone who wants to extend CL in that direction would probably be well
advised to take a look at how it works in Dylan. Same goes for the
"ref" macro, too, which is standard Dylan (called "element" and
"element-setter") and works on all collections, whether sequences (key
is a natural number) or explicit key collections (trees, hash tables).
-- Bruce
From: Kent M Pitman
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <sfwn0y4xwy3.fsf@shell01.TheWorld.com>
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@sevak.isi.edu>, ···@sevak.isi.edu (Thomas
> A. Russ) wrote:
>
> > 5. Alists can use arbitrary comparison predicates, unlike hash tables.
>
> Surely that depends on the particular implementation of hash tables?
> For example, in Dylan you can make user-defined hash tables merely by
> using <table> as a base class and adding an appropriate method to the
> table-protocol GF (which returns a key hashing function and a key
> comparison predicate).
How hard are hashing functions to write? Surely not as easy as
writing comparison predicates? So the term "merely" seems vaguely out
of place here. The sheer mechanics looks to me like triple the work
just to start with, leaving aside the difficulty of making sure one's
hash function is good enough that it doesn't force all the data into
one bucket, destroying the expected distribution. I know we
considered doing this for CL and it looked hard enough that various
people involved didn't want to move ahead on this; I don't recall the
details of why, though. My guess is probably we _should_ have allowed the
capability even if it's painful, for the sake of generality, but even with
it there, I'm not sure I'd be able to say that this makes alists and hash
tables just as easy to use; plainly writing two functions is more work than
writing one.
> Anyone who wants to extend CL in that direction would probably be well
> advised to take a look at how it works in Dylan. Same goes for the
> "ref" macro, too, which is standard Dylan (called "element" and
> "element-setter") and works on all collections, whether sequences (key
> is a natural number) or explicit key collections (trees, hash tables).
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > In article <···············@sevak.isi.edu>, ···@sevak.isi.edu (Thomas
> > A. Russ) wrote:
> >
> > > 5. Alists can use arbitrary comparison predicates, unlike hash
> > > tables.
> >
> > Surely that depends on the particular implementation of hash tables?
> > For example, in Dylan you can make user-defined hash tables merely by
> > using <table> as a base class and adding an appropriate method to the
> > table-protocol GF (which returns a key hashing function and a key
> > comparison predicate).
>
> How hard are hashing functions to write? Surely not as easy as
> writing comparison predicates? So the term "merely" seems vaguely out
> of place here. The sheer mechanics looks to me like triple the work
> just to start with, leaving aside the difficulty of making sure one's
> hash function is good enough that it doesn't force all the data into
> one bucket, destroying the expected distribution.
It's made considerably easier when you have ready access to:
- the hashing functions used by the standard library hash table types
(e.g. ID-hash, string hash, value hash), and
- standard built-in functions for combining hash values
Of course you *could* just get completely unlucky and find everything
hashing into the same bucket, but a) that can happen anyway no matter
how clever your hash function is, and b) it's easy and cheap for an
implementation to detect that and expand the table to the next higher
number of buckets, which will spread the values out unless you were *so*
unlucky that everything hashed to the exact same value and not just the
same bucket.
Here's the complete source code in Gwydion Dylan for <string-table>, a
class not in the DRM but standardized between Gwydion and Harlequin's
"common Dylan".
define class <string-table> (<value-table>)
end class <string-table>;
define method table-protocol (ht :: <string-table>)
=> (key-test :: <function>, key-hash :: <function>);
values(\=, string-hash);
end method table-protocol;
define inline method string-hash
(s :: <string>, initial-state :: <hash-state>)
=> (id :: <integer>, state :: <hash-state>);
sequence-hash(value-hash, s, initial-state);
end method string-hash;
define function sequence-hash
(element-hash :: <function>, seq :: <sequence>,
initial-state :: <hash-state>)
=> (id :: <integer>, state :: <hash-state>);
let (current-id, current-state) = values(0, initial-state);
for (elt in seq)
let (id, state) = element-hash(elt, current-state);
let captured-id = merge-hash-ids(current-id, id, ordered: #t);
current-id := captured-id;
current-state := state;
end for;
values(current-id, current-state);
end function sequence-hash;
"value-hash" is a Generic Function defined in the runtime library and
with predefined methods for integers, floats, chars, booleans, symbols,
and pointer-based objects.
"merge-hash-ids" is a standard function in the runtime library.
-- Bruce
From: Raymond Toy
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <4nbseqjpzd.fsf@rtp.ericsson.se>
>>>>> "Erik" == Erik Naggum <····@naggum.net> writes:
Erik> Copyright notice: Copyright � 2002 Erik Naggum. The code may be used to
Erik> create commercial products without charge or other license provided that
Erik> the author is credited in each source file that uses it or the syntax it
Erik> allows. Creation of derivative works is permitted under two conditions:
Erik> No rewrites to use if* or not to use loop are allowed, and the author
I don't quite follow the wording here. I think you're saying that any
of the following is forbidden:
1. rewrite this to use if*
2. rewrite this not to use loop
Right?
Ray
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222681122640264@naggum.net>
* Ed L Cashin <·······@uga.edu>
| Also, I remember thinking that lisp looked like "text vomit" compared
| to languages whose structure lexically mirrors what's going on.
It appears warranted by the various reactions people have posted and told
of elsewhere to conclude that Common Lisp is a language that is better
suited for those who are more verbal than visual in how they remember and
learn. Those who are more visual, tend to be thrown off by the lack of
visual clues and the preponderance of words they need to recognize in
order to "see" the structure. The verbal, who recognize words the way
the visual see pictures and figures, have no such problem.
However, since XML and the like is not the disaster it should have been,
I guess that either those who use it are completely clueless verbally as
well as visually (95% chance of being true) or people can learn to be
more verbal even if they are "naturally" visual (5% chance of being true).
This is not to imply that those who are more verbal than visual are
superior beings, but they are clearly more suited to certain tasks than
those who are more visual.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Tim Bradshaw
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <ey3it905gt2.fsf@cley.com>
* Erik Naggum wrote:
> It appears warranted by the various reactions people have posted and told
> of elsewhere to conclude that Common Lisp is a language that is better
> suited for those who are more verbal than visual in how they remember and
> learn. Those who are more visual, tend to be thrown off by the lack of
> visual clues and the preponderance of words they need to recognize in
> order to "see" the structure. The verbal, who recognize words the way
> the visual see pictures and figures, have no such problem.
I think this is an interesting point. However I'm not sure it's right
or at least not uniquely right. I think I'm a terribly visual person
(although I also can read). Whenever I write systems in Lisp (or any
other language, but my only recent experience of non-trivial systems
is Lisp), I end up with a huge mass of throwaway `browser'-type tools
which show me pictures of the various structures in the system. I
find it fairly hard to work without these tools. One of the beauties
of Lisp, for me, is that it's so good at talking about complex data
structures, and that typically it's easy to get pictures of these
things of various kinds.
--tim
From: Gareth McCaughan
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <slrna6or63.1d97.Gareth.McCaughan@g.local>
Tim Bradshaw wrote:
> * Erik Naggum wrote:
>
> > It appears warranted by the various reactions people have posted and told
> > of elsewhere to conclude that Common Lisp is a language that is better
> > suited for those who are more verbal than visual in how they remember and
> > learn. Those who are more visual, tend to be thrown off by the lack of
> > visual clues and the preponderance of words they need to recognize in
> > order to "see" the structure. The verbal, who recognize words the way
> > the visual see pictures and figures, have no such problem.
>
> I think this is an interesting point. However I'm not sure it's right
> or at least not uniquely right. I think I'm a terribly visual person
> (although I also can read).
[etc]
Whereas I'm a visually terrible person :-), so according to Erik's
criterion it makes sense that I like Lisp; but I also find visual
tricks like syntax-colouring extremely helpful, in Lisp and also in
other languages. (Maybe I find those tricks helpful *because* I'm
not very visual; perhaps if my visual subsystem worked better it
would do those jobs unaided.)
And, despite being very "verbal", I do find that sometimes the
"verbosity" of Lisp bothers me. I don't think I've yet found an
instance where it's (1) genuine verbosity and (2) not easily
fixed with a bit of macrology or read-table manipulation; but
it can still cause discomfort. It's possible that the discomfort
is a useful signal that macrology might be in order.
*
Example: Earlier in the thread, someone posted a comparison between
two code snippets, one in Ruby and one in Lisp. Both had the form:
build a hash table containing known keys and values, then iterate
over it. The Ruby code was shorter and allegedly clearer. (I find
the ambiguous use of curly brackets in Ruby disagreeable, but never
mind that.) And it's true: the CL code is verbose and hard to read.
But, if you're doing a lot of that sort of thing then it's the work
of a minute (well, OK, five minutes) to write two simple macros so
you can write
(dohash (key value)
(hash ("foo" "bar") ("baz" "quux"))
(format t "~&~A -> ~A.~%" key value))
which seems to me just as clear (to someone with a little Lisp
experience; no one denies that Lisp takes getting used to) as
{"foo" => "bar", "baz" => "quux"}.each {
|key, value|
print key, " -> ", value, "\n"
}
or, for that matter,
for key,value in {"foo": "bar", "baz": "quux"}.items():
print key, "->", value, "\n"
except that FORMAT looks too much like line noise to some readers.
(Compression implies near-randomness.) Again, if you do a lot of
writing sequences of things to *STANDARD-OUTPUT* then it's the
work of another minute or two to write a function so you can say
(dohash (key value)
(hash ("foo" "bar") ("baz" "quux"))
(output key " -> " value #\Newline))
Ruby and Python and all sorts of other languages have advantages
over CL, but brevity and clarity aren't among them unless either
your programs are so short that brevity and clarity don't matter
anyway, or you're deliberately choosing to write CL in a way that
doesn't provide the sort of brevity and clarity you want.
*
(defvar *preferred-hash-test* 'equal)
(defmacro hash (&rest pairs)
(let ((result (gensym)))
`(let ((,result (make-hash-table :test ',*preferred-hash-test*)))
,@(loop for (key value) in pairs collect
`(setf (gethash ,key ,result) ,value))
,result)))
(defmacro dohash ((k v) hform &body body)
`(loop for ,k being each hash-key of ,hform using (hash-value ,v) do
. ,body))
(defun output (&rest values)
(loop for value in values do (princ value)))
--
Gareth McCaughan ················@pobox.com
.sig under construc
From: Holger Schauer
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <whbsesrxg1.fsf@ipanema.coling.uni-freiburg.de>
On Thu, 14 Feb 2002, Erik Naggum wrote:
> * Ed L Cashin <·······@uga.edu>
>| Also, I remember thinking that lisp looked like "text vomit"
>| compared to languages whose structure lexically mirrors what's
>| going on.
I think the structure of Lisp does mirror what's going on.
> It appears warranted by the various reactions people have posted
> and told of elsewhere to conclude that Common Lisp is a language
> that is better suited for those who are more verbal than visual in
> how they remember and learn. Those who are more visual, tend to
> be thrown off by the lack of visual clues and the preponderance of
> words they need to recognize in order to "see" the structure. The
> verbal, who recognize words the way the visual see pictures and
> figures, have no such problem.
I wonder on what basis you draw the conclusion that the distinction is
between verbal and visual and wonder even more about the possible
implications. For instance, a verbal learner should not be thrown off
by code like (member (car (list (do-something here (based on another
complicated computation) ... <bunch of further arguments elided>)))).
This seems counterintuitive to me, I think even experienced Lisp
programmers tend to have (reading) problems with such gross code. [1]
With respect to the more visual oriented, I think what helped me most
was to recognize that there is structure but that parentheses are not
an issue one needs to care about, as long as you do follow it. I think
Graham has an example in his "Ansi CL" book in which he presents some
Lisp code with and without the parens. It's getting the structure that
matters, not the parens. I think, a claim somebody made is likely to
be true across most programming languages, which is that it does not
really matter what style you're following, it's following the style
that matters [2].
But then again, I may be one of those who you would classify as a
visual oriented person, although I tend to see myself as being verbal
oriented. Come to think of it, I'm a very unlikely candidate for
participating in an obfuscated code contest, although I am uncertain
whether that tells a story or doesn't.
Holger
Footnotes:
[1] Some time ago, I made some whitespace modifications to some old
and very ugly looking code. I was not the only one feeling that the
result was much more readable afterwards.
[2] Of course, when you have to follow some style guideline enforced
by external forces, this may throw you off when its totally against
your personal preferences.
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"/home/moehwald > echo "the quick brown fox jumps over the lazy dog" |
tr -d aeiou"
"Jetzt weiss ich endlich, wie ein gewisser A.K. seine Postings erstellt."
-- Sven Geggus in de.comp.os.unix.linux.misc
From: Thom Goodsell
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <7vofist9qg.fsf@shalott.cra.com>
Holger Schauer <··············@gmx.de> writes:
>
> I wonder on what basis you draw the conclusion that the distinction is
> between verbal and visual and wonder even more about the possible
> implications. For instance, a verbal learner should not be thrown off
> by code like (member (car (list (do-something here (based on another
> complicated computation) ... <bunch of further arguments elided>)))).
> This seems counterintuitive to me, I think even experienced Lisp
> programmers tend to have (reading) problems with such gross code. [1]
>
> With respect to the more visual oriented, I think what helped me most
> was to recognize that there is structure but that parentheses are not
> an issue one needs to care about, as long as you do follow it. I think
> Graham has an example in his "Ansi CL" book in which he presents some
> Lisp code with and without the parens. It's getting the structure that
> matters, not the parens. I think, a claim somebody made is likely to
> be true across most programming languages, which is that it does not
> really matter what style you're following, it's following the style
> that matters [2].
>
I don't believe Erik intended to suggest that verbal people can easliy
read poorly formatted code. Rather, lisp code is more about words than
about granting special meaning to every non-text character on your
keyboard. As a simple example, consider array access in Lisp and
C/C++/Java:
(aref *some-array* 10)
vs.
some_array[10];
In C, the braces take the place of "aref" and are easily spotted, even
by someone who has trouble spotting "aref" in a mass of text. Thus,
discounting syntactic characters (parens, semi-colons, and braces), C
code has a lot more non-character symbols than Lisp. The structure is
still important in both cases.
I show the extreme example of a visually-oriented language, but I've
so far managed to avoid learning any Perl.
Thom
--
(map 'string #'(lambda (char) (let ((char-code (char-code char)))
(code-char (if (< 64 char-code 123) (+ (mod (+ 13 char-code) 52) 65)
char-code)))) ····@IXG.IUS")
From: Holger Schauer
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <whpu38qefs.fsf@ipanema.coling.uni-freiburg.de>
On 14 Feb 2002, Thom Goodsell wrote:
> I don't believe Erik intended to suggest that verbal people can
> easliy read poorly formatted code. Rather, lisp code is more about
> words than about granting special meaning to every non-text
> character on your keyboard.
Well, yes, I agree with that largely. I would not go as far as saying
that words don't matter in other languages (but then nobody said that,
either). They do matter, of course, as much as in CL, minus you've got
to get those non-text characters right first :-) Syntax can be pretty
annoying, but after all, it's just syntax, not semantics.
More to the point though, even if, in CL, words matter "more" than
other things, formatting still is an important matter. But formatting,
or structure, is clearly an issue of visually grasping what's going
on. That's an important support to (verbally) understanding code.
I hasten to add (that I believe) that throwing a bunch of non-text
characters all over the place to further enhance such support is
misguided.
> The structure is still important in both cases.
Exactly my point.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"/home/moehwald > echo "the quick brown fox jumps over the lazy dog" |
tr -d aeiou"
"Jetzt weiss ich endlich, wie ein gewisser A.K. seine Postings erstellt."
-- Sven Geggus in de.comp.os.unix.linux.misc
From: Erik Naggum
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3222685224902770@naggum.net>
* Holger Schauer <··············@gmx.de>
| I wonder on what basis you draw the conclusion that the distinction is
| between verbal and visual and wonder even more about the possible
| implications.
Sigh. I wrote:
It appears warranted by the various reactions people have posted and
told of elsewhere to conclude that Common Lisp is a language that is
better suited for those who are more verbal than visual in how they
remember and learn.
| For instance, a verbal learner should not be thrown off by code like
| (member (car (list (do-something here (based on another complicated
| computation) ... <bunch of further arguments elided>)))). This seems
| counterintuitive to me, I think even experienced Lisp programmers tend to
| have (reading) problems with such gross code. [1]
On what basis do you conclude something about what a "verbal learner"
should or should not be thrown off by?
| But then again, I may be one of those who you would classify as a
| visual oriented person
Why do you think this is an either-or issue? When I write "more verbal
than visual" and try to be very clear that we are talking about a point
on a line between two extrama, please do not waste my time by assuming
that only the extrema are worth talking about. Nobody is "classified" as
a visual-oriented person, it is a matter of what you are more comfortable
with, not some one-bit flag in your personality.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
From: Holger Schauer
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <whu1skqf2z.fsf@ipanema.coling.uni-freiburg.de>
On Thu, 14 Feb 2002, Erik Naggum wrote:
> * Holger Schauer <··············@gmx.de>
>| I wonder on what basis you draw the conclusion that the distinction
>| is between verbal and visual and wonder even more about the
>| possible implications.
>
> Sigh. I wrote:
>
> It appears warranted by the various reactions people have posted
> and told of elsewhere to conclude that Common Lisp is a language
> that is better suited for those who are more verbal than visual
> in how they remember and learn.
Yes, I actually read what you wrote but was not sure what exactly the
various reactions have led you to this conclusion, as I have
difficulties -- given what I've read in this thread -- to arrive at
the same.
>| For instance, a verbal learner should not be thrown off by code
>| like (member (car (list (do-something here (based on another
>| complicated computation) ... <bunch of further arguments
>| elided>)))). This seems counterintuitive to me, I think even
>| experienced Lisp programmers tend to have (reading) problems with
>| such gross code. [1]
>
> On what basis do you conclude something about what a "verbal
> learner" should or should not be thrown off by?
Good question. I was in fact just reacting to the second half of your
paragraph, substituting "visual learner" for your "those who are more
visual":
>> Those who are more visual, tend to be thrown off by the lack of
>> visual clues and the preponderance of words they need to
>> recognize in order to "see" the structure. The verbal, who
>> recognize words the way the visual see pictures and figures,
>> have no such problem.
As I said, I was wondering whether my "conclusion" would be a valid
implication of the distinction you put forward. It doesn't seem to be,
though. The question then is whether I'm bashing a strawmen or not (I
don't intend to).
>| But then again, I may be one of those who you would classify as a
>| visual oriented person
>
> Why do you think this is an either-or issue? When I write "more
> verbal than visual" and try to be very clear that we are talking
> about a point on a line between two extrama, please do not waste
> my time by assuming that only the extrema are worth talking about.
> Nobody is "classified" as a visual-oriented person, it is a matter
> of what you are more comfortable with, not some one-bit flag in
> your personality.
Yes, this is certainly true. However, I was wondering whether I'm as
verbal as I think I am and whether that leads me to some fast (and
wrong) conclusions.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"/home/moehwald > echo "the quick brown fox jumps over the lazy dog" |
tr -d aeiou"
"Jetzt weiss ich endlich, wie ein gewisser A.K. seine Postings erstellt."
-- Sven Geggus in de.comp.os.unix.linux.misc
Holger Schauer <··············@gmx.de> wrote in message news:<··············@ipanema.coling.uni-freiburg.de>...
> On Thu, 14 Feb 2002, Erik Naggum wrote:
> > * Ed L Cashin <·······@uga.edu>
> >| Also, I remember thinking that lisp looked like "text vomit"
> >| compared to languages whose structure lexically mirrors what's
> >| going on.
>
> I think the structure of Lisp does mirror what's going on.
>
> > It appears warranted by the various reactions people have posted
> > and told of elsewhere to conclude that Common Lisp is a language
> > that is better suited for those who are more verbal than visual in
> > how they remember and learn. Those who are more visual, tend to
> > be thrown off by the lack of visual clues and the preponderance of
> > words they need to recognize in order to "see" the structure. The
> > verbal, who recognize words the way the visual see pictures and
> > figures, have no such problem.
>
> I wonder on what basis you draw the conclusion that the distinction is
> between verbal and visual and wonder even more about the possible
> implications. For instance, a verbal learner should not be thrown off
> by code like (member (car (list (do-something here (based on another
> complicated computation) ... <bunch of further arguments elided>)))).
> This seems counterintuitive to me, I think even experienced Lisp
> programmers tend to have (reading) problems with such gross code. [1]
>
> With respect to the more visual oriented, I think what helped me most
> was to recognize that there is structure but that parentheses are not
> an issue one needs to care about, as long as you do follow it. I think
> Graham has an example in his "Ansi CL" book in which he presents some
> Lisp code with and without the parens. It's getting the structure that
> matters, not the parens. I think, a claim somebody made is likely to
> be true across most programming languages, which is that it does not
> really matter what style you're following, it's following the style
> that matters [2].
>
> But then again, I may be one of those who you would classify as a
> visual oriented person, although I tend to see myself as being verbal
> oriented. Come to think of it, I'm a very unlikely candidate for
> participating in an obfuscated code contest, although I am uncertain
> whether that tells a story or doesn't.
>
> Holger
It does seem like a "limb" has been rather far "gone out on", here.
>
> Footnotes:
> [1] Some time ago, I made some whitespace modifications to some old
> and very ugly looking code. I was not the only one feeling that the
> result was much more readable afterwards.
>
> [2] Of course, when you have to follow some style guideline enforced
> by external forces, this may throw you off when its totally against
> your personal preferences.
Eric Moss <········@alltel.net> wrote in message news:<················@alltel.net>...
> zaphod wrote:
> >
> > My idea of the perfect language would be something like any of the
> > four following:
> >
> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > turtle-graphics
> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > 3)lisp without so many parentheses
> > 4)C without structured programming concepts
> >
> > Anyone got a good candidate?
>
> Yes.
>
> Common Lisp comes closest for you, despite your loathing of
> parentheses. First off, your dislikes wrt the other languages appear to
> be structural and therefore unavoidable. Your beef with Lisp appears to
> be cosmetic. That is least problematic when it comes to making a
> working piece of code.
>
> Addressing the parentheses phobia, which I see in other students in my
> AI course, I say several things.
>
> Firstly, parentheses are actually a necessity. You have to have *some*
> delimiter in a language, after all, and it can't be just whitespace.
>
> Secondly, parentheses are an *advantage* over other delimiters. Note
> that C uses {} and ; and " " and ",", so it only *appears* to not be
> full of delimiters. Lisp is far more elegant, separating tokens with
> whitespace and expressions with ().
>
> Thirdly, with a good editor, the parentheses become minor blips on your
> screen, and the indentation (which is orthogonal to what makes parsing
> easy for the compiler) can be your guide. If you wanted, you could even
> customize the indentation, although lots of experience indicates that
> emacs does just fine.
>
> To summarize, Lisp appears to have everything you want except for its
> cosmetic "flaw", which isn't really a flaw. That can be gotten past
> with experience or editor-tinkering. All the other languages have major
> structural issues that can't be avoided.
>
>
> Or something like that...
>
> Eric
From experience (very little, but it don't take more)it is not just
cosmetic to me! If it were just a matter of making sure you close all
of your parentheses; that would be fine (i've figured that out, just
close with a zero, on a count-down from all open parentheses), but the
problem is, I think you have to know the whole damned kit-and kaboodle
to know WHEN to open, and WHEN to close; either that or I have yet to
find anything that adresses the idea behind the opening and closing of
them.
From: Marc Spitzer
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <slrna6mfkg.uqe.marc@oscar.eng.cv.net>
In article <····························@posting.google.com>, zaphod wrote:
> Eric Moss <········@alltel.net> wrote in message news:
> <················@alltel.net>...
>> zaphod wrote:
>
> From experience (very little, but it don't take more)it is not just
> cosmetic to me! If it were just a matter of making sure you close all
> of your parentheses; that would be fine (i've figured that out, just
> close with a zero, on a count-down from all open parentheses), but the
> problem is, I think you have to know the whole damned kit-and kaboodle
> to know WHEN to open, and WHEN to close; either that or I have yet to
> find anything that adresses the idea behind the opening and closing of
> them.
Here are the rules that work for me, a begining lisper working on small
stuff, probably not the real reason but it has worked so far:
name ; it gets evaled no parens
(function_name ; it get evaled as a function, because it is the first
; thing that lisp sees after a open paren
Some thing like cond conditions or let apear different, they start with 2
parens, but that is because there is some stuff going on behind the seens.
With cond I think the first form is just checked for a boolena return value
so you need to scope what is checlked by wrapping it in a set of parens,
unless you are checking the value of a varable then you can just type it.
There I have contradicted my self, it is time to shut up now.
so the short answer is when you need a function use a paren and when it is
done close it.
good luck
marc
Eric Moss <········@alltel.net> wrote in message news:<················@alltel.net>...
> zaphod wrote:
> >
> > My idea of the perfect language would be something like any of the
> > four following:
> >
> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > turtle-graphics
> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > 3)lisp without so many parentheses
> > 4)C without structured programming concepts
> >
> > Anyone got a good candidate?
>
> Yes.
>
> Common Lisp comes closest for you, despite your loathing of
> parentheses. First off, your dislikes wrt the other languages appear to
> be structural and therefore unavoidable. Your beef with Lisp appears to
> be cosmetic. That is least problematic when it comes to making a
> working piece of code.
>
> Addressing the parentheses phobia, which I see in other students in my
> AI course, I say several things.
>
> Firstly, parentheses are actually a necessity. You have to have *some*
> delimiter in a language, after all, and it can't be just whitespace.
>
> Secondly, parentheses are an *advantage* over other delimiters. Note
> that C uses {} and ; and " " and ",", so it only *appears* to not be
> full of delimiters. Lisp is far more elegant, separating tokens with
> whitespace and expressions with ().
>
> Thirdly, with a good editor, the parentheses become minor blips on your
> screen, and the indentation (which is orthogonal to what makes parsing
> easy for the compiler) can be your guide. If you wanted, you could even
> customize the indentation, although lots of experience indicates that
> emacs does just fine.
>
> To summarize, Lisp appears to have everything you want except for its
> cosmetic "flaw", which isn't really a flaw. That can be gotten past
> with experience or editor-tinkering. All the other languages have major
> structural issues that can't be avoided.
>
>
> Or something like that...
>
> Eric
Is it appropriate to call parens in lisp "cosmetic"? They have been a
feature in every lisp since the get-go; they make lisp the only
language based on a math (set theory[this is that I know of]), they
are part of how the language operates, to a quite large extent. In
essence, they are a key part of the language. They are more than
cosmetic. Even if their importance was limmited to just closing all
open parens, I would have no problem, since I know that trick. That
it is more than that is the difficult part, and I am betting that CL
has made it more difficult than in earlier dialects. I am guessing
that one of CL's weaknesses, is that it is more difficult to learn
than many earlier dalects may have been. Eliminating some of lisps
eccentricities may have even been mistake. Who does this serve? I
think it serves people who learned lisp, and then came to appreciate
other languages, and few else; becouse Lisps eccentricities are
remembered by the beginner, precisely FOR their eccentricness, and
they are beloved by the lisp loyalists. That; I suppose, is the crux
of why CL seems a little turn-coat to me. I am being slightly
trollish here, I suppose.
From: Eric Moss
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <3C77DD1A.3F4F44DA@alltel.net>
zaphod wrote:
> Is it appropriate to call parens in lisp "cosmetic"?
No--your *complaint* appeared to be cosmetic in nature. Therefore it's
something you can overcome with tools like emacs; that, as opposed to
structural problems which you could not.
This thread is going nowhere, so I will...
Eric
zaphod wrote:
> Is it appropriate to call parens in lisp "cosmetic"?
Yes. definitely. For example, see "Sugar", an alternative reader
for Scheme that uses whitespace-sensitive syntax (like python) -
it is easy to imagine a similar one for common lisp.
It doesn't substantially change the language, just needs to introduce
a "group" keyword to express nested ( )s for some situations.
http://Sugar.mini.dhs.org/
Thus parens are merely a cosmetic feature of the language -
one idea I'm toying with is "fully enclosing" expressions in
pastel-shaded pseudo-3d bevelboxes for a form of syntax highlighting...
Saves your brain having to isolate 'em (or having to (oh, the horror)
mouseover to highlight in emacs)
Here's sugar:
define
fac x
if
= x 0
1
* x
fac
- x 1
Here's the valid scheme translation (a couple too many newlines, perhaps,
to be "standard indenting")
(define
(fac x)
(if
(= x 0)
1
(* x
(fac
(- x 1)))))
The parens have the advantage that I don't _have_ to use
a particular indentation scheme -
(define (fac x) (if (= x 0) 1 (* x (fac (- x 1)))))
In article <···················@news.iol.ie>, David Golden wrote:
> zaphod wrote:
>> Is it appropriate to call parens in lisp "cosmetic"?
>
> Yes. definitely. For example, see "Sugar", an alternative reader
> for Scheme that uses whitespace-sensitive syntax (like python) -
> it is easy to imagine a similar one for common lisp.
>
> It doesn't substantially change the language, just needs to introduce
> a "group" keyword to express nested ( )s for some situations.
>
> http://Sugar.mini.dhs.org/
>
> Thus parens are merely a cosmetic feature of the language -
> one idea I'm toying with is "fully enclosing" expressions in
> pastel-shaded pseudo-3d bevelboxes for a form of syntax highlighting...
> Saves your brain having to isolate 'em (or having to (oh, the horror)
> mouseover to highlight in emacs)
>
> Here's sugar:
>
> define
> fac x
> if
> = x 0
> 1
> * x
> fac
> - x 1
>
> Here's the valid scheme translation (a couple too many newlines, perhaps,
> to be "standard indenting")
>
> (define
> (fac x)
> (if
> (= x 0)
> 1
> (* x
> (fac
> (- x 1)))))
>
> The parens have the advantage that I don't _have_ to use
> a particular indentation scheme -
> (define (fac x) (if (= x 0) 1 (* x (fac (- x 1)))))
I disagree, even in the orignal format the paren using code is much
easier to read. I have more visual clues to use. And parens save you
from scoping whoopsies, you by acedent hit the space/tab/backspace key
when you should not have and thus the meaning of the program changes.
marc
David Golden wrote:
> Here's sugar:
>
> define
> fac x
> if
> = x 0
> 1
> * x
> fac
> - x 1
Ouch. I find this very unpleasant to read, much worse than
the version with parens. And it's not because I'm unused
to indentation-based grouping; I write a lot of Python.
However, I think the following wouldn't be so bad:
define (fac x)
if (= x 0)
1
* x (fac (- x 1))
Does this "Sugar" thing permit that?
--
Gareth McCaughan ················@pobox.com
.sig under construc
Gareth McCaughan wrote:
> However, I think the following wouldn't be so bad:
>
> define (fac x)
> if (= x 0)
> 1
> * x (fac (- x 1))
>
> Does this "Sugar" thing permit that?
>
Yes, the above works in sugar just how you've written it - the indentation
adds extra parens, parens you already have are respected.
--
Don't eat yellow snow.
David Golden <············@bprnaserr.arg> writes:
> Gareth McCaughan wrote:
>
> > However, I think the following wouldn't be so bad:
> >
> > define (fac x)
> > if (= x 0)
> > 1
> > * x (fac (- x 1))
> >
> > Does this "Sugar" thing permit that?
> >
>
> Yes, the above works in sugar just how you've written it - the indentation
> adds extra parens, parens you already have are respected.
Looks nice, but a bit too Schemish.
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti wrote:
>
> David Golden <············@bprnaserr.arg> writes:
>
> > Gareth McCaughan wrote:
> >
> > > However, I think the following wouldn't be so bad:
> > >
> > > define (fac x)
> > > if (= x 0)
> > > 1
> > > * x (fac (- x 1))
> > >
> > > Does this "Sugar" thing permit that?
> > >
> >
> > Yes, the above works in sugar just how you've written it - the indentation
> > adds extra parens, parens you already have are respected.
>
> Looks nice, but a bit too Schemish.
It seems pretty clear that one could do essentially the same thing
for CL.
--
Gareth McCaughan ················@pobox.com
.sig under construc
················@pobox.com (Gareth McCaughan) writes:
> Marco Antoniotti wrote:
> >
> > David Golden <············@bprnaserr.arg> writes:
> >
> > > Gareth McCaughan wrote:
> > >
> > > > However, I think the following wouldn't be so bad:
> > > >
> > > > define (fac x)
> > > > if (= x 0)
> > > > 1
> > > > * x (fac (- x 1))
> > > >
> > > > Does this "Sugar" thing permit that?
> > > >
> > >
> > > Yes, the above works in sugar just how you've written it - the indentation
> > > adds extra parens, parens you already have are respected.
> >
> > Looks nice, but a bit too Schemish.
>
> It seems pretty clear that one could do essentially the same thing
> for CL.
Of course... just keeping the Schemers on their toes :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Brian P Templeton
Subject: Re: looking for a language with any of the following 4 charachteristics (all 4 would be nice).
Date:
Message-ID: <87k7t2rkkh.fsf@tunes.org>
······@ureach.com (zaphod) writes:
> Eric Moss <········@alltel.net> wrote in message news:<················@alltel.net>...
>> zaphod wrote:
>> >
>> > My idea of the perfect language would be something like any of the
>> > four following:
>> >
>> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
>> > turtle-graphics
>> > 2)Forth w/out all that OS STUFF, and stack STUFF.
>> > 3)lisp without so many parentheses
>> > 4)C without structured programming concepts
>> >
>> > Anyone got a good candidate?
>>
>> Yes.
>>
>> Common Lisp comes closest for you, despite your loathing of
>> parentheses. First off, your dislikes wrt the other languages appear to
>> be structural and therefore unavoidable. Your beef with Lisp appears to
>> be cosmetic. That is least problematic when it comes to making a
>> working piece of code.
>>
>> Addressing the parentheses phobia, which I see in other students in my
>> AI course, I say several things.
>>
>> Firstly, parentheses are actually a necessity. You have to have *some*
>> delimiter in a language, after all, and it can't be just whitespace.
>>
>> Secondly, parentheses are an *advantage* over other delimiters. Note
>> that C uses {} and ; and " " and ",", so it only *appears* to not be
>> full of delimiters. Lisp is far more elegant, separating tokens with
>> whitespace and expressions with ().
>>
>> Thirdly, with a good editor, the parentheses become minor blips on your
>> screen, and the indentation (which is orthogonal to what makes parsing
>> easy for the compiler) can be your guide. If you wanted, you could even
>> customize the indentation, although lots of experience indicates that
>> emacs does just fine.
>>
>> To summarize, Lisp appears to have everything you want except for its
>> cosmetic "flaw", which isn't really a flaw. That can be gotten past
>> with experience or editor-tinkering. All the other languages have major
>> structural issues that can't be avoided.
>>
>>
>> Or something like that...
>>
>> Eric
>
> Is it appropriate to call parens in lisp "cosmetic"?
Yes.
[SNIP]
You are *seriously* confusing syntax and semantics here. *Semantics*
are what matter, not syntax. I at least won't reply further in this
thread until you write some useful questions, comments, or
suggestions, instead of posting trollish unsupported complaints based
on misunderstandings.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
In article <····························@posting.google.com>,
······@ureach.com (zaphod) wrote:
> My idea of the perfect language would be something like any of the
> four following:
>
> 1)Logo that concentrated on lisp tricks and didn't even HAVE
> turtle-graphics
> 2)Forth w/out all that OS STUFF, and stack STUFF.
> 3)lisp without so many parentheses
> 4)C without structured programming concepts
>
> Anyone got a good candidate?
Well, to respond to exactly what you've asked for, I'd recommend Dylan
(which is a descendant of lisp with infix syntax) or ML (which is a
functional programming language with infix syntax, although it may seem
more weird to you than Dylan).
For Dylan, see the pages of the two implementations:
http://www.gwydiondylan.org (the open source implementation)
http://www.fun-o.com (the commercial implementation)
A web search should suffice for finding out stuff about ML (I've found
that when doing web searches about Dylan, I find lots of out of date
pages, so you have to know where to look to find the decent information).
>
> I'll even let you tell me how dumb I am for wanting what I want.
> It seems that the common denominator of the four languages I like is
> that they are all extensible, and I think all could be said to have
> charachteristics of functional languages.
Other languages you might want to consider but I can't say much about
are Oz/Mozart, Erlang, Haskell, Mercury, Smalltalk, or Self.
Of course, as plenty of other people have pointed out, the parentheses
in lisp really aren't that much of a problem, and lisp is far more
mature and complete than any of these other languages I've pointed out.
I've found that as I look at the newest features people are adding to
other languages and the problems people are encountering, they all seem
to have been solved in Lisp 20 years ago (that may be a slight
exaggeration, but not much of one).
Actually, though it makes me shudder to recommend it, the feature set of
perl seems to be slowly converging on an infix lisp, but perl is not a
language I'd recommend for anyone who wants anything close to resembling
elegance
>
> Someone could make me extraordinarilly happy by a real nice thorough
> analysis of my essentially stupid and trivial thought(s) here.
--
Brian Campbell
Real email: lambda (at) cs (dot) dartmouth (dot) edu
Brian Campbell <··········@yahoo.com> wrote in message news:<································@merrimack.dartmouth.edu>...
> In article <····························@posting.google.com>,
> ······@ureach.com (zaphod) wrote:
>
> > My idea of the perfect language would be something like any of the
> > four following:
> >
> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > turtle-graphics
> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > 3)lisp without so many parentheses
> > 4)C without structured programming concepts
> >
> > Anyone got a good candidate?
>
> Well, to respond to exactly what you've asked for, I'd recommend Dylan
> (which is a descendant of lisp with infix syntax) or ML (which is a
> functional programming language with infix syntax, although it may seem
> more weird to you than Dylan).
>
> For Dylan, see the pages of the two implementations:
> http://www.gwydiondylan.org (the open source implementation)
> http://www.fun-o.com (the commercial implementation)
>
> A web search should suffice for finding out stuff about ML (I've found
> that when doing web searches about Dylan, I find lots of out of date
> pages, so you have to know where to look to find the decent information).
>
> >
> > I'll even let you tell me how dumb I am for wanting what I want.
> > It seems that the common denominator of the four languages I like is
> > that they are all extensible, and I think all could be said to have
> > charachteristics of functional languages.
>
> Other languages you might want to consider but I can't say much about
> are Oz/Mozart, Erlang, Haskell, Mercury, Smalltalk, or Self.
>
> Of course, as plenty of other people have pointed out, the parentheses
> in lisp really aren't that much of a problem, and lisp is far more
> mature and complete than any of these other languages I've pointed out.
> I've found that as I look at the newest features people are adding to
> other languages and the problems people are encountering, they all seem
> to have been solved in Lisp 20 years ago (that may be a slight
> exaggeration, but not much of one).
>
> Actually, though it makes me shudder to recommend it, the feature set of
> perl seems to be slowly converging on an infix lisp, but perl is not a
> language I'd recommend for anyone who wants anything close to resembling
> elegance
Thank You very much. I'm quite pleased. Have you checked out python, by the way?
>
>
> >
> > Someone could make me extraordinarilly happy by a real nice thorough
> > analysis of my essentially stupid and trivial thought(s) here.