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

[Seamus MacRae]

And rigtly you should! Machine-generated code is what will put you jobless.


Well, be happy, you won't have to maintain machine-generated code, the
machine will do it itself.

Why put it in the source code then?

 

[Seamus MacRae]

You're ridiculous! Go learn some lisp before puting yourself to such a shame.

Your response to my post is an ad hominem argument that does not say
anything about either Lisp or Java.

Please hang up, and try your reasoning skills again.

 

[Seamus MacRae]

OK. But Java takes all of the methods that do essentially the same
thing and hides them each in their own file. So instead of being able
to see the commonality in a particular set of methods all in one place,
you have to go searching through each class that implements the method.

Maybe. But Lisp is no better if you have (defmethod frobnobdicate)
instances sprinkled all over the code base. Gathering them all in one
place means using the (defgeneric frobnobdicate) form, which puts them
all in one namespace too, as well as centralizing the place to create
more dispatches and implementations.

The only compromise I can see is using defmethod, but putting them all
in one place. And then there'll be a whole mess of explicit scoping
since that "one place" will belong to one package and you'll want to be
able to distribute the defmethods among several. All but one of those
will therefore involve explicit scoping.

At least in Common Lisp you have the choice of choosing a Java-esque
file organization or one that is more function-oriented. So you could
ahve all of the print-related methods grouped together, all of the
database-related methods grouped together, etc.

Instead of all of the methods that deal with the internals of foobars
together, and all of the methods that deal with the internals of
bazquuxs together.

There goes encapsulation. Here comes that distinctive zigzag pattern
that signifies an imminent migraine. Now where in the code are all the
references to that ivar? Hell if I know!

 

[Seamus MacRae]

OK. Lisp is better than Java. Victory for the Knights of Lisp!

Thomas has utterly failed to prove anything of the sort. See also my
direct followup to Thomas's post.

 

[Joost Kremers]

(Frankly, I would like the best of both worlds: a logical markup
language in a left hand pane and a right hand pane showing a
near-real-time WYSIWYG view, possibly supporting at least a subset of
editing commands. I know of nothing that provides such. Certainly it
would have to be a modern GUI application though.)

Interestingly, Emacs can do this:

<http://user.uni-frankfurt.de/~kremers/emacs1.png>

That's a screenshot of a typical Emacs session for me. Notice how LaTeX
commands such as \section, \ref, \textsc or \emph are hidden, with some
font effect on the arguments to approximate the command's effect (e.g. the
section title "Transfer", the italic "all", etc.) Notice also the image,
which is actually produced by some LaTeX code, which can be made visible
and edited by moving the cursor into it:

<http://user.uni-frankfurt.de/~kremers/emacs2.png>

Then, after editing, a few key presses (or mouse clicks, if you prefer) and
the updated image is displayed.

Leaving aside any quibbles about exactly how useful "customizing emacs"
really is,

The LaTeX editing features here are provided by an add-on package. So yes,
customising Emacs is extremely useful. Elisp means that anyone who wants to
can add features to Emacs. I also handle my BibTeX databases from within
Emacs, for example.

Note that "customising Emacs" doesn't mean changing background colour and
default window size or stuff like that. Elisp is as powerful as any
so-called "scripting" language (python, perl, etc.) and gives one the
ability to add basically any feature imaginable to Emacs.

So please stop talking about something you obviously no absolutely nothing
about.

 

[Seamus MacRae]

I'll just jump in right here and point out that

[personal attacks deleted]

Eh, there's nothing left?

 

[Seamus MacRae]

[We'll ignore the fact that + in Common Lisp is not a generic function,
but rather a built-in function that does coercion. We'll also ignore
the fact that complex numbers are built-in to Common Lisp, since
neither fact affects the larger issue here.]

Now you can see where the problem will show up. If I want to add a
Complex noun, now I have to add a plus(Complex, Complex) to plus. Which
means I have to modify something in the system package. Uh-oh!

Well, this paragraph is great up until you get to "Uh-oh!".

Which means we have a second "uh-oh": the fact that Thomas A. Russ does
not consider it an "uh-oh" that someone has to modify something in the
system package. Uh-oh!

There is not "Uh-oh!" in Common Lisp at this point. In fact, that it
precisely the point of all of this. You can do this. It is natural.
It is not a problem. You just do it.

You just do it, and then your coworkers string you up by your toenails
and leave you hanging from the sprinkler head above the office Xerox
machine overnight.

Well, why not use a system that makes either one just as easy?

Because no such system exists. It would require needing to scope both
nouns and verbs separately, instead of the verb being disambiguated
based on the noun or vice versa so only one of the two needed
disambiguation by the programmer. Now the programmer has to worry his
head about both!

Then it doesn't matter which is more frequent, because either option
is handled exactly the same way.

Yes. Instead of 84% of the job being easy and the other 16% of it being
hard, or 84% of it being hard and the other 16% being easy, 84% of it is
hard and the other 16% of it is also hard.

That leads to a nicer, more uniform way of
operating with the language, so that the entire language model is easier
to understand.

Easier to understand! You're a laugh riot. Java's basic language model
can be grasped in a day. You've spent more than a week attempting to
convey Lisp's to the people of comp.lang.java.programmer and have
apparently thus confused at least two of them and probably most of them.
Either you're all exceptionally bad at explaining things, down to the
last man, or Lisp is emphatically NOT "easier to understand".

Why is that a problem?

Because you have to monkey around in someone else's namespace and in
someone else's code to add quux.frobnobdicate() when there's already a
frobnobdicate verb and you're addign the quux noun.

I thought I'd explained this?

BTW, in Common Lisp, namespaces are not tied to classes at all.

Big mistake.

They are their own separate entity, so any effect based on namespaces
is equally easy

which is to say, about as easy as ascending Everest without any special
equipment or any clothing and living to tell the tale

regardless of whether you are talking about new classes,
new generic functions or new methods for existing generic functions.


Right. So here is a class of problem where one particular object system
gets in your way.

The solution adopted by CLOS apparently being to make an object system
that gets in the way for EVERY class of problem!

See, for example, my nice hammer and picnic blanket analogy elsewhere
in this thread.

See, for example, the demolition of your hammer and picnic blanket
analogy elsewhere in this thread.

The error in this analysis is conflating the notion of a namespace with
that of a class or function/method.

I did no such thing. I only assumed that classes and/or
functions/methods live IN namespaces.

I assumed that there were three possible ways to resolve names:

package.class.method (perhaps with inheritance) (Java uses this)
package.method.class
package1.class.package2.method

that is, either packages namespace classes which namespace methods (Java
model), packages namespace methods which namespace classes (don't know
what uses this), or packages namespace both methods and classes.

You seem to be saying that Lisp does the last of the three.

The problem, partly, is the combinatorical explosion of possible package
pairs in every invocation of a method when there are now two packages
involved in resolving every method invocation instead of one.

Regardless, there are no errors in my analysis. Ever.

One uniform mechanism that handles both cases with equal ease.

Equality of ease isn't the be all and end all. Making it hard in all
cases is worse than making it easy in some cases and hard in others, as
a general rule.

That is one reason I think the Common Lisp object model is superior.
Another is multiple-dispatch, but that's a completely different
discussion.

Heartburn macros upset stomach, dispatch tables diarrhea! Yay, Pepto-Bismol!

Well, part of that may be conditioning

Nope. I'm a human being, not one of Pavlov's dogs, and the suggestion
otherwise is frankly insulting.

Well, actually that's perhaps a bit strong. Typically the solution to
this is to either write wrapper classes or interfaces to add the new
functionality or else to use static methods on some utility class so
you can write methods that affect classes to which you don't have
source code access.

Perhaps that is the price of encapsulation and having a non-hairy name
resolution system. The amount of bug-hunting time saved by encapsulation
alone in the history of OO probably makes it worth it.

Well, the workaround does have the minor problem that you don't get
dynamic dispatch for the static methods.

Make the utility class have subclasses and change the static method to a
polymorphic one. Well, it still can't be polymorphic in the arguments,
but it can still use the polymorphic methods OF the arguments.

So if you want to have a
hierarchy of classes with different methods, you lose the benefits of
dynamic dispatch and have to manage that yourself. That sounds to me to
be a bit more tedious and potentially error-prone.

It's going to be no matter what. If you want to add more classes and
more methods both, or more classes with dispatch of a two-argument
method based on the types of both parameters, then no simple inheritance
system is going to work and you'll have to manually specify what to do
for every possible pair ... somehow.

When it's one dimensional, you can use inheritance and have each
subclass take care of itself.

As soon as it's two-or-more dimensional, you can't. Some of the
information about class X or whatever is going to be scattered about,
and there's going to be something like a switch statement, pointer
array, or other explicit dispatch mechanism in the source code.

Lisp just sticks you with this by default instead of letting the cases
that CAN be easy actually BE easy.

And yet, oddly enough, in practice there don't seem to be any. It works
just fine.

So you claim. Color me skeptical.

First of all, you don't "change the verb". You simply add a method.

Which changes the verb.

Adding a method to a class is changing the class, right?
Lisp methods live in generic functions instead of classes, right?
Ergo adding a method to a genetic function changes the generic function.

(Subclassing a class doesn't change the base class. But subclassing a
class creates a new class that has its own name and is in its own
package. Adding a method to a generic function does not create a new
generic function that has its own name and is in its own package. It
adds to the existing generic function instead, thus changing it.)

And there is absolutely no reason that the code for your new class has
to be scattered anywhere. You can, if the organization makes the most
sense for your application, put the method definitions IN THE SAME FILE
as the class definition. If it makes more sense to organize around the
generic function instead, then you can. Or you can even mix it.

Your coworkers are going to have SO much fun trying to guess where you
put everything.

No ouch.

Yes ouch.

Simply a misunderstanding of how Common Lisp programs are organized.

I have misunderstood nothing. According to you, Common Lisp programs are
organized at the whims of individual programmers. Not conducive to
scaling up to a large development team, mind you.

This debate really puts you at a bit of a disadvantage,

etc. etc. etc.

I think I've had quite enough of being insulted by you.

The rest of your text has been deleted unread, with one small exception.

Well, we think that there is a fundamental difference between different
sorts of close and prefer to make sure they have different names.

So instead of everything you can "close" having a "close" method, you
end up "close"ing one type, "shut"ting another, "slam"ming a third,
"plug"ging a fourth, and onward to increasingly unintuitive and
unguessable names? Wow, that must REALLY help code readability.

 

[Seamus MacRae]

That was not me

<sigh> Lisp did that in the Sixties, and with a better Pole Star ("code is
data is code") than Java ("programmers are incompetent"). I must say, you
do not seem incompetent, you seem quite bright. Shouldn't you be using a
language that respects you? Sorry for getting personal.

http://groups.google.com/group/comp.lang.lisp/msg/7b770fd050b6c0b1 if
you don't believe me.

Don't falsely accuse me of lying, misquoting, or misattributing again.

You missed my point

I missed nothing. But is this a tacit admission that you did indeed
write what you just accused me of misattributing?

that Lispers know all these other languages, meaning we are you only we
have been saved by finding Lisp.

It's nice to have it confirmed that this is a matter of religious belief
for you rather than anything you can be persuaded about rationally. That
is the only conclusion to be drawn by the use of such phrases as "we
have been saved"; this is some sort of messianic belief system rather
than an evidence-based one.

Which, in turn, explains why many of your "arguments" are just
hand-waves: "Wouldn't X then cause all kinds of headaches?" "Nah, not a
problem" rather than a detailed explanation, argument, or some evidence
and citations pointing to some unconsidered workaround for X and
documenting its effectiveness.

The problems are "not a problem" for you not because you have solved
them then but because you have become inured to them; have accepted them
as your penance. They are "not a problem" for you in the way that their
whips are not a problem for flagellants.

If the ALU had not managed to erase The Road to Lisp from written
history I could point you to the stories of how Lispers found Lisp.

This religion is even more well-developed than I'd thought! It already
has conspiracy theories, tales of persecution, and a supposed attempt to
purge it from history already woven into it.

Of course, in the modern age in developed countries we do not have
book-burnings or other forms of historical revisionism, so you'll pardon
me if I take the above with a grain of salt roughly the size of Iowa.

Nothing like that kind of madness has happened in western Europe or
North America since 1945, and Lisp hadn't been invented then.

A few were born into Righteousness

Okay, I think I've heard enough of this hysteria.

Rational discussion with you people is clearly out of the question, so I
guess that's the end of this thread.

No, she could have used improvement and maintenance but I put up with
her for ten years before switching to a Cherry 2000.

Those (fully-functional female androids) haven't been invented yet.

Let me guess: you're from the future, and the anti-Lisp book-burnings
and feedings of Lispers to lions in the Colosseum occur in the year 2074?

You should stick to writing science fiction and leave the computer
programming to us.

I can imagine you complaining to the fireman carrying you out of the
burning building that he did not knock before coming in.

Analogy failure. Java is not comparable to a burning building, and
(outside of your messianic religion) Lisp is not a savior, though it may
(in some instances) turn out (occasionally) to be a useful tool.

 

[Seamus MacRae]

PUWAHAHAHAHA - Puwaaahahhhahaaahahaaa - Good grief, man, you're talking
to Kenny Tilton.

Yet he did indeed get his nose tweaked. Repeatedly.

You are so sweet in your childish innocence.

Blow it out your ethernet jack.

Well, man, I can tell you, he is one of the Lisp Gods, really.

OK, then let's see him zap that clown Lew with a large bolt of lightning
up the ass.

Go ahead.

Come on!

....

Thought not.

Moving on ...

If he says something then you should *listen* - er, read. I have learned
to read twice (at least) when one of the Language Gods (not just the
Lisp Gods, you know) is sending us their wisdom.

The last "pearls of wisdom" I read from him was an explicit denial that
he'd written some quoted text I'd attributed to him.

My response was to post the message-ID, Google Groups URL, and a larger
chunk of quoted text solidly cementing the case for him having written
the text he denied having written.

This is the sort of "wisdom" typically displayed during interrogation by
suspects on CSI, right before the forensics come back and nail their
asses to the wall.

I think I'll pass, thanks.

Or, do you mean ... are you one of the Java Gods ?

No. I would never be so presumptuous or arrogant as to accept, let alone
grab for, such a title. I'm just a Java programmer.

 

[Seamus MacRae]

[stuff elided]...

Well, man, I can tell you, he is one of the Lisp Gods, really. Because
he is one of those who are able to help and support others in doing them
good and in doing them bad. (That's a *hint* for you !)

If he says something then you should *listen* - er, read. I have learned
to read twice (at least) when one of the Language Gods (not just the
Lisp Gods, you know) is sending us their wisdom.

Or, do you mean ... are you one of the Java Gods ?

I assure you that "Seamus" is most definitely not one of the Java gods.

Nope. Just an ordinary guy.

 

[Seamus MacRae]

Well, I was looking for the right tone in my response and came up short
and dry. This sounded about right and appropriate to the unbelievable
arrogance of Seamus and of Series Idiocy, ah, Series Expansion.

What arrogance? The arrogance on display was "we are also better at
those languages than you. Sorry for the comedown." and a quick Google
search will confirm that Kenneth wrote it, not I nor Series Expansion.

Note also that it is not I that has sunk to the level of flinging around
such astoundingly erudite and adult forms of debate as "Series Idiocy,
ah, Series Expansion" and similar childish insults. I've also not seen
Series Expansion do that much, aside from the odd "dirtbag" or
"fuckhead" or similar every fiftieth post or so.

If an objective judge were to create a ranked list of participants here
from the most to the least mouthfoaming it would resemble:

Lew
You
Pascal and one or two others
Kenneth
Several assorted minor flamers, most from the Lisp side
Series Expansion
one or two random people
me
one or two random people

based on the posts up to this date.

As you know I am fond of pictures and diagrams.

Strange to see in a confessed emacs lover. One expects an emacs lover to
be very word-focused rather than image-focused, or verbally rather than
visually dominant, or some such, but the reverse for someone "fond of
pictures and diagrams", who you'd therefore expect to prefer tools more
like NetBeans.

 

[Seamus MacRae]

Trolls. I recommend not feeding them.

But I am not one. Nor am I arrogant.

 

[Seamus MacRae]

Yes, you're right, I know.

But I am not one, nor arrogant.

In order to make even this post really valuable to all readers I want to
once again point everybody to a series of screen casts:

http://lispcast.blip.tv/posts?view=archive&nsfw=dc

Start at Episode 1 and watch them in full screen mode. A real good way
of understanding the power of Common Lisp as a full-fledged languange,
SLIME as being a full-fledged IDE. And have some fun.

A full-fledged IDE needs to be more, visually, than just a grid of text.

 

[Seamus MacRae]

Hmm, not really.

Yes really, unless you're going to change your claim.

seems to me to imply that the code at the bottom is the Lisp analogue of
"import foo;". Are you saying that this was an error, perhaps even a lie?

The Java equivalent of that defpackage form would be:

package my.package;
import cl.*;
import foo.*;

repeated in every file that is in package "my.package" and uses
packages "cl" and "foo"

Apparently you are saying that.

Arguing with a side that contradicts itself and changes the "rules"
every time it's pressed quickly gets tiresome.

I may not bother much longer.

 

[Seamus MacRae]

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...

Well, OK, let's talk about the not-so-general case, where you try to
use two packages that both export the same name.

You'll get an error telling you that you're trying to use two packages
with the same name, and what that name is. Now that the implementation
has stopped you from defining the new package

Hey, hey, hey. Wait a minute here. Who said anything about defining a
new package? I'm not interested in that. In the equivalent of Java code
such as:

package foo;
import java.util.Date;

....

Date today = new Date();
javax.sql.Date thingyDate = thingyFromDatabase.getDate();

I am interested in the "import java.util.Date;" and the "javax.sql.Date
thingyDate = thingyFromDatabase.getDate()" bits, or rather, their Lisp
equivalents, rather than the "package foo;" bit or its equivalent.

Why not? You keep insisting I'm a rocket scientist.

Actually, that you have pretensions in that area, and an unknown actual
level of skill, but a lot of pride and little self-examination or
thought given to the possibility that you might be, you know, *wrong*
once in a while.

Yeah, except what I've done is equivalent to Java's

package myPackage;
import foo;

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!

If you want to obsess about a few extra characters, have fun.

The point is that the Lisp option is not conspicuously easier. At best
it's about on a par; in practice, the quantity of shifted characters is
likely to make it quite bit more awkward to type. (Those would be :#()
with a total of 11 of those -- as many characters as the ENTIRE Java
import has; ZERO of which were shifted.)

 

[Seamus MacRae]

I mean, "import foo.*;" of course, like Mr Stalla said.

I don't know Java all that well. However, if you really like, I can
invent a bunch of terrible problems with the language that you've just
been ignoring all this time due to your exuberant optimism.

That would be silly, perhaps even sillier than your thinly-veiled and
erroneous implication that I've been doing something analogous.

 

[Seamus MacRae]

That is such an irrelevant comparison.

Take that up with Pillsy. He's the one who asserted that Lisp's way of
doing this was easier than Java's, and thereby raised the issue that you
claim is irrelevant. I just refuted that assertion, that's all.

 

[Seamus MacRae]

No

Yes. Count the characters yourself if you don't believe me.

Anyway, you are not seriously trying to argue that, if for one thing
CL use a few more characters, than CL is necessarily bad.

No, I'm trying to argue that if CL uses a lot more characters, many of
them shift-chords, then it is NOT true that Lisp's way of doing this is
easier. As for why I'm doing so, it's to refute Pillsy's assertion
that Java's wasn't easy.

You really don't have good arguments.

This insult is false. If anyone doesn't have good arguments here it's
Pillsy. He's the one that started arguing about which language's import
statements were easier, after all, I just continued it.

 

[Paul Foley]

No, no, no! I want REAL windows, not those split-screen views that the
emacs documentation oh-so-helpfully mislabeles as "windows" and that I
found to be more trouble than they were worth.

Emacs calls those "frames"...since it already used the word "window"
for something else before frames existed. Is the important thing that
you have them, or that they're called by a particular name?

[You can even have multiple frames on different displays, in different
countries if you want...]

 

[Seamus MacRae]

He really doesn't.

These insults are becoming tiresome. So is hearing people discussing me
as if I wasn't in the room.

Let's recap:

* Pillsy claims Java's imports are harder to type than Lisp's.
* Someone posts Lisp's syntax for doing an "import foo;".
* I post a note making explicit what was already obvious on inspection:
Java's is considerably easier to type.
* Everyone jumps down my throat.

What is this, National Shoot the Messenger Day?

He seems to understand the Java language well enough, but he doesn't
make a good apologist for it.

More personal attacks and more talking about me in the third person in
my presence!