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

[Paul Foley]

Insults will not convince me that Lisp is better than Java. Only

I'm quite sure nobody /wants/ to convince you that Lisp is better than
Java. That would be the last thing we'd want! Then you'd be in the
Lisp groups all the time.

 

[Paul Foley]

What parameter name? All I see is a list of arguments. A
transaction-manager and a picture-library might conceivably both be
arguments to the same call.

I know you're the world's greatest expert on Lisp and all, but:

(defmethod db-librarypen-transaction ((transaction-manager picture-library:jpeg-picture)) ...whatever...)
^ ^ ^ ^ ^ ^ ^
A B C D E F G


A is the name of the macro being invoked (defmethod)
B is a package name
C is a symbol name in that package, naming the generic function for which
this method is being defined
D is the parameter name that you claim not to be able to see
E is a package name
F is a symbol name in that package, specifying the type of D
G represents the code to be executed when the method is invoked


See the parameter name - it's "transaction-manager"

My point was that Lisp's encapsulation granularity is much fucking
coarser!! Are you fucking dense?

Please stop these vicious personal attacks.

Yes, that would be terrible! It would make our code look like Java,
where /every/ method has to be qualified...

foo.bar()
^^^
hey, look!

 

[Alessio Stalla]

No, for reasons I've already explained. In Java you get:
* Assignability to references of the base type(s) (compile-time "is-a")
   (no Lisp equivalent),

In Lisp you always have assignability, since variables have no type,
only values have.

* Polymorphism (in Lisp you can easily get this without inheritance),

The fact you can get it without inheritance does not mean inheritance
does not give it to you.

* Tidy delegation of unspecialized methods to base type(s) (in Lisp
   you can get this without inheritance with a bit of work),

The only sensible way I know of doing this in Lisp is using
inheritance.

* Documentation of is-a relationship (in Lisp you can get this with
   actual documentation), and

And by a DEFCLASS form, which is code and not documentation, and gives
you runtime is-a behavior.

* Access to protected members of base type(s) (no Lisp equivalent).

The Lisp equivalent is access to slots of the base type.

[snip]

So, private in Lisp == "has to fully qualify name" rather than actually
private. How fascinating.

Fully qualify using a different kind of notation:

package:external-symbol ("public") vs
package::internal-symbol ("private").

The latter, while possible, is generally considered bad practice. Just
like setAccessible(true) when using reflection in Java to access
private fields.

The ones that know about numbers, strings, symbols, cons cells,
functions, macros, and very little else*. You know -- Lisp compilers!

I know Lisp compilers, and I know they can and often do take CLOS into
account.

Effects that I have now had to explain THREE TIMES Lisp lets you get
anyway, unlike Java where you *have* to implement an interface or extend
a class.

Again, no:

(m (make-instance 'c2)) => 42

would exhibit a different behavior if c2 did not inherit from some-
class.

Yep. Kablooey!
??



Strange then that when it suits you you appear to suddenly forget they
ever existed.

I mean I'm using DEFCLASS, DEFGENERIC and DEFMETHOD, which *are*
macros. Just not written by me

[snip total useless flaming]

 

[Paul Foley]

Not really. A statement separator is pretty obvious. Lisp just uses
spaces as separators, so the #: prefix (not used much of anywhere
else) remains mysterious.

It's mysterious /to you/ because you refuse to learn anything at all
about Common Lisp (even the things that people tell you directly, that
don't even require you to go the trouble of clicking a link), claiming
you just know everything there is to know by virtue of your infallible
logic. See how that doesn't work out?

#:foo is how you write a symbol named foo that isn't in any package.

 

[Paul Foley]

Then it doesn't make sense the way you interpreted it -- it then looks
like one has named a transaction-manager typed variable
jpeg-picture.

Adlai has it backwards: the first symbol is the parameter name, the
second is the type.

Last but not least though, how can
that variable have a type at all? Variables don't have types in
Lisp. Data sometimes seems to, but not variables.

So you keep saying. Since you obviously know far more about Lisp than
people who actually use and implement Lisp, you must be right.
Obviously CLOS doesn't actually work; we just photoshop the screenshots
to make it look that way.

 

[Lars Enderin]

Lars Enderin wrote:
Seamus MacRae wrote:
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, [numerous insults deleted]
Who are you, and what is the point of this unprovoked drive-by flaming?

The point is to expose you as a [insult deleted].
And unless you really are a schizo, you know me through your other
aliases: Twisted, Jerry Gerrone, etc, etc.

No. Seamus is not me and none of the nasty things that you have said
or implied about me are at all true.

I find it difficult to believe that there could exist more than one
person (in Canada) with your particular hangups and delusions. It's a
kind of Occams's Razor reasoning. The alternative, that there are
several wackos like you, is quite horrible to contemplate.

 

[Guest]

The problem with C's pointers is they went too far in allowing
arithmetic on them.  There isn't any need for that at the source
level.  

it can be a handy thing to have

Anything you can do with a C pointer you can also do more
safely with a C++ reference and indexing.

unsigned char *io_port = 0x60001234;

/* reset the laser cannon */
*io_port = 0x10;
*io_port + 1 = 0x55;

Now you could do this with indexing, but it is equally dangerous.
Sometimes you *really* need to stuff bits into arbitary memory
locations and however you do that it's going to be dangerous.

io_port[1] = 0x55;
poke (io_port, 1, 0x55);

<snip>

 

[Lars Enderin]

unsigned char *io_port = 0x60001234;

/* reset the laser cannon */
*io_port = 0x10;
*io_port + 1 = 0x55;

ITYM *(ioport+1) = 0x55;

 

[Seamus MacRae]

I'm quite sure nobody /wants/ to convince you that Lisp is better than
Java. That would be the last thing we'd want! Then you'd be in the
Lisp groups all the time.

More personal attacks, and not even any worthwhile attempts at rational
argumentation in the post. It might as well not have been posted. Why
are so few people reasonable or rational?

 

[Seamus MacRae]

But what makes you think real Lisp compilers can't do those things?
CLOS is part of Common Lisp.

Because a user could conceivably use the core of CL without CLOS, and
even with an object system incompatible with CLOS, perhaps one that
resembles CLOS enough that the compiler cannot reliably tell the difference.

Any valid CL code has to compile flawlessly and run to spec. When CLOS
was developed as a CL library, it was made of valid CL code. Design
decisions were made in the process, that could perhaps have gone the
other way. Now suppose someone makes a clone of CLOS but changes one of
those design decisions and diverges things from there? The result, we
assume, is valid CL code, and moreover, this para-CLOS resembles CLOS,
with parts probably being identical. If the compiler assumes that
anything that "looks like" CLOS is CLOS, and that anything that "looks
like" CLOS client code (defining classes with the same syntax, invoking
methods, etc.) is CLOS client code, and based on those assumptions
rejects code that "uses CLOS wrong" or imposes CLOS semantics on some
things, then if you feed that implementation para-CLOS it will blow up
and fail to conform to the standard.

So the most it can do is optimize for the common case that it really is
CLOS but without going to far as to make the rare case, para-CLOS or
something like it, actually broken.

 

[Seamus MacRae]

In Lisp you always have assignability, since variables have no type,
only values have.

Exactly my point: you no longer get this assignability from inheritance,
because you have it even without.

The fact you can get it without inheritance does not mean inheritance
does not give it to you.

It does mean inheritance isn't required to get it.

The only sensible way I know of doing this in Lisp is using
inheritance.

No, just having a dispatch in a generic function in each class suffices.
They needn't be related at all.

And by a DEFCLASS form, which is code and not documentation, and gives
you runtime is-a behavior.

WHAT "runtime is-a behavior"? I've just run down the list. Can assign to
variables that can hold an X: in CL you can do so without inheriting
from X. Can have a method dispatch to different versions depending on
whether some argument is an X or an instance of your class: in CL you
can do so without inheriting from X. Can access protected methods of X:
in CL there are no "protected" methods, so moot.

Fully qualify using a different kind of notation

Fully qualify.

In other words, there is no real "private". Anyone can access anything,
even without using reflection or something equally hairy that says
"Danger -- use sparingly" with its awkwardness.

So much for encapsulation.

package:external-symbol ("public") vs
package::internal-symbol ("private").

The latter, while possible, is generally considered bad practice. Just
like setAccessible(true) when using reflection in Java to access
private fields.

Java doesn't allow you to access a private field inadvertently with a
single slip of a finger.

I know Lisp compilers, and I know they can and often do take CLOS into
account.

In their optimizations. As explained elsewhere, they can do little else
without risking breaking other legal CL code, including very likely any
implementation of a CLOS-like object system that was slightly different
from CLOS.

Again, no

Yes, it was three times. It is now four, but it was three at the time
that I wrote that.

(m (make-instance 'c2)) => 42

would exhibit a different behavior if c2 did not inherit from some-
class.

Unless you did the appropriate defgeneric, defmethod stuff to create a
specialization of m for c2 "the hard way".

I mean I'm using DEFCLASS, DEFGENERIC and DEFMETHOD, which *are*
macros. Just not written by me

Writing them is what I was referring to.

And must you randomly write the same identifiers in all-caps sometimes
and not others?

[snip total useless flaming]

There'd be less of it to snip if you posted less of it to begin with.
(Though also, admittedly, if I quoted less of it when you did.)

 

[Seamus MacRae]

Adlai has it backwards: the first symbol is the parameter name, the
second is the type.

What? That's like writing

foo int;

instead of

int foo;

Why would anyone do it like that, unless they were Hebrew or Arabic
speaking? (And even then -- most language designs seem to have
originated not only in left-to-right writing countries, but specifically
in English-speaking countries, by and large!)

So you keep saying.

(let ('variable value)). (defun 'name (param1 param2) (body)). Where are
the types? There only seem to be the argument names and variable names
in these places.

Lisp does not have typed variables and parameters. Maybe CLOS does, but
Lisp does not.

Since you obviously know far more about Lisp than
people who actually use and implement Lisp, you must be right.

Don't be ridiculous.

Obviously CLOS doesn't actually work; we just photoshop the screenshots
to make it look that way.

Obviously it does work, just not quite the way some people are
describing it here.

 

[Seamus MacRae]

It's mysterious /to you/ because you refuse to learn anything at all

*sigh* More useless flaming.

claiming you just know everything there is to know by virtue of your
infallible logic. See how that doesn't work out?

No. I have made no such claims of knowing everything. I have claimed to
be able to make logical deductions from data. Not the same thing.

I had no basis for deducing anything about what #: might mean. Indeed
that was my point, that it was cryptic and probably needlessly so.

And so I asked. You seem to think it a vice rather than a virtue to
respond to not knowing something by asking. This is evidenced by your
rude demands ("go read a book" etc. for the umpteenth time) and personal
attacks (you don't know that? what an idiot!) in response to the question.

#:foo is how you write a symbol named foo that isn't in any package.

Another contradiction! Earlier Alessio said something made something
that wasn't in any package, thus (he claimed) making it inaccessible to
anything that didn't already have the reference. Looks like according to
you, things that are not in any package aren't quite so inaccessible.

Care to get your stories straight before continuing this debate, you two?

 

[Seamus MacRae]

I know you're the world's greatest expert on Lisp and all

That would be incorrect.

but: [condescension deleted]

My point was that Lisp's encapsulation granularity is much fucking
coarser!! Are you fucking dense?

Please stop these vicious personal attacks.

Frustration. And I think I can be excused after the large number of
similar attacks I have weather from you AND from each of your compatriots.

For a pack that can't even agree with one another on whether macroexpand
changes the source code in the editor or not, whether you can get at
symbols not in any package with #: or not, and various other things, you
sure seem to have no trouble mutually agreeing that I'm the enemy and
opening up with both barrels.

Yes, that would be terrible!

I'm glad you're beginning to see reason.

It would make our code look like Java,
where /every/ method has to be qualified...

foo.bar()
^^^
hey, look!

That hardly counts. (bar foo) is exactly the same number of characters.
You still have to specify the "foo" to pass one of the arguments. Java
also uses the leftmost argument to scope method name lookup. In other
words it gets a package specification of sorts FOR FREE. You Lispers
gotta pay for it in extra keystrokes.

Only in the case of static method calls versus function calls do you
maybe have a slight point. And it's outweighed by all the cases where
Java saves on some typing and Lisp doesn't -- all those "close" methods,
for instance.

 

[Seamus MacRae]

Seamus MacRae wrote:
Lars Enderin wrote:
Seamus MacRae wrote:
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, [numerous insults deleted]
Who are you, and what is the point of this unprovoked drive-by flaming?
The point is to expose you as a [insult deleted].
And unless you really are a schizo, you know me through your other
aliases: Twisted, Jerry Gerrone, etc, etc.

No. Seamus is not me and none of the nasty things that you have said
or implied about me are at all true.

I find it difficult to believe that there could exist more than one
person (in Canada) with your particular blah blah blah blah blah blah blah

Who said I was in Canada? Whoever it was ought to try asking me instead
of making wild guesses next time.

 

[Alessio Stalla]

Because they reside in different namespaces. Java doesn't just consider
them both "symbols" and throw them together into a single namespace;
instead, it creates separate ones within the class for fields and for
methods.

However, an earlier poster said that Common Lisp just considers method
names and the like to be "symbols" and throws them all together into a
single namespace per package.

That was me.

If that earlier poster was incorrect, take it up with him. Attacking me
for simply quoting him is pointless, rude, and should make you feel
guilty now that you realize the attack was aimed at the wrong target and
you just smacked an innocent bystander for someone else's offense.

The earlier post WAS correct.

(symbol-package my-package:my-symbol) ==> #<package "MY-PACKAGE">
;my-symbol is in my-package

(boundp 'my-package:my-symbol) ==> T
;my-package:my-symbol names a variable

(fboundp 'my-package:my-symbol) ==> T
;my-package:my-symbol names a function (it's "fbound")

(find-class 'my-package:my-symbol) ==> #<standard-class MY-PACKAGE:MY-
SYMBOL>
;my-package:my-symbol names a class

And, no clashes!!

(let ((my-package:my-symbol ;variable
(make-instance 'my-package:my-symbol))) ;class
(my-package:my-symbol 42)) ;function

The meaning of a symbol is apparent from the context. Yet there is a
single namespace, the package. Actually the mapping is:

string --> symbol --> denoted object


string --> symbol lookup is done using a package (single namespace)

symbol --> denoted object lookup is done implicitly by the Lisp
implementation, or explicitly by the programmer using certain
functions or special operators (e.g. find-class above); if you like to
think like that, there are multiple namespaces here (one for
variables, one for classes, one for functions and macros, ...)

Well, I was simply considering the possibility that they ARE all used,
and it seems that using two of them causes problems.

I don't think it can cause any problem whatsoever. If you think
otherwise, make an example showing how it causes problems.

What parameter name? All I see is a list of arguments. A
transaction-manager and a picture-library might conceivably both be
arguments to the same call.

Others have explained it to you already. Still, I said it's a
parameter name, and I know Lisp better than you - why do you doubt of
every single thing people say to you?

My point was that Lisp's encapsulation granularity is much fucking
coarser!! Are you fucking dense?

If I use the "private" symbol P::X, this means that anything named
P::X is private: the CLASS P::X, the VARIABLE P::X, the FUNCTION P::X.
If I use the "public" symbol P:X, this means that anything named P:X
is public: the CLASS P:X, the VARIABLE P:X, the FUNCTION P:X.

How is this "much ****ing coarser" than Java? Sure, I can't have
function X private and class X public. In practice this has never been
a problem for me, since classes tend to have different names than
functions.
Besides that, what can you express in Java that you cannot in Common
Lisp?? (apart from the fact CL has no "protected")?

public class, public method --> class name and generic function name
are exported symbols
public class, private method --> class name exported symbol, gf name
unexported symbol
public class, private field --> class name exported symbol, slot name
unexported symbol
private class, public method --> class name unexported symbol, gf name
exported symbol

etc...

Thank you for admitting the truth at last.


Why?


There are only a few class collisions in Java's standard library. I've
mentioned javax.sql.Date and java.util.Date before.

There are no symbol collisions in CL's standard. There are maybe a few
in CL libraries, but I can't recall any (except in those libraries
that provide a replacement for some standard operator, but in that
case the "clash" is desired).

If methods could collide, there'd be 17,392 collisions of them (counting
N of the same name as N^2 collisions; if N-1, it's "only" a couple
thousand; in neither case counting polymorphic overrides as colliding
with the overridden version(s)). The names "close", "dispose", "next",
"readResolve", and "writeExternal" are particular culprits.

You can't avoid to think in Java, can't you? Sure, if suddenly in Java
we removed the namespaces created by classes, and put all methods in a
single namespace, then there would be a lot of collisions. But CL IS
NOT JAVA and IT WORKS DIFFERENTLY. Namespaces in CL ARE NOT TIED TO
CLASSES. So the generic function "close" HAS THE SAME NAME (no
conflict!) FOR ANY CLASS FOR WHICH IT IS APPLICABLE.

close(file), close(socket), close(string-output-stream) BELONG ALL TO
THE SAME GENERIC FUNCTION and HAVE THE SAME NAME, so THERE IS NO
COLLISION WHATSOEVER. Is that clear? Sorry for "shouting", but I
really don't know how to explain it to you, yet it seems simple to me.

Stick THAT in your pipe and smoke it.



This is what lack of a REAL type system gets you: one object doing
triple, quadruple, even quintuple duty. Jack of all trades, master of
none. (This last can also be a criticism of emacs.)

T is one NAME with multiple meanings.

As damning as when the same line is spoken on TV by a politician.


The chart would be an instance of some class, say Chart, implementing
the other interface, the one with a drawOn(Graphics2D) method specified.
The drawOn() method would call the Graphics2D methods. Code that wanted
to draw a chart on a Graphics2D would call the chart's drawOn() method
with the appropriate parameter. Different chart instances would produce
different drawings.

So while I can drawRect() and drawCircle(), I can't drawChart() but I
have to use a workaround, Chart.drawOn(graphics). And if I want drawOn
(graphics) be the common way of doing drawing, I need ALL objects that
can be drawed implement the Drawable interface. Unfortunately it's
unlikely I'll ever have control on ALL classes that can be drawed...
So I end up having "primitive" drawXXX on Graphics,
com.mypackage.Drawable.drawOn(Graphics),
com.yourpackage.DrawableObject.draw(Graphics), and so on. Instead in
Lisp I can have
(draw object graphics) and stop - if I want to draw a new kind of
object, I'll write the appropriate method for the draw generic
function.

But if you confuse your personal preference with objective
truth, and write that "truth" in public, I - we - feel the need to
correct your claims.
That statement makes several insulting and false insinuations about me.
I'm sorry, but I genuinely think [repeats insults]
Think what you want, but please restrain the urge to blurt out uncivil
things in public. Weren't you taught any manners as a child?

I don't think

That needs rectifying right away, then.

If I write MY:frobnobdicate specialized on YOUR:quux, I'm not altering
the behavior of MY:frobnobdicate specialized on other objects.

Cop-out. Are you or are you not altering MY:frobnobdicate?

I'm adding a possibility, not changing behavior.

You are changing behavior. Suppose I had code that passed a quux
superclass object around, gotten from somewhere, and called
MY:frobnobdicate on it? Add the quux class and pass one to my code, and
its behavior changes. Not because you subclassed my class to make quux
and put a polymorphic method in YOUR:quux but because you subclassed by
class to make quux and put a polymorphic method in MY:frobnobdicate!

See the difference? In Java you put the method in your own class. In
Lisp you put it in MY generic function. Mine, I tell you, mine!

In Java I really put MY method in the dispatch table of YOUR
superclass. This is the analogy I'm making. If this is not modifying
the class, then it is not modifying the generic function.
To be clearer: object.method(...args...) in Java is like (generic-
function object ...args...) in Lisp (not considering single/multiple
dispatch). Adding a subclass in Java that overrides the method IS
EXACTLY LIKE adding a method in Lisp specialized on the subclass. It's
the very same thing.

This seems a minor wart. Until you have experience working in a large
development effort with many many people involved, and this inability to
fence off parts of things goes from wart to colossal headache.

In pseudo-Java:

[snip]

Poor analogy. Once again, you are subclassing under a new name instead
of changing the original. Because that's what Java does. It supports
exactly the kind of modularization and localization of code changes that
Lisp doesn't.

Viewing one as a list and the other as a tree (class hierarchy)

A simple strategy: when an apples-to-apples comparison makes your side
look bad, rebut by comparing apples to oranges instead!

imho my comparison is more correct than yours.

That's why it's better to find a happy middle:

too few ways                                       too many ways
BASIC     FORTRAN   Pascal    Java      C++       Lisp      perl



I know this. The point is, the names are less SELF-explanatory. (And you
omitted to state what the #: bit is for the latter.)

#: is read syntax that makes the symbol not being interned in any
package.

I had been being sarcastic about code readability.

[quite a lot of untrimmed-but-unused quoted material now trimmed]

Mind you, I usually refrain from saying something is absolutely
"superior" because there are really many dimensions to be considered

Good good.

but

Ah, there's always a "but", isn't there?

I do think [subjective opinions and stuff]

Which I'm sure are absolutely fascinating, but which prove nothing in
this debate.

Ok, that's fair.

The URLs leave a thing or two to be desired. For one thing they're not
integrated, there's just a standard library class for 'em, and OOTB it
only works with HTTP and one or two other things, one their own
Java-specific jar: protocol.

Can't your register custom protocol handlers? If you can't, then Java
really sucks!

I don't think they should be integrated more than that, mind you, but
there's some warts, like MalformedURLException's handling (and more
generally, illegal argument exceptions should not be checked
exceptions!) and some awkwardness with certain patterns of use. Just
constructing a URL triggers some behavior beyond mere construction,
unlike a File abstract pathname object, which I disagree with.
Constructors that do more than construct are evil.


Clojure?

No, ABCL.

 

[Alessio Stalla]

Because a user could conceivably use the core of CL without CLOS, and
even with an object system incompatible with CLOS, perhaps one that
resembles CLOS enough that the compiler cannot reliably tell the difference.

Any valid CL code has to compile flawlessly and run to spec. When CLOS
was developed as a CL library, it was made of valid CL code. Design
decisions were made in the process, that could perhaps have gone the
other way. Now suppose someone makes a clone of CLOS but changes one of
those design decisions and diverges things from there? The result, we
assume, is valid CL code, and moreover, this para-CLOS resembles CLOS,
with parts probably being identical. If the compiler assumes that
anything that "looks like" CLOS is CLOS, and that anything that "looks
like" CLOS client code (defining classes with the same syntax, invoking
methods, etc.) is CLOS client code, and based on those assumptions
rejects code that "uses CLOS wrong" or imposes CLOS semantics on some
things, then if you feed that implementation para-CLOS it will blow up
and fail to conform to the standard.

So the most it can do is optimize for the common case that it really is
CLOS but without going to far as to make the rare case, para-CLOS or
something like it, actually broken.

There cannot be anything that looks like CLOS but is not CLOS, since
CLOS's functions and macros have names in the COMMON-LISP package and
as such cannot be redefined by portable programs. I.e. when the
compiler sees a call to CLEFCLASS, for example, it can safely assume
it's a CLOS class declaration. (In reality DEFCLASS is a macro so the
compiler will probably optimize the underlying functions used in its
expansion, but the principle is the same).

Alessio

 

[Kaz Kylheku]

These pointless jabs and pokes do not advance your case for Lisp. All

I'm a comp.lang.lisp regular, and most of the names behind these jabs and pokes
are completely new to me.

For instance, let's see, looking at Arne's posting history on Google Groups,
it's concentrated Java and C# newsgroups, and in a small sample of it
I have not discovered Lisp advocacy.

[Nice to meet you, Arne.]

It looks like you're attracting jabs and pokes from your comp.lang.java fellows.

 

[Tamas K Papp]

So you keep saying. Since you obviously know far more about Lisp than
people who actually use and implement Lisp, you must be right. Obviously
CLOS doesn't actually work; we just photoshop the screenshots to make it
look that way.

Well, at least Photoshop has macros

Tamas

 

[Seamus MacRae]

That was me.

So now you're disagreeing with *yourself*? Well, I guess you might
sometimes change your mind about one of these things, but still, the
timing in this case was atrocious!

The earlier post WAS correct.

But it wasn't. Or else the later one wasn't correct. You can't have it
both ways! Either they all go into one name-resolution pool or they
don't; they can't both do so and not do so at the same time.

And, no clashes!!

So, the earlier post WAS incorrect.

The meaning of a symbol is apparent from the context. Yet there is a
single namespace, the package.

Not consistent. Either the former or the latter is false. I think you
have package and namespace confused, and the package actually has a
separate namespace in it for each of several kinds of thing. In other
words, it doesn't just have symbols, it has methods separate from
variables separate from classes etc.; it has some notion of which of
these is which and keeps them tidy.

there are multiple namespaces here (one for
variables, one for classes, one for functions and macros, ...)

An admission of the truth at last?

I don't think it can cause any problem whatsoever.

By "problems" in this instance I meant scoping headaches for the
programmer, rather than actual failures of the code.

What parameter name? All I see is a list of arguments. A
transaction-manager and a picture-library might conceivably both be
arguments to the same call.

Others have explained it to you already. [more condescension in this vein]

How rude.

If I use the "private" symbol P::X, this means that anything named
P::X is private: the CLASS P::X, the VARIABLE P::X, the FUNCTION P::X.

Oh God, it just gets worse and worse! Now you say your system's bollixed
up enough that you can't even have, say, a private variable named foo
and a public method named foo in the same place? Who thought this up?
Why would you make private apply to everything of the same NAME,
regardless of whether that name was overloaded? Why?

Oh, nevermind. It's wacky, you like it anyway, I don't, and that's the
end of the matter. There's really little point in continuing this.

How is this "much ****ing coarser" than Java?

It's spelled "****". With an F.

Sure, I can't have function X private and class X public.

Let's tick things off shall we? One. More. Time.

1. Your module size is like in C, a few per program (plus libraries'),
rather than like Java or even C++, one per class.
Imagine C++ only with "private" visible to everything in the same
.cc file, or all pairs of classes in a single source file implicitly
mutual "friends".
2. The encapsulation is extremely weak even so. Not only can you
circumvent it by adding a single colon to a scope operator somewhere,
a) it's right next to another colon, so an easy typo to make simply
by bouncing a key; b) you can presumably automate even the one lousy
extra colon using a macro; and c) it will look enough like normal to
be easily overlooked and mistaken for innocent code, unlike, say,
Java reflection and setAccessible(true) calls. Heck you can even get
your Java IDE to find all setAccessible calls on reflection API
objects without false positives and throughout the code base, if your
IDE is decent enough. Meanwhile :: is a search that will have false
positives I guarantee it. All two-or-less-character searches do.

Besides that, what can you express in Java that you cannot in Common
Lisp?? (apart from the fact CL has no "protected")?

Technically nothing since they're both Turing complete. But much that is
decent and good in Java would require implementing a Java emulator in CL
to get in CL. (The JVM spec is readily available, so this should be
trivial right?)

Class-granular "private" comes to mind in particular.

Why?

Should be obvious to most people. Can't be bothered to try to explain
it, given that.

There are no symbol collisions in CL's standard. There are maybe a few

Always the one-upmanship with you, isn't it?

You can't avoid to think

This isn't about me, it's about the code. Please leave your personal
criticisms of me at the door and focus on the actual topic here. Thank you.

CL IS NOT JAVA and IT WORKS DIFFERENTLY.

Exactly my point. It works differently, and in this case, differently =
worse. Now every unrelated pair of "close" methods collides, unless you
start being creative with your thesaurus, and then code gets less
readable and there's more and harder memorization to learn to use the
darn thing.

close(file), close(socket), close(string-output-stream) BELONG ALL TO
THE SAME GENERIC FUNCTION

The one for iostreams.

What about closing windows? Oops, no windows, forgot. Well, I'll
think of *something*...

Sorry for "shouting"

No you're not, not one damn bit.

I really don't know how to explain it to you, yet it seems simple to
me.

I'm sure the guys down at Bellevue that think they're Napoleon think the
same thing when they try to get people to believe them.

And we can always use more criticism of emacs. Right, guys?

So while I can drawRect() and drawCircle(), I can't drawChart() but I
have to use a workaround, Chart.drawOn(graphics).

That's not a workaround. We can also have Circle.drawOn, Rect.drawOn,
etc. if we want to be able to do them all consistently. Or we can add a
generic draw() to Graphics2D that takes a Drawable and just calls
argument.drawOn(this). (Assuming we control Graphics2D.) Then you can
happily do graphics.draw(chart).

I need ALL objects that can be drawed implement the Drawable
interface. Unfortunately it's unlikely I'll ever have control on ALL
classes that can be drawed...

Why? You're the one designing the system, hypothetically.

So I end up having "primitive" drawXXX on Graphics,
com.mypackage.Drawable.drawOn(Graphics),
com.yourpackage.DrawableObject.draw(Graphics), and so on.

Why? The system's designed would make Drawable public, and an interface
so any class could implement it regardless of constraints on its superclass.

Instead in
Lisp I can have
(draw object graphics) and stop - if I want to draw a new kind of
object, I'll write the appropriate method for the draw generic
function.

The cost of having this is that you can change someone else's code, and
even are encouraged to. If they didn't make their class Drawable, why,
you'll just do it for them!

If someone did that to one of my Java classes, it would annoy me. Hello,
compatibility headaches, now there's more than one incompatible version
out there.

[some quoted material dropped that wasn't replied to -- please trim
more, your posts are very long and slow to load]

In Java I really put MY method in the dispatch table of YOUR
superclass.

Not explicitly! And not really at all; the classloader builds up a
dispatch table at runtime.

This is the analogy I'm making.

And I'm telling you, it doesn't quite work.

Adding a subclass in Java that overrides the method IS
EXACTLY LIKE adding a method in Lisp specialized on the subclass. It's
the very same thing.

NO, IT ISN'T! If you still don't understand why I'm afraid you never
will. It's time to drop this line of debate.

imho my comparison is more correct than yours.

I once knew a guy who was of the opinion that the earth was flat.

#: is read syntax that makes the symbol not being interned in any
package.

"Read syntax"?

Can't your register custom protocol handlers? If you can't, then Java
really sucks!

Of course you can, but since they don't come with the standard library,
you need to either reinvent them or dredge one up somewhere. And then
the licensing fun begins. Even with open source, there's various
sometimes-incompatible licenses. There are even pairs of licenses in the
FSF's own GPL family of licenses that can't be used together. Sometimes
there are attribution clauses, and those create scaling problems.
(Consider that work is typically built on previous work. Suppose a work
always built on three earlier works, except for first-generation works,
and acknowledgement was required. First generaton works have 0
attributions. Second tend to have 3. Third, 3x3 + 3 = 12. Fourth, 12x3 +
3 = 39. Fourth, 120. Fifth, 363. Sixth, 1095. Whoa, over a thousand
already! The credits list is gonna be as long as at the end of Revenge
of the Sith on those sixth-generation works... The exact numbers don't
matter, just that whatever they are they'll increase exponentially.)

Clojure?

[calls me a liar]

Oh, nice.