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

[Seamus MacRae]

[lots of back-and-forth]

Emacs provides the same feature for cpp: you can select a region
containing macros calls in a C or C++ buffer and use the
c-macro-expand command to have it send the #includes and the selected
text to the C pre-processor, and display the result to another
temporary buffer.

Ah, regions and temporary buffers! How quaint.

Here in the 21st century we have balloon help and the ability to overlap
windows with one another.

Who said it was manual?

You said something about putting macros in a separate source file "and
defining correctly the dependencies of the other files". Sounds like you
need to stick (defdependency foo bar) type thingies in "the other
files", which sure seems manual to me.

Neither lisp programmers: these features are provided by any
programmer editor such as emacs. There's nothing to be done.

Oh? You said earlier, that it "can be implemented using" technical stuff
etc. etc. yadda yadda yadda. I'd rather spend my time implementing what
my boss is paying me to implement than implementing my own half-assed
pseudo-IDE with some editor's scripting language.

I don't presuppose that there is no documentation of your java codes,
so don't presuppose that there's no documentaiton of my lisp codes.

My Java codes (note: capitalization) had documentation right there in
them when I posted them. Your lisp codes had none. Unless maybe all
those parentheses somehow constitute the documentation.

I saw no more documentation of the java code I had the occasion to see.

Try turning the contrast knob to the right, and then reread the post of
mine that somebody characterized as a "piece of vomit" earlier today.

It is called in place, but doesn't replace in-place.

What, you mean that guy's editor's user interface lies to the user? WTF?

I know of no lisp IDE having this feature.

Well, gugamilare apparently does, so that makes one of you.

Lisp IDEs are not hypothetical.

Eh. I'll believe that when I see one. (And no, a text editor with
delusions of grandeur is not an IDE.)

Has anybody said it was otherwise?

Well, certainly the curses-based editors you lot all seem to be using
wouldn't know balloon help even if it fell from the sky and knocked
their neat little grids of ASCII characters all out of whack.

Such a feature has never been described.

I think gugamilare might have some objections to your implied claim that
one of his news-posts doesn't exist.

Yes, I've been programming professionnaly for 27 years, that must have
been IMAGINARY. Have you a -i to spare?

Will it annihilate you? It sounds like it might be your antiparticle,
and I wouldn't want to have a murder rap hanging over my head. Well,
maybe just negligent homicide or something.

No, as trivial as using the simple features provided with emacs, or as
downloading the slime IDE and using its more sophisticated but simple
to use features.

Slime IDE. Well, that's probably a step up from emacs, though I'll bet
dollars to doughnuts it's no NetBeans.

The point is that the tools renders the bookkeeping so oblivious that
it feels like if you are just editing the running image, but ...

If I liked using tools that render me oblivious to live dangerously, I'd
fly a Cessna while wearing dark glasses.

Thanks, but no thanks.

If flying blind is your kick, all the power to you. I'll stick with my
NetBeans, which never leaves me in any doubt as to where anything is or
where any changes are going, and which nicely interoperates with svn.

What CLI?

Well, that would depend. On our Windows machines, we use the lame
Windows command.com most of the time, but occasionally some enterprising
soul seems to have a Windows port of bash. The Unix wizards running the
server room seem to prefer bash, with the odd ksh or csh user. Not that
it really matters, the svn commands to check in and check out files in
the repositories are pretty much the same whichever shell is used.

Most of us use IDEs that talk directly to the repository anyway, saving
us the bother.

Where do you think NetBeans developers got the idea from?

Probably from Eclipse.

Where these developers even _born_ when emacs was created?

Probably some of them were and some of them were not. Not that legacy
applications are really our forte. We're not an old enough shop for
that. I think some of the unix guys that manage the web servers use vi,
and other deep wizard stuff, but us programmers prefer full-featured
IDEs with modern user interfaces, not to mention language-aware search,
svn integration, and all sorts of other bells and whistles you won't
find even in a modern programmer's text editor, let alone in things like
Editpad and MacWrite, or thirty-year-old curses-based museum-pieces, or
forty-year-old line editors, or fifty-year-old card punches.

 

[Seamus MacRae]

+---------------
| (e-mail address removed) (Pascal J. Bourguignon) wrote:
| > Lisp macros are just a much simplier and much more powerful to archive
| > the same results much faster.
|
| It's hard to make the power of CL macros clear to non-Lispers. They think
| in terms of the macros of other programming languages, and have no idea
| what CL macros are. From their point of view, we seem to be telling them
| we want to use macros as a klugey substitute for C++ templates, or for the
| Java type system, or whatever.
+---------------

Oddly enough, it is *much* easier to explain Lisp macros to those
who have experience with assembly language macros in such "antiques"
as the DEC PDP-10 or IBM 360/370 mainframes which supported looping,
deconstruction/construction of symbol names (down to individual
characters), definition of new macros *by* macros, access to the
assembler's symbol table at compile time (accessing & mutating the
values of symbols and tags), "pass1" vs. "pass2" conditionals
(collect data from the whole program in pass 1 and drop it into
instruction and/or data locations in pass 2), etc., etc.[1]

But for those whose first or only experience of "macros" came from
the crippled incarnation of them in C, well, you are quite correct,
sadly.

The preprocessor in gcc lets you write macros that glue symbol names
together out of pieces. I think it's not an ANSI-standard feature
though. On the other hand, gcc-only compatibility is enough to get you
pretty wide operating-system and hardware portability these days.

 

[Pillsy]

Pascal J. Bourguignon wrote: [...]

Concerning the names, it's like if having a class foo.String, you
could define a java method foo.doIt and another java method bar.doIt.
(new foo.MyString).(foo.doIt)() would no call the same method as
(new foo.MyString).(bar.doIt)().

Isn't this exactly the problem Series Expansion foresaw? Lots of extra
namespace qualifiers dangling all over the place and virtually
unreadable code.

In practice, no. You would import what you want into the namespace
you're working in a way that would allow you to avoid most clashes and
thus most of the need for qualifiers. So you could do (translated into
more CLish language, because my Java knowledge is quite limited):

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

(do-it (make-instance 'my-string))
(bar:do-it (make-instance 'my-string))

Only one qualifier is necessary in this example. DEFPACKAGE provides
very fine-grained control if you need it, should you decide, for
instance, that you really are going to use BARO-IT a lot more than
FOOO-IT and thus want to be able to use BARO-IT unqualified
instead.

Cheers,
Pillsy

 

[Dangling Pointer]

On the much more frequent occasion I wanted to
add a new noun, I'd often be forced to change verbs that lived in
pre-existing namespaces, and maybe even in more than one namespace; the
code for my new noun would be scattered all over the codebase AND the
namespaces within the system, rather than in exactly one place in each.

This, at least, is a *potential* problem, but in *practice* it's never
caused me any difficulty. [emphasis mine]

My God, what a bunch of Pollyannas.

 

[Pillsy]

On the much more frequent occasion I wanted to
add a new noun, I'd often be forced to change verbs that lived in
pre-existing namespaces, and maybe even in more than one namespace; the
code for my new noun would be scattered all over the codebase AND the
namespaces within the system, rather than in exactly one place in each.

This, at least, is a *potential* problem, but in *practice* it's never
caused me any difficulty. [emphasis mine]

My God, what a bunch of Pollyannas.

My God, what an uninteresting rebutal.

Cheers,
Pillsy

 

[Pascal J. Bourguignon]

Well, that would depend. On our Windows machines, we use the lame

I meant that NetBeans has exactly the same feature as emacs, nothing
more. AFAIR, emac has been able to checkout and checkin files from
any version control system. There's no need to go to a cli to do
these operations anymore in emacs than in NetBean. And again, guess
who copied who?

Probably from Eclipse.

No, from emacs.

 

[Seamus MacRae]

This, at least, is a potential problem, but in practice it's never
caused me any difficulty.

*deep sigh*

Lisp development environments are quite
helpful when it comes to locating method definitions wherever they
might be.

What development environments? That curses-based museumstrosity you were
evangelizing half an hour ago? Surely ye jest?

Same in Common Lisp. Classes can inherit from other classes, and
generic functions dispatch on the run-time class, respecting
inheritance relationships.

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.

Not at all. The necessary modification of the generic function is
handled automatically (really, CLOS would be remarkably useless if it
weren't) when you define the new method.

You mean, the source code for a dispatch table you posted is
machine-generated, like yacc output? No wonder it looks like ... well,
what a lay person will probably imagine "yacc output" describes.

I hate machine-generated code. I hatehateHATE having to *maintain*
machine-generated code. (Object code and .class files notwithstanding.)
It's always a mess, and you're always tempted to fix something in it
directly, and then the next time make runs, all your changes go bye-bye
as the code generator blithely overwrites every last byte of 'em.
Keeping it somewhat prettified is a Sisyphean task, since the boulder
rolls back down every time anyone builds that part of the codebase.
Finding the file that it's generated from can be a nuisance.

That's with bison parsers and Matisse GUIs and crap like that. Your Lisp
dispatch thingies (generic functions, did you say?) must get built from
snippets scattered all over the damn place. Finding all the code that
generates those must be nigh-impossible.

And there's no problem defining methods from one namespace on classes
from another namespace.

What about using the darn things? Let me guess, "there's no problem", by
which is meant "it is physically possible, though you'll need a few
tablets of Excedrin afterward and might want to save up a few sick days
first".

You need to be able to do this to add methods
for user-defined classes to built-in generic functions (like PRINT-
OBJECT or INITIALIZE-INSTANCE).

Such a pain, when Java lets you just go

public class MyWhatsit {
@Override
public String toString () {
return "I'm a MyWhatsit!";
}
}

sticking this in your own namespace and not monkeying with any other
code anywhere (either manually, or by running some sort of
code-generator), yet if a MyWhatsit is subsequently passed to e.g.
String.valueOf(Object), out pops "I'm a MyWhatsit!".

It ain't real polymorphism until you can do that, *without* scribbling
outside the lines around the box your code is in.

In Common Lisp, you'd just write the four method definitions; you
wouldn't even have to mention the "implements Number" part.

Duck-typing? Well, it beats no typing at all I suppose.

Eh, wait a minute, you'd write the four method definitions and then run
that code-generator thingy to generate the new versions of the dispatch
tables.

Er, how does that code-generator resolve conflicts again? If someone
else makes a class, also calls it Complex, implements it differently
(r-theta instead of x-y say), and writes methods with the same four
names? Does it use the package the Complex class is in to keep the two
versions of each separate?

 

[Seamus MacRae]

Pascal J. Bourguignon wrote: [...]

Concerning the names, it's like if having a class foo.String, you
could define a java method foo.doIt and another java method bar.doIt.
(new foo.MyString).(foo.doIt)() would no call the same method as
(new foo.MyString).(bar.doIt)().

Isn't this exactly the problem Series Expansion foresaw? Lots of extra
namespace qualifiers dangling all over the place and virtually
unreadable code.

In practice, no.

Subject to some qualification, no doubt.

You would import what you want into the namespace
you're working in a way that would allow you to avoid most clashes and
thus most of the need for qualifiers. So you could do (translated into
more CLish language, because my Java knowledge is quite limited):

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

(do-it (make-instance 'my-string))
(bar:do-it (make-instance 'my-string))

Only one qualifier is necessary in this example. DEFPACKAGE provides
very fine-grained control if you need it, should you decide, for
instance, that you really are going to use BARO-IT a lot more than
FOOO-IT and thus want to be able to use BARO-IT unqualified
instead.

Ah, okay. I see; the qualification is evidently "must be rocket
scientist, or have economy-size bottle of Motrin".

Java lets you get by with a plain old

import foo;

by contrast. No mess, no fuss, and none of that shift-3 shit.

 

[Seamus MacRae]

I meant that NetBeans has exactly the same feature as emacs, nothing
more.

That's a joke, right? One's a full-blown IDE, the other just a text editor.

No, from emacs.

Copying something from emacs is a good way to give your user base a
headache. Especially if it involves "meta" or (n)curses.

 

[anonymous.c.lisper]

That's a joke, right? One's a full-blown IDE, the other just a text editor.



Copying something from emacs is a good way to give your user base a
headache. Especially if it involves "meta" or (n)curses.

I love your posts,
Please never stop.

 

[Adlai]

You said something about putting macros in a separate source file "and
defining correctly the dependencies of the other files". Sounds like you
need to stick (defdependency foo bar) type thingies in "the other
files", which sure seems manual to me.

There is a very minimal amount of dependency-defining. Defining
packages in Lisp used to be a task involving several different
functions, until it was standardized into a system using -- guess
what? -- a handful of macros that do the job very powerfully and
concisely.

Oh? You said earlier, that it "can be implemented using" technical stuff
etc. etc. yadda yadda yadda. I'd rather spend my time implementing what
my boss is paying me to implement than implementing my own half-assed
pseudo-IDE with some editor's scripting language.

This is where something like SLIME comes in.

Superior Lisp Integration Mode for Emacs is, essentially, a set of
options and scripts for Emacs that turn it into a Lisp IDE. While you
can't have minor cosmetic features such as help bubbles and popping
things into half a trillion windows all over your screen, you CAN:
- Compile files as you work on them, or choose specific functions to
compile separately.
- Run a Lisp image so that you can test out new ideas and debug your
code as you write it.
- View macroexpansions.
- Jump to source definitions for functions and macros.
- Perform sophisticated function tracing and cross-referencing for
debugging.
- When you compile and the compiler has warnings, the warnings show
up in the relevant places in the source code.
- With two mouse clicks, you can deal with checking parenthesis
matching, updating indentations, etc -- in other words, you have to
manually deal with less syntax than a Python programmer does.

I'm not gonna go into a whole list of features here, but basically,
SLIME turns Notepad into NetBeans.

My Java codes (note: capitalization) had documentation right there in
them when I posted them. Your lisp codes had none. Unless maybe all
those parentheses somehow constitute the documentation.

EVERY SINGLE Lisp form that "defines" something -- be it a function,
macro, class (even slots within a class get this), constant, etc --
has a syntax for adding documentation. It's good style to add
documentation in exactly the same way that it's good style to add
documentation to programs in Java, C, or any other language.

Some examples:

(defun foo (bar)
"Returns the foorier transform of bar"
(form1)
(form2)
... etc)

(defvar *users* NIL
"A list of all the users of the system")

(defclass programmer (engineer designer)
((languages
:documentation "A list of the languages the programmer is
'fluent' in.")
(current-project
:documentation "The project that this programmer spends most of
his time on."))
documentation "The programmer class. Inherits from the classes
Engineer and Designer."))

Lisp also has comment syntax, just like any other language. You can
intersperse comments anywhere in your code.

(defun tr-fact (n &optional (acc 1))
"A tail-recursive factorial function" ; This line has both
documentation and a comment
(if (= n 1)
acc ; Factorial value is accumulated in
variable
(tr-fact (1- n) ; ACC as the function recurses. This is
done
(* n acc)))) ; to facilitate tail recursion.

Whether you comment and document your code in great detail or not
depends on you, and your taste, not on the language you're using.

There's a function that's part of the Common Lisp standard, for
retrieving documentation for a function, class, variable, etc. If the
person who wrote the libraries you're using wrote documentation,
you'll be able to read it. Good IDEs for Lisp provide quick ways to
access documentation, so that you just select a function and you can
view the docstring for it.

What, you mean that guy's editor's user interface lies to the user? WTF?

Capsule summary of Lisp macros:

A macro call doesn't change your source code. The macro changes the
code once it's being compiled or interpreted. When you write (some-
macro-call foozbozz (a b c) (print foo)), that is what will stay in
your source files until you manually change it. Macros work their
magic once you send that form to be compiled or evaluated. Although
SLIME is aware of macro calls and formats them differently from
function calls, the place where "in-place" macroexpansion happens is
in the compiler.

However, there is a way to view the code that a macro call expands
into, if you want to view it to catch that one bug and fix 50 errors
at once. This is part of the CL standard, it's a function called
MACROEXPAND that displays the expansion of a macro call which you pass
as its argument, and it's also a command supported by most Lisp IDEs.

Eh. I'll believe that when I see one. (And no, a text editor with
delusions of grandeur is not an IDE.)

Emacs is just a text editor. Emacs + SLIME is a full-fledged IDE.

Well, certainly the curses-based editors you lot all seem to be using
wouldn't know balloon help even if it fell from the sky and knocked
their neat little grids of ASCII characters all out of whack.

Firstly, in SLIME, when you use various IDE options, they usually open
apart from the source code.
Secondly, commercial IDEs actually -- big surprise -- do use separate
windows for stuff!

Will it annihilate you? It sounds like it might be your antiparticle,
and I wouldn't want to have a murder rap hanging over my head. Well,
maybe just negligent homicide or something.

Seamus, for someone who started out their posts criticising people for
flaming, you're starting to seem a bit hypocritical. I know this
sounds like giving advice to a 6yo kid, but -- if someone starts
taunting you, that's no reason to send it back. If you think they
don't understand something you tried to say -- as I think that some
people posting here aren't familiar with the differences between Lisp
as it was in 1958, and Common Lisp as it is today -- then just
patiently try to clear up any misunderstandings, ok?

Slime IDE. Well, that's probably a step up from emacs, though I'll bet
dollars to doughnuts it's no NetBeans.

I've addressed this already. It might not have the exact same sugar-
coated bubbles and glossy GUI, but it has very powerful functionality.
You could customize it further if you really wanted to, but SLIME is
like a library of customizations, and it's quite powerful as-is.

Probably from Eclipse.

Not to put words in Pascal's mouth, but I think he's implying that 1)
these ideas originated in Emacs, or early IDEs similar to it, and 2)
functionalities that originated there, are still there today, as
powerful as ever.


I hope I've cleared up a few confusions about the IDE and about macro
expansions.

- Adlai

 

[Series Expansion]

I know Java. In fact, I use it every day at work. I don't think it's a
bad language; it has some  features (some not well-known) that you
could only dream of in mainstream languages prior to it. And it has a
huge standard library, and many widely used open source libraries for
all sorts of things.

Now, is there any Lisp implementation for which this is true?
Particularly, as broad coverage of common requirements (GUIs,
networking, threading, math) as Java has in standard/widely-used
libraries?

But. Especially in big applications, static typing really shows its
limits.

You're kidding. Especially in BIG applications? But we've just been
through why the static typing overhead is a smaller proportion of the
work the bigger the app, and the bug-finding savings bigger.

[a whole lot of some tangent about XML]

I'm not saying Java is unusable and should be dropped tomorrow. Just
that maybe it's not the be-all, end-all of programming languages

I'm not sure any of them are.

Don't knock having the compiler check for type errors until you've
tried it.

 

[Series Expansion]

I don't see how it follows that you cannot collaborate but in
any case it's the same with functions: you and a coworker might
write functions with the same name but doing different things.
Any solution you have for this problem will work with macros.

Three messages saying this, more or less. Two of them identical and
from you.

None acknowledging the difference between merely defining named
functions and actually *altering how the compiler interprets the
language* (or, and this came up elsethread, altering a system class to
add idiosyncratic new methods).

 

[Kenneth Tilton]

Say rather that Lisp programmers drink the Kool-Aid and Java programmers
are pragmatic and thoughtful.

Say this: Lisp programmers have programming jobs meaning they know Java
or Python or Ruby or whatever so there is prolly not much delusion
involved. It is more of an informed comparison. Yes, the bad news is
that we are also better at those languages than you. Sorry for the comedown.

I was not wondering, and you have not established that goggle-eyed
adoration is superior.

I took a different path, I pointed out that we Lisp Gods have Perfect
Knowledge of crud like Java, we have to to feed the kids.

I think it's a good sign that Java adherents are
committed to improvement and constant examination. I also find it
telling that far more commercial projects are programmed in Java than
Lisp.

I find it telling that Groovy got invented because the tide had left
static typing and all-OO-all-the-time and catch-every-exception high and
dry and was not coming back.

So it's a good and healthy sign that competent Java programmers,
of whom I'm one, continue to examine the language.

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

ps. [sic] I thought you were going to *watch*. Won't you keep knocking
over that bowl of popcorn? kt

Interesting that you feel the need to resort to personal attack. What fun!

You made three jokes about popcorn and I made one, which did nothing
more than catch you out on a minor gaffe (claiming to sit back as you
were diving in) and you call that a personal attack? Hmmm... OK, I have
two interpretations. Either you are barking mad or you slipped up and
trotted out the "ooh that's personal" flamewar gambit without
foundation? I am guessing the latter, and blame the popcorn.

Perhaps Java programmers are more secure in their knowledge of the
language ...

Explaining why they spend all their time complaining about it? I had a
wife like that once.

...and see it merely as a tool, and not some cult that requires
snarky remarks and blind devotion in lieu of reasoned and dispassionate
utility. Or perhaps not. I just notice that the tone in this thread
from the Lisp programmers tends to the nasty and personal compared to
those who are trying to explain why they find Java useful.

Useful? A tool? Oh, be still my beating heart. A wise man once said that
Java was the only language no one ever loved.

I am suspicious of anyone who claims any programming language is the
be-all and end-all for all purposes world without end amen.

Ah, never had the pleasure of macros, have we? Glory be to the
readability and to the parsing and to the &whole parameter.

You seem like a great guy and quite bright at that. Do yourself a favor,
STFU and learn Lisp. Mr Costanza can fill you in on the rest.

hth, kt

 

[Series Expansion]

You can blow your foot off with pretty much every language. You
seem convinced that macros make things much more dangerous
but this hasn't been the experience of Lisp programmers or they
would have abandoned macros.

That's interesting. It HAS been the experience of C programmers. And
they haven't abandoned macros; they're still alive and well, if used
sparingly.

Note that core parts of Lisp
are implemented with macros and it hasn't caused anyone's foot
to blow off.

Core parts of Lisp are well-tested, I assume.

Five-minute quick hacks are another story, and unfortunately, it's in
the nature of macros to potentially interact with practically the
entire code base.

If you doubt that, think for two seconds about the consequences of
taking any very large C project and sticking this at the top of the
most commonly-included header file:

#define malloc(x) 1

The horror of it is, it will probably actually compile (at least if
the malloc.h header is seen before the one you edited) but it will
bomb with SIGSEGV or otherwise blow up spectacularly when run.

And that's macro mischief in a "safe" (well, type-safe) language.

I can only begin to imagine what might happen (even by accident) with
a macro in a dynamically-typed language.

With a badly-written function, the code that uses that function has
problems. A badly-written macro can throw a spanner into the works
just about *anywhere*. Or, sometimes, just about *everywhere*.

Regarding whether metaprogramming is needed then strictly
speaking it is not. Strictly speaking one doesn't even need a
high level language , people have written useful programmes
in assembly.

Interesting that people mostly prefer C and Java to assembly, but
mostly prefer C and Java to Lisp, then ...

 

[Pillsy]

Pillsy wrote:

*deep sigh*

What? A mix of commonly used idioms, coding practices and tool support
allow you to avoid a potential problem when writing programs. That's a
pretty common state of affairs in software development.

What development environments? That curses-based museumstrosity you were
evangelizing half an hour ago? Surely ye jest?

No, Emacs + SLIME has convenient features for locating method
definitions in their source files. Just because the interface looks a
like something out of 1983 doesn't mean it doesn't work well.

Inheritance relationships recorded where?

In the class definition...? If I want to say that FOO is a subclass of
BAR, I just write

(defclass foo (bar)
;; This space for rent!.
)
[...]

You mean, the source code for a dispatch table you posted is
machine-generated, like yacc output?

No, I mean, you never see any of it. All you do is write the message
definition and compile it and you're done, since methods can be added
or changed at run-time.
[...]

I hate machine-generated code.

So do I. It's a very good thing that you don't have to use it to use
CLOS.
[...]

Your Lisp
dispatch thingies (generic functions, did you say?) must get built from
snippets scattered all over the damn place. Finding all the code that
generates those must be nigh-impossible.

You select the name of the generic function, hit Alt-., and a list
pops up listing all the methods for the generic function and their
classes. Then you click on the one you want, and you're taken to the
definition. It's really, really similar to looking up definitions in
Eclipse.

What about using the darn things?

You just... use them?

Let me guess, "there's no problem", by
which is meant "it is physically possible, though you'll need a few
tablets of Excedrin afterward and might want to save up a few sick days
first".

No, I mean, "there's no problem", by which is meant that I can't even
figure out what problem you might be referring to.

Such a pain, when Java lets you just go

public class MyWhatsit {
     @Override
     public String toString () {
         return "I'm a MyWhatsit!";
     }

}

sticking this in your own namespace and not monkeying with any other
code anywhere (either manually, or by running some sort of
code-generator), yet if a MyWhatsit is subsequently passed to e.g.
String.valueOf(Object), out pops "I'm a MyWhatsit!".

I'm really not seeing much difference between that and

(defclass my-whatsit () ())

(defmethod print-object ((object my-whatsit) stream)
(print-unreadable-object (obj stream)
(format stream "I'm a whatsit!")))

That's all you have to do. No monkeying with any other code anywhere
else. No code generation.

Neither fuss nor muss.
[...]

Duck-typing? Well, it beats no typing at all I suppose.

Eh, wait a minute, you'd write the four method definitions and then run
that code-generator thingy to generate the new versions of the dispatch
tables.

No, you write the four method definitions and then compile them. All
the machinery for doing the dispatch is handled by the Lisp
implementation transparently.

Cheers,
Pillsy
[...]

 

[Series Expansion]

I guess that's one of the downsides of an inside-out object
system.
Inside-out?


No, he's saying that support methods that don't make up a library's API
won't be exported from packages

Er, that's basically what I meant by "make them private". Duh.

MY point, which remains unaddressed, is that there are three ways to
deal with a commonly-desired support method:

1. The vendor puts it in the system class. No problemo.
2. Everyone rolls their own. Ugh.
3. A third party library puts it in the system class.
Whereas the vendor would create an automatic standard,
absent this, most likely multiple third party libraries
would develop to do the job, and would each do it a bit
differently. Code using one and code using another one
could not typically be combined without problems.

so there's no hazard of name clashes
between them when one chooses to import all symbols from a package. That
leaves a smaller number of potential name clashes to resolve manually.

And leaves everyone who wants to add the same utility method to the
same class to each do it separately. Ugh.

Not boilerplate. Just resolving a couple of conflicts if they arise.

Everywhere the symbols were used there'd need to be some preamble code
to "explicitly tell how the clashes should be handled". Repeated over
enough usage-sites, that adds up to boilerplate.

 

[Pillsy]

Subject to some qualification, no doubt.

Nope, not really.

Ah, okay. I see; the qualification is evidently "must be rocket
scientist, or have economy-size bottle of Motrin".

Eh, in the general case you just use the packages you want to use and
that's that, but if you want more flexibility it's there.

Java lets you get by with a plain old

import foo;

by contrast.

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

No mess, no fuss, and none of that shift-3 shit.

The "#:" is optional, actually.

Cheers,
Pillsy

 

[Series Expansion]

"first"?

I do not understand the question, unless it was to suggest a slightly-
longer but more-intuitive name for what they called "car".

(The rest I won't dignify with a response.)

 

[Adlai]

Everywhere the symbols were used there'd need to be some preamble code
to "explicitly tell how the clashes should be handled". Repeated over
enough usage-sites, that adds up to boilerplate.

You have to remember though, that there's not really such a thing as
boilerplate Lisp code. If you need to use some code once, you write it
there and that's it. If you need to use it more than once -- or if you
can conceive of situations in other projects, where you'd need to do
the same thing again -- you whip up a macro, and bye bye boilerplate.

The beautiful thing about macros is that it's not "machine-generated
code". You actually get complete control over the code into which a
macro call expands. You can use nitty gritty low-level special forms,
or build your new syntax on top of existing high-level forms. Once
you've written a macro, using it is like hitting Ctrl+V to paste some
code you used earlier, except the code reads your mind and customizes
itself to the situation. Unless you're writing wizard macro-defining
macros[1], debugging macro code is fairly straightforward with the
assistance of macroexpansion tools available in modern IDEs such as
Emacs + SLIME, and a working macro that you'll reuse in the future is
a huge asset.

- Adlai

[1] For example, Peter Seibel's once-only macro from PCL.
http://www.gigamonkeys.com/book/macros-defining-your-own.html