low quality lisp books
Philip
Lately I've been thinking of buying a lisp book. I was thinking of Paul
graham's book, but my friend pointed out that its not very good. He had a
problem with the guy lying on the first page. What do you guys think?
Here is my friends email:
Hi Phil, read the first page and then compile this C program:
#include <stdio.h>
typedef int (* f_p)(int);
static int k = 0;
int add (int x) { return k + x; } ;
f_p addn(int n) {
k = n;
return add ;
}
int main ( int argv, char** argc ) {
printf("Calling (*addn(12))(13): %d\n",
(addn(12))(13));
printf("Calling (*addn(1))(13): %d\n",
(addn(1))(13));
printf("Calling (*addn(2))(3): %d\n",
(addn(2))(3));
printf("Paul Graham is a liar.\n");
return 1;
}
Save it in a file test.c and compile with "gcc -Wall test.c"
and then run the resulting executable a.out.
This file is sufficient to prove that Paul Graham's statement
"What does addn look like in C ? You just can't write it."
is false.
(The hardest part was the fact that we needed that typedef to
get around this bug)
http://gcc.gnu.org/ml/gcc-prs/2000-q2/msg00168.html
Paul Graham would no doubt note that if you store a
reference to addn(1), and then store a reference to addn(2),
calling the first reference with 1 as an argument would give 3
not 2, because the static variable k would be overwritten.
There are several things to note about this observation, which
I am going to go ahead and note before they make it:
1) Paul Graham's statement on page 2 of his book is still a
lie.
2) If Graham wanted to produce a more extensive snippet of
lisp to demonstrate the behaviour above, and then said you
couldn't do that in C, he would still be liar. This is
because you would solve that problem by having static
structures which kept track of the related function
pointers and k variables. It would be a few more lines of
code that you would have to write carefully, but you can do
it. I just want to make sure that I pre-emptively call
Paul Graham a liar just in case he makes that statement.
3) If Graham said that his point was that lisp automatically
kept the relationship between the k and function via the
"closure" or whatever, he'd might be right; but he'd still
be a liar, because he didn't say that function was more
beautiful in lisp, he said "You just can't write it" in C.
Furthermore, it is a little silly to present a function and
claim you can't do it in C, and then complain that it
wasn't done in C the way you would have done it in lisp.
The fact is, you have to keep track of those things in C.
That doesn't mean you can't do it. (You can hack some evil
macros, of course, but let's not go there.)
4) Paul Graham is liar.
5) Paul Graham (that's the guy who is a liar) did not correct
his lie in the online errata for the book.
6) Even if it was a mistake and not a lie, he's a fucking
professor in comp sci, he should know about what can and
can't be written in C.
7) I paid $47 for this book which has a lie on page 2. (Did I
mention it was written by Paul Graham ?)
--Rob
P.S. Not only did Paul Graham only last til page 2 without telling a
lie, the lie is AT THE VERY TOP of page 2. Given that part of page 1
is taken up by a large font chapter title, you could consider that he
lied on the first page of his book.
Either way, he's a liar.
P.P.S. The rest of the book might be great. I'll never find out,
because I'd rather read a book by someone who gets things right.
Sorry for my friends strong words,
----
Philip
Tim Moore
Tim
Thomas F. Burdick
> Hi, I usually don't post on here much.
>
> Lately I've been thinking of buying a lisp book. I was thinking of Paul
> graham's book, but my friend pointed out that its not very good. He had a
> problem with the guy lying on the first page. What do you guys think?
>
> Here is my friends email:
Frankly, your friend is a jackass. Graham was not lying, he was
trying to demonstrate lexical closures. When you're writing a book,
you have to assume that your audience is not alt.hate.lisp or
alt.hate.paul-graham, which is what your friend is acting like. If
you wrote for that kind of audience, the book would be at least 10x
longer, and useless to everyone else.
[ sophmoric rantings elided ]
> 3) If Graham said that his point was that lisp automatically
> kept the relationship between the k and function via the
> "closure" or whatever, he'd might be right; but he'd still
> be a liar, because he didn't say that function was more
> beautiful in lisp, he said "You just can't write it" in C.
> Furthermore, it is a little silly to present a function and
> claim you can't do it in C, and then complain that it
> wasn't done in C the way you would have done it in lisp.
> The fact is, you have to keep track of those things in C.
> That doesn't mean you can't do it. (You can hack some evil
> macros, of course, but let's not go there.)
Oh dear god, this is one step away (if that) from bringing up Turing
machines. For the record: anything that can be computed in any
Turing-complete language can be computed in any other, given enough
time and effort on the part of the developer; Common Lisp, C, and x86
assembly language are all Turing-complete; the previous two statements
are useless.
> 7) I paid $47 for this book which has a lie on page 2. (Did I
> mention it was written by Paul Graham ?)
He paid $47 and won't read past page 2??? He certainly values his
juvenile smugness more than his hard-earned cash.
> P.P.S. The rest of the book might be great. I'll never find out,
> because I'd rather read a book by someone who gets things right.
The rest of your friend's behavior might be great, but I'd reccomend
against listening to a word he has to say regarding Lisp, Paul Graham,
or anything related. He obviously has an irrational bug up his ass.
I'd go ahead and buy "ANSI Common Lisp", it's a fine book. It has
some good points and some bad points, but they have nothing to do with
what your friend said. There are also other good intro books to Lisp,
but I'm sure your friend could find plenty of "lies" in them or any
other book he wanted to.
Bob Riemenschneider
> Hi, I usually don't post on here much.
>
> Lately I've been thinking of buying a lisp book. I was thinking of Paul
> graham's book, but my friend pointed out that its not very good. He had a
> problem with the guy lying on the first page. What do you guys think?
Philip,
I have good news and bad news for you. Which do you want to hear first?
The bad news? Okay.
The bad news is that your friend is an idiot.
The good news is that he is probably willing to part with his copy of
_ACL_ for far less than the $47 he paid. You should make him an offer.
-- rar
Israel Raj T
>Hi, I usually don't post on here much.
>Lately I've been thinking of buying a lisp book. I was thinking of Paul
>graham's book, but my friend pointed out that its not very good. He had a
>problem with the guy lying on the first page.
I guess that Paul Graham is pointing out that higher order functions
and first class objects are not part of the normal set of C idioms.
Philip M
With the kinds of personalties you have its no wonder that more people don't
want to program in lisp. Basically I post on here, with a rational post,
apologizing in advance for any strong words, and you guys start out calling
my best friend an asshole. Well, there goes your credibility. You know I can
read and use a compiler too, I'm not a stupid monkey. The way I see it he
*is* a liar.
Gee thanks. How the hell am I supposed to separate that kind of elitist
attitude of the people who program in lisp from lisp itself?
Philip
"Thomas F. Burdick" <t...@blizzard.OCF.Berkeley.EDU> wrote in message
news:xcv8zfc...@blizzard.OCF.Berkeley.EDU...
Duane Rettig
> Hi, I usually don't post on here much.
>
> Lately I've been thinking of buying a lisp book. I was thinking of Paul
> graham's book, but my friend pointed out that its not very good. He had a
> problem with the guy lying on the first page. What do you guys think?
>
> Here is my friends email:
>
> Hi Phil, read the first page and then compile this C program:
Your friend has led you down a clever garden path lie of his
own. I wonder if he was just toying with you.
Try the following program, which _should_ do the same thing
as your friend's version (but doesn't, of course, since C doesn't
do closures):
#include <stdio.h>
typedef int (* f_p)(int);
static int k = 0;
int add (int x) { return k + x; } ;
f_p addn(int n) {
k = n;
return add ;
}
int main ( int argv, char** argc ) {
f_p addn12, addn1, addn2;
addn12 = addn(12);
addn1 = addn(1);
addn2 = addn(2);
printf("Calling (*addn(12))(13): %d\n",
addn12(13));
printf("Calling (*addn(1))(13): %d\n",
addn1(13));
printf("Calling (*addn(2))(3): %d\n",
addn2(3));
printf("Paul Graham is NOT a liar.\n");
return 1;
}
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Daniel Barlow
> Gee thanks. How the hell am I supposed to separate that kind of elitist
> attitude of the people who program in lisp from lisp itself?
On the evidence presented so far, I think that you will be happier if
you don't.
For what it's worth, there's a difference between a "jackass" and an
"asshole". My dictionary defines the former as "male ass" or "stupid
person", so , for example, if you're living in a builtup area and
careful about the company you keep then it's entirely excusable to be
unable to find your jackass with both hands.
Hope this helps.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Kaz Kylheku
>Hi, I usually don't post on here much.
>
>Lately I've been thinking of buying a lisp book. I was thinking of Paul
>graham's book, but my friend pointed out that its not very good. He had a
>problem with the guy lying on the first page. What do you guys think?
>
>Here is my friends email:
>
>Hi Phil, read the first page and then compile this C program:
>
>
>
>#include <stdio.h>
>typedef int (* f_p)(int);
>static int k = 0;
>int add (int x) { return k + x; } ;
>f_p addn(int n) {
> k = n;
> return add ;
>}
I think you and your friend Phil are missing a few clues upstairs.
Note that in the C language, the static object 'k' refers to a single
object.
Each time you call addn() it will clobber the object 'k' with a new
value.
In Lisp, a closure can capture a local variable. So that you can
have multiple instances of returned functions, each with their own
value of k.
If you want to simulate closures, switch to C++ and write function-objects;
they are the closest thing, and provide a clue as to how to do it in C.
In C++, you could write a function which returns an object, and then
that object could have an overloaded operator (int) so that you
could treat that object as a function that takes an int parameter.
The value 'k' would be represented as a member of that object.
In C, you could perhaps the closure as a struct, and a pointer
to a function, here is a sketch:
struct add_closure {
int k;
int (*func)(struct add_closure *context, int arg);
};
Then the addn function would have to dynamically allocate this bugger:
#include <stdlib.h>
static add_func(struct add_closure *context, int arg)
{
return context->k + arg;
}
struct add_closure *addn(int add_amount)
{
struct add_closure *ac = malloc(sizeof *ac);
if (ac) {
ac->k = add_amount;
ac->func = add_func;
}
return ac;
}
int main(void)
{
struct add_closure *ac = addn(42);
if (ac == 0) { /* handle failure */ }
ac->func(ac, 1); /* call ``closure'' */
return 0;
}
But now the caller has to worry about checking for a memory allocation
failure, and for ensuring that the object is freed when it is no longer
needed. You have a totally half-assed, horribly inconvenient emulation,
but at least the naive problem of k being overwritten has gone away.
>"What does addn look like in C ? You just can't write it."
You can do everything in C that you can do in Lisp. Proof: simply write
a Lisp interpreter function in C, then encode what you want to do in
a character array representing a Lisp program, and then invoke the
interpreter on that array.
However, there are things you can do *directly* in Lisp that
are not *directly* possible in C. Lisp gives you a different
``programming space'' for expressing solutions.
When you have two languages that are substantially different, it's often
possible to emulate some features of one in the other. But unless such
an emulation is perfect, it can't be said to constitute an equivalence;
to be perfect, it has to capture all the relevant aspects of the feature,
not only selected use-instances. If the emulation breaks in fundamental
ways, then it's useless. If it requires a whole lot of tedious manual
work to set up and maintain, it's equally useless.
Kaz Kylheku
>Man you guys are nasty.
Is there no depth to your arrogance and imbecility?
You started this thread by accusing an author of lying. In polite
academic circles, you do not assume that someone is lying when he
appears to have made a mistake. And you do not assume that someone has
made a mistake when he presents facts that appear to conflict with
your present understanding. You take the humble position that *your*
understanding is wrong. Then if you are lucky, you can work from there to
show that *he* made a mistake. Only if you can show some kind of
academic or scientific misconduct can you accuse someone of deliberate
dishonesty; for example, a researcher who falsifies results to
fit his hypotheses is a liar.
Before you accuse others of being nasty, consider the tone
of your best friend's letter:
"Even if it was a mistake and not a lie, he's a fucking
professor in comp sci, he should know about what can and
can't be written in C."
Now your friend can be excused for using this tone when writing to
you. But you are the one who chose to publish that correspondence.
Since you have not named your friend, as far as anyone knows
you are the sole author of this vociferous diatribe, and
the invocation of a third party is just a ploy to deflect heat.
>With the kinds of personalties you have its no wonder that more people don't
>want to program in lisp. Basically I post on here, with a rational post,
>apologizing in advance for any strong words, and you guys start out calling
>my best friend an asshole.
As far as anyone knows, your best friend is merely ignorant, if indeed
he is real. *You* are the asshole.
>Well, there goes your credibility.
You, on the other hand, moments ago, missed an opportunity to
discover what it feels like to lose credibility, for lack of it.
Michael Parker
>
> Man you guys are nasty.
>
> With the kinds of personalties you have its no wonder that more people don't
> want to program in lisp. Basically I post on here, with a rational post,
> apologizing in advance for any strong words, and you guys start out calling
> my best friend an asshole. Well, there goes your credibility. You know I can
> read and use a compiler too, I'm not a stupid monkey. The way I see it he
> *is* a liar.
Then you aren't seeing clearly. Graham is not a liar. At least not
in the way you think he is. And the reason he didn't explain himself
more fully is because it isn't the sort of thing you want to get into
on page 2. Think about it: Neither you nor your friend realized the
fundamental flaw in your program, probably because as C programmers you
aren't used to thinking about the tightly intertwingled nature of code
and data.
Your friend's implementation is flawed in a way that is difficult to
fix without inventing (inefficiently) a large chunk of lisp. Think
about this: what happens if your program creates several f_p's using
addn? What if you need to create *lots* of them?
Example: I've got a regex library written in C++ that compiles to
closure-objects similar to way I do it in the C++ example I give below.
The program I'm using it in has thousands of compiled regexes. The
technique in your C example fails utterly at this. Stallman's GNU
regex engine doesn't use this (quite obvious) technique, probably
because it's too much trouble in C. My engine is 30-50% faster than
Stallman's, so it's a double win for us.
Here's a slight modification to your program that shows off the flaw:
int main ( int argv, char** argc ) {
f_p add_12 = addn(12);
f_p add_1 = addn(1);
f_p add_2 = addn(2);
printf("Calling (*add_12))(13): %d\n",
(add_12)(13));
printf("Calling (*add_1)(13): %d\n",
(add_1)(13));
printf("Calling (*add_2)(3): %d\n",
(add_2)(3));
printf("Paul Graham is telling the truth.\n");
return 1;
}
You could solve this in C++, which should give away the trick of how
to solve this in C (as well as a good idea of how Lisp solves it under
the hood):
class addn
{
int _n;
public:
addn(int n) : _n(n) {}
int operator()(int m) {return _n + m;}
};
int main(int argv, char** argc)
{
addn add_12(12);
addn add_1(1);
addn add_2(2);
printf("Calling add_12(13): %d\n",
add_12(13));
printf("Calling add_1(13): %d\n",
add_1(13));
printf("Calling add_2(3): %d\n",
add_2(3));
exit(1);
}
I haven't read Graham's book, but even this C++ is considerably clunkier
than it's CL equivalent, and this textual bloat gets *very* troublesome
(and quite frankly not worth the trouble) if you need to use it a lot,
such as when using the C++ STL.
Erik Naggum
> How the hell am I supposed to separate that kind of elitist attitude of
> the people who program in lisp from lisp itself?
Grow smarter? You know, these days, there is a lot of your attitude
going around, and Arab-Americans get seriously hurt because of it. I
would have thought that at least _some_ people would grow a clue from
current events and curb such stupid attitudes as you display here. Also
consider the fact that you posted a provocative, fairly hateful message,
and that nobody _really_ believes it is a friend speaking, "friend" is
just chicken speak for "I cannot stand by this, but I post it anyway".
Your first message could be answered reasonably, however. Your followup
shows everybody that _you_ are the asshole who has to resort to that kind
of response when you do not get things your way. You will of course not
accept this, but think that you are in the right and everybody else is in
the wrong. Calling a well-respected author and his faily well-respected
book really bad things is OK with you, but getting a response in kind is
not, and that says a whole lot about you that I think you _should_ have
been smart enough to figure out is not to your benefit. You can still
grow a clue, though. Just respond maturely to the criticism you get, OK?
///
Erik Naggum
> Lately I've been thinking of buying a lisp book. I was thinking of Paul
> graham's book, but my friend pointed out that its not very good. He had a
> problem with the guy lying on the first page. What do you guys think?
That your friend is a stupid liar who missed the point entirely.
A lexical closure is a function-callable structure with local data. You
construct a new such structure by capturing the values of all variables
bindings that close over the function. However, this structure can be
called directly with language primitives and it looks no different than
normal functions.
(defun addn (n)
(lambda (x)
(+ x n)))
amd you call this with
(funcall (addn 1) 2)
Now, there are several interesting problems with this solution from a C
point of view. The first and foremost is that writing a function that
can call an arbitrary function or function-like object in C with an
arbitrary number of arguments is _really_ hard. Thefore, you typically
write a specialized function in C. This is the first case of cheating.
You see, the lexical closure support in Common Lisp is _general_.
struct closure {
int (*body) (int, struct closure *, ...);
int args;
];
/* This would be done with classes and inheritance in C++. */
struct addn_closure {
int (*body) (int, struct closure *, ...);
int args;
int n;
}
int addn_lambda (int count, struct closure *closure, va_list arg_list)
{
int argument;
argument = va_arg (arg_list, int)
return (argument + (struct addn_closure *)closure->n);
}
struct addn_closure * addn (int n)
{
/* This would be done with class initialization in C++. */
struct addn_closure *new_closure = malloc (sizeof (struct addn_closure));
new_closure->body = addn_lambda;
new_closure->n = n;
return new_closure;
}
int funcall_closure (int count, struct closure *closure, ...)
{
int result;
va_list arg_list;
/* This would be done with exceptions in C++. */
if (count != closure->args)
exit (1);
va_start (arg_list, closure);
result +> closure->body (count, closure, arg_list);
va_end (arg_list);
return result;
}
Now we can do this, more or less, but you may have to engage in casting
to get the stupid static typing cruft in the compiler to agree with you,
which also screwed up our ability to use any other argument type than
int, which is really, really painful. (So maybe it should have used
pointers to various object types, and passed void* around instead, but
then you could not have passed integer constants directly, but would have
had to make up some objects to hold such values.)
funcall_closure (1, addn (1), 2);
If you think all of this supports your (friend's) view that Paul Graham
is a liar and that you _can_ do lexical closures in C, you are actually
gravely mistaken. We are cheating and limiting the functionality all
over the place. More than half of what cannot be done in C is precisely
the generality of the solution.
It is perhaps possible to do lexical closures in C++, with support for
overloading and lots and lots of heavy-duty features, but even with STL
and all kinds of "foundation classes" and shit, it is not actually done.
There has to be a good reason for this, considering how tremendously
useful lexical closures are when passing functions around, and the reason
is two-fold: (1) Since it is so incredibly hard to do this in C/C++, it
is not done, and (2) since it is not done, the kinds of solutions that
benefit from it are not done in C/C++. Therefore, a C/C++ programmer,
like your friend, will have absolutely no use for lexical closures and
neither will will he understand how he missed the point, because the
whole concept is _actually_ outside the reach of the C/C++ mindset.
I suggest you get smarter friends who do not keep you down by confusing
you with negative bullshit when you clearly should spend your time
reading and understanding books that open your mind instead of closing
them down. You might then learn something and be able to tell your
friend that he is a liar in terms he can understand, although it is
highly doubtful that he will grow a clue considering this insistence that
he need not understand what he argues against. This seems to happen to
C/C++ people a lot, and it is part of the survival tactics of those
language to keep people from discovering that their languages are
limiting them to that which is easy to do in thelr languages. Common
Lisp makes a lot of simple things in those languages a little harder, but
the things that are _really_ hard in C/C++ is no harder than the rest,
and when you run out of hard things to do in C/C++, the complex stuff you
work with in Common Lisp is still going to be equally hard to what you
have been used to. This is where higher-level languages beat lower-level
languages. Incidentally, it is far easier to do lexical closures at the
assembly level than at the C level. This is an indication that C/C++ is
a step up from assembly, but in the wrong direction, such that you cannot
get any further, and your friend hit the C level from _below_ (and lots
of other C/C++ people react the same way), and cannot get anywhere. This
is the _real_ tragedy of C/C++ and the people who think they do not need
what these languages cannot provide (easily) are so pathetic it hurts to
watch them make fools of themselves.
Incidentally, there are not enough high-quality Common Lisp books that
explain things to people who have been used to working with the machine
at the C level. I may think a book like that would have worked better
for you, too, but the only one I can think of is "Anatomy of Lisp", which
is out of print and hard to come by.
///
Eric Moss
>
> Hi, I usually don't post on here much.
>
> Lately I've been thinking of buying a lisp book. I was thinking of Paul
> graham's book, but my friend pointed out that its not very good. He had a
> problem with the guy lying on the first page. What do you guys think?
>
> Here is my friends email:
Well, lying... I don't know what is in Paul Graham's heart. I DO know
it's STILL a good lisp book, and such a visceral response from your
friend is doing both him and you a great disservice if it prevents you
from reading the book. I suppose it's a hazard of the profession to have
such an unforgiving personality. Some people around here have that, too.
:)
Buy the book off him used, as he is not showing the spirit needed to
explore and appreciate the vastness of lisp (this sounds sarcastic, but
I'm serious). You'll learn a lot, as you would from a number of other
lisp books. I am learning that comparing many perspectives on what
constitutes beautiful programming, and in particular, beautiful lisp,
are a boon. I personally don't like the macros Mr. Graham uses in his
second book. I find them hard to follow, but maybe that's just me--I
find lots of things hard to follow. Had I let page 2 of the first book
stop me, though, I wouldn't have learned anything.
Eric
PS. Your friend's code used two dedicated, purpose-specific functions,
both named, which only work on integers of limited range. Further (I
believe--others here would know better than I), I don't see how his code
could be thread-safe without nasty modifications and maybe even with. In
effect, it provides only one function and a static variable to provide
the *effect* of this particular lisp lambda, but only in a very limited
case.
By contrast, the lisp code creates a new function at every invocation.
That new function exists independently of any other "addn" functions
created at runtime, and could be directly applied to a list, tree, or
whatever, to numbers (not just integers) of limited *or* arbitrary
precision. The lambda is also anonymous (if you want it to remain so),
so you don't have to clutter the namespace with what is really just a
temporary tool--if that's what you need it to be. Your friend's code
doesn't appear to do anything like that. It only (as with much of C,
IMO) provides a zeroth order approximation of one specific application
of a general concept. The lisp code, however, gives you the whole
enchilada, is absolutely clear in its purpose, and doesn't depend on
side-effects, or lack thereof.
I think Mr. Graham might have said (possibly to better effect), "To do
much of what lisp does so elegantly and generically, a language such as
C can do so only through the creation of code which approximates the
functionality of a lisp interpreter."
Or something like that. At least now I'm sure he isn't lying. Just as
with much of life, the coolest things are subtle and require that we see
beneath the surface appearance.
PPS. I personally like starting with Graham's "Common Lisp",
supplemented by the Hyperspec (thanks, Mr. Pitman!) and CLTL2. Then
progress to Keene's CLOS book and Norvig's "Paradigms of Artificial
Intelligence Programming". After that, "The Art of the MetaObject
Protocol". I'm sure others here have equally, or more, valid opinions,
and you'll get a few. ;)
Whew.
Frank A. Adrian
> Man you guys are nasty.
I prefer to view it as being brutally honest.
> Gee thanks. How the hell am I supposed to separate that kind of elitist
> attitude of the people who program in lisp from lisp itself?
To be quite honest, when you have the chutzpah to call one of the better
authors on our language a liar, when it's clear that the code you offer is
in no way equivalent, I'd say that you were treated quite gently. As far
as separating attitude from elitism goes, let's just say that the attitude
is a reflection of yours. As far as elitism goes, I would plead guilty on
behalf of many of the people here - they ARE better than average
programmers in C, C++, and Lisp (and probably a few other languages)
because they have taken time to study and use them. They are a true elite
class of programmers.
They DO, however, share their knowledge freely with those who come here
with open minds and considerate (and well-considered) questions. But when
you barge in like a braying ass, you take your chances. Life is hard.
Deal with it.
faa
Geoffrey Summerhayes
"Philip" <p...@yahoo.com> wrote in message
news:dd1860e3.01091...@posting.google.com...
>
> P.P.S. The rest of the book might be great. I'll never find out,
> because I'd rather read a book by someone who gets things right.
>
Once you have it tell Rob to go to the back of
the class, he completely misunderstood the point.
The code he wrote is incorrect, he's captured
correct behaviour that only works under for the
scenario _he_ choose.
Consider this Lisp behaviour
(setf add1 #'1+) -> #<function> ; the point
(setf add5 (addn 5)) -> #<closure>
(setf add6 (addn 6)) -> #<closure>
(funcall add1 3) -> 4
(funcall add5 3) -> 8
(funcall add6 3) -> 9
Won't work in C, even if you corrected his C
code to use a struct to fake a closure. Functions
and structs cannot be exchanged this way.
...
int add_one(int x){return x+1;}
...
f_p add1=add_one, add5=addn(5), add6=addn(6);
printf("%d\n",add1(3));
/*
if your compiler made it
this far the next line
either gives the wrong
answer or has a excellent
chance of dumping core
depending on the return
value(struct* or function*)
from addn()
*/
printf("%d\n",add5(3));
printf("%d\n",add6(3));
...
If you want to do the screamingly ugly C to mimic the
Lisp, I'd suggest starting with Erik Naggum's code in
message news:32098542...@naggum.net and add to
it. You'll have to wrap _all_ functions with empty
`closures' so you have an accurate way of
distinguishing an ordinary function from a closure.
And it gets hairier, for instance...
CL > (defun foo(x)
#'(lambda (y)
#'(lambda (z) (* x (+ y z)))))
FOO
CL > (setf bar (funcall (foo 5) 3))
#<closure>
CL > (setf baz (foo 3))
#<closure>
CL > (setf qux (funcall baz 5))
#<closure>
CL > (funcall qux 2)
21
CL > (funcall bar 2)
25
etc.
As for the reponses, what do you expect from posting
something so inflammatory, was it really necessary
to post his letter verbatim? "strong words" was a bit
of an understatement, "rabid foaming" might have been
more accurate. ;-)
------------
Geoff
P.S. Note by _all_ functions I include your C funcall
function as well as those in stdio.h, stdlib.h,
string.h, etc. No point in stopping halfway!
Thomas F. Burdick
> Man you guys are nasty.
You come here posting anonymously, badmouthing a respected figure in
the Lisp community, who's not present, specifically accusing him of
being a liar, academically dishonest, and/or a fool; and you call me
nasty? Go re-read what I wrote. The worst thing I called your friend
was a "jackass" -- hardly the worst insult in the book. Go re-read
the rantings you quoted of his. Those *are* nasty. And either
ignorant or dishonest. Probably ignorant, which wouldn't be
surprising, given that we'd be talking about ignorance of Lisp, which
is generally the case when someone buys an intro to Lisp book.
I have an anecdote here that I can't resist. I met this dumbass
buster who'd "become" buddhist about 6 months before. He kept talking
about how he had this whole new view of the world and how eyes were
open and he could see more clearly than most people. So, he decided
to learn a martial art. He had been to something like 15 different
places, some known for being quite good, but he didn't like the
feeling he got from the instructors. Despite the fact that he didn't
know what he was talking about (how could he? he was there to learn,
right?) he felt that the instructors didn't "get it", but apparently
he did.
Hmm, maybe I meant "allegory" instead of "anecdote".
Geoffrey Summerhayes
"Geoffrey Summerhayes" <sNuOmS...@hNoOtSmPAaMil.com> wrote in message
news:jMWp7.16041$TN5.2...@news20.bellglobal.com...
>
> Lisp, I'd suggest starting with Erik Naggum's code in
> message news:32098542...@naggum.net and add to
>
Oops, wrong message should be
news:32098536...@naggum.net
Thomas F. Burdick
> "Philip M" <a...@b.com> writes:
>
> > Gee thanks. How the hell am I supposed to separate that kind of elitist
> > attitude of the people who program in lisp from lisp itself?
>
> On the evidence presented so far, I think that you will be happier if
> you don't.
>
> For what it's worth, there's a difference between a "jackass" and an
> "asshole". My dictionary defines the former as "male ass" or "stupid
> person"
Exactly, and that's quite a difference. Calling someone an "asshole"
is just being nasty. Calling someone a "jackass" is referring to his
unreasonable, illogical orneriness, much like a male ass. Not the
most pleasant description, certainly, but definitely different.
Feel free to re-read my post and replace "jackass" with "buster", if
it makes you feel better -- they both pretty much capture what I
meant.
Thomas F. Burdick
> But when you barge in like a braying ass, you take your chances.
> Life is hard. Deal with it.
Hey, check it out, I'm not the only one who thought of the same animal here...
(Okay, maybe I should get of usenet and write some code :)
Israel Raj T
>apologizing in advance for any strong words, and you guys start out calling
>my best friend an asshole. Well, there goes your credibility. You know I can
>read and use a compiler too
Hmm...
Sounds like you should stick to C.
Israel Raj T
>* "Philip M" <a...@b.com>
>> How the hell am I supposed to separate that kind of elitist attitude of
>> the people who program in lisp from lisp itself?
>
> Grow smarter? You know, these days, there is a lot of your attitude
> going around, and Arab-Americans get seriously hurt because of it. I
> would have thought that at least _some_ people would grow a clue from
> current events and curb such stupid attitudes as you display here. Also
> consider the fact that you posted a provocative, fairly hateful message,
> and that nobody _really_ believes it is a friend speaking, "friend" is
> just chicken speak for "I cannot stand by this, but I post it anyway".
Never thought that I would applaud something that Eric wrote but this
time I agree wholeheartedly with him !
Aleksandr Skobelev
newsgroup (including me) want to have this book.
I wouldn't mind to get a little present. :)
Philip <p...@yahoo.com> wrote:
> ...
>
> P.P.S. The rest of the book might be great. I'll never find out,
> because I'd rather read a book by someone who gets things right.
>
>
>
> Sorry for my friends strong words,
He is very hot tempered.
Ingvar Mattsson
> Man you guys are nasty.
>
> With the kinds of personalties you have its no wonder that more people don't
> want to program in lisp. Basically I post on here, with a rational post,
> apologizing in advance for any strong words, and you guys start out calling
> my best friend an asshole. Well, there goes your credibility. You know I can
> read and use a compiler too, I'm not a stupid monkey. The way I see it he
> *is* a liar.
>
> Gee thanks. How the hell am I supposed to separate that kind of elitist
> attitude of the people who program in lisp from lisp itself?
OK, let's step back a little bit, here.
Let's look at the following code:
#include <stdio.h>
typedef int (* f_p)(int);
static int k = 0;
int add (int x) { return k + x; } ;
f_p addn(int n) {
k = n;
return add ;
}
Now, let's do the following:
int main (void) {
f_p *a1, *a2, *a3, *a4;
a1 = addn(1);
a2 = addn(2);
a3 = addn(17);
a4 = addn(47);
...
..
.
}
Now keep calling a1, a2, a3 and a4 in an interleaved fashion and tell
me that it is as easy and transparent as it is in lisp.
Elitist we may be, but seeing as how "what you can write in X" is much
closer to "can write in language X with smoething approaching a sane
amount of manual book-keeping"...
//Ingvar
--
My LART is feeding
Blood-eagle on wooden floor
Luser is no more
Tim Bradshaw
> Lately I've been thinking of buying a lisp book. I was thinking of Paul
> graham's book, but my friend pointed out that its not very good. He had a
> problem with the guy lying on the first page. What do you guys think?
Others have pointed out that your friend's code is hopelessly buggy,
and how you can (painfully) implement something which is more
approximately correct in C/C++.
However this isn't really what Graham is talking about I think. It's
trivially (well, not trivially, it took some very smart people to
work out) the case that anything you can express in one language you
can express in another, providing that they are both sufficiently
powerful, and almost all programming languages are sufficiently
powerful. This is the kind of stuff that I guess people learn in 1st
year CS courses.
So the issue can only be how painful it is to do something, not
whether it is doable. Obviously you can implement something
equivalent to closures in C/C++ (even though the code you quote is
*not* equivalent), but it's really a pain to do it: you have to
continually know which bindings you want to close over, and if you
want to close over other things (like blocks) you'd have to do that in
some additional special way. In Lisp this just happens, by magic: the
bindings closed over are those that were visible at the time the
closure was created, similarly with the blocks and so on.
An example of the kind of power that this gives you is stuff like
this:
(defun my-hairy-search (ob)
(let ((results '()))
(do-search ob #'(lambda (e)
(cond ((interestingp e)
(push e results))
((finisherp e)
(return-from my-hairy-search results))
(t nil))))))
Here DO-SEARCH is some function that recurses through OB and calls its
second argument on each element, and OB is some big recursive
structure.
This function is interesting in a number of ways, some of which may
not be apparent to non-Lisp people. First of all, the `capture' of
bindings by the closure just happens, I didn't have to have some
elaborate mechanism. Secondly the block capture also just happens, to
allow the early return from the search if some condition is met. And
this is not just a GOTO to escape: DO-SEARCH (or some function it
calls) may have used UNWIND-PROTECT, and the unwind clauses of those
forms will get run on the way back out. And again, my little closure
doesn't have to know about any of that: the language just deals with it.
Obviously, all this can work in C/C++, but it's so painful to do it
that almost no-one does, to the extent that almost no-one even
recognises what is being done (again, witness the code you quoted).
--tim
Janos Blazi
> time I agree wholeheartedly with him !
Sorry, but it is difficult to agree with you.
(1)
I have read 'ANSI Common Lisp' and it did what I expected from it: it showed
me the first principles of Lisp in a very short time and I could go on to
Steel after that. So the book was all right though I had the feeling that
this book could have been written better. But it was all right and it was
worth the money.
(2)
I suspect that we all believe that Church's Principle is true. So the
statement by Graham, if he really makes this statement, is incorrect. Even
if it is a bona fide statement, it does not do Lisp any good and Lisp does
not need such statements either. It must be allowed to criticize such a
statement. Of course you can not conclude that Mr Graham is a liar, he just
made an incorrect statement. That he had not enough space to make that
statement correct, is of course no excuse.
(3)
Of course it is permitted to flame at a posting that is obviously
malevolent, even if a 'friend' is pretended to be the author.
But showing up any connection between this first posting (possibly by a
troll) and the 'current events', i.e. making the 'current events' a part of
the repertoire Erik uses, is absolutely sick and he really should see a
doctor as things are becoming worse, I am afraid.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Geoff Summerhayes
"Janos Blazi" <jbl...@hotmail.com> wrote in message
news:3ba8d...@news.newsgroups.com...
>
> (2)
> I suspect that we all believe that Church's Principle is true. So the
> statement by Graham, if he really makes this statement, is incorrect.
Even
> if it is a bona fide statement, it does not do Lisp any good and Lisp
does
> not need such statements either. It must be allowed to criticize such
a
> statement. Of course you can not conclude that Mr Graham is a liar, he
just
> made an incorrect statement. That he had not enough space to make that
> statement correct, is of course no excuse.
>
From CLHS:
lexical closure n. a function that, when invoked on
arguments, executes the body of a lambda expression
in the lexical environment that was captured at the
time of the creation of the lexical closure, augmented
by bindings of the function's parameters to the
corresponding arguments.
It boils down to definitions, C functions do not carry around
lexical environments so you can't write a function to return a
C function that does. You can in Lisp. Paul Graham is correct.
The other interpretation is that code can't be written in C to
have similar results. Not true. You can return a struct
containing the lexical environment and a function that takes
that environment as one of its arguments. Paul Graham is wrong.
Now I wonder which interpretation he was going for when he wrote
the statement...
---------
Geoff
Kalle Olavi Niemitalo
> I suspect that we all believe that Church's Principle is true.
What is that principle?
Philip M
spewing, so I'll reply to this one now, since its one of the least hostile.
Speaking to your third point: if you decide what is and is not malevolent so
easily and then allow personal insults and flames based on your flimsy
illogical decision, then don't be surprised if you end up with a forum like
this one.
I detect very much a "russian" personality disorder in Erik's and a bunch of
other people's posts. I'm sure at least half of you where knocking down
shots of vodka and beating your non existent girlfriends as you were writing
your wonderful replies about closure and assholes, excuse me, jackasses.
Alcoholism is a disease, Erik. Heal thyself.
Yes, lisp is closer to language and algebra than C, but C is closer to
computers, so C is going to be faster. Some of the closure discussions were
interesting. However, I'm still having trouble with the absolute statements.
I'm sure it wouldn't be that hard to extend the concept of closure to C to
quickly provide C some of the capabilities of LISP. After all C does have
superior more flexible notation. And, look!, no alcoholism involved!
As for Rob, I'll ask him to post, but given his opinion and your hostile
responses, don't be surprised if things turn out very predictably if he
does. Of-course, one would think that if you guys were good at prediction or
logic, there would be less fanaticism and less flaming. Hmmm. I wonder what
conclusion I should draw?
Philip
"Janos Blazi" <jbl...@hotmail.com> wrote in message
news:3ba8d...@news.newsgroups.com...
Thomas F. Burdick
> I'm having trouble wading through all the antisocial crap that you guys are
> spewing, so I'll reply to this one now, since its one of the least hostile.
>
> Speaking to your third point: if you decide what is and is not malevolent so
> easily and then allow personal insults and flames based on your flimsy
> illogical decision, then don't be surprised if you end up with a forum like
> this one.
I find it difficult to think of any reasonable definition of
"malevolent" that would not apply to a message accusing a prominent,
absent figure of being a liar no less than 7 times. And in case you
hadn't noticed, the animosity was directed against your "friend", not
you.
> I detect very much a "russian" personality disorder in Erik's and a bunch of
> other people's posts. I'm sure at least half of you where knocking down
> shots of vodka and beating your non existent girlfriends as you were writing
> your wonderful replies about closure and assholes, excuse me, jackasses.
> Alcoholism is a disease, Erik. Heal thyself.
Wow, racism and ad hominem attacks. So you really were a troll.
> Yes, lisp is closer to language and algebra than C, but C is closer to
> computers, so C is going to be faster. Some of the closure discussions were
> interesting. However, I'm still having trouble with the absolute statements.
> I'm sure it wouldn't be that hard to extend the concept of closure to C to
> quickly provide C some of the capabilities of LISP. After all C does have
> superior more flexible notation. And, look!, no alcoholism involved!
>
>
> As for Rob, I'll ask him to post, but given his opinion and your hostile
> responses, don't be surprised if things turn out very predictably if he
> does. Of-course, one would think that if you guys were good at prediction or
> logic, there would be less fanaticism and less flaming. Hmmm. I wonder what
> conclusion I should draw?
Lemme guess, "Rob" will be posting from an anonymous yahoo or hotmail
account? I see you had no desire to learn Lisp, and were just wasting
our time. If there really were a Rob, I'd hope you'd have seen that
the overwhelming response from this group was to try to break you
intellectually from this very close-minded fellow, and to try to get
you to actually learn Lisp.
Erik Naggum
> I'm having trouble wading through all the antisocial crap that you guys
> are spewing, so I'll reply to this one now, since its one of the least
> hostile.
Antisocial? The inability to accept responsiblity for one's own behavior
is the core element in any definition of antisocial personality disorders,
and you are a veritable poster boy for just that personality trait.
Add to it that you, like nearly every other antisocial cretin who has
caused flamewars here, have a strong personal need to accuse people of
all kinds of things that are _completely_ insane. Alcoholism? Geez!
> Hmmm. I wonder what conclusion I should draw?
May I auggest the following: That you are way too immature to deal with
people who do not think _exactly_ like you. As you mature, you will find
that being only with people who think exactly like you has kept you back
in your personal development. If you are not very young, you prove this.
///
Matthieu Villeneuve
> Yes, lisp is closer to language and algebra than C, but C is closer to
> computers, so C is going to be faster.
This is simply not true. Anyone who knows a little about compilers and
the principles involved in compilation would disagree with this.
The following text may interest you, especially the paragraph "Myth #1:
Lisp is slow":
http://www.xanalys.com/software_tools/products/myths_and_legends.html
> Some of the closure discussions were interesting. However, I'm still
> having trouble with the absolute statements.
Your statement about speed looks quite "absolute" to me...
> I'm sure it wouldn't be that hard to extend the concept of closure to C to
> quickly provide C some of the capabilities of LISP. After all C does have
> superior more flexible notation.
Could you expand a little about those two ideas?
Thanks,
--Matthieu
Kaz Kylheku
>I'm having trouble wading through all the antisocial crap that you guys are
>spewing, so I'll reply to this one now, since its one of the least hostile.
>
>Speaking to your third point: if you decide what is and is not malevolent so
>easily and then allow personal insults and flames based on your flimsy
>illogical decision, then don't be surprised if you end up with a forum like
>this one.
>
>I detect very much a "russian" personality disorder in Erik's and a bunch of
>other people's posts. I'm sure at least half of you where knocking down
>shots of vodka and beating your non existent girlfriends as you were writing
>your wonderful replies about closure and assholes, excuse me, jackasses.
>Alcoholism is a disease, Erik. Heal thyself.
>
>Yes, lisp is closer to language and algebra than C, but C is closer to
>computers, so C is going to be faster. Some of the closure discussions were
>interesting. However, I'm still having trouble with the absolute statements.
>I'm sure it wouldn't be that hard to extend the concept of closure to C to
>quickly provide C some of the capabilities of LISP.
But then it wouldn't be C any more, but a new language that resembles C.
And don't be so sure that it wouldn't be hard! Consider that a closure
captures local variables. In C, when a statement block terminates, its
local variables disappear; any references to them result in undefined
behavior. C compilers typically implement local variables using a simple
stack. To support closures directly, the support for local variables would
have to be redesigned. You would probably end up needing to implement
garbage collection, because those captured variables that hang around
after the termination of their block have to be cleaned up sometime!
In general, without garbage collection, you would have a hard time
effectively implementing many of the features of a dynamic language,
because if your implementation of these features pushed the computation
of object lifetimes onto the programmer, programs would become vastly
more complicated.
If you think that it's easy to add closures to C, then prove it:
download the GCC sources and hack in the support!
>superior more flexible notation.
C programs cannot construct or transform C code, and then execute
that code. Firstly, the C compiler is not available to a C program
in any portable way. It's possible for a C program to write out
C source into a file and then invoke the compiler as a command using the
system() function, but this is not a standard language feature. The C
standard doesn't specify any way to invoke the translator from a C
program; the translation and execution environment can even be completely
distinct, as is the case with cross-compiling. Even if you
can invoke the compiler from your C program, you have no portable way
to load the resulting object file into the program so that you can
run it in the same environment.
Secondly, the syntax of C makes a terribly inconvenient representation
of program code as data. To read a C program, change it in some way,
and then write out the modified program as C source, requires you to
write a full blown C parser and formatter.
The C syntax is basically a baroque ornamentation which a C compiler
turns into an abstract syntax tree. Why do C compilers do that? So
the can check, manipulate and translate the program using a reasonable
representation! The Lisp notation is very close to writing those abstract
syntax trees directly, so that the programmer can often forget about
the difference between the printed representation and the structure;
the reasonable syntax tree representation is directly available to
the programmer.
Once a convenient representation of a program is available to the
programmer, the next logical step is to allow the programmer to write
code which manipulates that representation: code can be
analyzed and synthesized by code which treats it as a data representation.
And then it can become code again, by undergoing evaluation.
This is what you can do in Lisp. Code and data can be treated
interchangeably, and the evaluation function which turns code into
the semantic action that it calls for is built into the language.
What was that about flexible notation?
Nevertheless, sometimes it is useful to have some syntactic sugar which
lets you express structure in some condensed way. In Lisp there are a
variety of ways to create special notations which trade flexibility for
economy of expression. If you feel jealous that your Perl and C programming
friends can compile modem line noise, you can have that too!
Kaz Kylheku
>computers, so C is going to be faster. Some of the closure discussions were
>interesting. However, I'm still having trouble with the absolute statements.
>I'm sure it wouldn't be that hard to extend the concept of closure to C to
>quickly provide C some of the capabilities of LISP.
But then it wouldn't be C any more, but a new language that resembles C.
Philip M
and will never do so, so help you god? I promise to never do any of those
things in the future, but every once in a while I may have a cherry lambic
or three.
Can I have that in writing?
If you provide that, I promise not to "express my opinion" (or is that
troll - its really so hard to tell) about you any more.
"Erik Naggum" <er...@naggum.net> wrote in message
news:32099293...@naggum.net...
Philip M
some kids what it means?
You do bring up a good point, however. Only half of the animosity was
against me, the other half was probably against fathers and childhoods and
so on.
Anyway, I half apologize. I'm half sorry that the fathers had sons like
these.
As for russians, have you ever met any? I mean, I know its not PC and all,
but really.
A diarrhetic weasel has an easier time keeping his house clean than a
russian has pretending to consider someone elses opinion.
Oh and Thomas, you should take responsibility for your own actions. I think
YOU wasted YOUR time.
I ended up being pleasantly entertained watching a bunch of second graders
jump irrationaly in defending a typical self serving academic who can't be
bothered to curb his criticism of a language that has done far more good
than he ever will.
But then again, I'm good natured by nurture.
Oh "sure", his incorrect statement, which he has had a chance to correct
many times, isn't really a lie. Its merely a, what do you call it, a
faux-pas?
Am I lying, or merely making an incorrect statement?
"Thomas F. Burdick" <t...@conquest.OCF.Berkeley.EDU> wrote in message
news:xcvelp2...@conquest.OCF.Berkeley.EDU...
Philip M
> the principles involved in compilation would disagree with this.
>
Mmmmkay?"
> The following text may interest you, especially the paragraph "Myth #1:
> Lisp is slow":
> http://www.xanalys.com/software_tools/products/myths_and_legends.html
Ok, I read it, it says:
"However, something Lisp does which other languages don't is to allow you to
run code with no type declarations." along with a whole bunch of weasely
triple talk about how you should compare apples to oranges.
Have these people heard of pointers in C? A pointer to the underlying
machine type is the fastest form of C there is. Jeez, what's the problem?
Are all lisp people like this?
> Your statement about speed looks quite "absolute" to me...
True, true. One can not be perfect when playing in the mud.
> > I'm sure it wouldn't be that hard to extend the concept of closure to C
to
> > quickly provide C some of the capabilities of LISP. After all C does
have
> > superior more flexible notation.
>
> Could you expand a little about those two ideas?
Sigh, OK, now I have to make stuff up. Oh wait, I mean "talk", or "post on
usenet".
C (and C++ which has clearly implemented object oriented like closure,
instead of leaving it as an excercise to the user, like C does) has more
notation than Lisp. C has more precise notation. That imprecise notation can
be used to mimic Lisps "Several too many shots of Vodka" notation. Ok?
Philip
P.S. I was the first one to say lisp has "Several too many shots of Vodka"
notation.
Me! It was me!
"Matthieu Villeneuve" <matthieu....@tumbleweed.com> wrote in message
news:3BA9294A...@tumbleweed.com...
> Philip M wrote:
> > Yes, lisp is closer to language and algebra than C, but C is closer to
> > computers, so C is going to be faster.
>
>
> > Some of the closure discussions were interesting. However, I'm still
> > having trouble with the absolute statements.
>
>
> Thanks,
>
>
> --Matthieu
Coby Beck
"Philip M" <a...@b.com> wrote in message
news:Bgaq7.12764$ot.21...@typhoon.ne.mediaone.net...
> Oh please, have you tried looking up the word in the dictionary or asking
> some kids what it means?
>
> You do bring up a good point, however. Only half of the animosity was
> against me, the other half was probably against fathers and childhoods and
> so on.
> Anyway, I half apologize. I'm half sorry that the fathers had sons like
> these.
>
> As for russians, have you ever met any? I mean, I know its not PC and all,
> but really.
> A diarrhetic weasel has an easier time keeping his house clean than a
> russian has pretending to consider someone elses opinion.
>
I think it is pretty clear there is nothing from this idiot that should be
taken seriously (it was clear at his second posting). Replying to him only
feeds him and wastes time and space....
> I ended up being pleasantly entertained watching
Who wants to give pleasure to such a jackass?
The faster he is ignored the sooner he will leave.
Boris Schaefer
| I suspect that we all believe that Church's Principle is true. So
| the statement by Graham, if he really makes this statement, is
| incorrect. Even if it is a bona fide statement, it does not do Lisp
| any good and Lisp does not need such statements either. It must be
| allowed to criticize such a statement. Of course you can not
| conclude that Mr Graham is a liar, he just made an incorrect
| statement. That he had not enough space to make that statement
| correct, is of course no excuse.
Bringing the Church-Turing Thesis[1] into play to argue that Paul
Graham is incorrect is as stupid as saying:[2]
Of course Paul Graham is correct. You really cannot write ADDN in
C, because (DEFUN ADDN (N) (LAMBDA (X) (+ X N))) is not a legal C
program.
Both viewpoints totally miss the point of Paul Graham's statement.
| But showing up any connection between this first posting (possibly
| by a troll) and the 'current events', i.e. making the 'current
| events' a part of the repertoire Erik uses, is absolutely sick and
| he really should see a doctor as things are becoming worse, I am
| afraid.
Have you actually tried to understand what Erik said, instead of just
turning your sickness alarm on, when you read the words "current
events"?
Boris
[1] I assume you mean the Church-Turing Thesis, when you say Church's
Principle, but I'm not sure if that's really what you mean.
[2] I consider the Church-Turing Thesis to be the most thoroughly
abused concept in language wars. It only says that it is always
possible to write a program A in Turing-equivalent language LA
that behaves exactly like some other program B in some other
Turing-equivalent language LB. It doesn't say anything about
whether A and B look somehow similar, or are vastly different, or
whether A took 10 times longer to write than B.
Actually, since the proof relies on the fact that it is always
possible to write an interpreter for LB in LA, I wonder, can there
any programs in LA for which you MUST write an interpreter for LA,
to solve it. That is, are there Lisp programs for which you MUST
write a Lisp interpreter in C, to get the program written in C?
--
bo...@uncommon-sense.net - <http://www.uncommon-sense.net/>
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain
Janos Blazi
> turning your sickness alarm on, when you read the words "current
> events"?
No, I did not. I turned on my 'sickness alarm' immediately. I did not try to
fathom that sickness.
> [1] I assume you mean the Church-Turing Thesis, when you say Church's
> Principle, but I'm not sure if that's really what you mean.
Yes. We in Germany call it Church's Thesis and sometimes the Church-Turing
Thesis. (Sometimes they even use a third name I forgot. Maybe Post?)
> [2] I consider the Church-Turing Thesis to be the most thoroughly
> abused concept in language wars.
I do not know if this is true as I do not participate in those wars, but
Chuch's Thesis does not say anything about the practical usability of a
language.
> It only says that it is always
> possible to write a program A in Turing-equivalent language LA
> that behaves exactly like some other program B in some other
> Turing-equivalent language LB. It doesn't say anything about
> whether A and B look somehow similar, or are vastly different, or
> whether A took 10 times longer to write than B.
First, this is not what is meant by Church's Thesis, but I am not going into
this.
And in principle you are right. You cannot expect from an intelligent
assembly language like C to measure up to Lisp's power to realize abstract
and subtle concepts. But then he should have put it the way as you did (if
he really makes such a statement).
Hartmann Schaffer
"Philip M" <a...@b.com> writes:
> ...
> Have these people heard of pointers in C? A pointer to the underlying
> machine type is the fastest form of C there is. Jeez, what's the problem?
> Are all lisp people like this?
>> > I'm sure it wouldn't be that hard to extend the concept of closure to C
> to
>> > quickly provide C some of the capabilities of LISP. After all C does
> have
>> > superior more flexible notation.
>>
>> Could you expand a little about those two ideas?
>
> Sigh, OK, now I have to make stuff up. Oh wait, I mean "talk", or "post on
> usenet".
>
> C (and C++ which has clearly implemented object oriented like closure,
> instead of leaving it as an excercise to the user, like C does) has more
> notation than Lisp. C has more precise notation. That imprecise notation can
> be used to mimic Lisps "Several too many shots of Vodka" notation. Ok?
am i the only one who gets the impression that someone forgot to lock
the terminal in the administration office of the asylum for the insane
beyond hope of any cure?
hs
--
War is not healthy for children and other living beings
Matthieu Villeneuve
please realize that reading the first chapter of "Computers for dummies"
does not make you an expert in programming. So grow up, learn, and then
you may come back.
--Matthieu
Patrick
> [...] showing up any connection between this first posting (possibly
> by a troll) and the 'current events', i.e. making the 'current
> events' a part of the repertoire Erik uses, is absolutely sick and
> he really should see a doctor as things are becoming worse, I am
> afraid.
Either you have missed Erik's point completely, or you're engaging in
tactics more worthy of a hyena than a man.
I suggest that if you want to continue this, you should read Erik's
posting one more time, then get back to us. It'll clarify whether
you're simply mistaken, or whether you're as cunningly malicious as
you now seem.
Espen Vestre
> am i the only one who gets the impression that someone forgot to lock
> the terminal in the administration office of the asylum for the insane
> beyond hope of any cure?
every now and then we get a reminder that it has been september
for more than 8 years now :-(
--
(espen)
Patrick
> am i the only one who gets the impression that someone forgot to lock
> the terminal in the administration office of the asylum for the insane
> beyond hope of any cure?
Nah, there's hope for him yet. (It'll cost at least $47 though).
Meantime, sit back and enjoy the interesting spectacle of a man
disrobing himself in a public place and haranguing the passersby.
Something is compelling our Philip to humiliate himself here. It
doesn't require much psychological acumen to figure out what's going
on ... but it makes for a potentially amusing drama.
The question is: How far will Philip go before he figures it out for
himself? What will happen when he does?
It's ironic that young Philip takes an interest in "Russian" character
traits. I know of no other literature that deals so often and so well
with the theme of a somewhat naive and self-inflated buffoon talking
and acting himself out on a limb and finding himself with nowhere left
to go but deeper and deeper into self-humiliation. And then,
occasionally ... well ... we'll have to wait and see, I guess.
After his last devastatingly insightful foray into the equivalence of
dynamic typing and "pointers in C" (which you Lispers can't be
expected to understand, hehe), it's clear that he's already quite
naked. So what next?
Well, he seems to enjoy strutting the nuts before a chuckling
audience, so I guess we won't have to wait long to find out.
Boris Schaefer
| * Boris Schaefer wrote:
|
| > Have you actually tried to understand what Erik said, instead of just
| > turning your sickness alarm on, when you read the words "current
| > events"?
|
| No, I did not. I turned on my 'sickness alarm' immediately. I did
| not try to fathom that sickness.
How can you say something's "absolutely sick", if you didn't even try
to understand it? In my opinion that's probably the hallmark of
stupidity.
| > [1] I assume you mean the Church-Turing Thesis, when you say
| > Church's Principle, but I'm not sure if that's really what
| > you mean.
|
| Yes. We in Germany call it Church's Thesis and sometimes the
| Church-Turing Thesis. (Sometimes they even use a third name I
| forgot. Maybe Post?)
No. I, at least, in Germany call it the Church-Turing Thesis.
| > [2] I consider the Church-Turing Thesis to be the most thoroughly
| > abused concept in language wars.
|
| I do not know if this is true as I do not participate in those wars,
| but Chuch's Thesis does not say anything about the practical
| usability of a language.
You do just now. This thread is a language war, in case you haven't
noticed.
| > It only says that it is always possible to write a program A
| > in Turing-equivalent language LA that behaves exactly like
| > some other program B in some other Turing-equivalent language
| > LB. It doesn't say anything about whether A and B look
| > somehow similar, or are vastly different, or whether A took 10
| > times longer to write than B.
|
| First, this is not what is meant by Church's Thesis, but I am not
| going into this.
Yes, you are right, this is not what is said by the Church-Turing
thesis. I'm sorry, I really meant Turing-equivalence as the most
thoroughly abused concept, but I was confused.
Boris
I dote on his very absence.
-- William Shakespeare, "The Merchant of Venice"
Janos Blazi
impressionthat he meant the following: Only beceause we think that the
terrorist attack was undertaken by people of Arab nationality, we must not
treat *all* people of Arab nationality as criminals.
I admit I did not ponder upon the subtle meaning of his words.
And I should subscribe to his pont of view if I am right and this is what he
meant. This was not my point.
I mean the very talking about those events in the context of a newsgroup on
computer languages is a sacrilege and so utterly tasteless that I cannot put
it into words.
Philip M
I'll get on that learning thing any day now.
Excpect great results soon, and thanks for your help.
Philip
"Matthieu Villeneuve" <matthieu....@tumbleweed.com> wrote in message
news:3BA959FD...@tumbleweed.com...
Philip M
haven't read that much, but the little I have read (some of which was no
doubt targeted at pointing out to adolescents how stupid they are and how
they must learn from the wisdom of their elders) usually is very depressing.
Actually this whole business of learning from very smart people which you
magically find on usenet (I would have thought that the first thing that you
get when you look in the sewer is rats) is very related to the first
definition of irony:
socratic irony which means:
http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=irony
1 : a pretense of ignorance and of willingness to learn from another assumed
in order to make the other's false conceptions conspicuous by adroit
questioning -- called also Socratic irony
Of-course half of these rats degenerated to personal insults very very
quickly. I guess they have been Pavlovian trained. Maybe we should update
the definition of irony (since these modern whipper-snappers don't seem to
sit still for questioning) to include questioning *and* personal insults -
the number one russian patented learning technique.
Aside from the people ivolved in the "does the theory of Munchkins prove
that the sky really is blue" thread, all the original posters seem to have
left. I guess they were offended when someone attempted to learn from what
they said, and not what they "meant".
"Patrick" <xu...@yahoo.com.au> wrote in message
news:87vgie5...@xeno.localhost...
Philip M
like you are scum. A circle of academics is a great opportunity for a
bonfire. All books should be burned. Oh, wait now I've gone too far! All non
sci-fi books should be burned to improve the book gene pool.
I quote from one of your previous posts:
>YOU sir, are not just a troll, but you are also an ASS...
"Note that the distinction usually goes to the first one to use the word."
Now, who was the first one to use the word ass? Repeat after me: "I was!"
Why would I want to have credibility with you? Having credibility with you
is like asking a russian: "Who killed JFK, Mr. Russian?"
"Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
news:zTSp7.23616$jY.5...@news1.rdc1.bc.home.com...
> In article <PLRp7.7920$ot.11...@typhoon.ne.mediaone.net>, Philip M
wrote:
> >Man you guys are nasty.
>
> Is there no depth to your arrogance and imbecility?
>
> You started this thread by accusing an author of lying. In polite
> academic circles, you do not assume that someone is lying when he
> appears to have made a mistake. And you do not assume that someone has
> made a mistake when he presents facts that appear to conflict with
> your present understanding. You take the humble position that *your*
> understanding is wrong. Then if you are lucky, you can work from there to
> show that *he* made a mistake. Only if you can show some kind of
> academic or scientific misconduct can you accuse someone of deliberate
> dishonesty; for example, a researcher who falsifies results to
> fit his hypotheses is a liar.
>
> Before you accuse others of being nasty, consider the tone
> of your best friend's letter:
>
> "Even if it was a mistake and not a lie, he's a fucking
> professor in comp sci, he should know about what can and
> can't be written in C."
>
> Now your friend can be excused for using this tone when writing to
> you. But you are the one who chose to publish that correspondence.
> Since you have not named your friend, as far as anyone knows
> you are the sole author of this vociferous diatribe, and
> the invocation of a third party is just a ploy to deflect heat.
>
> >With the kinds of personalties you have its no wonder that more people
don't
> >want to program in lisp. Basically I post on here, with a rational post,
> >apologizing in advance for any strong words, and you guys start out
calling
> >my best friend an asshole.
>
> As far as anyone knows, your best friend is merely ignorant, if indeed
> he is real. *You* are the asshole.
>
> >Well, there goes your credibility.
>
> You, on the other hand, moments ago, missed an opportunity to
> discover what it feels like to lose credibility, for lack of it.
Raymond Wiker
*plonk*
--
Raymond Wiker
Raymon...@fast.no
Philip M
that "American people target Arab-Americans because Americans are assholes"
There are many things wrong with that statement, the biggest beaing that tv
trains americans to target dark skinned people with beards (much bigger than
just arabs).
Nor is it the "stupidity" of Americans that causes this to happen, but I
think I have had enough of this, and I''l refrain from talking about stuff
unrelated to lisp.
"Israel Raj T" <isra...@optushome.com.au> wrote in message
news:04ggqt41j3uj4g5ij...@4ax.com...
> On Wed, 19 Sep 2001 02:10:36 GMT, Erik Naggum <er...@naggum.net> wrote:
> >* "Philip M" <a...@b.com>
> >> How the hell am I supposed to separate that kind of elitist attitude of
> >> the people who program in lisp from lisp itself?
> >
> > Grow smarter? You know, these days, there is a lot of your attitude
> > going around, and Arab-Americans get seriously hurt because of it. I
> > would have thought that at least _some_ people would grow a clue from
> > current events and curb such stupid attitudes as you display here.
Also
> > consider the fact that you posted a provocative, fairly hateful
message,
> > and that nobody _really_ believes it is a friend speaking, "friend" is
> > just chicken speak for "I cannot stand by this, but I post it anyway".
Erik Naggum
> I mean the very talking about those events in the context of a newsgroup
> on computer languages is a sacrilege and so utterly tasteless that I
> cannot put it into words.
Good. Keep not putting it into words. Preferably elsewhere.
///
Daniel Barlow
> Actually, since the proof relies on the fact that it is always
> possible to write an interpreter for LB in LA, I wonder, can there
> any programs in LA for which you MUST write an interpreter for LA,
> to solve it. That is, are there Lisp programs for which you MUST
> write a Lisp interpreter in C, to get the program written in C?
(loop (print (eval (read))))
OK, I guess you could write a compiler instead ...
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Patrick
> I can't say that I agree with your statement about russian literature, I
> haven't read that much, but the little I have read (some of which was no
> doubt targeted at pointing out to adolescents how stupid they are and how
> they must learn from the wisdom of their elders) usually is very depressing.
>
> Actually this whole business of learning from very smart people which you
> magically find on usenet (I would have thought that the first thing that you
> get when you look in the sewer is rats) is very related to the first
> definition of irony:
>
> socratic irony which means:
> http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=irony
> 1 : a pretense of ignorance and of willingness to learn from another assumed
> in order to make the other's false conceptions conspicuous by adroit
> questioning -- called also Socratic irony
Ah yes. Socratic irony and rats on usenet. I see the connection. Very
good.
But what kind of irony results when the "willingness to learn" may
indeed have been genuine, the other's conceptions are definitely not
false, the ignorance of the questioner is painfully and shamelessly
real, and the line of "questioning" is anything but 'adroit'? It's no
longer Socratic irony, but what is it?
Assuming you agree that the complete inversion of all four citeria
(three of them for certain) makes a slightly different kind of irony,
what should we call it?
> Of-course half of these rats degenerated to personal insults very
> very quickly. I guess they have been Pavlovian trained.
That's right. The knee-jerk reaction is all they know. I guess if you
stick around (and bring your best buddy) together we might teach 'em
how to get beyond Page 2 one of these days.
And, you know, something else that's ironic: many of these Lisping
cretins have been using C for decades, and STILL haven't figured out
that pointers and structs make Lisp redundant! It's all a big wank!
(No wonder they're upset, Phil).
> Aside from the people ivolved in the "does the theory of Munchkins prove
> that the sky really is blue" thread, all the original posters seem to have
> left. I guess they were offended when someone attempted to learn from what
> they said, and not what they "meant".
Yeah, but you know what they're like. They'll probably try to refute
this argument by claiming you didn't understand what they meant, and
therefore don't know how to evaluate what they said. It's a filthy
tactic, and it's part of their lousy alcoholic Russian vodka-swilling
wife-beating salivating Lisping Pavlovian rat mentality.
But have pity, Phil. It's a self-defense mechanism, you see? They
don't want to look as dense as they are, so they insult you. If they
had any sense, they might have temporarily swallowed their pride and
tried to learn from you (and your high-principled best mate who
insists on "getting it right"). But it's too late for that. They
missed the opportunity this time around. (But they'll be back. Count
on it).
I'll leave you the last word Philip, but one genuine suggestion first:
read the book, or try Peter Norvig's "Paradigms of Artificial
Intelligence - Case Studies in Common Lisp" instead. Chances are
you'll find both books packed with new ideas that you theoretically
CAN but, in practice, DON'T don't get from C or any other language. If
you do that, it'll more than compensate for any perceived inaccuracy
on page 2 of Graham. (And if not, so be it).
Best of luck. See you 'round, perhaps.
P.
Geoffrey Summerhayes
> > This is simply not true. Anyone who knows a little about compilers and
> > the principles involved in compilation would disagree with this.
> >
> There's that absolut vodka again. Repeat after me : "Alcohol is bad.
> Mmmmkay?"
>
> > The following text may interest you, especially the paragraph "Myth #1:
> > Lisp is slow":
> > http://www.xanalys.com/software_tools/products/myths_and_legends.html
>
> Ok, I read it, it says:
>
> "However, something Lisp does which other languages don't is to allow you
to
> run code with no type declarations." along with a whole bunch of weasely
> triple talk about how you should compare apples to oranges.
>
> Have these people heard of pointers in C? A pointer to the underlying
> machine type is the fastest form of C there is. Jeez, what's the problem?
> Are all lisp people like this?
<rant>
Has this person heard of assembly language? Blows the
doors off C, the way compilers ignore inline directives
is shameful, writing in a set of mnemonics that
translate directly into machine code obviates all
of that "my code optimizer is better than yours" crap.
MY code optimizer _is_ ME. BWAH HAH HAAA!
Better yet, I avoid all those "my language is better
than yours" arguments because all that C/FORTRAN/LISP
shit is being translated into what I'm writing. So
what makes C soooooo much better? I can write faster,
more efficient code. Working directly with machines
types is the fastest form _period-dot-the-i's_ there
is. Jeeez, what's the problem? Are all C people like
this?
>
> be used to mimic Lisps "Several too many shots of Vodka" notation. Ok?
>
Obviously one too many J.D.'s. Mmmmkay? Repeat after me:
Alcohol is bad. (Unlike you, I admit I'm trolling)
Seriously, by comparing times/space of higher level languages,
you aren't comparing the languages, you're comparing the
`state-of-the-art' compiler for those languages.
Forth will do better then C on most stack based processors
and quite a few others that don't, depending how much you
allow a language to `cheat' i.e. __asm__
The difference in real-time may be miniscule, not worth
bothering about. Or it MIGHT be, it depends on requirements.
Lisp is a higher level language than C, it is farther
removed from _current_ machine architectures. Learning,
using, and dealing with a language is your choice, if
runtime speed is your major problem, switch to machine code.
There are a lot of languages that handle specific problems
better but Lisp is the best `general' language I've seen,
it handles most problems well. Did you think the introduction
of templates in C++ was a virgin birth?
</rant>
:-):-):-):-)(-:(-:(-:(-:(-:
Phew,
Geoff
Raymond Wiker
> Seriously, by comparing times/space of higher level languages,
> you aren't comparing the languages, you're comparing the
> `state-of-the-art' compiler for those languages.
> Forth will do better then C on most stack based processors
> and quite a few others that don't, depending how much you
> allow a language to `cheat' i.e. __asm__
> The difference in real-time may be miniscule, not worth
> bothering about. Or it MIGHT be, it depends on requirements.
> Lisp is a higher level language than C, it is farther
> removed from _current_ machine architectures. Learning,
> using, and dealing with a language is your choice, if
> runtime speed is your major problem, switch to machine code.
Note that a high-level language can allow *much* better
optimisation than a low-level language. I heard of one example where a
certain algorithm was implemented in heavily optimised C. The same
program was then implemented in (a subset of) Scheme, translated to C
(via a compiler called "Stalin"), and compiled. The Scheme version ran
17 times faster than the hand-optimised C code.
--
Raymond Wiker
Raymon...@fast.no
Tim Bradshaw
> Has this person heard of assembly language? Blows the
> doors off C, the way compilers ignore inline directives
> is shameful, writing in a set of mnemonics that
> translate directly into machine code obviates all
> of that "my code optimizer is better than yours" crap.
> MY code optimizer _is_ ME. BWAH HAH HAAA!
> Better yet, I avoid all those "my language is better
> than yours" arguments because all that C/FORTRAN/LISP
> shit is being translated into what I'm writing. So
> what makes C soooooo much better? I can write faster,
> more efficient code. Working directly with machines
> types is the fastest form _period-dot-the-i's_ there
> is. Jeeez, what's the problem? Are all C people like
> this?
Wimp. Real programmers don't waste their time on that assembler
language crap. Real programmers write their programs in silicon.
--tim
Eduardo Muñoz
> Wimp. Real programmers don't waste their time on that assembler
> language crap. Real programmers write their programs in silicon.
Or worse even :)
I like this story:
http://www.tuxedo.org/~esr/jargon/html/The-Story-of-Mel.html
--
Eduardo Muñoz
pj
LOL.
Sorry for the redundant post.
But couldnt help it.
I will go back to lurking now..
Geoff Summerhayes
"Tim Bradshaw" <t...@cley.com> wrote in message
news:ey366ac...@cley.com...
>
> Wimp. Real programmers don't waste their time on that assembler
> language crap. Real programmers write their programs in silicon.
>
Poofdah. Kids and their silicon implants. Oh, for the good old days,
a sheet of core and a bar magnet.
-Geoff
Dr. Shlomo Argamon
"Geoff Summerhayes" <sNuOmS...@hNoOtSmPaAiMl.com> writes:
Spoiled moderns! Give me a bunch of gears and rods any day!
-Shlomo-
Tim Bradshaw
Gears, rods, hah. We had to mine our own iron ore and coal, and
invent blast furnaces before we could get our machine running. In the
snow. 15 miles (that's imperial miles, none of yer modern metric
nonsense), and uphill both ways, mind you.
--tim
We had to collect our own garbage too - I hear some people living in
very backward parts still do that.
Israel Raj T
>Wimp. Real programmers don't waste their time on that assembler
>language crap. Real programmers write their programs in silicon.
Real programmers use qubits.
Reini Urban
>OK, let's step back a little bit, here.
>Let's look at the following code:
>
>#include <stdio.h>
>typedef int (* f_p)(int);
>static int k = 0;
>int add (int x) { return k + x; } ;
>f_p addn(int n) {
> k = n;
> return add ;
>}
>
>
>Now, let's do the following:
>
>int main (void) {
> f_p *a1, *a2, *a3, *a4;
>
> a1 = addn(1);
> a2 = addn(2);
> a3 = addn(17);
> a4 = addn(47);
>
>...
>..
>.
>}
>
>
>Now keep calling a1, a2, a3 and a4 in an interleaved fashion and tell
>me that it is as easy and transparent as it is in lisp.
>
>Elitist we may be, but seeing as how "what you can write in X" is much
>closer to "can write in language X with smoething approaching a sane
>amount of manual book-keeping"...
Besides Eric Naggum's trick, you can also do some insane lexical
closures (say n private k's, not only one global k) in C with a library,
which actually stores lexical data with each dynamically constructed
function:
Bruno Haible's libcallback from ffcall which comes with clisp.
http://clisp.cons.org/~haible/packages-ffcall.html
The drawback is that it needs inline assembler, is not portable and is
not pure C. With pure C alone you can never ever get to dynamic lexical
closures lisp offers.
what you have are n static closures closed over one k only, not over n
k's.
>> 2) If Graham wanted to produce a more extensive snippet of
lisp to demonstrate the behaviour above, and then said you
couldn't do that in C, he would still be liar. This is
because you would solve that problem by having static
structures which kept track of the related function
pointers and k variables. It would be a few more lines of
code that you would have to write carefully, but you can do
it. I just want to make sure that I pre-emptively call
Paul Graham a liar just in case he makes that statement.
Well, can create an static array of n "static" k's, connected to n
static functions.
But how do you do dynamic static structures in C then? not talking about
dynamic functions. this is not just "a few more carefully written lines
of code". this is impossible without the stack manipulation tricks eric
showed you for a fixed number or args or the enhanced trampoline from
ffcall, which offers a variable number of args.
nevertheless, this still offers less than lisp, but EVAL and CLOS is
another story.
--
Reini Urban
http://tv.mur.at/film/
Rob Warnock
+---------------
| "Geoff Summerhayes" <sNuOmS...@hNoOtSmPaAiMl.com> writes:
| > "Tim Bradshaw" <t...@cley.com> wrote:
| > > Wimp. Real programmers don't waste their time on that assembler
| > > language crap. Real programmers write their programs in silicon.
| >
| > Poofdah. Kids and their silicon implants. Oh, for the good old days,
| > a sheet of core and a bar magnet.
|
| Spoiled moderns! Give me a bunch of gears and rods any day!
(*sigh*)
Full circle we now come. Thank you, Ivan Sutherland, for describing such
wheels of reincarnation. <URL:http://citeseer.nj.nec.com/context/72129/0>
I refer, of course, to the nanotech guys' plans for gear & rod computers...
-Rob
-----
Rob Warnock, 30-3-510 <rp...@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]
Hartmann Schaffer
real men do it with their fingers
hs
--
War is not healthy for children and other living beings
Israel Raj T
Schaffer) wrote:
>> Spoiled moderns! Give me a bunch of gears and rods any day!
>real men do it with their fingers
Semaphores
Drums
Smoke signals
Oh, these decadent children...
Janos Blazi
> >> a sheet of core and a bar magnet.
> >
> > Spoiled moderns! Give me a bunch of gears and rods any day!
>
> real men do it with their fingers
In Hungary, where I come from, only boys did it with their fingers. (Sorry.)
Hartmann Schaffer
"Janos Blazi" <jbl...@hotmail.com> writes:
>> >> Poofdah. Kids and their silicon implants. Oh, for the good old days,
>> >> a sheet of core and a bar magnet.
>> >
>> > Spoiled moderns! Give me a bunch of gears and rods any day!
>>
>> real men do it with their fingers
>
> In Hungary, where I come from, only boys did it with their fingers. (Sorry.)
why sorry? are you trying to imply that real men don't use their
fingers or that hungarians are not real men? ;-)