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

[Series Expansion]

Really?

Yes, really, as explained previously. No clever attempt at a
workaround will fail to contain some subtle flaw, if not an overt one.

I have purposedly used the name "generated-variable" for my global
variable, without using the naming convention of *global-variable-
name*

Use of global variables, of course, is the flaw in this instance. And
not a subtle one.

 

[Series Expansion]

I'll grant that you are not flaming.  You are just blathering.  You are
just spouting idiotic comments about technology that you clearly do not
understand.

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

I just explained why the package system won't. Adding new classes in
their own packages? No problem, the package system can distinguish
foo.String from bar.String. Adding new methods to an existing class,
say foo.String? Uh-oh. Is that baz's foo.String.doIt() or quux's
foo.String.doIt()? They have the same method name, are methods of
classes with the same name, and the classes are in the same package.
As far as the compiler is concerned, they are the same. The package
system cannot distinguish them unless we add another layer of
namespacing, this time INSIDE classes, and have foo.String.baz.doIt()
and foo.String.quux.doIt() instead of just foo.String.doIt() as the
fully-qualified names. And now we're deep in migraine-headache
territory, without oar or compass...

Well, the above paragraph is prima facie evidence that you have a
profound ignorance [lots more bullshit deleted]

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

[much deleted]
To put this into Java terms for you, the confusion you are
imagining would be akin to saying that one could have two
classses java.lang.String and java.lang.String which are
different, and thus confusable.  You can't, since they are
the same classes.

Unless they were created with different ClassLoaders.

[most of rest of post deleted]
that you in your lack of knowledge so blithely assert.

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

 

[Series Expansion]

I prefer not to participate in Usenet pissing matches, but I sometimes
get my jollies by reading along.  In this case I gotta say, with
Series the laughs just never stop.

I fear you're wasting your breath, though.

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

 

[Series Expansion]

Come off it. You're grafting on something the compiler and language
weren't originally designed for, so it's going to necessarily suck
compared to the real deal.

[calls me a liar]

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

 

[Series Expansion]

Seamus MacRae and Series Expansion are proving themselves to be
grandmasters of trolling. The Troll-o-Matic will have to be updated to
reflect their expert techniques.

And has anyone else noticed that they are never both present at the
same time? Just a thought.

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

And I think Seamus and I are both online posting right now as a matter
of fact. One more thing you got wrong. This is what happens to those
that allow their emotions to overrule their reason.

 

[Seamus MacRae]

A generic full-fledged IDE, or just the particular kind of full-
fledged IDE you're accustomed to?

A generic full-fledged IDE. An IDE is more than just the text editor
inside it!

 

[Adlai]

On May 17, 6:28 pm, Adlai <[email protected]> wrote:

Altering the behavior of that not-yours code via macro is hardly a
successful evasion of my point. In fact it compounds it, for not only
are you still effectively altering the behavior of that code, but
furthermore, you are causing changes at remote locations in the code
base via macro use, which I previously contended was a hazard of Lisp
macros and which your group repeatedly denied could happen. Yet now,
when it suits you, you admit that it can, indeed, happen.

Macros never change the code itself. A defmethod form would add to the
generic function as it existed in the currently running Lisp image,
when the defmethod form was evaluated. However, it would NEVER alter
the code itself.

Furthermore, being able to define a method, but not append a dispatch
for it to a generic function, would not address the issue in which
such dispatch was essential to your plan.

The expansion code generated by a defmethod form deals with adding it
to the generic function's dispatch. It even creates the generic
function if none exists yet.

That would constitute perhaps the worst possible failure: it silently
works incorrectly, neither alerting anyone to the conflict nor
satisfying everyone's requirements.

The compiler emits warnings when things get redefined unexpectadly.

Also -- writing code like that is not a good idea, and I doubt would
ever be done in practice. That code is almost like writing x = 1 / 0.

If you're thinking of what happens when you override an existing
method with a defmethod form in your code -- the compiler will emit a
warning in that situation.

That is not possible. The defmethod body itself may be local to that
package, but the added dispatch table entry/ies will be local to the
package containing the generic function of which it is the newest
method-member.

Packages don't contain dispatch tables, they contain symbols. A
dispatch table for a generic fn only exists within the Lisp image
after some code has created a generic fn -- not local to any package.
This is why you need to understand the Lisp package system to critique
various aspects of the language that interact with it.

This would also make it difficult to use polymorphic objects widely in
a system without importing a large number of packages just about
everywhere in the code base, effectively somewhat diluting the name-
collision-avoiding capabilities of the package system.

If you've compiled some code, the definitions in it are reflected in
the running Lisp image. Packages control symbol references, however,
you don't have to import a package for references to symbols in that
package to work in code that the Lisp image is already running.

This seems likely, given the extreme dubiousness of the design
decision of enabling a public generic function to have dispatches to
private methods when called with certain combinations of public
classes.

There's not really a public/private distinction in Lisp packages.
There are just uninterned symbols (gensyms go here), and symbols
interned in packages.

No, just to add a dispatch entry to call that method.

Nope. DEFMETHOD takes care of that.

You omit to mention adding a dispatch to the generic function that
invokes your new method. Somewhere in the code base the generic
function's dispatch table lives, resembling anonymous_c_lisper's
example for a generic function named "frobnobdicate". This dispatch
table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
obj) to call your new method when both arguments are my-objs. How is
this entry to be added?

DEFMETHOD does it. I couldn't for the life of me tell you exactly how,
but when CLOS was written 20-some years ago, they designed it well.
DEFMETHOD forms add to the dispatch table of a generic function,
without messing with source code, just by updating the Lisp image.

let me guess: you're going to do it anyway? And make some utterly
preposterous claim?


Yes, and yes. Particularly preposterous this time. It's
straightforward excluded middle: you can't simultaneously both have
and lack static type checking.

You have static type checking on variables for which you declare
types, and you don't have it for undeclared variables.

Since it rubs you the wrong way when I say "should", I'll put it this
way: Please read up (either in these posts, or elsewhere aka here
http://www.flownet.com/ron/packages.pdf about the Lisp package system)


- Adlai


PS -- Ignore the name of the package tutorial. It's not intended to be
an insult.

 

[Pillsy]

I do not know, though strongly suspect "appearing to be the victor of a
particular Usenet pissing match" to be among his motives. Nonetheless,
what he claimed flies in the face of logic. [...]
That statement makes several insulting and false insinuations about me.

OK, that's comedy gold right there.

Cheers,
Pillsy

 

[jborder]

OK, that's comedy gold right there.

You know, I thought that perhaps I was forming a rather unfair opinion
of Seamus.

I thought that maybe he was geniunely competent as a Java programmer,
but having trouble grasping some CL concepts.

So I thought I'd take a look at comp.lang.java.programmer, and perhaps
report back that he was actually quite reasonable there...

However:

http://groups.google.co.in/group/co...ca7c276521/ed286a98157a62e5?#ed286a98157a62e5

I would hate to offend him, so I won't quote directly.

Trust me though, comedy gold lies here also...

Jamie

 

[jborder]

[...] geniunely competent [...]

^^^^^^^^^

I thought I'd say it first.

 

[Seamus MacRae]

["Followup-To:" header set to comp.lang.lisp.]

Taking it as a given that Complex should be a subtype of Number, how
else would you go about doing it?

Are you asking about implementation strategies about how to add
this ANSI CL feature to Seamus MacRae Imaginary Lisp.

No; there's no such thing as SMIL anyway. I was asking Pillsy to clarify
something that he wrote, and how he would do something. And since you're
not Pillsy, it is very odd for you to jump in at this point.

Not really.

Yes really.

Lisp is the same way. Originally, everything had type.

In Lisp? Surely you jest. At base, it has no static types and precious
few dynamic ones (integer, maybe a few other numerics, cons cell,
string, symbol, nil, and little else).

Are complex numbers a subtype of numbers?

(subtypep 'number 'complex) -> T ;; Yes!

This seems to be checking some programmed-in notion of types, not
compile-time types of any kind. You could program this behavior in any
language.

Lack of static typing saves work in the type system too?

Maybe a bit. At the cost of lots of debugging later on, in big enough
systems.

There isn't a Lisp macro called THINK which will do this for you

I meant *think*. With your head! Maybe a bit of a foreign concept to you?

You keep asking people for rational evidence. Where is your rational
evidence that these errors are such a threat?

I have stated it repeatedly. You keep ignoring it.

I agree that there is a nonzero probability that you will be
confronted with an error like ``foo does not understand the method bar''.

Well, there we are. I guess we are now in agreement.

So why am I still apparently only 1/3 of the way through your
interminably long post?

1. How much of a threat is this? Can we quantify this risk in numbers?

Easy: what would have been caught in seconds at compile time, or even
instantly in the IDE when editing (red squiggly underlines: another
feature untranslatable to a box of pure ASCII), instead isn't caught
until run-time and possibly far from the true location of the error.
Seconds of debugging becomes minutes at best, hours at worst.

Say the downside is 30 minutes.

Now note that type errors are an estimated 30% of bugs. So nearly 10
minutes per bug, total, saved with static types.

2. What are the costs of preventing this problem with static typing?

A bit more up-front keyboard typing. Maybe more thought as to what
should be what and going where during design and coding, but that will
pay off as an investment down the line.

Are there risks, and what are they?

There's a risk you won't be able to mischievously sneak a Float into a
group of Strings...

You are asserting that there are no costs, or risks, only benefits,

No, I am not. I am asserting that they balance out in favor of static
typing.

Don't accuse others of having no rational evidence

Then get some and post it.

People who have actual years of experience with dynamic typing find that the
actual threat from type mismatch errors is small compared to the inconvenience
of working with static typing.

This is the kind of worthless anecdotal "evidence" that all too many
people mistake for the real thing. Of course, no scientist worth his
salt will take it other than with a grain of same, and no court of law
will accept this kind of claim as admissible testimony, on the grounds
that it's hearsay.

Macros are a part of compilation.

Macros are user-defined. Macro EXPANSION is a part of compilation,
probably one of the earliest parts.

What is the difference between, say:

synchronized (obj) { ... code .. }

and

(synchronized obj ... code ...)

Java's synchronized block construct is a de facto macro. The difference is
that it's hard-wired into the compiler.

You'll also find that all of Java's "de facto macros" lack multiple use
of any argument, and so don't run into the variable capture/global
variable/multiple evalaution trichotomy.'

The point is that the C generated by bison is

C, not assembly.

You're having problems with Bison and version control because you have no clue
what should go into version control and what shouldn't.

You're jumping to unwarranted conclusions about me. I don't have serious
problems with Bison and version control. I do anticipate there could be
serious problems with Lisp code rewriting the (foo foo) bits of itself
and version control.

I saw elsewhere in this thread that you were shown a screenshot of Emacs and
you still denied it was Emacs.

I was shown a screenshot and told by a known hostile entity and probable
liar that it was emacs, and the screenshot showed something that
resembled emacs the way the Eiffel Tower resembles a tea saucer.

The only Emacs is Seamus MacRae Imaginary Emacs.

I find that particularly unlikely to be true. I'm adding you to my list
of "probable liars" in this thread.

An organized reference manual for Seamus MacRae Lisp would be helpful,
instead of the collage assembled from these fleeting glimpses of
what it is about.

I'm sorry, but I don't know of any "Seamus MacRae Lisp". I doubt it
exists. If it does, you'll have to ask someone else about it -- the name
is a total coincidence and I don't know beans about it.

 

[Seamus MacRae]

Yes, and that's true in Java, too.

Not as nicely as I'll bet you can do it with Lisp macros or just
diddling those dispatch tables.

That's totally orthogonal to the claim that "inheriting from a class
gets you very little in Lisp".

It is not.

Neither does Lisp.

Only because in Lisp there seems to be no encapsulation to break.

and in the class hierarchy, which exists in the system's state and not
only in the programmer's mind...

but which does NOT exist for the compiler. It's just data, like dates in
a java.util.Calendar.

(defclass A (B) ()) is source code, and declares that every A "is-a"
B: every thing you can do with a B, you can do with an A too.

My point, which you are intentionally trying not to get, is that if that
doesn't *do* much useful beyond save a peck of typing and document the
relationship, then you might as well just document the relationship.

But there's a *value* type, and the fact that object X is of class A
or B *does* change runtime behavior, or else classes would be
completely useless.

It changes runtime behavior in ways I just explained how you could
accomplish by other means, using the powers of the macros YOU have been
touting.

If there's a DRAW method specialized on SHAPE, and
my object is of class CIRCLE, whether CIRCLE inherits or not from
SHAPE *does* change what will happen when I call DRAW with it as a
parameter.

Not if you manually diddle the dispatch table in lieu of subclassing SHAPE.

I completely fail to see your point here.

That is obvious. Perhaps you should clean your reading glasses.

Your public insinuation that I'm a liar is rude and unwelcome. Please
refrain from engaging in such behavior in the future.

[naught left but flamage]

Well, this is becoming increasingly useless.

 

[Seamus MacRae]

I, for one, would gladly address some those issues, but I can't do that without
a reference manual.

Is there a website where I can download, or read online, the specification of
Seamus MacRae Lisp?

Never heard of it, sorry. I thought we were discussing Common Lisp anyway.

 

[Seamus MacRae]

I do not know, though strongly suspect "appearing to be the victor of a
particular Usenet pissing match" to be among his motives. Nonetheless,
what he claimed flies in the face of logic. [...]
That statement makes several insulting and false insinuations about me.

OK, that's comedy gold right there.

No, that's an intentional and dishonest misquotation of me that takes
one of my comments out of context. What I actually said:

I do not know, though strongly suspect "appearing to be the victor of
a particular Usenet pissing match" to be among his motives.
Nonetheless, what he claimed flies in the face of logic.


That statement makes several insulting and false insinuations about me.

Clearly the first paragraph by me refers to Thomas and the second to
some text that Thomas wrote.

Do not intentionally misquote me again.

 

[Seamus MacRae]

OK, that's comedy gold right there.

[a lot of flamage and no worthwhile content]

I don't even know you. Why appear out of nowhere just to conduct a
drive-by flaming of a random bystander?

 

[Seamus MacRae]

Yes, apparently I'm saying that. So?

So, you're contradicting Pillsy. Pillsy implied that that code only does
the equivalent of "import foo.*".

That's because the concepts are similar enough between Lisp and Java,
yet not completely equal.

No, it's two different Lisp users contradicting each other about Lisp
here that I'm pointing out, not a Lisp and a Java user disagreeing.
(Though we've had lots of that, too.)

(defpackage :my-package
use #:cl #:foo))

in Lisp does 2 things:

1. declares package my-package exists
2. declares that all symbols from packages :cl and :foo are also in
package my-package (and thus can be accessed unqualified when code is
read in package my-package)

How ugly. Imports shouldn't genuinely change package membership, just
visibility. Now people can use my-package:sym when sym is really foo:sym!

Furthermore, the explicit :use #:cl must be something like having an
explicit import java.lang.*; in Java. Java does that automatically so
you don't have to. That's one more point in favor of Java, albeit a very
minor one.

 

[Thomas M. Hermann]

Altering the behavior of that not-yours code via macro is hardly a
successful evasion of my point. In fact it compounds it, for not only
are you still effectively altering the behavior of that code, but
furthermore, you are causing changes at remote locations in the code
base via macro use, which I previously contended was a hazard of Lisp
macros and which your group repeatedly denied could happen. Yet now,
when it suits you, you admit that it can, indeed, happen.

Actually, the DEFMETHOD macro does not alter the behavior directly, it
macro-expands to an ENSURE-METHOD function call. ENSURE-METHOD creates
a new method metaobject and adds it to the generic function with ADD-
METHOD. ADD-METHOD adds the method to the generic function's list of
methods and to each of the specializers' list of direct methods. This
is verbatim text I've assembled from "The Art of the Metaobject
Protocol".

So, the hazard of changing the behavior of an existing method is not
really associated with macros, it is just the hazard of redefining the
behavior of an existing function. That's why a good Common Lisp
implementation warns you when you do it. Furthermore, you can set
*BREAK-ON-SIGNALS* to an appropriate level to invoke the debugger when
it occurs so that your input is immediately required before the
program proceeds, or not if it suites you.

Supplanting others' code is one of the capabilities that I had
previously noted to be fraught with hazard.

A good(most, at least all that I have used) Common Lisp implementation
warns you when this occurs so that you may take the appropriate action
and mitigate the hazard.

Furthermore, being able to define a method, but not append a dispatch
for it to a generic function, would not address the issue in which
such dispatch was essential to your plan.

Fortunately, the ADD-METHOD function does just that.

It seems that it is not possible in Lisp to simultaneously avoid both
of the above issues.

It is possible to avoid both of the above issues.

The implication had been made that not only were tables like in
anonymous_c_lisper's code snippet compiled, like other Lisp source
code, to bytecode, but that those tables were themselves created or
modified by automated tools.

If by automated tools, you mean the ENSURE-METHOD and ADD-METHOD
functions, I suppose that's correct. How the internals of these
functions actually operate is an implementation detail that is only of
concern to the implementers.

This has already been mentioned elsewhere, and while it does not help
you on the generic function modification issue, it actively hurts you
on the type-safety issue, since it corroborates my claim there that
the compiler cannot type-check CLOS code since it cannot safely make
assumptions about the presence or nature of any object systems in the
code.

If you'll expand on this statement or direct me to a previous post
that expands on it, I'll attempt to address it. The point you are
trying to make is not clear from the above information.

That would constitute perhaps the worst possible failure: it silently
works incorrectly, neither alerting anyone to the conflict nor
satisfying everyone's requirements.

I was unable to find the specified behavior for a duplicate
specialized lambda list passed to the :METHOD option of DEFGENERIC. I
performed a little experiment in the implementation that I use and the
second method was ignored. It should be stressed, though, that
the :METHOD option has limited utility and most times methods are
added to a generic function with DEFMETHOD. If you are using
the :METHOD option to add methods to a generic function, then they
will necessarily be collected in one place, so when you test your
methods and observe the incorrect behavior, you will know exactly
where to look to correct the problem. Otherwise, you will have defined
the method with DEFMETHOD and the implementation will have given you a
warning that there was a redefinition.

That is not possible. The defmethod body itself may be local to that
package, but the added dispatch table entry/ies will be local to the
package containing the generic function of which it is the newest
method-member.

Indeed, this raises the possibility that a reference to an object of a
type defined in the former package, and to which the method in
question applies, will escape into the system to eventually be
referenced by a variable in code defined in a different package.
Presumably the generic function is visible there, including the
dispatch entry for that particular type. However, you claim the method
body is inaccessible there. It follows that if that code invokes that
method on that variable, while it is holding that object, the dispatch
table entry will effectively be pointing nowhere.

In C, invoking a dangling function pointer tends to result in a crash.
Whereas I expect Lisp to be somewhat better behaved in a certain
sense, a run-time exception or similar occurrence seems likely.

This would also make it difficult to use polymorphic objects widely in
a system without importing a large number of packages just about
everywhere in the code base, effectively somewhat diluting the name-
collision-avoiding capabilities of the package system.


But problems will arise if they invoke that generic function on an
object of a type for which that package had added a "private" version
of the method, as noted above.

Adlai, you were wrong about the details and therefore the response by
SE is not addressable.

This seems likely, given the extreme dubiousness of the design
decision of enabling a public generic function to have dispatches to
private methods when called with certain combinations of public
classes.

In the CLOS, there are no such things as a private or public methods,
so this statement is not addressable.

No, just to add a dispatch entry to call that method.

There is no need to manually add a dispatch entry, this is handled by
ADD-METHOD.

You omit to mention adding a dispatch to the generic function that
invokes your new method. Somewhere in the code base the generic
function's dispatch table lives, resembling anonymous_c_lisper's
example for a generic function named "frobnobdicate". This dispatch
table clearly needs to gain an entry for (my-obj my-obj) (my-obj my-
obj) to call your new method when both arguments are my-objs. How is
this entry to be added?

This entry is added by ADD-METHOD. Details can be found in "The Art of
the Metaobject Protocol".

[ Snipped text that contained nothing addressable. ]

Hope that helps,

Tom

 

[jborder]

[a lot of flamage and no worthwhile content]

I don't even know you. Why appear out of nowhere just to conduct a
drive-by flaming of a random bystander?

Because on the (remote) offchance that somebody who's curious about CL
is still reading this thread, I would hate for them to believe the
misguided nonsense you have posted.

The word "nonsense" is justified because the overwhelming majority of
what you have said appears factually incorrect, and you have not shown
any interest in providing any corroborating evidence (or even a cogent
argument).

Note that I did not call you a liar, because I do not know you.

Perhaps you could extend this courtesy to some of the other
participants?

Jamie

PS: "drive-by flaming" is marvellous. Thanks!

 

[Seamus MacRae]

Pillsy wrote: [...]
Pollyanna much?
Why do you keep insisting that I believe you instead of my own lying
eyes?

Your eyes lie? Or do you mean the other sense ... amblyopia then?

Anyway, you keep insisting I believe you instead of what reason and
logic says follows from your own prior statements...

If you think I'm lying about what problems I've experienced, this
conversation couldn't be more pointless. If you don't think I'm
lying, the only other option is that your logic and reason are faulty.

Nope. False dichotomy. I think you're not so much intentionally lying as
viewing Lisp through rose-colored glasses.

(My logic and reason are, of course, flawless.)

IMO, when theory and practice differ, practice ought to trump theory,

When theory and hearsay testimony differ, hearsay testimony ought to
give way to theory.

I did.

Well, that's cheating. You're not doing the same exact thing as I was,
which will render any comparison meaningless and result in you failing
to prove that Lisp does it more efficiently, which I assume is your goal.

Believe it or not, different things are grouped differently in
different languages.

This remark does not seem to be relevant.

Except this was in response to, basically, "how does Lisp do import
foo;?". Apparently it was not actually an accurate answer to the posed
question!

That may be because [excuses, excuses]

Are you endeavoring to assist in getting to the truth of the matter of
which language has the more efficient syntax for imports, or are you
intentionally muddying the waters?

I suspect this is ultimately because Java closely intertwines a number
of things that Lisp leaves separate.

From what you said earlier, it's the other way around, with Lisp
intertwining package declarations and imports and Java keeping them
separate (though all at the top of the source file).

I'm not sure where you got the idea that anybody said it's
conspicuously easier. It looks about the same to me.

You were the one to originally raise the question as to which was
easier, in
<[email protected]>:

http://groups.google.com/group/comp.lang.lisp/msg/948007c3b7f26ec9

You:

Me:

I'm missing the part where that's conspicuously easier than the Lisp
option.

You implied the Java way of doing things wasn't; by implication, that
the Lisp way of doing things was the easier instead. I disputed that.
But I did not originally raise the topic.

So, where I got the idea that anybody said it's conspicuously easier was
from you claiming Java's wasn't and implying that Lisp's was, four days ago.

 

[Seamus MacRae]

You're right though about the productivity of this debate. It's like
evolutionists vs. creationists: one side has logic and evidence on its
side, the other unshakable faith, and neither will budge. We'll never
give up our logic and evidence and apparently you'll never give up
your faith. And since there are no important public policy issues at
stake, your continuing to argue is pointless.

It's ironic, really, that when you write something which seems to make
sense, you have got it exactly backwards: You are obviously the one
arguing from faith and faulty reasoning. [& further personal attacks]

Who are you, and what is the point of this unprovoked drive-by flaming?