Re: Seeking computer-programming job (Sunnyvale, CA)

[Pascal J. Bourguignon]

GENSYM generates a symbol that is not interned in any package; in

This has already been repeated 5 times in this thread. The guy won't
learn, no matter what you may write on usenet. The only way left is
to hit him on the head. Are you prepared to buy a rule and pay the
flight fare to go see him and do the needed pedagogical actions? If
not, PLEASE, just leave it, stop posting in this thread.

 

[Adlai]

On May 20, 1:40 pm, Adlai <[email protected]> wrote:

[a missing attribution goes here]

This again. The point is that the dispatch table belongs to a generic
function, and that function's name is in some particular package. The
dispatch table thus effectively belongs to that package.

Most computer programmers consider the things named to belong to
namespaces however their names belong, as a convenient shorthand. Why
you Lispers apparently feel the need to remind people constantly that
only the names technically and directly do, I do not know, but it
complicates and slows down communication to eschew the useful
shorthand.

Because names and symbols are different things in Lisp. Names are
symbol's printed representations. If a symbol is within the current
package, there's no need to distinguish between its name and the
symbol itself. If the symbol is not internet in ANY package then
they're distinct, and in fact a one-way connection -- the name doesn't
help you one bit in locating the symbol.

- Adlai

 

[Adlai]

The really interesting thing in this trash is how fast the various
"entities" respond, just check the posting time.  Perhaps the fricken
idiot humans still posting can check that and see exactly how good
Eliza-Expansion or whatisname have been coded.  Java is good for
something it appears.

I declare Turing Test victory!

Actually, I think Eliza is too big a compliment for these folks... I
would guess Henley.

To read about Henley, look at section 8.8 of ANSI Common Lisp by Paul
Graham. This book is not available online, though the code is, so you
could look the code up there... or just seach the text "henley" on one
of these pages:
http://www.perlmonks.org/?node_id=494297
http://www.cs.northwestern.edu/academics/courses/325/exercises/graham-exs.html

- Adlai

 

[Series Expansion]

That was not a personal attack, but noting a fact.

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne, "Lew", and Adlai.

 

[Thomas M. Hermann]

Sure looked like you were.

That is what you perceived. I responded to clarify.

Why? Very few people in the world tend to keep Lisp texts lying around.
Probably mostly just you guys.

My sentence concluded "... because you had been repeatedly given
references to freely accessible Lisp texts including the language
standard." If you had read the entire sentence, there would have been
no reason to ask why.

No, that also would have been incorrect.

There were three possibilities, (1) you have a problem, (2) you have
no interest in understanding Common Lisp and (3) you don't have a lisp
text. Possibility (1) is outside the scope of this discussion. You had
repeatedly been given the means to rectify possibility (3) prior my
response. Consequently, possibility (2) was the only one remaining.
The fact that you have been given the means to rectify possibility (3)
and have not further supports possibility (2).

There! You just did it again -- you argued!

No I didn't.

I have had no misunderstandings, save perhaps when one of you has made
an erroneous or otherwise misleading statement here.



That's an exceedingly odd thing for you to say shortly after saying
things contradicting things that both of us have said AND after
insulting me personally.

You have not been insulted personally by me, ever. Conversely, you
have insulted me.

I referred to your conspicuous omission of two levels of quoted
material, quotation of some other material, and then giving your signoff
without any more topical text of your own.

All omissions were noted. Enough context was left to support the
discussion.

P.S. I noticed that you selectively clipped the quotations of my
responses [rest of accusation of dishonesty deleted]

I did sometimes elide pointless and insulting parts, leaving only what
was relevant to the issue of Java vs. Lisp, in the interests of decorum,
clarity, and avoiding unnecessary distractions from the topic at hand.

The omissions contained points, you insult me calling them pointless.


Do you, Seamus MacRae, have an interest in learning and understanding
Common Lisp?

 

[Series Expansion]

This is false.

You are being illogical.

And I told you Lisp macros are functions.  They can expand into
anything computable, not just "some code, inside which placeholders
are replaced with copies of the call's arguments"

If they don't expand into code, then the result after applying the
macro will not compile. So a functional macro does expand into "some
code". And when macros have arguments, these are typically not ignored
but, rather, used as inputs to that function, generally by
substituting them for something in the expansion.

Regardless, the key point I am making is that "a variable name that
will not collide with any variable name in any enclosing scope" is not
computable from just the arguments -- it is only computable from the
entire code base, or a large fraction thereof.

 

[Series Expansion]

That's like saying tools are tools are tools.

Did you have a point?

Macros have certain features in common. So do tools. One can reason
about them without knowing more about the specific type, although with
less information one can draw fewer conclusions. For instance, if all
one knows is that an object is a tool, one cannot immediately infer
that it is heavy. One can however infer that it is useful in some
manner and probably an artifact of human civilization. Likewise with a
macro, one can infer it will be expanded in some manner, replaced with
some deterministic function of its arguments.

 And there are some situations where some tools are known to be dangerous.
 Therefore you want to disallow tools.

I don't want to disallow anything, except possibly illogical arguments
and pointless personal attacks.

Your "leap of logic" here is akin to if I had said that 400-volt 10-
amp electricity is dangerous and that that high a power level would be
unwise to employ in home wiring, and you responded by accusing me of
advocating to have electric power banned entirely.

You should also keep in mind that when you argue with Lisp novices about
the advantages and disadvantages of various Lisp features, you aren't
necessarily learning as much as you think you are.

Are you, then, admitting to be novices? This explains your internal
contradictions and apparent inability to make a good impression or
present a coherent case for preferring Lisp over Java. However, it
prompts a new question: if you are novices, then why have you insisted
on playing the role of a "know-it-all" and why have you been so
certain that it is superior to Java? Your inability to back the latter
up with convincing arguments, and apparent need to resort to personal
attacks to press your points home and even to change the subject
entirely away from Lisp, to me indicates that you have no proof
whatsoever of your claim of its superiority. In which case your
starting and continuing this argument is clearly illogical.

As I said before, it's useless for us to try to explain the advantages of
CL macros

Perhaps, but not for the reasons you think. The apparent fact that you
are novices yourselves may have more to do with this.

there is a powerful synergy in their advantages, such that you could
memorize a list of their advantages and still not get it, till you have
enough experience with them to become aware of that synergy.

This borders on an expression of religious faith. Only the initiated
can understand, we cannot or will not explain things to lay persons,
logic is irrelevant, and so forth.

I have little interest in joining your mystery cult, or any other. I
believe in the ability of thinking minds to communicate, explain, and
understand any abstract subject matter, if it is explained coherently
enough; that is, in the power of general-purpose intelligence. This is
diametrically opposed to any belief that there are things that "only
the initiated can understand", or similar statements that have been
implied by some of your assertions.

Most of the macro fears you express here are not even significant in CL.

It is for each individual user or potential user to judge for himself
what problems are or are not "significant".

The kinds of bugs that happen in actual practice with macros are easy to
see and easy to fix.

Extraordinary claims require extraordinary evidence, and as yet you
have furnished nothing of the sort.

 And even if they weren't, the extra effort to fix them
would be worth it, because CL macros are so powerful that they enable one
programmer to do the work of dozens.

Extraordinary claims require extraordinary evidence.

 C macros don't provide any such power, which should tell you that CL
and C macros are two different usages of the word "macro" with two
different meanings.

Not 100% different, and my objections have been primarily based on
specific knowledge of CL macros. None have yet addressed my
observation that a variable name guaranteed to avoid capture cannot be
reliably computed by any function of a macro's arguments, except for
the case that the arguments contain the entire rest of the code base
aside from the invocation itself and the macro's definition.

 

[Series Expansion]

You agree in principle, but argue about practice, without any actual
practice to support such arguments.

Perhaps not in Common Lisp development projects, but you assume I have
no experience with large scale development efforts at all, without
evidence that this is so. What I said about chaos resulting from lack
of encapsulation and temptation was in no way specific to Lisp.

 And even agreeing in principle, you don't understand what you're agreeing
with.  What exactly did you think I meant by "DSL"?

Domain-specific language, though it does not seem to be relevant to
the matter under debate, to whit, what happens in large programming
teams when encapsulation is absent or weak.

In any case, CL has far better encapsulation than any other programming
language I've ever used.  And I've used a lot of them.

This statement is contradicted by your own prior testimony and other
available evidence. Anyone can get at any symbol from anywhere in the
code base, even supposedly "private" (non-exported) ones. Classes
don't encapsulate their data together with their behavior. Macros
don't encapsulate their own output from their call sites, unlike
normal function bodies. Need I go on?

 Your "absence of much encapsulation in Lisp" is absurd.

Your tiresome personal attacks do not constitute rational arguments in
favor of either Lisp or Java.

 

[Series Expansion]

It's easy to run Thunderbird and Firefox in different windows more or
less simultaneously, so that doesn't invalidate the highly plausible
hypothesis that you and Seamus are one and the same person.

That hypothesis is nonetheless:
a) Wrong.
b) Off-topic for both newsgroups.
c) Irrelevant in a debate about which is better, Lisp or Java.
d) Speculation about persons, made publicly, that at least one of
those
persons considers unwelcome.
e) Speculation about matters that would be none of your business
no matter what.

Any single one of those items is reason enough why it shouldn't have
been posted and why you shouldn't continue to discuss it.

Please return to the topic at hand, namely which is better, Lisp or
Java.

 

[Series Expansion]

This remark by Arne is unsupported by any evidence.

As explained previously, I find it necessary to assume that all
insults aimed at "Paul D." here are actually intended for me, and
respond in both of our defense.

Explained where? This does not seem logical.

To set the record straight:

* I am not Paul.
* None of the nasty things that you have said or implied are
  true of me.
* I don't know whether the insults are true of Paul, but I
  very much doubt that he'd appreciate you insulting him behind
  his back.

Fascinating, but hardly relevant to the matter of Lisp vs. Java.

 

[Series Expansion]

[elaborate discussion of Lisp equivalent of "new" operator]

Irrelevant.

No, it's got all the relevance in the world.

It does not.

The way symbols work in Lisp makes it possible to generate
never-seen-before symbols.

At run-time. This does not help you much with your problems with
macros, which occur at compile time. The macro must replace

some code
macro invocation (arguments)
other code

with

some code
macro result
other code

subsequent to which the latter is compiled by the compiler. If the
macro result contains a local variable, that code must contain
something of the form "(let (name" etc. etc. (or some other form that
binds a name) and if that same name happens to occur in the "some
code" portion a collision has occurred. What is more, the names that
occur in the "some code" portion cannot in general be computed from
only the macro invocation's arguments. More generally, the list of
names to avoid cannot in general be computed from only the macro
invocation's arguments.

The "(let (name" or similar is the problem, and it cannot in general
be avoided without resort to either global variables or multiple
evaluation. Even if the macro outputs code that, at run-time later,
will create a novel symbol (using the symbol table that exists in
memory at run time to find an unused one), that same code, at compile
time, must refer to this somehow. It must create a local variable that
refers to that symbol, and that can be used elsewhere in the macro's
output to refer to it again at need, and that local variable must have
a name, and that name will then be the potential cause of a collision.
Adding one layer of indirection does not solve the problem, though it
may well impair efficiency.

Also, a symbol's printed representation is not it's entire representation

Not relevant. The printed representation is all that is available to
the compiler at compile-time. You are apparently suggesting that it is
possible for a macro to take code like

(let (foo ... ))
(macro (argument))

and expand it to

(let (foo ... ))
((let (foo ... ))
...)

with the property that somehow the compiler will know to treat the two
foos as separate, and without variable hiding. But how can it?

More significantly, what you are saying would require as a consequence
that hand-replacing a macro invocation with its expansion could result
in different behavior at run-time than having the expansion done by
the preprocessor pass of the compiler. This would be a violation of
the broadest reasonable definition of a macro.

The nutshell is this: while your "gensym" might well be globally
unique, the code output by the macro, and later compiled by the
compiler, must reference it somehow. That reference must involve a
name, if it is to be referenced more than once. And that name cannot
be guaranteed to be unique, even if its referent can.

GENSYM is not the equivalent of the new operator. It doesn't need to
look at the code where a macro is being called from to do its job. All
GENSYM needs to do is examine the Lisp image and grab an unused
reference.

See above. This must occur at run-time. I am concerned with what
occurs at compile time.

This is not a 100% analogy, but it's like generating a
pointer to an empty reference, that can then be filled in.

This indirection is possible in Java and C as well.

In Java, it is as if you had

WeakReference<T> foo = new WeakReference<T>(someTInstance);

Although the T instance now has no name, and the WeakReference created
at runtime is guaranteed not to collide with any local or global
variables, the name "foo" of the reference TO that reference may
collide with or hide other variables with the name "foo" in that and
enclosing scopes. (Ignore for now the effect of WeakReference on
garbage collection.)

In C, it is as if you had

void *foo = malloc(sizeof(void *));
*foo = &my_obj;

Now, *(*foo) is my_obj and the direct pointer to my_obj is stored in
formerly unallocated space; that is a reference to my_obj that cannot
collide with any other reference in the system, barring bugs in
pointer arithmetic making malloc() stop working correctly (an
unfortunate problem sometimes in C, but a preventable one, by
debugging the pointer use that causes the corruption.)

However, the reference TO that reference again has a name, "foo",
which may collide with other names in the same scope.

Most significantly, C has macros, and one could have a C macro
generate code like the above, malloc'ing a pointer to refer to a
temporary. However, the pointer to this reference must itself be
referenced so that it can be DEreferenced and that temporary used. And
that pointer must have a name for the compiler to be able to do its
job. And a list of all potentially-colliding names in the scope could
not in general be computed as any function of the macro's arguments,
even were C macros to be like Lisp ones, able to replace themselves
with arbitrary computable functions of their arguments.

You have asserted that the Lisp macro's ability to become any function
of its arguments grants it extraordinary powers. I have demonstrated
that one particular and important power you have attributed to them
cannot possibly occur as a result of that trait, however.

 

[Series Expansion]

Series Expansion escreveu:
[snip crap]

No, I did not excrete crap. I posted a rational argument against the
assertion that Lisp was superior to Java.

Furthermore, my bodily functions are irrelevant here. Additionally,
they constitute a vulgar topic inappropriate for public discussion.
Please make no further reference to them.

I can't believe this whole HUUUGE thread is dedicated to trying to
persuade a troll!

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, namekuseijin.

 

[Series Expansion]

Thomas A. Russ wrote: [snip]
Not that it really matters for your argumentation - it is still
perfectly valid.

No, Thomas's argumentation is not "perfectly valid". Argumentum ad
hominem has been recognized as a fallacy for thousands of years.

You must be smoking something illegal.

I most certainly am not.

He is arguing very technical about classes and namespaces in Lisp
and Java.

I was not referring to any technical argument he may have made. I was
referring to the ad hominem argument that he also made.

Meanwhile, it would be wise of you to look into what laws against
defamation apply in your location of residence. It is quite possible
that posting the unsubstantiated and erroneous accusation of criminal
activity that you just posted was itself an illegal act on your part.

 

[Series Expansion]

Well that is what the IP address indicates.

It indicates nothing more than, at most, that we happen to share the
same Internet service provider.

 

[Series Expansion]

Running in an xterm is not considered running on X.

That was precisely my point. Running in an xterm does not really
qualify you to claim to be graphical, contrary to what several other
people have implied.

Fascinating. Arne appears to believe that Unicode is a subset of
ASCII.

Fascinating that someone is so dumb [rest deleted]

These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, Arne.

Hand-editing UTF-8 (where it includes some double-wide characters) in
an ASCII editor is not a recommended way to edit text.

Graphics hardware, and software that acknowledges its existence, is
needed in order to display the full Unicode character set at one time.

 

[Series Expansion]

I completely agree that anonymous posters are cowards.

The types that uses motzarella and the like to post!

I do not use Motzarella to post. As can be easily determined from my
post headers, I use Google Groups.

 

[Series Expansion]

Absolutely not.

And yet I am.

Typical Java programmers are reasonable guys (or girls).

As am I.

You are just a complete wacko.

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.

 >                     Moreover, it is tantamount to calling me a liar,

You claim of being a typical Java programmers is not true.

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.

 

[Alessio Stalla]

Running in an xterm is not considered running on X.

That was precisely my point. Running in an xterm does not really
qualify you to claim to be graphical, contrary to what several other
people have implied.

Fascinating that someone is so dumb [rest deleted]

These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, Arne.

Hand-editing UTF-8 (where it includes some double-wide characters) in
an ASCII editor is not a recommended way to edit text.

Graphics hardware, and software that acknowledges its existence, is
needed in order to display the full Unicode character set at one time.

This is a screenshot of Emacs on my machine taken right now:
http://img219.imageshack.us/img219/3889/thisisemacs.png

As you can see, it is a GUI app, and not because it's running in xterm.

 

[Alessio Stalla]

None have yet addressed my
observation that a variable name guaranteed to avoid capture cannot be
reliably computed by any function of a macro's arguments, except for
the case that the arguments contain the entire rest of the code base
aside from the invocation itself and the macro's definition.

It can, if the variable name is not a string but a symbol. Symbols
have identity. So I can have two variables with different names
(different symbols) even if the printed representation of the symbols
(their name as a string) is equal.

(eq 'a 'a) ==> T ;same symbol

(eq '#:x '#:x) ==> NIL ;different symbols due to #: syntax

(let ((a '#:x)) (eq a a)) ==> T ;same symbol referenced twice

I can create a unique symbol, store it somewhere, and reference it
multiple times (e.g. as a variable name). The fact it's unique isn't a
function of anything; simply is a new symbol object which is not
reachable through any package, and so it can only be referenced by
holding a pointer to it.

 

[Seamus MacRae]

Seamus MacRae wrote:
(e-mail address removed) wrote:
[You can even have multiple frames on different displays, in
different
countries if you want...]
The ability to run multiple xterms concurrently had occurred to me,
yes. Why would I want to though? Twice as much of a bletcherous thing
is more, rather than less, bletcherous. One xterm at a shell
prompt is
the most I'd normally ever desire.

Besides, it's not as if I'd magically get any real-GUI goodness
out of
it, like being able to cut in one window and paste in a different
one. The X clipboard and the various emacs instances' clipboards
would
all know nothing of one another.
You must be aware that emacs can run in windowed mode under both
X-windows and MS windows (and others I am not familiar with).

Yes, trivially; any console app can be run "in windowed mode" by
displaying it in a windowed terminal emulator instead of a
full-screen one or a real terminal.

But

But nothing. Any console app can be run "in windowed mode" by
displaying it in a windowed terminal emulator instead of a full-screen
one or a real terminal.

X is a full-blown windowing system.

A well-known and irrelevant fact.

Emacs communicates directly with X

Not possible. If it had been designed to do so, then it would follow
that a) it did not predate X, b) it could not be used remotely over a
terminal, and c) it used the X clipboard. However, a) it does predate X,
b) it can be used remotely over a terminal, and c) it has its own
internal clipboard. On the other hand, if it had not been designed to do
so, it could not do so now without being completely rewritten, and the
result of such a rewrite would not be emacs.

What will it take to get through your mind-blocks?

Politeness is necessary, though not sufficient. Correctness is likewise
necessary, though not sufficient. Or, at the very least, plausibility.