http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton wrote:
> http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
>
Happy Valentine's:
http://www.infoq.com/interviews/mccarthy-elephant-2000
Jeez, Paul Graham should have done Eek (E2K) not Arc. Paul or Mark, Qi
would be the perfect platform.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton wrote:
>
>
> Ken Tilton wrote:
>> http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
>>
>
> Happy Valentine's:
>
> http://www.infoq.com/interviews/mccarthy-elephant-2000
>
> Jeez, Paul Graham should have done Eek (E2K) not Arc. Paul or Mark, Qi
> would be the perfect platform.
>
> kenny
>
"So, in that respect Ruby still isn�t up to where Lisp was in 1960."
That's exactly the point. All the new languages don't get to the core of
Lisp!
??>>
http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
??>>
KT> Happy Valentine's:
KT> http://www.infoq.com/interviews/mccarthy-elephant-2000
KT> Jeez, Paul Graham should have done Eek (E2K) not Arc. Paul or Mark, Qi
KT> would be the perfect platform.
you seem to be a person who understood what Elephant is, so maybe you can
explain what does it mean?
references to the past.. isn't it same thing as persistence lib?
we actally have a library called elephant, doing CLOS persistence. i.e. you
call make-instance, and then this instance is persistent -- you can find it
via slot or something.
well, he speaks about compiler inventing data structures for you.. ok, we
can have RDF database -- so statements about objects are recorded in a form
of triples, and you can search for them in various ways, or access
properties in object-oriented fashion.. how is this different from
Elephant's references to the past?
he also said about commitments.. but i cannot understand how language can
have (and why should it) commitments as first-class objects to work with..
i've tried to read the paper, twice, but failed to understand what is it
about..
Alex Mizrahi wrote:
> ??>>
> http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
> ??>>
> KT> Happy Valentine's:
>
> KT> http://www.infoq.com/interviews/mccarthy-elephant-2000
>
> KT> Jeez, Paul Graham should have done Eek (E2K) not Arc. Paul or Mark, Qi
> KT> would be the perfect platform.
>
> you seem to be a person who understood what Elephant is, so maybe you can
> explain what does it mean?
What part of "I am just a simple application programmer" did you not
understand? :) My thinking is that JM has been right before in quite a
big way, he might be right again, and he *is* still talking about e2k so
it is worth a look.
>
> references to the past.. isn't it same thing as persistence lib?
Not if you throw away information! If a banking application persisted
only my current balance (silly example) then it could not answer
questions about the past. A better example might be an usual requirement
of the clinical data manager I did -- FDA rules required we never throw
away information. Users felt like they were correcting mistakes in the
patient data recorded, but what they were really doing was adding
"change" instances atop "original" data instances. Something like that.
I guess that is pretty close to McCarthy's example: having a reservation
means (a) having made a reservation in the past and (b) not having
cancelled it, meaning we have recorded a "reserve" and not recorded a
corresponding "cancel".
> we actally have a library called elephant, doing CLOS persistence.
Could be a coincidence, could be a playful tip of the hat, might have
been the start of work on e2k, might have... I dunno, I did not see e2k
mentioned on their site, you could try the list.
> i.e. you
> call make-instance, and then this instance is persistent -- you can find it
> via slot or something.
> well, he speaks about compiler inventing data structures for you.. ok, we
> can have RDF database --
Yeah, baby! RDF, my new passion. I will be starting on e2k today since
by coincidence (there are no such things) I just happened to have turned
up the heat on TripleCells.
> so statements about objects are recorded in a form
> of triples, and you can search for them in various ways, or access
> properties in object-oriented fashion.. how is this different from
> Elephant's references to the past?
I may have answered that above, but the mechanics of data storage are
just that, mechanics. The important thing (as best I can make out with
by my poor wits) is to view data as a time stream.
Funny thing is that I had been thinking along the same lines as a
solution to the problems I imagine with threaded/parallel Cells. Does
everyone have to wait on everyone to catch up with the current clock
cycle before continuing, as my current definition of data integrity
entails? or can we do one of those general relativity deals where chunks
of data are allowed to fall behind and catching up is required only when
two chunks of data want to get together on something? In which case a
place (in the Lisp sense) must be a time stream of values so someone
running behind still has the past information to work with.
>
> he also said about commitments.. but i cannot understand how language can
> have (and why should it) commitments as first-class objects to work with..
That would be by JM's example so two planes in flight do not bang into
each other. Tho from what I have read lately all the excitement seems to
be on the ground with taxiing planes moseying across runways on which
other planes happen to be landing. Not good.
> i've tried to read the paper, twice, but failed to understand what is it
> about..
What I see is a bet by McCarthy that we can use distinctions like
illocution vs. perlocution to get (a) a somewhat natural language
interface without solving strong AI to (b) more powerful automated
systems, by which I mean they can better automate things like keeping
airplanes apart.
Re (a) one of my favorite quotes from the interview he mentions a system
useable by children and generals, so we can't have the user posing
questions with a screwy syntax like Qi.
Re (b) sure we have automated systems which start screeching at pilots
when things take a turn for the ugly, but who knows what happens next.
One crew got distracted by a balky landing gear and flew a jetliner into
the ground -- well, the swamp, the Everglades. As far as I could make
out, the screeching would be the illocutionary act meaning all that has
been accomplished is that the announcement has been made, while the
perlocutionary act would be getting the pilots to react. By
distinguishing the two we get an aha moment. The overall systems
developer suddenly realizes, hang on, all we have done so far is
announce the low altitude situation, we have not accomplished the
perlocution which is what we are after. Hmmm, how can we ascertain
compliance by the flight crew? Then, should they not respond, what else
can we automate? The bet as I see it is that more effective systems
emerge when we express these linguistic distinctions as programming
language primitives. By the by, I just said "linguistic" but this
passage was a hoot:
Meanwhile, no one has offered a guess to something I posed in a blog
comment: can anyone figure out what McCarthy said during the interview
that I found most astonishing and impressive? Hints: it was while
answering the interviewer's question about Ruby.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Wed, 27 Feb 2008 13:46:12 -0500, Ken Tilton
<···········@optonline.net> wrote:
>Alex Mizrahi wrote:
>
>> references to the past.. isn't it same thing as persistence lib?
>
>Not if you throw away information! If a banking application persisted
>only my current balance (silly example) then it could not answer
>questions about the past. A better example might be an usual requirement
>of the clinical data manager I did -- FDA rules required we never throw
>away information. Users felt like they were correcting mistakes in the
>patient data recorded, but what they were really doing was adding
>"change" instances atop "original" data instances. Something like that.
Not exactly. I've also done FDA certified apps (for pharmaceutical
manufacture). The FDA requires an audit trail ... not "original +
changes" but rather "current + history". The SEC and IRS have similar
rules for financial and banking apps.
George
--
for email reply remove "/" from address
Ken Tilton <···········@optonline.net> writes:
> [...]
> Meanwhile, no one has offered a guess to something I posed in a blog
> comment: can anyone figure out what McCarthy said during the interview
> that I found most astonishing and impressive? Hints: it was while
> answering the interviewer's question about Ruby.
The point is the video is only viewable with closed proprietary software.
Please, post an url to the video in a standard format.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>>[...]
>>Meanwhile, no one has offered a guess to something I posed in a blog
>>comment: can anyone figure out what McCarthy said during the interview
>>that I found most astonishing and impressive? Hints: it was while
>>answering the interviewer's question about Ruby.
>
>
> The point is the video is only viewable with closed proprietary software.
> Please, post an url to the video in a standard format.
>
OK, we can do it in a Hollerith deck or Jacquard loom, what works for you?
Then again, I do not see why you even want to see it, you already have
that sanctimonious glow from using free as in how we defined it software.
To tell you the truth, I am kinda glad you cannot see it, McCarthy also
comes out against proprietary software, I have to install Debian later
today. :(
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 28, 12:08 pm, Ken Tilton <···········@optonline.net> wrote:
> Pascal J. Bourguignon wrote:
> > Ken Tilton <···········@optonline.net> writes:
>
> >>[...]
> >>Meanwhile, no one has offered a guess to something I posed in a blog
> >>comment: can anyone figure out what McCarthy said during the interview
> >>that I found most astonishing and impressive? Hints: it was while
> >>answering the interviewer's question about Ruby.
>
> > The point is the video is only viewable with closed proprietary software.
> > Please, post an url to the video in a standard format.
>
> OK, we can do it in a Hollerith deck or Jacquard loom, what works for you?
>
> Then again, I do not see why you even want to see it, you already have
> that sanctimonious glow from using free as in how we defined it software.
>
> To tell you the truth, I am kinda glad you cannot see it, McCarthy also
> comes out against proprietary software, I have to install Debian later
> today. :(
You're probably joking, but I suggest Ubuntu - nicer for the desktop
and derived from Debian.
Also, regarding your recent comment re: Windows vs. burning 25% of
your time on OS maintenance; the only time I've spent on OS
maintenance in the last 3 years has been to click the little icon to
automatically update my software, and I expect I could have that
automatically done, but I like to take a look at the packages first.
There may be many reasons for you to not use Linux, but I don't think
"time spent on OS maintenance" is one of them. Now I'm only referring
to a development workstation - if you want to sync your Palm, edit
movies, etc. maybe OSX :)
Brian Adkins wrote:
> On Feb 28, 12:08 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Pascal J. Bourguignon wrote:
>>
>>>Ken Tilton <···········@optonline.net> writes:
>>
>>>>[...]
>>>>Meanwhile, no one has offered a guess to something I posed in a blog
>>>>comment: can anyone figure out what McCarthy said during the interview
>>>>that I found most astonishing and impressive? Hints: it was while
>>>>answering the interviewer's question about Ruby.
>>
>>>The point is the video is only viewable with closed proprietary software.
>>>Please, post an url to the video in a standard format.
>>
>>OK, we can do it in a Hollerith deck or Jacquard loom, what works for you?
>>
>>Then again, I do not see why you even want to see it, you already have
>>that sanctimonious glow from using free as in how we defined it software.
>>
>>To tell you the truth, I am kinda glad you cannot see it, McCarthy also
>>comes out against proprietary software, I have to install Debian later
>>today. :(
>
>
> You're probably joking, but I suggest Ubuntu - nicer for the desktop
> and derived from Debian.
Thx, I'll keep it in mind. But I just remembered the one install I did
was of the Knoppix bootable CD, which wrapped Debian.
Yeah, I was joking, time to shutdown and start doing Algebra.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 28, 7:26 pm, Ken Tilton <···········@optonline.net> wrote:
> Brian Adkins wrote:
> > On Feb 28, 12:08 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>Pascal J. Bourguignon wrote:
>
> >>>Ken Tilton <···········@optonline.net> writes:
>
> >>>>[...]
> >>>>Meanwhile, no one has offered a guess to something I posed in a blog
> >>>>comment: can anyone figure out what McCarthy said during the interview
> >>>>that I found most astonishing and impressive? Hints: it was while
> >>>>answering the interviewer's question about Ruby.
>
> >>>The point is the video is only viewable with closed proprietary software.
> >>>Please, post an url to the video in a standard format.
>
> >>OK, we can do it in a Hollerith deck or Jacquard loom, what works for you?
>
> >>Then again, I do not see why you even want to see it, you already have
> >>that sanctimonious glow from using free as in how we defined it software.
>
> >>To tell you the truth, I am kinda glad you cannot see it, McCarthy also
> >>comes out against proprietary software, I have to install Debian later
> >>today. :(
>
> > You're probably joking, but I suggest Ubuntu - nicer for the desktop
> > and derived from Debian.
>
> Thx, I'll keep it in mind. But I just remembered the one install I did
> was of the Knoppix bootable CD, which wrapped Debian.
>
> Yeah, I was joking, time to shutdown and start doing Algebra.
Ok, if McCarthy can't do it, I certainly won't continue the pitch :)
P� Thu, 28 Feb 2008 11:55:34 +0100, skrev Pascal J. Bourguignon
<···@informatimago.com>:
> Ken Tilton <···········@optonline.net> writes:
>> [...]
>> Meanwhile, no one has offered a guess to something I posed in a blog
>> comment: can anyone figure out what McCarthy said during the interview
>> that I found most astonishing and impressive? Hints: it was while
>> answering the interviewer's question about Ruby.
>
> The point is the video is only viewable with closed proprietary software.
> Please, post an url to the video in a standard format.
>
So, It is a standard plug-in so all major browsers can view it.
(I viewed it in Opera)
Or is it so that you have to have access to the software of the viewer to
see the video..
--------------
John Thingstad
Ken Tilton wrote:
> http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
>
> kenny
>
I'd like to discuss this in the newsgroup:
Stever said...
"It's been around fifty years and yet there are really are not that many
libraries for it, particularly GUI and graphic libraries. Sure there are
a few, but not as many as other languages have access to or as well
designed. And what I've seen many of those libraries are not maintained."
I think that is one of the two problems of Lisp. Not enough library
support. The other problem is that there is no progress in the language
standard. Why not a new version of the standard? I mean Sockets and
Threads are not that new!
Hi,
> I think that is one of the two problems of Lisp. Not enough library
> support.
Right. I'm immediately switching back to Java because of that.
...not really.
> The other problem is that there is no progress in the language
> standard. Why not a new version of the standard? I mean Sockets and
> Threads are not that new!
Yeah, just as if C didn't have threads and sockets in the language
standard, nobody could have ever written any network-based
applications in C. Oh, wait...
~ Matthias
> I think that is one of the two problems of Lisp. Not enough library
> support. The other problem is that there is no progress in the language
> standard. Why not a new version of the standard? I mean Sockets and
> Threads are not that new!
i agree that the standard is in some way hindering development of
common lisp, but you don't need a standard for threads and sockets.
just grab portable-threads (part of GBBOpen) and iolib which provides
portable access to raw sockets.
- attila
Michael Bohn wrote:
> Ken Tilton wrote:
>
>> http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
>>
>> kenny
>>
>
> I'd like to discuss this in the newsgroup:
OK, but I just responded on the blog:
"Libraries? A couple of answers here. First of all, CFFI rocks, Lisp
can use any C library. I use a very tight interface to Tcl/Tk, and
others use GTk, tho I have no argument with assertions they could be
better maintained. Commercial Lisps offer nice GUIs and database
wrappers and sometimes great native DBs such as AlllegroCache and
AllegroGraph, it's just the "free software" geniuses scraping by with
weak open source libraries. :)
"But my main answer is that in these
intial smug Lisp posts I am talking about the language itself, and that
a great language will (and in this case is) eventually attract the users
needed to produce even solid open source stuff, and then they will be as
better as is Lisp itself because Lisp macros allow more than just
bindings, they allow a higher-level API.
"This should probably be its own blogpost...."
The overarching metamistake is being too good a Buddhist and thinking
only in the present. We have first and second derivatives of popularity
over time to consider. Languages come and go, but one of them
mysteriously came back from the dead and separately had much of the best
parts of its genome copied by other languages.
G*d may be talking to us. :)
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 27, 9:24 am, Ken Tilton <···········@optonline.net> wrote:
> Michael Bohn wrote:
> > Ken Tilton wrote:
>
> >>http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
>
> >> kenny
>
> > I'd like to discuss this in the newsgroup:
>
> OK, but I just responded on the blog:
>
> "Libraries? A couple of answers here. First of all, CFFI rocks, Lisp
> can use any C library. I use a very tight interface to Tcl/Tk, and
> others use GTk, tho I have no argument with assertions they could be
> better maintained. Commercial Lisps offer nice GUIs and database
> wrappers and sometimes great native DBs such as AlllegroCache and
> AllegroGraph, it's just the "free software" geniuses scraping by with
> weak open source libraries. :)
>
> "But my main answer is that in these
> intial smug Lisp posts I am talking about the language itself, and that
> a great language will (and in this case is) eventually attract the users
> needed to produce even solid open source stuff, and then they will be as
> better as is Lisp itself because Lisp macros allow more than just
> bindings, they allow a higher-level API.
>
> "This should probably be its own blogpost...."
>
> The overarching metamistake is being too good a Buddhist and thinking
> only in the present. We have first and second derivatives of popularity
> over time to consider. Languages come and go, but one of them
> mysteriously came back from the dead and separately had much of the best
> parts of its genome copied by other languages.
>
> G*d may be talking to us. :)
>
> kenny
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
can someone explain this?
TimDaly said...
Lisp has two fundamental features.
1) Programs and data are the same.
2) nil eq () eq false
Almost all other programming
languages miss the first features.
Scheme screwed up when the broke
the second feature.
Without these features, it is
not lisp.
Python is just one of thousands
of languages that pretend to be
lisp "without the parens". Python
is a lost cause, its just too young
to bother dying but it will.
On Feb 27, 11:24 am, Ken Tilton <···········@optonline.net> wrote:
> a great language will (and in this case is) eventually attract the users
"a great language is eventually attract the users"
That no make sense.
--
The only good bureaucrat is one with a pistol at his head. Put it in
his hand and it's good-bye to the Bill of Rights.
--- H.L. Mencken
Ken Tilton <·········@gmail.com> wrote:
+---------------
| Languages come and go, but one of them mysteriously
| came back from the dead and separately had much of the
| best parts of its genome copied by other languages.
+---------------
Ah, yezzz...
http://xkcd.com/297/
Lisp Cycles
+---------------
| G*d may be talking to us. :)
+---------------
Oh, well in *that* case, maybe you'd prefer this one:
http://xkcd.com/224/
Lisp
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Ken Tilton <·········@gmail.com> wrote:
> +---------------
> | Languages come and go, but one of them mysteriously
> | came back from the dead and separately had much of the
> | best parts of its genome copied by other languages.
> +---------------
>
> Ah, yezzz...
>
> http://xkcd.com/297/
> Lisp Cycles
>
> +---------------
> | G*d may be talking to us. :)
> +---------------
>
> Oh, well in *that* case, maybe you'd prefer this one:
>
> http://xkcd.com/224/
> Lisp
>
Well, I gotta tell you, I am a bit of a fan of comedy and have studied
up on it a little -- if you are in the mood for a mindf*ck, download the
audio of zany Jerry Lewis discussing the craft of comedy -- and there
are a lot of technical flaws in that work, all of which make it terribly
unfunny. The only good bit was "My god, it's full of 'car's" and he
spoiled that with the quotes around car. Always leave some work for the
audience (and if they do not know what CAR is the quotes won't help
anyway. Maybe capitalizing it would have worked. As for the punch line,
every pro emphasizes the need to eliminate words. Jack Benny talked
about working with his writing staff to cut just one word. The laugh
response is a surprise, just as is the one-punch knockout -- doesn't
happen if you see the punch coming, and too many words tell us "Here
comes the joke any minute now don't go away are you ready this is it!"
The last frame has been set up by Sticky exclaiming the Gods must have
used Lisp. Then in that last frame we get three separate speeches,
unheard of in good strips. The first speech:
"No, it's not."
Great a tense error (after the setup "Truly this was the language..."),
breaking the momentum like a speed bump. Speaking of speed bumbs, Jerry
Seinfeld will not even finish a joke if he makes a mistake in the
delivery -- he said the audience will beg him to finish the joke anyway!
but he explains it simply cannnot be done, and I think anyone who has
blown a joke but finished it anyway knows what he means. Getting back to
the tense error, he did not even have to go there, all he had to do was
have the god say, "Nope.".
"It's not?", says Sticky, adding words that do nothing for the punch
line. Cut! Cut! Cut! A simple surprised look or ? would do, tho nothing
is really needed. Then:
"I mean, ostensibly, yes." Well aside from the needless commas, who
needs the verbiage and illogic? He is headed for the "Perl" punch line,
what does this add? And what on Earth does it mean? Where is the logic?
There is something apparent about the universe that makes it seem like
Lisp must have been used? War? Disease? Bush?
"Honestly,..." Wrong word. He meant to say, "To tell you the truth,.."
which sounds the same but is not, it carries with it "Sorry for the
letdown", but then look what is being done, you are giving away the
premise, that something ordinary was used. We want to crash into a joke
like a wall, he is building a ramp to the top. We'll end up at the same
place (Perl was used) but without a jolt.
"...we hacked most of it together with Perl". Words, words, words. As an
exercise, create six to ten increasingly shorter punch lines until you
get to: "Perl".
But that won't work. That is just a premise. You need something after
that that would actually be the surprise, the joke.
It could go either way, putting down Perl:
"No, Perl. Remember Hitler?"
...or putting down Lisp:
"No, Perl. ________________"
Contest closes at midnight GMT.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 28, 10:58 am, Ken Tilton <···········@optonline.net> wrote:
>
> "No, Perl. ________________"
>
"We lost the documentation on quantum mechanics. You'll have to
decode the regexes yourself." Who knew the img tag had a title
attribute.
You're getting too used to defending Lisp - the comic is an attack on
Perl.
On Feb 28, 4:30 pm, Scott <·······@gmail.com> wrote:
> "We lost the documentation on quantum mechanics. You'll have to
> decode the regexes yourself." Who knew the img tag had a title
> attribute.
Cool. I never noticed that before.
Scott wrote:
> On Feb 28, 10:58 am, Ken Tilton <···········@optonline.net> wrote:
>
>> "No, Perl. ________________"
>>
>
>
>
> "We lost the documentation on quantum mechanics. You'll have to
> decode the regexes yourself." Who knew the img tag had a title
> attribute.
>
> You're getting too used to defending Lisp - the comic is an attack on
> Perl.
>
Scot, you ignorant slut. The subject is comedy, not language wars. Do
try to keep up.
Come to think of it, does Perl /ever/ get into flamewars? Java, Scheme,
Python, OCaml -- sure, but Perl? Is that because it never tried to crawl
out of the primordial ooze of scripting to walk upright on dry land?
Seems to me that was Python's mistake.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 28, 2:57 pm, Ken Tilton <···········@optonline.net> wrote:
>
> Scott, you ignorant slut.
>
:-)
> Come to think of it, does Perl /ever/ get into flamewars? Java, Scheme,
> Python, OCaml -- sure,
Ocaml wars? One guy waving a purple plastic sword doesn't count as a
war...
>
> but Perl? Is that because it never tried to crawl
> out of the primordial ooze of scripting to walk upright on dry land?
>
There is an oozy ball of organic material called Perl 6 trying to
sprout appendages. Maybe they'll join in after that.
>
> Seems to me that was Python's mistake.
>
only one mistake eh...
On Feb 28, 5:25 pm, Scott <·······@gmail.com> wrote:
> Ocaml wars? One guy waving a purple plastic sword doesn't count as a
> war...
Thanks for that image :)
On Feb 28, 11:25 pm, Scott <·······@gmail.com> wrote:
> > Come to think of it, does Perl /ever/ get into flamewars? Java, Scheme,
> > Python, OCaml -- sure,
>
> Ocaml wars? One guy waving a purple plastic sword doesn't count as a
> war...
Great job Scot:) added to my favourite quotes.
Slobodan
Ken Tilton <···········@optonline.net> writes:
> Scot, you ignorant slut. The subject is comedy, not language wars. Do
> try to keep up.
>
> Come to think of it, does Perl /ever/ get into flamewars? Java,
> Scheme, Python, OCaml -- sure, but Perl? Is that because it never
> tried to crawl out of the primordial ooze of scripting to walk upright
> on dry land? Seems to me that was Python's mistake.
Hey now. Perl is actually pretty capable. It just looks amazingly ugly
and "organically grown".
Also, everybody young and blind to the problems of his "language of
choice" enough to get into flamewars is probably using Ruby nowadays. It
has all the problems that perl has (and a few extra), but it looks
nicer.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
On Feb 28, 4:10 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
> Also, everybody young and blind to the problems of his "language of
> choice" enough to get into flamewars is probably using Ruby nowadays.
The evidence proves that users of COMMON-LISP surpass everyone else in
their zealous, religious, and fanatical defense of their language.
To them, it is truly a holy war.
--
Common Lisp is a significantly ugly language. If Guy and I had been
locked
in a room, you can bet it wouldn't have turned out like that.
--- Dick Gabriel
On Feb 28, 5:49 pm, William James <·········@yahoo.com> wrote:
> On Feb 28, 4:10 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
>
> > Also, everybody young and blind to the problems of his "language of
> > choice" enough to get into flamewars is probably using Ruby nowadays.
>
> The evidence proves that users of COMMON-LISP surpass everyone else in
> their zealous, religious, and fanatical defense of their language.
> To them, it is truly a holy war.
I don't know about that. They may have a better sense of humor though
- although subtle and dry at times ...
William James <·········@yahoo.com> writes:
> On Feb 28, 4:10 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
>> Also, everybody young and blind to the problems of his "language of
>> choice" enough to get into flamewars is probably using Ruby nowadays.
>
> The evidence proves that users of COMMON-LISP surpass everyone else in
> their zealous, religious, and fanatical defense of their language.
> To them, it is truly a holy war.
Yup. CL programmers as a group seem to have several magnitudes more of
both paranoia and smugness than any other programmer group I know.
Now I get the smugness. I just don't get the paranioa.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Joost Diepenmaat wrote:
> William James <·········@yahoo.com> writes:
>
>
>>On Feb 28, 4:10 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
>>
>>>Also, everybody young and blind to the problems of his "language of
>>>choice" enough to get into flamewars is probably using Ruby nowadays.
>>
>>The evidence proves that users of COMMON-LISP surpass everyone else in
>>their zealous, religious, and fanatical defense of their language.
>>To them, it is truly a holy war.
>
>
> Yup. CL programmers as a group seem to have several magnitudes more of
> both paranoia and smugness than any other programmer group I know.
>
> Now I get the smugness. I just don't get the paranioa.
>
Are you saying there isn't a second key to the strawberries?
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Joost Diepenmaat <·····@zeekat.nl> writes:
>
> Yup. CL programmers as a group seem to have several magnitudes more of
> both paranoia and smugness than any other programmer group I know.
>
Nah, Smalltalkers are both more smug and more annoying about it. Especially
if you run into one of the ones that used a Smalltalk-80 computer system.
Those morons will scream and moan and try to bruise both your shins if you
even mention the word 'filesystem'. (Apparently, theirs was never completed.)
Joost Diepenmaat wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Scot, you ignorant slut. The subject is comedy, not language wars. Do
>>try to keep up.
>>
>>Come to think of it, does Perl /ever/ get into flamewars? Java,
>>Scheme, Python, OCaml -- sure, but Perl? Is that because it never
>>tried to crawl out of the primordial ooze of scripting to walk upright
>>on dry land? Seems to me that was Python's mistake.
>
>
> Hey now. Perl is actually pretty capable.
Oh, I am sure, I was trying to compliment Perl on being sensible enough
to Just Be Perl. Python started out as a scripting language with KISS as
its prime directive. It did very well (congrats!) but then made the
mistake of trying to be a complete HLL.
I mean, have we ever had a Perl vs. Lisp flamewar? Is such a thing
conceivable?
kenny
ps. Tell Scott he still owes me the homework showing how six or more
shorter and shorter variations on the punch line until it just says
"Perl". k
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 28, 4:01 pm, Ken Tilton <···········@optonline.net> wrote:
>
> ps. Tell Scott he still owes me the homework showing how six or more
> shorter and shorter variations on the punch line until it just says
> "Perl". k
>
This was too easy - I should take up being a newsgroup troll. Make
one comment and a dozen folks pop in defending Ruby of all things...
Actually, it's your thread, so you get some credit for being a troll
too, but no one was responding to your suggestion that the xkcd guy do
comedy like Andrew badda-bing-short-one-liners Dice Clay. Still
you're right, no Perl zealots anywhere to be seen.
Actually, maybe Larry Wall's comments count:
"By policy, LISP has never really catered to mere mortals. And,
of course, mere mortals have never really forgiven LISP for not
catering to them."
"You know, take Lisp. You know, it's the most beautiful language
in the world. [...] But, you know, every program in Lisp is just ugly.
I don't figure how that works."
"Lisp has all the aesthetic appeal of toenail clippings in a bowl
of cold porridge."
On Feb 28, 4:34 pm, Scott <·······@gmail.com> wrote:
> On Feb 28, 4:01 pm, Ken Tilton <···········@optonline.net> wrote:
>
> Actually, maybe Larry Wall's comments count:
>
> "You know, take Lisp. You know, it's the most beautiful language
> in the world. [...] But, you know, every program in Lisp is just ugly.
> I don't figure how that works."
>
> "Lisp has all the aesthetic appeal of toenail clippings in a bowl
> of cold porridge."
This from LARRY WALL??? The same comments from, say, Niklaus Wirth,
or Bertrand Meyer, or even Brian Kernighan might carry some weight.
From Larry Wall it's just trash talk. Friendly trash talk, no
doubt :)
-- Scott
On Mar 1, 10:34 am, Scott Burson <········@gmail.com> wrote:
>
> > Actually, maybe Larry Wall's comments count:
>
> > "You know, take Lisp. You know, it's the most beautiful language
> > in the world. [...] But, you know, every program in Lisp is just ugly.
> > I don't figure how that works."
>
> > "Lisp has all the aesthetic appeal of toenail clippings in a bowl
> > of cold porridge."
>
> This from LARRY WALL??? The same comments from, say, Niklaus Wirth,
> or Bertrand Meyer, or even Brian Kernighan might carry some weight.
> From Larry Wall it's just trash talk. Friendly trash talk, no
> doubt :)
>
> -- Scott
Wirth carries weight? The guy who invented the same ugly BEGIN END
block language 6 times. What Wirth language could you possibly enjoy
programming in?
Ahh Eiffel, as soon as you mention Bertrand Meyer, I get the picture.
You're one of those kinky discipline and bondage guys.
Cheers!
On Sat, 01 Mar 2008 13:43:46 -0800, Scott wrote:
> Ahh Eiffel, as soon as you mention Bertrand Meyer, I get the picture.
> You're one of those kinky discipline and bondage guys.
>
>
> Cheers!
The B&D guys believe that their approach leads to fast, reliable programs
that work first time or close to first time.
I don't think this is true, based on my own experience and watching
projects unfold. I was thinking why this would be the case.
My theory is that adding type information to a program by hand does not
actually add much information to it. If you take out the type information,
you can still tell what the program does:
(defun string-all-upper-case-p (string) ...)
One the other hand if you only have the type information you hardly know
anything:
bool function (char * parameter) {...}
That is to say, type information is very entropy-poor. There are not that
many types of interest at a particular point in a program and so all your
type information tells you very little.
On the other hand, adding type information adds considerable bulk to the
program, all of which has to be correct and consistent, and which has to
be understood when debugging and enhancing the program.
So my argument is that you do a lot of work to add very little information
/ entropy. This is usually a bad trade-off.
I was thinking of firming up this argument by pulling in a large java
project and actually working out the percentage of tokens consumed by type
information, and the percentage of information that they represent. This
would provide a very concrete basis for understanding why B&D style
programming is so unproductive. But then maybe someone else has already
done this and I didn't want to reinvent the wheel. Is anyone aware of
prior work on this?
[When extreme reliability or performance is at stake you may be prepared to
pay the price. With Lisp, you can add the type information for performance
purposes at least, and you can add asserts to guarantee types when it is
important.
Type inference by the compiler is another story. From the programmer's
perspective, it is more or less for free so it's usually worthwhile. Even
here it can sometimes be a nuisance. For example sometimes SBCL complains
about type inconsistencies in functions I know I will never call (it is a
work in progress). I have to fix things that don't matter. Anyway, type
inference is not necessarily a bad thing, it's just costly to make the
programmer provide all the type information always.]
Tim
P� Fri, 29 Feb 2008 00:01:58 +0100, skrev Ken Tilton
<···········@optonline.net>:
>
>
> Joost Diepenmaat wrote:
>> Ken Tilton <···········@optonline.net> writes:
>>
>>> Scot, you ignorant slut. The subject is comedy, not language wars. Do
>>> try to keep up.
>>>
>>> Come to think of it, does Perl /ever/ get into flamewars? Java,
>>> Scheme, Python, OCaml -- sure, but Perl? Is that because it never
>>> tried to crawl out of the primordial ooze of scripting to walk upright
>>> on dry land? Seems to me that was Python's mistake.
>> Hey now. Perl is actually pretty capable.
>
> Oh, I am sure, I was trying to compliment Perl on being sensible enough
> to Just Be Perl. Python started out as a scripting language with KISS as
> its prime directive. It did very well (congrats!) but then made the
> mistake of trying to be a complete HLL.
>
> I mean, have we ever had a Perl vs. Lisp flamewar? Is such a thing
> conceivable?
>
> kenny
>
> ps. Tell Scott he still owes me the homework showing how six or more
> shorter and shorter variations on the punch line until it just says
> "Perl". k
>
Not flamewars per se. But Naggum's long monologs on the subjct.
--------------
John Thingstad
Ken Tilton <···········@optonline.net> writes:
> Joost Diepenmaat wrote:
>> Ken Tilton <···········@optonline.net> writes:
>>
>>
>>>Scot, you ignorant slut. The subject is comedy, not language wars. Do
>>>try to keep up.
>>>
>>>Come to think of it, does Perl /ever/ get into flamewars? Java,
>>>Scheme, Python, OCaml -- sure, but Perl? Is that because it never
>>>tried to crawl out of the primordial ooze of scripting to walk upright
>>>on dry land? Seems to me that was Python's mistake.
>>
>>
>> Hey now. Perl is actually pretty capable.
>
> Oh, I am sure, I was trying to compliment Perl on being sensible
> enough to Just Be Perl. Python started out as a scripting language
> with KISS as its prime directive. It did very well (congrats!) but
> then made the mistake of trying to be a complete HLL.
>
> I mean, have we ever had a Perl vs. Lisp flamewar? Is such a thing
> conceivable?
Can Perl manipulate code as data? Well, Perl 6 will apparently have a
Lisp-like macro contept, <URL:
http://en.wikipedia.org/wiki/Perl_6#Macros >, although there's hardly
a paranthesis in sight.
[...]
--
It's not a bug, it's the future.
Vetle Roeim <·············@gmail.com> writes:
Vetle Roeim <·············@gmail.com> writes:
> Ken Tilton <···········@optonline.net> writes:
>
>> Joost Diepenmaat wrote:
>>> Ken Tilton <···········@optonline.net> writes:
>>>
>>>
>>>>Scot, you ignorant slut. The subject is comedy, not language wars. Do
>>>>try to keep up.
>>>>
>>>>Come to think of it, does Perl /ever/ get into flamewars? Java,
>>>>Scheme, Python, OCaml -- sure, but Perl? Is that because it never
>>>>tried to crawl out of the primordial ooze of scripting to walk upright
>>>>on dry land? Seems to me that was Python's mistake.
>>>
>>>
>>> Hey now. Perl is actually pretty capable.
>>
>> Oh, I am sure, I was trying to compliment Perl on being sensible
>> enough to Just Be Perl. Python started out as a scripting language
>> with KISS as its prime directive. It did very well (congrats!) but
>> then made the mistake of trying to be a complete HLL.
>>
>> I mean, have we ever had a Perl vs. Lisp flamewar? Is such a thing
>> conceivable?
>
> Can Perl manipulate code as data? Well, Perl 6 will apparently have a
> Lisp-like macro contept, <URL:
> http://en.wikipedia.org/wiki/Perl_6#Macros >, although there's hardly
> a paranthesis in sight.
Why do you mention parenthesis at all?
http://groups.google.com/group/comp.lang.lisp/msg/6ec4dab4a8d57f6e
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This machine is a piece of GAGH! I need dual Opteron 850
processors if I am to do battle with this code!"
Pascal Bourguignon <···@informatimago.com> writes:
> Vetle Roeim <·············@gmail.com> writes:
>
> Vetle Roeim <·············@gmail.com> writes:
>
>> Ken Tilton <···········@optonline.net> writes:
>>
>>> Joost Diepenmaat wrote:
>>>> Ken Tilton <···········@optonline.net> writes:
>>>>
>>>>
>>>>>Scot, you ignorant slut. The subject is comedy, not language wars. Do
>>>>>try to keep up.
>>>>>
>>>>>Come to think of it, does Perl /ever/ get into flamewars? Java,
>>>>>Scheme, Python, OCaml -- sure, but Perl? Is that because it never
>>>>>tried to crawl out of the primordial ooze of scripting to walk upright
>>>>>on dry land? Seems to me that was Python's mistake.
>>>>
>>>>
>>>> Hey now. Perl is actually pretty capable.
>>>
>>> Oh, I am sure, I was trying to compliment Perl on being sensible
>>> enough to Just Be Perl. Python started out as a scripting language
>>> with KISS as its prime directive. It did very well (congrats!) but
>>> then made the mistake of trying to be a complete HLL.
>>>
>>> I mean, have we ever had a Perl vs. Lisp flamewar? Is such a thing
>>> conceivable?
>>
>> Can Perl manipulate code as data? Well, Perl 6 will apparently have a
>> Lisp-like macro contept, <URL:
>> http://en.wikipedia.org/wiki/Perl_6#Macros >, although there's hardly
>> a paranthesis in sight.
>
> Why do you mention parenthesis at all?
> http://groups.google.com/group/comp.lang.lisp/msg/6ec4dab4a8d57f6e
Just trying to be funny ... obviously failing. ;(
--
It's not a bug, it's the future.
Vetle Roeim <·············@gmail.com> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> Vetle Roeim <·············@gmail.com> writes:
>>
>> Vetle Roeim <·············@gmail.com> writes:
>>
>>> Ken Tilton <···········@optonline.net> writes:
>>>
>>>> Joost Diepenmaat wrote:
>>>>> Ken Tilton <···········@optonline.net> writes:
>>>>>
>>>>>
>>>>>>Scot, you ignorant slut. The subject is comedy, not language wars. Do
>>>>>>try to keep up.
>>>>>>
>>>>>>Come to think of it, does Perl /ever/ get into flamewars? Java,
>>>>>>Scheme, Python, OCaml -- sure, but Perl? Is that because it never
>>>>>>tried to crawl out of the primordial ooze of scripting to walk upright
>>>>>>on dry land? Seems to me that was Python's mistake.
>>>>>
>>>>>
>>>>> Hey now. Perl is actually pretty capable.
>>>>
>>>> Oh, I am sure, I was trying to compliment Perl on being sensible
>>>> enough to Just Be Perl. Python started out as a scripting language
>>>> with KISS as its prime directive. It did very well (congrats!) but
>>>> then made the mistake of trying to be a complete HLL.
>>>>
>>>> I mean, have we ever had a Perl vs. Lisp flamewar? Is such a thing
>>>> conceivable?
>>>
>>> Can Perl manipulate code as data? Well, Perl 6 will apparently have a
>>> Lisp-like macro contept, <URL:
>>> http://en.wikipedia.org/wiki/Perl_6#Macros >, although there's hardly
>>> a paranthesis in sight.
>>
>> Why do you mention parenthesis at all?
>> http://groups.google.com/group/comp.lang.lisp/msg/6ec4dab4a8d57f6e
>
> Just trying to be funny ... obviously failing. ;(
No, I was dead serrious. Any lisp programmer will confirm you that
visions of parentheses disappear after a few weeks of lisp
programming.
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
Vetle Roeim <·············@gmail.com> writes:
> Ken Tilton <···········@optonline.net> writes:
> [...]
>> I mean, have we ever had a Perl vs. Lisp flamewar? Is such a thing
>> conceivable?
>
> Can Perl manipulate code as data? Well, Perl 6 will apparently have a
> Lisp-like macro contept, <URL:
> http://en.wikipedia.org/wiki/Perl_6#Macros >, although there's hardly
> a paranthesis in sight.
% (sed -e 's/[^][{}()<>]//g'|tr -d '\012'|wc -c) <<EOF
macro hello($what) {
q:code { say "Hello { {{{$what}}} }" };
}
EOF
14
I count 7 pairs of parentheses in this little perl6 macro. (You should
really count one pair more, for the semicolon, but let's not bury the
'competition' too deep).
(defmacro hello (what)
`(format t "Hello ~A~%" ',what))
Only 3 pairs of parentheses in the correponding lisp macro.
--
__Pascal Bourguignon__ http://www.informatimago.com/
WARNING: This product attracts every other piece of matter in the
universe, including the products of other manufacturers, with a
force proportional to the product of the masses and inversely
proportional to the distance between them.
Pascal Bourguignon <···@informatimago.com> writes:
> Vetle Roeim <·············@gmail.com> writes:
>
>> Ken Tilton <···········@optonline.net> writes:
>> [...]
>>> I mean, have we ever had a Perl vs. Lisp flamewar? Is such a thing
>>> conceivable?
>>
>> Can Perl manipulate code as data? Well, Perl 6 will apparently have a
>> Lisp-like macro contept, <URL:
>> http://en.wikipedia.org/wiki/Perl_6#Macros >, although there's hardly
>> a paranthesis in sight.
>
> % (sed -e 's/[^][{}()<>]//g'|tr -d '\012'|wc -c) <<EOF
> macro hello($what) {
> q:code { say "Hello { {{{$what}}} }" };
> }
> EOF
> 14
>
> I count 7 pairs of parentheses in this little perl6 macro. (You should
> really count one pair more, for the semicolon, but let's not bury the
> 'competition' too deep).
Hey, now _you're_ the one mentioning parentheses!
> (defmacro hello (what)
> `(format t "Hello ~A~%" ',what))
>
> Only 3 pairs of parentheses in the correponding lisp macro.
True, but it has backticks and commas, whereas the Perl6 macro has
dollar signs and colons (and strange-looking parentheses).
--
It's not a bug, it's the future.
On Thu, 28 Feb 2008 23:10:13 +0100, Joost Diepenmaat wrote:
> Ken Tilton <···········@optonline.net> writes:
>
> Also, everybody young and blind to the problems of his "language of
> choice" enough to get into flamewars is probably using Ruby nowadays. It
> has all the problems that perl has (and a few extra), but it looks
> nicer.
>
At least one of Perl's problems is not shared by Ruby. Ruby is a pleasure
to learn because it is so regular ("principle of least surprise").
Tim
tim wrote:
> On Thu, 28 Feb 2008 23:10:13 +0100, Joost Diepenmaat wrote:
>
>
>>Ken Tilton <···········@optonline.net> writes:
>>
>>Also, everybody young and blind to the problems of his "language of
>>choice" enough to get into flamewars is probably using Ruby nowadays. It
>>has all the problems that perl has (and a few extra), but it looks
>>nicer.
>>
>
>
> At least one of Perl's problems is not shared by Ruby. Ruby is a pleasure
> to learn because it is so regular ("principle of least surprise").
Oh, I thought Python had that, too. Or was it "one way to do everything"?
btw, slight attribution error abode, looks like I said the quote. No big.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Thu, 28 Feb 2008 18:27:05 -0500, Ken Tilton wrote:
> tim wrote:
>> On Thu, 28 Feb 2008 23:10:13 +0100, Joost Diepenmaat wrote:
>>
>>
>>>Ken Tilton <···········@optonline.net> writes:
>>>
>>>Also, everybody young and blind to the problems of his "language of
>>>choice" enough to get into flamewars is probably using Ruby nowadays. It
>>>has all the problems that perl has (and a few extra), but it looks
>>>nicer.
>>>
>>
>>
>> At least one of Perl's problems is not shared by Ruby. Ruby is a pleasure
>> to learn because it is so regular ("principle of least surprise").
>
> Oh, I thought Python had that, too. Or was it "one way to do everything"?
>
> btw, slight attribution error abode, looks like I said the quote. No big.
>
> kt
>
Well when I was learning Python, I found that every time I guessed
something, I got it wrong. Example:
Length of a list or array. Easy: myarray.length
Bzzzt! Wrong: it is length (myarray)
A lot of people don't like the use of spaces as syntax. I really like them
- I think that is real lateral thinking.
As someone else commented, for those who were used to sed, grep, sed and
sh, perl was definitely a step up and familiar. I suppose if you were used
to drinking methylated spirits, cheap sherry would seem good, too.
There was a talk at the Conference of Australian Linux Users wherein
Anthony Baxter boasted about a) How incompatible the new version of Python
(3.0) is going to be, and b) They are talking all the functional stuff out
like reduce, map, multi-line lambdas.
http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/183-2snakes.pdf
See slide 121 for a laugh.
Tim J
tim <····@internet.com> writes:
> On Thu, 28 Feb 2008 18:27:05 -0500, Ken Tilton wrote:
[...]
> There was a talk at the Conference of Australian Linux Users wherein
> Anthony Baxter boasted about a) How incompatible the new version of Python
> (3.0) is going to be, and b) They are talking all the functional stuff out
> like reduce, map,
I've seen this mentioned elsewhere, and it's just not true. They are
simply moved into a module, so they haven't gone away.
> multi-line lambdas.
Well, yes. You'll have to name your functions.
> http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/183-2snakes.pdf
>
> See slide 121 for a laugh.
>
> Tim J
--
It's not a bug, it's the future.
On Sun, 02 Mar 2008 17:20:31 +0100, Vetle Roeim wrote:
> tim <····@internet.com> writes:
>
>> On Thu, 28 Feb 2008 18:27:05 -0500, Ken Tilton wrote:
>
> [...]
>
>> There was a talk at the Conference of Australian Linux Users wherein
>> Anthony Baxter boasted about a) How incompatible the new version of Python
>> (3.0) is going to be, and b) They are talking all the functional stuff out
>> like reduce, map,
>
> I've seen this mentioned elsewhere, and it's just not true. They are
> simply moved into a module, so they haven't gone away.
>
I'll take your word for it. But do you have a reference for this because
that's not what he said.
The whole tone of the segment was very antagonistic towards functional things.
He said the only thing people used reduce for is to get totals, so we
replaced it with list comprehensions.
Tim
tim <····@internet.com> writes:
> At least one of Perl's problems is not shared by Ruby. Ruby is a pleasure
> to learn because it is so regular ("principle of least surprise").
Yes, I was being a bit unfair. I do like the way the ruby language and
libraries are designed, most of the time. Much more regular than perl.
On the other hand, I will probably never understand why ruby needs
different types for blocks, procs and methods.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
P� Fri, 29 Feb 2008 00:18:30 +0100, skrev tim <····@internet.com>:
> On Thu, 28 Feb 2008 23:10:13 +0100, Joost Diepenmaat wrote:
>
>> Ken Tilton <···········@optonline.net> writes:
>>
>> Also, everybody young and blind to the problems of his "language of
>> choice" enough to get into flamewars is probably using Ruby nowadays. It
>> has all the problems that perl has (and a few extra), but it looks
>> nicer.
>>
>
> At least one of Perl's problems is not shared by Ruby. Ruby is a pleasure
> to learn because it is so regular ("principle of least surprise").
>
> Tim
Well Perl isn't that hard if you already know awk, sed, grep, C and Corn
shell script.
So for Unix admins and the like to which the language was originally
written it wasn't so hard.
Learning by familiarity. In fact I would say Perl scripting is a step up
from shell scripting.
It is when people start thinking of it as a application language it gets a
bit silly.
--------------
John Thingstad
On Feb 28, 11:58 am, Ken Tilton <···········@optonline.net> wrote:
> Speaking of speed bumbs, Jerry
> Seinfeld
--
The death of one man is a tragedy. The death of millions is a
statistic.
--- Joseph Stalin
Death solves all problems---no man, no problem.
--- Joseph Stalin
On Wed, 27 Feb 2008 14:44:30 +0100, Michael Bohn wrote:
> Ken Tilton wrote:
>> http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
>>
>> kenny
>>
>>
> I'd like to discuss this in the newsgroup:
>
> Stever said...
> "It's been around fifty years and yet there are really are not that many
> libraries for it, particularly GUI and graphic libraries. Sure there are
> a few, but not as many as other languages have access to or as well
> designed. And what I've seen many of those libraries are not
> maintained."
>
>
> I think that is one of the two problems of Lisp. Not enough library
> support. The other problem is that there is no progress in the language
> standard. Why not a new version of the standard? I mean Sockets
http://www.sbcl.org/manual/Networking.html
> and Threads
http://www.sbcl.org/manual/Threading.html
..works for me. I don't really care if these things are not part of the
language standard. It's been like this for years in C. Just write a thin
wrapper if you need portability, or find someone who has done this for
you.
But I must admit that a complete GUI library for Lisp would be nice, even
though I mostly do "web-stuff". Something that uses the JRE would be nice
( https://jdk6.dev.java.net/6uNea.html ).
--
Lars Rune Nøstdal
Lars Rune Nøstdal wrote:
> But I must admit that a complete GUI library for Lisp would be nice
What is wrong with Celtk? That is (+ Cells Tcl Tk), meaning it is even
more complete, you get a scripting language as well and some free libs
like the Snack audio lib.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Wed, 27 Feb 2008 13:11:06 -0500, Ken Tilton wrote:
> Lars Rune Nøstdal wrote:
>> But I must admit that a complete GUI library for Lisp would be nice
>
> What is wrong with Celtk?
Well, I don't know .. but it doesn't compile - which
might mean that it is not stable nor complete yet:
; compiling file "/home/lars/programming/lisp/cells/utils-kt/core.lisp" (written 11 FEB 2008 03:47:31 PM):
; compiling (IN-PACKAGE :UTILS-KT)
; compiling (DEFMACRO EVAL-NOW! ...)
; compiling (DEFMACRO EXPORT! ...)
; compiling (EVAL-NOW! (DEFMACRO DEFINE-CONSTANT ...))
; compiling (EXPORT! EXE-PATH ...); compilation aborted because of fatal error:
; READ failure in COMPILE-FILE:
; SB-INT:SIMPLE-READER-PACKAGE-ERROR at 1459 (line 52, column 21) on #<SB-SYS:FD-STREAM for "file /home/lars/programming/lisp/cells/utils-kt/core.lisp" {A96DF49}>:
; package "EXCL" not found
--
Lars Rune Nøstdal
Lars Rune Nøstdal wrote:
> On Wed, 27 Feb 2008 13:11:06 -0500, Ken Tilton wrote:
>
>
>>Lars Rune Nøstdal wrote:
>>
>>>But I must admit that a complete GUI library for Lisp would be nice
>>
>>What is wrong with Celtk?
>
>
> Well, I don't know .. but it doesn't compile - which
> might mean that it is not stable nor complete yet:
No, it means that I am surprised, a couple of people are keeping my
stuff patched so that it builds under other lisps besides ACL.
The larger point is that there /is/ a complete GUI for Lisp, you are
just looking for excuses to stand by your claim that there is not.
The people I respect shrug off things like that and send me patches, or
offer me $150/hr to hold their hands.
Bye-bye.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Wed, 27 Feb 2008 15:09:57 -0500, Ken Tilton wrote:
>
> The larger point is that there /is/ a complete GUI for Lisp, you are
> just looking for excuses to stand by your claim that there is not.
>
> The people I respect shrug off things like that and send me patches, or
> offer me $150/hr to hold their hands.
..or maybe I'll roll "my own" GUI lib instead. $75/hr (half the price!)
and I'll make it work out of the box on SBCL and ACL on Linux/Windows/
Mac. :}
--
Lars Rune Nøstdal
On Feb 27, 10:52 pm, Lars Rune Nøstdal <···········@gmail.com> wrote:
> On Wed, 27 Feb 2008 15:09:57 -0500, Ken Tilton wrote:
>
> > The larger point is that there /is/ a complete GUI for Lisp, you are
> > just looking for excuses to stand by your claim that there is not.
>
> > The people I respect shrug off things like that and send me patches, or
> > offer me $150/hr to hold their hands.
>
> ..or maybe I'll roll "my own" GUI lib instead. $75/hr (half the price!)
> and I'll make it work out of the box on SBCL and ACL on Linux/Windows/
> Mac. :}
>
> --
> Lars Rune Nøstdal
Just great, create one more hackbrary, we need more of them:
http://tourdelisp.blogspot.com/2008/01/common-lisp-libraries-victims-of-drive.html
Common Lisp, the only language that has more hackbraries than
applications.
Slobodan
Slobodan Blazeski wrote:
> On Feb 27, 10:52 pm, Lars Rune N�stdal <···········@gmail.com> wrote:
>
>>On Wed, 27 Feb 2008 15:09:57 -0500, Ken Tilton wrote:
>>
>>
>>>The larger point is that there /is/ a complete GUI for Lisp, you are
>>>just looking for excuses to stand by your claim that there is not.
>>
>>>The people I respect shrug off things like that and send me patches, or
>>>offer me $150/hr to hold their hands.
>>
>>..or maybe I'll roll "my own" GUI lib instead. $75/hr (half the price!)
>>and I'll make it work out of the box on SBCL and ACL on Linux/Windows/
>>Mac. :}
>>
>>--
>>Lars Rune N�stdal
>
>
> Just great, create one more hackbrary, we need more of them:
> http://tourdelisp.blogspot.com/2008/01/common-lisp-libraries-victims-of-drive.html
>
> Common Lisp, the only language that has more hackbraries than
> applications.
I'm a little disappointed he is not first going to write his own Lisp.
What a slouch.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton wrote:
> http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
| I (re)discovered Lisp just to find an easier way to create educational math
| software.
It is so easy and always fun to use, that your math software was released
in time and sold millionfold :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Ken Tilton wrote:
>
>
>>http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
>
>
> | I (re)discovered Lisp just to find an easier way to create educational math
> | software.
>
> It is so easy and always fun to use, that your math software was released
> in time and sold millionfold :-)
>
Yeah, in a followup post I will confess that Lisp is so much fun you
will lose all interest in your tedious application so as God is my
witness stick to Java!!!!!!
Either that or make sure you have a deadline, deadlines rock in
situations like this.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Why Lisp?
Date:
Message-ID: <rem-2008mar02-001@yahoo.com>
> From: Ken Tilton <···········@optonline.net>
> http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html
That blog itself was moderately interesting, but two links
triggered me in various ways:
<http://www.international-lisp-conference.org/2002/Tutorials/LC02-tutorials.html>
> Kent M. Pitmap
Um, you need to fix that spelling (even though the conference is
past, the Web page persists and should be fixed IMO).
<http://www.defmacro.org/ramblings/lisp.html>
That looks like a pretty good first attempt at this style of
presentation of why Lisp (specifically for structure-oriented
macros, as compared to C's raw-text macros). I'd like to see more
attempts of this general style.
In the blog, TimDaly said...
Lisp has two fundamental features.
1) Programs and data are the same.
2) nil eq () eq false
Adapting McCarthy's rebuke against Python, I would say that
there are only two languages X such that:
X can gracefully manipulate X code as data:
- Lisp
- Machine (not assembly) language for any CPU that has a fixed word
size for instructions and generally uniform format within each such
word-equals-instruction, such as PDP-10.
Of the two, Lisp is the *only* one which gracefully supports
manipulation of larger structures than individual machine
instructions, such as nested blocks of code with conditionals
and loops and function-with-argument calls.
Also, Lisp is the only one of the two that is programmer-friendly
at all, except for an opcode savant who has no trouble memorizing
the opcodes for all the various instructions and is comfortable
coding directly in octal-only DDT.
So really Lisp is the *only* usable language satisfying that X-statement.
Now I think this may be of some value: With Lisp being the only
usable language able to manipulate its own code as data, Lisp is
the only language suitable for tools that make it easy to create
domain specific languages (DSLs) and Lisp macros are in fact that
means to that end. So *that* is why it's so very important for Lisp
to be able to gracefully manipulate Lisp code as data, not just as
a neat fun hack to do that, but as the prerequisite for
structure-transforming macros that make it easy to define DSLs.
(And also syntactic tools within regular programming, as if
mini-DSLs used right along with regular code, such as the LOOP
macro and WITH-OPEN-FILE etc.)
As for nil being false, I'm not so sure that was such a good idea.
Maybe it would have been better if the number zero were false.
.. (everyone, except C programmers, start throwing tomatoes at me) ...
Nah, if zero were false, then we couldn't have POSITION return 0 if
the target was found at the very start of the sequence and have
that be distinguishable from not-found, and we'd need a second
return value to tell if the zero meant index-zero or not-found,
just as we currently do for GETHASH to distingush a value of NIL
from key missing from table. Yeah, we could offset all indexes by
1, so start of sequence was index one instead of zero, then zero
unambigously means not-found, but that's a bad idea.
Hey, we could have :FAIL instead of false=nil be the universal way
for a function to indicate failure?
.. (another round throwing tomatoes at me, now *including* C programmers) ...
Nah, I really like the idiom:
(OR (position key sequence) (length sequence))
and similar things, include complete chains of things that might
succeed where the first thing to succeed returns a value:
(OR (search1...) (search2....) (search3...) :DEFAULTVALUE)
Hey, I bet you can't do that easily in C!!
Wild and crazy idea:
false = :FALSE
() = :EMPTYLIST
neither of which is ever confused with each other nor with zero.
Any really good argument, other than tradition and user base, against that idea?
·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> Adapting McCarthy's rebuke against Python, I would say that
> there are only two languages X such that:
> X can gracefully manipulate X code as data:
> - Lisp
> - Machine (not assembly) language for any CPU that has a fixed word
> size for instructions and generally uniform format within each such
> word-equals-instruction, such as PDP-10.
> Of the two, Lisp is the *only* one which gracefully supports
> manipulation of larger structures than individual machine
> instructions, such as nested blocks of code with conditionals
> and loops and function-with-argument calls.
You missed forth. It's pretty easy in forth to write forth code that
runs at compile time and manipulates the input stream.
-russ
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Why Lisp?
Date:
Message-ID: <rem-2008mar08-004@yahoo.com>
> > Adapting McCarthy's rebuke against Python, I would say that
> > there are only two languages X such that:
> > X can gracefully manipulate X code as data:
> > - Lisp
> > - Machine (not assembly) language for any CPU that has a fixed word
> > size for instructions and generally uniform format within each such
> > word-equals-instruction, such as PDP-10.
> > Of the two, Lisp is the *only* one which gracefully supports
> > manipulation of larger structures than individual machine
> > instructions, such as nested blocks of code with conditionals
> > and loops and function-with-argument calls.
> From: Russell McManus <···············@yahoo.com>
> You missed forth. It's pretty easy in forth to write forth code that
> runs at compile time and manipulates the input stream.
In Lisp, the unit of data is a first-class object, which can be
nested in many cases. Lisp can gracefully manipulate such objects.
In machine language, the units of data are individual instructions
(with fields within them), and blocks of memory. There is no such
thing as "subroutine" in reality, since a jump can go to anywhere,
such as five locations after a label simply by using address
arithmetic. Machine language can gracefully manipulate both single
instructions with their fields, and blocks of memory.
Forth has two explicit levels of structure, individual words within
a script, and definitions of words which start with a special
keyword to announce the start of a definition and end with another
special keyword to announce the end of that definition. I am not
aware of any Forth software available to gracefully parse an input
stream into word-definition blocks and manipulate those blocks.
First of all, AFAIK Forth has no built-in memory allocation system
by which it would be graceful to store each word-definition in a
separate memory structure so that it can then be gracefully
manipulated. If there's some add-on module which provides such
graceful parsing and block-manipulation of word definitions, then
perhaps Forth plus that extra module might pass my criterion.
Please enlighten me, or concede my dismissal of Forth as comparable
to Lisp in regard to graceful manipulation of program structure.
Note that some Forth advocates require that each defined word
provide just one (1) of Dijkstra's primitives (decision, loop,
function-call, etc.). In that case, it might be possible to have
Forth software that understood the various Dijkstra primitives and
automatically classify each defined word according to which
primitive is implemented, and especially be able to compute what
effect each defined word would have upon the stack. Lisp can do
code-walking such as single-stepping or tracing rather easily.
Forth software would need to be able to "understand" how each word
affects the stack in order to do the analagous smarts on Forth
code. On the other hand, code that mixed more than one Dijkstra
primitive in a single defined word might be too complicated to
automatically analyze.
To my mind, gracefully manipulating code includes code-walking such
as single-stepping or tracing etc. If Forth doesn't have capability
of doing that, then it shouldn't be included with Lisp and machine
language.
Note that single stepping or tracing in machine language can be
done by at least these different methods:
- Inserting breakpoints at all possible next instructions after the
instruction being single-stepped or traced.
- Fully emulating the instruction set.
- Switching the CPU into supervisor-trap-after-each-user-instruction mode.
When I was using VM/CMS, debugging either compiled PSL (Portable
Standard Lisp) code or bootstrap code written in assembly language,
I sometimes used the auto-trap mode provided by VM
·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> Forth has two explicit levels of structure, individual words within
> a script, and definitions of words which start with a special
> keyword to announce the start of a definition and end with another
> special keyword to announce the end of that definition. I am not
> aware of any Forth software available to gracefully parse an input
> stream into word-definition blocks and manipulate those blocks.
> First of all, AFAIK Forth has no built-in memory allocation system
> by which it would be graceful to store each word-definition in a
> separate memory structure so that it can then be gracefully
> manipulated. If there's some add-on module which provides such
> graceful parsing and block-manipulation of word definitions, then
> perhaps Forth plus that extra module might pass my criterion.
> Please enlighten me, or concede my dismissal of Forth as comparable
> to Lisp in regard to graceful manipulation of program structure.
You can write what lisp programmers call macros in forth. If you want
COND in forth you can write it. If you want WHEN in forth you can
write it. Imagine me continuing with lots of other interesting
examples which I'm too bored to type...
It's not as nice as lisp for this stuff, agreed, but it works. Get
over it.
-russ
On Sun, 02 Mar 2008 00:21:54 -0800, ·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) wrote:
> As for nil being false, I'm not so sure that was such a good idea.
> Maybe it would have been better if the number zero were false.
> .. (everyone, except C programmers, start throwing tomatoes at me) ...
> Nah, if zero were false, then we couldn't have POSITION return 0 if
> the target was found at the very start of the sequence and have
> that be distinguishable from not-found, and we'd need a second
> return value to tell if the zero meant index-zero or not-found,
> just as we currently do for GETHASH to distingush a value of NIL
> from key missing from table. Yeah, we could offset all indexes by
> 1, so start of sequence was index one instead of zero, then zero
> unambigously means not-found, but that's a bad idea.
> Hey, we could have :FAIL instead of false=nil be the universal way
> for a function to indicate failure?
Then we would have to treat the :FAIL keyword in a special way, and it's
nil all over again, with a different name.
On the other hand, Scheme has been using #f for ages, and it seems to
cope quite well, so there's probably some value in #f :)
Giorgos Keramidas wrote:
> On Sun, 02 Mar 2008 00:21:54 -0800, ·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) wrote:
>
>>As for nil being false, I'm not so sure that was such a good idea.
>>Maybe it would have been better if the number zero were false.
>>.. (everyone, except C programmers, start throwing tomatoes at me) ...
>>Nah, if zero were false, then we couldn't have POSITION return 0 if
>>the target was found at the very start of the sequence and have
>>that be distinguishable from not-found, and we'd need a second
>>return value to tell if the zero meant index-zero or not-found,
>>just as we currently do for GETHASH to distingush a value of NIL
>>from key missing from table. Yeah, we could offset all indexes by
>>1, so start of sequence was index one instead of zero, then zero
>>unambigously means not-found, but that's a bad idea.
>>Hey, we could have :FAIL instead of false=nil be the universal way
>>for a function to indicate failure?
>
>
> Then we would have to treat the :FAIL keyword in a special way, and it's
> nil all over again, with a different name.
>
> On the other hand, Scheme has been using #f for ages, and it seems to
> cope quite well, so there's probably some value in #f :)
I just wish c.l.scheme had been copied so we could have a tiresome
rehash of this.
What I am looking for is the hilarious write-up of some student trying
to live without nil as false, I believe using the T language.
Anyone know it? Bonus points for a Google search string that leads to
it, "T" just does not stand out all the well.
:)
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
> What I am looking for is the hilarious write-up of some student trying
> to live without nil as false, I believe using the T language.
> Anyone know it?
Having been involved in its initial design, I know the language itself,
of course.
http://mumble.net/~jar/tproject/
But I don't know the user write-up you refer to.
> Bonus points for a Google search string that leads to
> it, "T" just does not stand out all the well.
Heh. People complained about our use of a one-letter name, so someone
at one point suggested an alternate title:
TEA (T with Extended Acronym).
Ken Tilton <···········@optonline.net> writes:
> I just wish c.l.scheme had been copied so we could have a tiresome
> rehash of this.
>
> What I am looking for is the hilarious write-up of some student trying
> to live without nil as false, I believe using the T language.
>
> Anyone know it?
I don't really find it hilarious (or particularily convincing as an
argument for NIL as false), but you're probably thinking of:
http://www.apl.jhu.edu/~hall/lisp/Scheme-Ballad.text
> Bonus points for a Google search string that leads to
> it, "T" just does not stand out all the well.
Google Groups, [assoc poem group:comp.lang.lisp]
--
Juho Snellman
Juho Snellman wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>>I just wish c.l.scheme had been copied so we could have a tiresome
>>rehash of this.
>>
>>What I am looking for is the hilarious write-up of some student trying
>>to live without nil as false, I believe using the T language.
>>
>>Anyone know it?
>
>
> I don't really find it hilarious (or particularily convincing as an
> argument for NIL as false), but you're probably thinking of:
>
> http://www.apl.jhu.edu/~hall/lisp/Scheme-Ballad.text
OMIGOD!!!
"The first day went fine; we learned of cells"
thx, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sun, 09 Mar 2008 23:34:08 -0400, Ken Tilton <···········@optonline.net> wrote:
> Giorgos Keramidas wrote:
>>On Sun, 02 Mar 2008 00:21:54 -0800,
>>·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) wrote:
>>>Hey, we could have :FAIL instead of false=nil be the universal way
>>>for a function to indicate failure?
>>
>> Then we would have to treat the :FAIL keyword in a special way, and it's
>> nil all over again, with a different name.
>>
>> On the other hand, Scheme has been using #f for ages, and it seems to
>> cope quite well, so there's probably some value in #f :)
>
> I just wish c.l.scheme had been copied so we could have a tiresome
> rehash of this.
Heh, sorry for spoiling all the fun, Kenny :)
On Mon, 10 Mar 2008 03:12:54 +0200, Giorgos Keramidas wrote:
> On the other hand, Scheme has been using #f for ages, and it seems to
> cope quite well, so there's probably some value in #f :)
I was initially intimidated by the size of Lisp, so I used Scheme for a
while first. Here is one data point: the existence of #f made life more
difficult in my opinion and was one thing I was glad to forget about when
I moved over to Lisp.
Tim
tim wrote:
> On Mon, 10 Mar 2008 03:12:54 +0200, Giorgos Keramidas wrote:
>
>
>>On the other hand, Scheme has been using #f for ages, and it seems to
>>cope quite well, so there's probably some value in #f :)
>
>
> I was initially intimidated by the size of Lisp, so I used Scheme for a
> while first. Here is one data point: the existence of #f made life more
> difficult in my opinion and was one thing I was glad to forget about when
> I moved over to Lisp.
The funny thing is that the CL response is usually that *we* have coped
quite well with the confusion of NIL and false.
So is Scheme code sprinkled with (not (null ...))s? I sure hope they do
not code (if (null x) y z), a sure recipe for bugs.
Meanwhile, at least one committed Lisp-1er thinks macrology is not the
only ball dropped by Scheme:
"It sometimes causes confusion to use the same thing for falsity and
the empty list, but many years of Lisp programming have convinced
me it's a net win, because the empty list is set-theoretic false,
and many Lisp programs think in sets."
-- http://ycombinator.com/arc/tut.txt
BTW, I am just a simple application programmer, I am not smart like
youse guys. Is that bit about the empty list being set-theoretic fals
true? If so, seems to me Scheme either needs fixing or if they insist on
this a set-theoretic set of conditionals.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mon, 10 Mar 2008 04:20:08 -0400, Ken Tilton <···········@optonline.net> wrote:
> BTW, I am just a simple application programmer, I am not smart like
> youse guys. Is that bit about the empty list being set-theoretic
> fals true?
Sounds like nonsense to me. But I only studied set theory for a
couple of years while Graham made a lot of money, so he must be
smarter than me.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Mon, 10 Mar 2008 04:20:08 -0400, Ken Tilton <···········@optonline.net> wrote:
>
>
>>BTW, I am just a simple application programmer, I am not smart like
>>youse guys. Is that bit about the empty list being set-theoretic
>>fals true?
>
>
> Sounds like nonsense to me. But I only studied set theory for a
> couple of years while Graham made a lot of money, so he must be
> smarter than me.
Yes, that $42m was going to be my trump card if von Stratten started
making feel dumb again with all that lambda algebra stuff like he did at
one LispNYC presentation*.
kenny
* Version 2008-03 in a pub near you tomorrow. k
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Edi Weitz <········@agharta.de> writes:
> On Mon, 10 Mar 2008 04:20:08 -0400, Ken Tilton <···········@optonline.net> wrote:
>
> > BTW, I am just a simple application programmer, I am not smart like
> > youse guys. Is that bit about the empty list being set-theoretic
> > fals true?
>
> Sounds like nonsense to me. But I only studied set theory for a
> couple of years while Graham made a lot of money, so he must be
> smarter than me.
FWIW, I think it's just a miserable attempt at a short description in
fancy words of the reasons behind the duality of NIL---making it look
like intellectual masturbation.
There is a certain similiarity between the empty list and false in the
notation of set theory, in Set Comprehensions, and even more so in their
look-alike in programming languages, List Comprehensions:
[ body | foo <- frob1 quux, bar <- frob2 quux ]
If FROB1 QUUX returns the empty list, neither FROB2 QUUX nor the BODY is
executed, making it behave like a conditional.
-T.
Tobias C. Rittweiler wrote:
> Edi Weitz <········@agharta.de> writes:
>
>
>>On Mon, 10 Mar 2008 04:20:08 -0400, Ken Tilton <···········@optonline.net> wrote:
>>
>>
>>>BTW, I am just a simple application programmer, I am not smart like
>>>youse guys. Is that bit about the empty list being set-theoretic
>>>fals true?
>>
>>Sounds like nonsense to me. But I only studied set theory for a
>>couple of years while Graham made a lot of money, so he must be
>>smarter than me.
>
>
> FWIW, I think it's just a miserable attempt at a short description in
> fancy words of the reasons behind the duality of NIL---making it look
> like intellectual masturbation.
Ewww. So much for gratification by analogy.
Something tells me you won't like my highfalutin explanation either:
No amount of truth is false, so nil is, too.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
P� Mon, 10 Mar 2008 10:46:51 +0100, skrev Tobias C. Rittweiler
<···@freebits.invalid.de>:
> FWIW, I think it's just a miserable attempt at a short description in
> fancy words of the reasons behind the duality of NIL---making it look
> like intellectual masturbation.
>
Perhaps I am dense here, but what is the 'duality' of nil. nil means not a
object.
--------------
John Thingstad
+ Edi Weitz <········@agharta.de>:
> On Mon, 10 Mar 2008 04:20:08 -0400, Ken Tilton <···········@optonline.net> wrote:
>
>> BTW, I am just a simple application programmer, I am not smart like
>> youse guys. Is that bit about the empty list being set-theoretic
>> fals true?
>
> Sounds like nonsense to me.
Sounds like nonsense to me, too. There is no true or false within the
universe of set theory, only sets. So if you wish to express truth or
falsehood within the theory, you just invent something. The closest I
can get is this: There are at the outset no relations in the universe of
set theory, either (other than the ∈ relation, “is a member of”, but
that is not so much in the universe as much as part of the theory
talking about that universe). So to be able to talk about relations, you
just identify the relation with the set of pairs (or tuples, in general)
that satisfy the relation. And then the relation that is never satisfied
by anything is represented by the empty set. But I don't find that a
compelling reason to identify ∅ with the boolean value “false”. The same
goes for using 0 and 1 for false and true; of course, in one model of
the natural numbers, 0 and the empty set are the same, so now we have
two weak arguments for identifying ∅ with false. On the other hand, some
people who work in recursion theory actually prefer to let 0 stand for
truth and any positive natural number for falsehood (and I don't think
it's because they have been infected by a unix meme: it just makes the
definition of some recursive functions easier). Really, set theory
provides no canonical candidate for the booleans.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
--=-=-=
Content-Type: text/plain; charset=iso-2022-jp
On 5304 September 1993, Harald Hanche-Olsen wrote:
> Sounds like nonsense to me, too. There is no true or false within the
> universe of set theory, only sets. So if you wish to express truth or
> falsehood within the theory, you just invent something. The closest I
> can get is this: There are at the outset no relations in the universe of
> set theory, either (other than the $B":(B relation,
--=-=-=
~is a member of~, but
> that is not so much in the universe as much as part of the theory
> talking about that universe). So to be able to talk about relations, you
> just identify the relation with the set of pairs (or tuples, in general)
> that satisfy the relation. And then the relation that is never satisfied
> by anything is represented by the empty set. But I don't find that a
> compelling reason to identify ~ with the boolean value ~false~.
The missing piece of information might be model theory for logic
calculi. ISTR that such an equation (well, it's more an axiom than
anything else) can be applied in automated theorem proving.
> Really, set theory provides no canonical candidate for the booleans.
Well, set theory gets used for a lot of stuff, doesn't it?
Holger
--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
--
--- http://hillview.bugwriter.net/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
62: professionelles Arbeiten
Tetris ist nicht auf der Festplatte (Sebastian
Kokemohr-Schmidt)
--=-=-=--
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Edi Weitz <········@agharta.de>:
>
>> On Mon, 10 Mar 2008 04:20:08 -0400, Ken Tilton <···········@optonline.net> wrote:
>>
>>> BTW, I am just a simple application programmer, I am not smart like
>>> youse guys. Is that bit about the empty list being set-theoretic
>>> fals true?
>>
>> Sounds like nonsense to me.
>
> Sounds like nonsense to me, too. There is no true or false within the
> universe of set theory, only sets. So if you wish to express truth or
> falsehood within the theory, you just invent something. The closest I
> can get is this: There are at the outset no relations in the universe of
> set theory, either (other than the ∈ relation, “is a member of”, but
> that is not so much in the universe as much as part of the theory
> talking about that universe). So to be able to talk about relations, you
> just identify the relation with the set of pairs (or tuples, in general)
> that satisfy the relation. And then the relation that is never satisfied
> by anything is represented by the empty set. But I don't find that a
> compelling reason to identify ∅ with the boolean value “false”. The same
> goes for using 0 and 1 for false and true; of course, in one model of
> the natural numbers, 0 and the empty set are the same, so now we have
> two weak arguments for identifying ∅ with false. On the other hand, some
> people who work in recursion theory actually prefer to let 0 stand for
> truth and any positive natural number for falsehood (and I don't think
> it's because they have been infected by a unix meme: it just makes the
> definition of some recursive functions easier). Really, set theory
> provides no canonical candidate for the booleans.
There's a direct and simple isomorphism between sets, complement,
intersection and union, and booleans, not, and and or.
{} = false
{{}} = true
complement(x,{{}}) = not x'
x inter y = x' and y'
x union y = x' or y'
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
Edi Weitz <········@agharta.de> writes:
> On Mon, 10 Mar 2008 04:20:08 -0400, Ken Tilton <···········@optonline.net> wrote:
>
>> BTW, I am just a simple application programmer, I am not smart like
>> youse guys. Is that bit about the empty list being set-theoretic
>> fals true?
>
> Sounds like nonsense to me. But I only studied set theory for a
> couple of years while Graham made a lot of money, so he must be
> smarter than me.
I don't believe either of you.
(defpackage boolean (:use) (:export "T" "NIL"))
(let ((boolean:t '(x))
(boolean:nil '()))
(format t "A B NOT A T-A AND INTER OR UNION~%")
(dolist (a (list boolean:nil boolean:t))
(dolist (b (list boolean:nil boolean:t))
(format t "~3A ~3A ~3A ~3A ~3A ~3A ~3A ~3A ~%"
a b
(not a) (set-difference boolean:t a)
(and a b) (intersection a b)
(or a b) (union a b)))))
A B NOT A T-A AND INTER OR UNION
NIL NIL T (X) NIL NIL NIL NIL
NIL (X) T (X) NIL NIL (X) (X)
(X) NIL NIL NIL NIL NIL (X) (X)
(X) (X) NIL NIL (X) (X) (X) (X)
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
On Mon, 10 Mar 2008 04:20:08 -0400, Ken Tilton wrote:
> BTW, I am just a simple application programmer, I am not smart like
> youse guys. Is that bit about the empty list being set-theoretic fals
> true? If so, seems to me Scheme either needs fixing or if they insist on
> this a set-theoretic set of conditionals.
>
> kenny
Well my answer to stuff like
The sentence below is true.
The sentence above is false.
is that those sentences are both compositionally false while consequently
true, assuming they are treated compositionally bound and consequently
unbound, because the result is a circular reference. A circular reference
is a null reference. A null reference can't be anything but a reference.
It cannot is anything. Therefore X which cannot is, cannot be said to is.
Those sentences are the parens (* ducks *) around the empty set in the
space of sentences.
So yes empty = false.
Of course, Georg Cantor and friends chose to go around the world in the
other direction.
Dnia 27.05.2008 Dihydrogen Monoxide <············@gmail.com> napisa�/a:
>> BTW, I am just a simple application programmer, I am not smart like
>> youse guys. Is that bit about the empty list being set-theoretic fals
>> true? If so, seems to me Scheme either needs fixing or if they insist on
>> this a set-theoretic set of conditionals.
>
> Well my answer to stuff like
>
> The sentence below is true.
> The sentence above is false.
>
> is that those sentences are both compositionally false while consequently
> true, assuming they are treated compositionally bound and consequently
> unbound, because the result is a circular reference. A circular reference
> is a null reference. A null reference can't be anything but a reference.
> It cannot is anything. Therefore X which cannot is, cannot be said to is.
>
> Those sentences are the parens (* ducks *) around the empty set in the
> space of sentences.
This metaphor seems utterly unacceptable to me, if only because it does
not generalize to other paradoxical sentences or sets of sentences.
The empty list being false comes in handy in certain situations, while
bringing annoyance in others. On the whole, I find it a rather nice
feature. One point where it is annoying are libraries like s-xml-rpc
or cl-json, which can serialize CL lists and vectors to the underlying
arrays, but the empty list is serialized as a boolean rather than an
array (i.e., if we don't know the list beforehand then it must be
coerced to a vector before serialization).
--
Daniel 'Nathell' Janus, ······@nathell.korpus.pl, http://korpus.pl/~nathell
Microsoft Windows is to computing as the Ottoman Empire was to late
nineteenth century politics: it covers a lot of territory, but
no-one takes it seriously anymore. [Robert Uhl, comp.lang.lisp]
On Tue, 27 May 2008 06:41:44 +0000, Daniel Janus wrote:
> Dnia 27.05.2008 Dihydrogen Monoxide <············@gmail.com> napisał/a:
>
>>> BTW, I am just a simple application programmer, I am not smart like
>>> youse guys. Is that bit about the empty list being set-theoretic fals
>>> true? If so, seems to me Scheme either needs fixing or if they insist
>>> on this a set-theoretic set of conditionals.
>>
>> Well my answer to stuff like
>>
>> The sentence below is true.
>> The sentence above is false.
>>
>> is that those sentences are both compositionally false while
>> consequently true, assuming they are treated compositionally bound and
>> consequently unbound, because the result is a circular reference. A
>> circular reference is a null reference. A null reference can't be
>> anything but a reference. It cannot is anything. Therefore X which
>> cannot is, cannot be said to is.
>>
>> Those sentences are the parens (* ducks *) around the empty set in the
>> space of sentences.
>
> This metaphor seems utterly unacceptable to me, if only because it does
> not generalize to other paradoxical sentences or sets of sentences.
it seems to work to me
which ones don't work?
--
http://dihymo.blogspot.com
http;//ntltrmllgnc.stumbleupon.com
P� Mon, 10 Mar 2008 02:12:54 +0100, skrev Giorgos Keramidas
<········@ceid.upatras.gr>:
> On Sun, 02 Mar 2008 00:21:54 -0800, ·······@yahoo.com (Robert Maas, see
> http://tinyurl.com/uh3t) wrote:
>> As for nil being false, I'm not so sure that was such a good idea.
>> Maybe it would have been better if the number zero were false.
>> .. (everyone, except C programmers, start throwing tomatoes at me) ...
>> Nah, if zero were false, then we couldn't have POSITION return 0 if
>> the target was found at the very start of the sequence and have
>> that be distinguishable from not-found, and we'd need a second
>> return value to tell if the zero meant index-zero or not-found,
>> just as we currently do for GETHASH to distingush a value of NIL
>> from key missing from table. Yeah, we could offset all indexes by
>> 1, so start of sequence was index one instead of zero, then zero
>> unambigously means not-found, but that's a bad idea.
>> Hey, we could have :FAIL instead of false=nil be the universal way
>> for a function to indicate failure?
>
> Then we would have to treat the :FAIL keyword in a special way, and it's
> nil all over again, with a different name.
>
> On the other hand, Scheme has been using #f for ages, and it seems to
> cope quite well, so there's probably some value in #f :)
>
Not quite sure what that value is. I would like to point out that from a
mathematical point of view boolean algebra is a set theory and generalized
boolean as used in CL is just as sound as a binary #true/#false based
algebra. I believe that parameter passing becomes more inefficient if I
have to return a tuple where one value sais if the call succeeded and
another which is only valid if the function succeeded. Exceptions could be
used here, but then it would flag not only error conditions but simple
checks as well. On the whole it just seems more cumbersome and the gain is
lost on me.
--------------
John Thingstad
On Mon, 10 Mar 2008 09:27:26 +0100, John Thingstad wrote:
> På Mon, 10 Mar 2008 02:12:54 +0100, skrev Giorgos Keramidas
> <········@ceid.upatras.gr>:
>
>> On Sun, 02 Mar 2008 00:21:54 -0800, ·······@yahoo.com (Robert Maas, see
>> http://tinyurl.com/uh3t) wrote:
>>> As for nil being false, I'm not so sure that was such a good idea.
>>> Maybe it would have been better if the number zero were false. ..
>>> (everyone, except C programmers, start throwing tomatoes at me) ...
>>> Nah, if zero were false, then we couldn't have POSITION return 0 if
>>> the target was found at the very start of the sequence and have that
>>> be distinguishable from not-found, and we'd need a second return value
>>> to tell if the zero meant index-zero or not-found, just as we
>>> currently do for GETHASH to distingush a value of NIL from key missing
>>> from table. Yeah, we could offset all indexes by 1, so start of
>>> sequence was index one instead of zero, then zero unambigously means
>>> not-found, but that's a bad idea. Hey, we could have :FAIL instead of
>>> false=nil be the universal way for a function to indicate failure?
>>
>> Then we would have to treat the :FAIL keyword in a special way, and
>> it's nil all over again, with a different name.
>>
>> On the other hand, Scheme has been using #f for ages, and it seems to
>> cope quite well, so there's probably some value in #f :)
>>
>>
> Not quite sure what that value is. I would like to point out that from a
> mathematical point of view boolean algebra is a set theory and
> generalized boolean as used in CL is just as sound as a binary
> #true/#false based algebra. I believe that parameter passing becomes
> more inefficient if I have to return a tuple where one value sais if the
> call succeeded and another which is only valid if the function
> succeeded. Exceptions could be used here, but then it would flag not
> only error conditions but simple checks as well. On the whole it just
> seems more cumbersome and the gain is lost on me.
I don't know (yet) about any kind of gain, but as a beginner scheme
programmer, I'm not finding it as terrible as you all make it sound.
For example, the assq example in the poem goes something like this:
(let ((e (assq key l))) (and e (cdr e)))
since you really want to return #f if you don't find the key you were
looking for. This works because (unlike in the poem) you don't actually
have to use #t for true: anything that isn't #f is fine.
You'd have to do the same in lisp if it weren't that (cdr nil) is nil,
rather than badness. So that's a bit of a different complaint.
In my case, I put my own alist-get and alist-get-all into my utilities
file and it's all "just working".
Cheers,
--
Andrew
Andrew Reilly wrote:
> (let ((e (assq key l))) (and e (cdr e)))
>
> since you really want to return #f if you don't find the key you were
> looking for. This works because (unlike in the poem) you don't actually
> have to use #t for true: anything that isn't #f is fine.
Sloppy, sloppy, sloppy! No, seriously, I was wondering if Scheme was
inconsistent and treated anything as #t, but in the poem I saw T was
consistent on that score and thought Scheme must be.
So how does Scheme justify that and not treat nil as false. Hang on,
just reread what you wrote: does that mean:
(when nil
(print "The Giants win!"))
-> "The Giants win!"
?
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mon, 10 Mar 2008 05:25:31 -0400, Ken Tilton wrote:
> Andrew Reilly wrote:
>
>> (let ((e (assq key l))) (and e (cdr e)))
>>
>> since you really want to return #f if you don't find the key you were
>> looking for. This works because (unlike in the poem) you don't
>> actually have to use #t for true: anything that isn't #f is fine.
>
> Sloppy, sloppy, sloppy! No, seriously, I was wondering if Scheme was
> inconsistent and treated anything as #t, but in the poem I saw T was
> consistent on that score and thought Scheme must be.
It's consistent like C (perhaps more so): just a different choice for the
"false" constant. True is always (not #f), if you're to be consistent.
> So how does Scheme justify that and not treat nil as false. Hang on,
> just reread what you wrote: does that mean:
>
> (when nil
> (print "The Giants win!"))
> -> "The Giants win!"
>
> ?
Nope:
(when nil (display "foo!"))
reference to undefined identifier: nil
:-)
But, indeed:
(when '() (display "foo!"))
--> foo!
Cheers,
--
Andrew
Andrew Reilly wrote:
> On Mon, 10 Mar 2008 05:25:31 -0400, Ken Tilton wrote:
>
>
>>Andrew Reilly wrote:
>>
>>
>>>(let ((e (assq key l))) (and e (cdr e)))
>>>
>>>since you really want to return #f if you don't find the key you were
>>>looking for. This works because (unlike in the poem) you don't
>>>actually have to use #t for true: anything that isn't #f is fine.
>>
>>Sloppy, sloppy, sloppy! No, seriously, I was wondering if Scheme was
>>inconsistent and treated anything as #t, but in the poem I saw T was
>>consistent on that score and thought Scheme must be.
>
>
> It's consistent like C (perhaps more so): just a different choice for the
> "false" constant. True is always (not #f), if you're to be consistent.
>
>
>>So how does Scheme justify that and not treat nil as false. Hang on,
>>just reread what you wrote: does that mean:
>>
>> (when nil
>> (print "The Giants win!"))
>> -> "The Giants win!"
>>
>>?
>
>
> Nope:
>
> (when nil (display "foo!"))
> reference to undefined identifier: nil
>
>
> :-)
>
> But, indeed:
>
> (when '() (display "foo!"))
>
> --> foo!
Oh, my. Talk about a message from G*d.
kenny
ps. You must be a Patriots fan. :) k
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mon, 10 Mar 2008 05:25:31 -0400, Ken Tilton <···········@optonline.net> wrote:
> Andrew Reilly wrote:
>
>> (let ((e (assq key l))) (and e (cdr e)))
>>
>> since you really want to return #f if you don't find the key you were
>> looking for. This works because (unlike in the poem) you don't
>> actually have to use #t for true: anything that isn't #f is fine.
>
> Sloppy, sloppy, sloppy! No, seriously, I was wondering if Scheme was
> inconsistent and treated anything as #t, but in the poem I saw T was
> consistent on that score and thought Scheme must be.
>
> So how does Scheme justify that and not treat nil as false. Hang on,
> just reread what you wrote: does that mean:
>
> (when nil
> (print "The Giants win!"))
> -> "The Giants win!"
There's no `when' in Scheme (R5RS even includes an example of how to
write one), so I guess the Giants deteriorate in a Schroedinger-cat
state, until the macro is written by the programmer :)
P� Mon, 10 Mar 2008 10:14:33 +0100, skrev Andrew Reilly
<···············@areilly.bpc-users.org>:
> For example, the assq example in the poem goes something like this:
>
> (let ((e (assq key l))) (and e (cdr e)))
>
I would condense that into:
(aand (assoc key l) (cdr it))
Using 'anamorphic and' with the implementation in On Lisp. And honestly
that is not proper Scheme.
--------------
John Thingstad
On Mon, 10 Mar 2008 11:05:47 +0100, John Thingstad wrote:
> And honestly
> that is not proper Scheme.
It's not? I'm just an egg here: what would have been better? (Or do you
mean that arc's anamorphic and/it isn't scheme?)
Cheers,
--
Andrew
On Mar 10, 7:11 am, Andrew Reilly <···············@areilly.bpc-
users.org> wrote:
> On Mon, 10 Mar 2008 11:05:47 +0100, John Thingstad wrote:
> > And honestly that is not proper Scheme.
> It's not? I'm just an egg here: what would have been better?
> (Or do you mean that arc's anamorphic and/it isn't scheme?)
You mean "anaphoric"?
------------------------------------------------
Dan Bensen
http://www.prairienet.org/~dsb/
P� Mon, 10 Mar 2008 11:05:47 +0100, skrev John Thingstad
<·······@online.no>:
> P� Mon, 10 Mar 2008 10:14:33 +0100, skrev Andrew Reilly
> <···············@areilly.bpc-users.org>:
>
>> For example, the assq example in the poem goes something like this:
>>
>> (let ((e (assq key l))) (and e (cdr e)))
>>
nop should be:
(let ((e (assq key l))) (and (not (null e)) (cdr e)))
Seems to me.
--------------
John Thingstad
On Mon, 10 Mar 2008 14:12:20 +0100, John Thingstad wrote:
> På Mon, 10 Mar 2008 11:05:47 +0100, skrev John Thingstad
> <·······@online.no>:
>
>> På Mon, 10 Mar 2008 10:14:33 +0100, skrev Andrew Reilly
>> <···············@areilly.bpc-users.org>:
>>
>>> For example, the assq example in the poem goes something like this:
>>>
>>> (let ((e (assq key l))) (and e (cdr e)))
>>>
>>>
> nop should be:
> (let ((e (assq key l))) (and (not (null e)) (cdr e))) Seems to me.
assq is only going to return #f if key isn't in a car slot in l. So if
it's not #f, then it found key, so the value must be in the cdr.
Besides, I think that the key could reasonably be '(), in scheme, and my
version would still work. Just like all logic in scheme, #f is the key.
You don't have to force an actual #t to have the opposite effect.
If you wanted to get cautious, you could make it (and (pair? e) (cdr e)),
but I don't see that that buys you anything over just testing e for not
#f.
Cheers,
--
Andrew