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

[Thomas A. Russ]

(e-mail address removed) wrote:

Eh, I don't see any namespace related anything in that. I do see
manually managed dispatch tables and plenty of other migraine-inducers
though.

Precisely. It doesn't enter into this at all, in most cases.
It is nicely in the background for when you need it, but it doesn't
intrude into your day-to-day programming most of the time.

Suppose you created all of that stuff and then someone else wanted to
frobnobdicate their quux objects. Now they have to mess with the
defgeneric ... etc. in your namespace, in your source code...

Um, no.
They don't need to do anything with DEFGENERIC at all, since that
function is already present.

They just add their own method by just doing

(defmethod frobnicate ((foo quux) (baz quux))
..body)

and this method gets added. They do this in their own source code.
They don't need to do anything to your source code.

Perhaps you were confused because the poster to which you were replying
used one of the alternate convenience techniques for adding methods to a
generic function.

That is ONE way to do it, but in Lisp there are often multiple ways to
accomplish the same thing. In this case, there is also a stand-alone
DEFMETHOD that could be used instead. Having a lot of flexibility in a
language takes some getting used to, but the philosophy of Lisp is to
provide a wide range of tools and techniques and rely upon programmers
being smart enough to pick the tool that is most appropriate to the
problem at hand.

I think one thing people are missing here is that real software projects
are typically worked on by teams, and even lone developers typically use
third-party and system libraries. That divides the typical project's
code base, from a particular developer's viewpoint, into "my code" and
"everyone else's code", and generally limits them to making changes to,
or putting things into the namespaces in, "my code" only.

The days of the lone hacker building a whole system from the ground up
singlehandedly are mostly gone, for better or for worse.

Languages that don't provide for other use-cases, and in particular ones
that don't play nice with modularising code, version control, or
testing-distinct-from-going-live, will increasingly be marginalized.

Well, that is one of the nice things about CLOS and being able to add
additional methods or even entire functions to existing objects (such as
in libraries) where you don't have access to the source code. There
have been lots of large systems built with lisp, and these things have
been given a fair amount of thought. Just because the solution is
different from Java's solution doesn't make it ineffective.

See again my hammer and picnic blanket analogy for why you might want to
be able to do new things with existing objects. Suppose you wanted to
graph a tree of objects. java.lang.Class doesn't have a graph()
method, and you can't add one. In CLOS you just define a graph method,
specializing as necessary, say if you wanted to render Class and
Interface differently.

It's far more general than that.

Results 1 - 10 of about 8,950 from dictionary.com for noun.
Results 1 - 10 of about 1,470 from dictionary.com for verb.

The implication of these two Google searches is that nouns are about six
times more numerous than verbs.

I doubt the scientific validity of this, but we'll let that pass.

It still doesn't follow that one would choose a methodology that makes
one or the other of these approaches MORE difficult, when one can
instead have a methodology where adding a noun or adding a verb are
equally easy. That seems a no-brainer to me.

It stands to reason that needing a new noun to use with existing verbs
might be about six times more frequent than needing a new verb to use
with existing nouns.

So, you advocate then arbitrarily making about 1/6th of your work harder
than it needs to be because, well it's only 16% of the time?

The case at issue is when there's a pre-existing generic function with
the desired name, in library code or otherwise where I couldn't fiddle
with it (except as a lone-wolf hacker), and in a namespace I shouldn't
put my own stuff in (except as a lone-wolf hacker).

Um. You are making unwarranted assumptions again.

1) You are expected to use pre-existing generic functions. That's how
you extend the existing library code base.
2) You are NOT expected to even have access to the source code. You
don't need it. You shouldn't mess with it. All you need to know is
what the API for the generic function is. That is all you need know
is the signature and the semantics (the latter so you know that this
is actually the generic function you want).
3) The name already exists in the namespace, so you aren't changing the
namespace at all. (BTW: Namespaces in Common Lisp are exactly
that. They are NAMEspaces and only concern themselves with the
resolution of names. They don't get overloaded with notions of
functions, classes, or anything extraneous like that)
4) Assuming that you are extending the generic function in a reasonable
manner, for example by adding methods that dispatch on types that
you have defined, then there is no "lone-wolf hacker" part to this
at all. It is a controlled extension of the library. It is no more
"lone-wolf hacker" than subclassing a library class in Java would be.

The hypothesis at issue is that this metaclass, or whatever, already
exists and I'm not free to modify that code.

So far so code.

There is an existing function or class.
You are not free to modify that code.

That doesn't stop you from either creating a subclass of that library
class or extending the generic function by adding methods. YOU DO NOT
NEED ACCESS TO THE ORIGINAL CODE TO ADD METHODS. No more so than you
need access to the source code in Java to create a subclass.

Perhaps that is the analogy that you need to understand this. In Common
Lisp adding a method to a generic function is the same as creating a new
subclass of an existing class. It extends the generic function by
allowing it to apply to a new combination of method argument types. It
is, in essence, adding a dynamically dispatched "subclass" to the
generic function.

We'll not get into metaclasses, because they don't really exist in Java.

Of course they are, but methods are in packages, and packages create
namespaces, and not everyone on a large project (or a typical project
even) will be able to make changes to things in every namespace.

Methods are not in packages.

Now there is some potential for confusion here, because both Java and
Common Lisp have things called "packages", but they are not quite the
same.

A Common Lisp package is simply a namespace. It controls the mapping
from surface strings to symbols. Symbols are first class objects in
Common Lisp. Symbols are used as the namees of things in Common Lisp,
but the package system affects only the mapping of strings to names when
lisp code (or data) is read.

Only symbols are in packages.

There is a difference between using and making changes. Even if you
can't (or shouldn't) make changes to a namespace, you can still use the
existing names that are in there. Just as you can subclass any class
you like (except Java final classes), you can extend any generic
function in Common Lisp. That doesn't change the namespace. It merely
extends the generic function, much as sublasses extend their parents.

 

[Thomas A. Russ]

Inheritance relationships recorded where? Lisp seems to take a
Java-esque class and explode it, scattering bits of it all across the
codebase and maybe hiding some bits up its sleeve for good measure.

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.

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.

 

[Thomas A. Russ]

Every time a serious problem is mentioned, you tend to dismiss it with
little more than a hand-wave. A can-do attitude is good to have, but
here it's verging on Pollyanna. You're liable to trip and pitch
headfirst down a six-hundred-foot chasm while staring up at the pretty
blue sky if you carry on like that.

Well, if you were to actually LEARN something about Common Lisp first,
perhaps you wouldn't raise so-called "problems" that don't really
exist. I fail to see what sort of response you would otherwise expect.

I mean, what would your response be if someone were to say:
"Java method overrides cause all sorts of problems. If you want
to override an inherited method, first you have to go in and
manually modify the dispatch table, so that your the right
method will be found."

Yet earlier someone was saying you'd omit to specify that Complex
inherited from Number.

Well, it turns out that the inheritance specification is optional. You
only need to specify that inheritance if you actuallly need to inherit
anything. If you are going to implement ALL of the methods, then it
doesn't matter if you inherit from number of not. You would get the
same dispatch.

Flexibility. It's all about flexibility.

This is absolutely fascinating. Now you're actually becoming visibly
incoherent.

Oh, lovely. Machine-generated code you can't even find and read? It's
annoying enough to get bison-generated code to play nice with version
control. Your phantom dispatch tables are going to bedevil any serious
developer until his hair falls out and his nose gets all wrinkly.

So I assume that you are in the habit of examining the Java method
dispatch tables? Sure, they exist somewhere in the code. But you never
ever look at them. I've been programming Java for quite a while (in
addition to Lisp and a number of other languages), but I've never looked
at the Java dispatch tables. I wouldn't even know where to find them.

Where are they? Do you examine the byte-code the compiler emits, too?

But ... but ... but ... but you just ...

I think you're being deliberately obtuse.

Oh, aren't you the clever troll!

Yet, amazinginly enough, Common Lisp compilers do it all the time.

You assume people are using some particular tool, with a fairly decent
interface, that I ain't never heard of. From all indications, a straw
poll here would show most of the other lispers to be using emacs or
something else equally primitive, though, and there might also be issues
with getting such a tool to work with different dialects of Lisp
reliably.

Well, the Emacs-based tools do that.

So do other IDEs, such as Allegro's and LispWorks.

But it really doesn't matter what tool it is, because you seem to be
quite able to imagine defects and malign technologies that you've never
bothered to understand, so what difference would it make if you had
heard of the particular systems?

Limp. Very limp.

But true, very true.
You just invoke the function the same way as any other lisp function.

Fully-qualifying the fuckin' names! What the hell else could I be
referring to?

You don't have to do it.

You seem to be getting frustrated that all of your putative objects are
really just whisps of smoke that don't exist in real usage. The
standard answer to your so-called problems really is that it isn't a
problem, because, frankly, it isn't.

Fully qualified names are no more of a problem in Common Lisp than they
are in Java. You occassionally need them if there is a specific
potential naming conflict, but otherwise various importing mechanisms
eliminate the need for it.

Let me guess: no MANUAL code generation. Something in the toolchain does
it for you.

Well, the only manual code generation is writing the specific part that
applies to the method you want. The linkage to the rest of the system
is handled by the compiler. The same way that you don't have to
manually link up your Java class hierarchy, or figure out the details of
the method dispatch. The language infrastructure does that.

That's not quite the same thing. And there's no namespace-related stuff
in your code. OK, there was none in mine, either, but you can just slap
a "package foo;" at the top of it. Whereas yours requires you to
defmethod the pre-existing, in some widely used namespace, print-object
method, with who knows what potential risks if you screw it up.

There are no more risks doing that than doing any other programming
task. You are just adding a method to the name. It's just like adding
a subclass, in many ways.

Oh yeah, I forgot: you're perfect and simply will not ever screw it
up. Ever.

Not any more than in any other programming language.

Like a C++ vtable, then, except that you (or a bug in your code) can
screw with the vtables for objects from the standard library, the
vtables for MY objects, ...

No, not like C++ vtables. They work differently.

But you can't screw them up any more than you can screw up the method
dispatch tables that Java generates internally. And dispatch tables
don't belong to classes!

 

[duane]

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.

I agree on both counts. This weekend has been very entertaining.
It's like the standard formula for SitComs on TV, where the
protagonist gets the entirely wrong idea about some reality, and the
interactions with the antagonists generates the humor to the delight
of the audience.

However, I'd give this comedy only 3 out of 5 stars, for two reasons:
first, it is too long, and second, such a sitcom is much funnier if
the antagonists would only misunderstand the protagonist as well; then
the double-meanings of the conversations would take on a whole new
level of hilarity. But unfortunately, this isn't happening here, and
thus the lower rating...

Duane

 

[Thomas A. Russ]

So, it is your opinion that object orientation is a mistake?
Fascinating.

So, it is your opinion that there is exactly one model for object
orientation? Fascinating.

 

[Stefan Ram]

No, no, no! Stick to LiSP, it is The Best Language.

I like to give adult evening classes on programming that I get
paid for. I can give Java classes because there is demand for
Java classes. I cannot give Lisp classes because there is not
sufficient demand for Lisp classes.

Insofar, in my realm, Java is more useable to me than Lisp.

I also often choose Java for my own programming projects,
because its large standard library includes standard features
even for GUI-based applications and for internet access. So my
software only depends on the standard Java SE distribution,
not on any additional libraries.

Because of the wide distribution of Java SE, I can expect the
platform to be still available and maintained in the future.
I cannot expect the same for third-party extension libraries.
Therefore, I like a language with a rich standard library.

I could possibly use Clojure for my own projects now, which is
a Lisp on the Java platform, but not for teaching. But it also
is nice to be able to concentrate on a single language (or not
too many different languages).

 

[Thomas A. Russ]

Java lets you get by with a plain old

import foo;

As opposed to Lisp, where one is force to use

(import 'foo)

instead. That seems to be a mere syntax change....

 

[Lew]

Actually, it's really closing in on 30 years.

The zmacs variant was a windowed program since sometime around 1980.
This was used in the Lisp machine, which was also one of the first
single-user workstation designs. It was also one of the early uses of
bit-mapped (as opposed to character or vector) displays.

BOR-ing!

 

[Lew]

Hmmm. It seems to be in the language spec:


http://www.lispworks.com/documentation/HyperSpec/Body/s_declar.htm

Nothing to do with Java.

 

[Lew]

Precisely. It doesn't enter into this at all, in most cases.
It is nicely in the background for when you need it, but it doesn't
intrude into your day-to-day programming most of the time.

[More Lisp-specific stuff] ...

As fascinating as this Lisp conversation is, it's off topic for a Java newsgroup.

 

[Lew]

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.

Both are absent at the same time through the magic of killfiles.

 

[Lew]

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.

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.

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

 

[Lew]

In actual practice, you would only need to use fully-qualified names in
the same type of circumstance that you need fully-qualified names in
Java: When there is an ambiguity in the "short names" in the namespace
that you are operating in.

Good news! Lisp is at least as good as Java!

You've made your point.

 

[Lew]

Really? Watch this:

[Lisp example elided] ...

Lisp is not Java.

 

[Lew]

Yes, well. I continued it where it began, not knowing where all
participants might be reading from. No harm when the thread was going
strong, but yes, it's winding down now.

Do us a favor and let it wind down off the Java group, hm?

 

[Lew]

However, I'd give this comedy only 3 out of 5 stars, for two reasons:
first, it is too long,

And yet you lengthen it.

 

[Lew]

http://www.inspiration.com/videos/InspireData

Done in Lisp.

Lisp is off-topic for a Java newsgroup.

 

[Lew]

diarrhea

Off topic in a Java newsgroup.

 

[Lew]

So, it is your opinion that there is exactly one model for object
orientation? Fascinating.

It is my request that this "fascinating" (not) discussion move off the Java
newsgroup. Please.

 

[Lew]

As opposed to Lisp, where one is force to use

(import 'foo)

instead. That seems to be a mere syntax change....

Nobody cares.