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

[Series Expansion]

Of course I won!

You did? What was it, the bozo of the week award? Can I see it? Pretty
please?

 You complained about a feature of CL, and I showed
you how you can correct that feature yourself, without patching the
compiler, without having to convince all the other users of that
language that your feature was worthwhile, without having to lobby Sun
Microssystem to change the language and without waiting for them to
issue a new JDK, which would render all the programs developed so far
obsolete.

No, now it will just make all your coworkers break out in hives when
your code is checked into the source code repository and a big
whirling red light and wailing Klaxon promptly pop out of panels on
the git server box to warn of an impending meltdown.

By the way, a few years ago I wrote a few java programs.  I tried to
run them again now, and they couldn't run.  Different JDK I suppose.
On the other hand, the programs I wrote twenty years ago in Common
Lisp still run nowadays with the new implementations of Common Lisp.

But they're just as obsolete. If nothing else, their user interfaces
will be woefully subpar by modern standards.

 

[Series Expansion]

The Law of the mean.

Where I live, law is decided by duly elected representatives of the
people, not by "the mean".

Where are you, where jungle rule apparently coexists with fairly
dependable internet access?

 

[Series Expansion]

Stop saying that already! I wouldn't!

You said otherwise yesterday.

What I wrote was just misinterpreted

I did nothing of the sort, of course.

what I really meant is what folks already said: I hit
three keys n my keyboard and a new buffer is open with the
macroexpansion!

That's not what you said before; you said, or at least strongly
implied, that it was expanded in place.

I just had to leave so I couldn't say it, but you
should take the other Lisp folks' word when they said what I really
meant.

Oh, really? Why? What they say about Lisp I expect will jibe with what
you say about Lisp. But there's no reason to expect that they can read
your mind regarding your own personal, idiosyncratic workflow.

Sorry to make this personal, but [makes this personal]

I'm not interested in getting into an insult-hurling contest, sorry.
You'll have to find someone else to participate in that sort of
silliness.

It is impossible to have a normal discussion with you folks. You
REALLY should EITHER learn Common Lisp or scheme RIGHT NOW so
that you KNOW what you are talking about or STOP POSTING HERE!

You keep posting anti-Java rants into comp.lang.java.programmer, you
can expect to keep seeing anti-Lisp rants in comp.lang.lisp. Not that
I've written any myself; I've questioned your faith, sure, and
rationally suggested that macros, CLOS, and some other particular
things have their downsides, but I have not "ranted".

 

[Series Expansion]

You point out one seriously destructive thing you can do with C
macros, I point out that you can't do that with Lisp macros and
explain why, and this is your response?

Let's see:
1. The "destructive C macro" I posted adhered to the Lisp restriction
that macros have to look like, syntactically, function calls. So you
can do that with Lisp macros.
2. If you really couldn't, it would mean Lisp macros were less, or
differently, rather than more, powerful.

 

[Series Expansion]

Not poor-man's, but very precise and powerful type-derivation and type-
checking.

Come off it. You're grafting on something the compiler and language
weren't originally designed for, so it's going to necessarily suck
compared to the real deal. You say C macros suck because they're
grafted on instead of a true part of the language, I say Lisp type
checking sucks because it's grafted on instead of a true part of the
language. Entirely symmetrical, so you can't have it both ways.

Nevermind that apparently the most you can get is run-time exceptions
and compile-time warnings -- no compile-time errors.

Before Java's generics, you could work within the pre-Java-5 Java
language to create something like their effects. For instance, you
could make a class StringList extends AbstractList implements List
that was constructed around any List and delegated to it, except that
its add method checked if its argument was a String before adding it
and its get method cast the return value to String before returning
it, both throwing ClassCastException on mismatch. Nobody would
consider this better than the present generics.

(One complication: without covariant return types you'd also have had
to leave get's return type Object, but you could add a parallel
getString returning String and a parallel add(String) overload too.)

Not having to worry about variable types is a bless.

Except that you do have to worry about variable types. Whether the
compiler helps you check it or not, if you don't understand the types
of the data flowing through different parts of your program, then you
don't understand your program, and it isn't going to turn out well. So
whether the variables have any distinct types the compiler knows
about, they still have types the programmer knows about, or at least
ought to.

The other way around is also true, once in a while static typing
languages encapsulate more than one type in a box. Sometimes they just
write the same code twice - once for each defined type.

If they're using a sucky language that lacks a facility like C++
templates or Java generics.

They are not when the user knows about them. I believe this amount of
control just confuses you, but it is really not that big deal.

Now, now, there's no need to get personal.

One issue here is that this "amount of control" will cause problems in
a realistic, team-oriented development effort.

The binding is local to the use of the if form, not global.

Well, that's just even more useless -- a variable you can't even get
at from elsewhere at the call site. (And which will still cause
problems if the call site uses a local variable of the same name,
which is shadowed within the macro, and one of the macro's arguments
uses that local variable.)

 

[Spiros Bousbouras]

Well , I did warn in [1] that the argument and counterargument
have been brought up before , years ago , on comp.lang.python so
you shouldn't be surprised if you encounter here it as well. I
think [1] appeared before you started commenting on macros.

What's this [1] shit? Some creative sort of pseudo-pronoun?

Who gives a crap. I can't figure it out without more information than
you've apparently chosen to provide.

[1] is a footnote. At the footnote, appearing at the end of my
post as footnotes tend to do was the following link:
<
http://groups.google.co.uk/group/co...1a8856b074/7385151a2ea1e6a9?#7385151a2ea1e6a9

[...]

Macros alter the compiler's behavior; you said it yourself earlier.

For the record, I never said such a thing.

[...]

I'm not in the UK, so I don't see how anything at groups.google.co.uk
could be relevant here, and I'm not sure I'd even get it. Half the BBC
website doesn't work from where I am, after all.

You're trolling, aren't you? I checked your Google profile and
you only have posts in this thread. So I guess you saw that a
flamewar was brewing and you decided to jump in to push people's
buttons. Ok man , good one , you had me going there for a while.
But now you've been made ;-)

 

[Series Expansion]

What the hell of a good point you have (ironic). Should I look for
unemployed Java programmers? I bet there are some.

In this economy, yes, though the only reason they're not outnumbered
by unemployed Lisp programmers is that there aren't all that many Lisp
programmers *total* whereas there are *millions* of Java programmers.

This is not Lisp vs. Java debate. We are not attacking Java at all,

sez Mr. "Java is slow, bloated, boilerplatey, and too lacking in
macros and dynamic typing for our sake, and besides, it's only for
incompetent programmers anyway".

because we are not the trolls here.

I think it was a pro-Lisp or anti-Java shot that got fired first,
which strongly suggests otherwise.

Give me one reference to someone here saying that Java is a bad language,
and I am done talking.

How about five?

http://groups.google.com/group/comp.lang.lisp/msg/36a74c9087908698
http://groups.google.com/group/comp.lang.lisp/msg/cc4b883036859e6c
http://groups.google.com/group/comp.lang.lisp/msg/26f94536dd3ff7ab
http://groups.google.com/group/comp.lang.lisp/msg/930c3cc4a528bfab
http://groups.google.com/group/comp.lang.lisp/msg/7b770fd050b6c0b1

In particular, the third link is to the now-infamous "Java code looks
like vomit" insult; the fourth post insults Java programmers rather
than the language directly, but I'm counting it; the fifth insults
both the language AND its programmers.

You Javaers are the ones treating us like if we are a bunch of
amateurs who don't know how to program.

One of you Lispers wrote, and I quote:

Lisp did that in the Sixties, and with a better Pole Star
("code is data is code") than Java ("programmers are
incompetent").

Sure looks like an insult to Java programmers. That's leaving aside
the numerous instances of personal attacks along the lines of "get a
clue", "learn xyz", "fool", "stop spouting ignorance on the net", and
so forth directed at the Java side from the Lisp side.

Indeed, I'd wager that more insults have been fired in that direction,
thus far, than in the other.

We over here are just showing why you are wrong, but this is a
difficult task since yadda yadda yadda

See what I mean? Yet another instance of a Lisper talking down to a
Java-user as if it were a given, rather than still under debate, that
the Lisp side is right and the Java side is wrong, and further
implying that we're all dullards that are more difficult to educate
than normal people.

Amazingly, the above is from the same person, in the very same *post*,
as:

You Javaers are the ones treating us like if we are a bunch of
amateurs who don't know how to program.

The irony is thick enough to cut with a knife!

If some feature would be an issue in the Java world, it does not
necessarily mean that it would be a bad thing in the Lisp world.

On the other hand, that does not preclude an argument being put forth
that demonstrates it to have unavoidable problems independent of
language syntax and other details like that.

For example, the variable-capture thing. Making a local scope within a
macro will avoid it, except that the scope inside the macro will
shadow same-name variables in the enclosing scope (the call-site) and
if the macro evaluates an argument in that nested scope, and that
argument is an expression that uses the same-name variable, poof! This
is an unavoidable consequence of how scope nesting works, combined
with how macros work, and is physically unavoidable on anything that
even has the concepts of local variables and a call stack and that
also has macros.

If the scope of a macro variable is not a local scope within the
macro, however, it has to be the call site's scope or a wider scope.
If it's the call site scope, we've got bog-standard variable capture.
If it's a wider scope, we've got some or all of the problems that
global variables cause, including reentrancy and thread-safety
problems that can't be swept under the rug by giving the global an
obscure name and/or sticking it in a namespace.

The best you can hope for is to use a nested scope, give the macro's
local variables long and obscure names, and pray.

And I have problems with prolific and carefree use of any language
feature whose best-practices instructions involve "... and pray".

The opposite might as well be true, there may be some Java features
that can't be transported to Lisp because of the way Java / Lisp
is, no arguments here.

Then the debate is over. Neither language "wins". It's a draw. Let's
all go home and get on with our lives now.

 

[gugamilare]

In this economy, yes, though the only reason they're not outnumbered
by unemployed Lisp programmers is that there aren't all that many Lisp
programmers *total* whereas there are *millions* of Java programmers.


sez Mr. "Java is slow, bloated, boilerplatey, and too lacking in
macros and dynamic typing for our sake, and besides, it's only for
incompetent programmers anyway".


I think it was a pro-Lisp or anti-Java shot that got fired first,
which strongly suggests otherwise.


How about five?

http://groups.google.com/group/comp...com/group/comp.lang.lisp/msg/7b770fd050b6c0b1

In particular, the third link is to the now-infamous "Java code looks
like vomit" insult; the fourth post insults Java programmers rather
than the language directly, but I'm counting it; the fifth insults
both the language AND its programmers.


One of you Lispers wrote, and I quote:

    Lisp did that in the Sixties, and with a better Pole Star
    ("code is data is code") than Java ("programmers are
    incompetent").

Sure looks like an insult to Java programmers. That's leaving aside
the numerous instances of personal attacks along the lines of "get a
clue", "learn xyz", "fool", "stop spouting ignorance on the net", and
so forth directed at the Java side from the Lisp side.

Indeed, I'd wager that more insults have been fired in that direction,
thus far, than in the other.


See what I mean? Yet another instance of a Lisper talking down to a
Java-user as if it were a given, rather than still under debate, that
the Lisp side is right and the Java side is wrong, and further
implying that we're all dullards that are more difficult to educate
than normal people.

I didn't say that the Java side is wrong. I just say things work
differently both ways, so, adding some features of Lisp inside Java
just the way they are do not work. And I noted that the opposite might
as well be true.

On the other hand, that does not preclude an argument being put forth
that demonstrates it to have unavoidable problems independent of
language syntax and other details like that.

But you still haven't given one argument independent of syntax and
implementation. In fact I don't even believe such a thing exists. Any
feature a language wants to include depends on its syntax and the way
that the programmers think.

For example, the variable-capture thing. Making a local scope within a
macro will avoid it, except that the scope inside the macro will
shadow same-name variables in the enclosing scope (the call-site) and
if the macro evaluates an argument in that nested scope, and that
argument is an expression that uses the same-name variable, poof!

Unless the user knows the macro locally creates a variable. This
shadowing variable thing is well known - we are not amateurs - and we
take a lot of care when using features like that. Anaphoric macros
(aif, awhen, ...) are very well known by almost every lisper, and I
have never seen other macro that captures some variable like that. It
is rare, and, when done, it is done very carefully.

The best you can hope for is to use a nested scope, give the macro's
local variables long and obscure names, and pray.

Or just use gensyms (see my most recent post) which completely avoid
variable name collision.

Then the debate is over. Neither language "wins". It's a draw. Let's
all go home and get on with our lives now.

Aleluia!

 

[Series Expansion]

That is what he meant - Emacs does this, not we.

It's a text editor. A text editor won't know Lisp source from Java
source, or either from a letter to Grandma.

You tell me that ain't also the case of Eclipse?

Naw. Eclipse is just an IDE! There's nothing magical about it.

I am sure you think that Eclipse is a very flexible and can
do very extraordinary things with you programming environment.
And we are not saying otherwise.

Yes, Eclipse is a fully-modern, graphical application that integrates
properly into the host window system, can display many different
things at once (even overlapping), and can do all kinds of things that
you simply cannot do (and sometimes cannot even fake in a half-assed
way) with a single undivided, rigid rectangular grid of ASCII-only
characters.

Furthermore, since it is an IDE rather than just an editor, it is
imbued with code that knows a heck of a lot more than how to string
ASCII characters together in large arrays, spool them to disk, and
read them back in. It contains a text editor, of course, but this is
only a small part of the whole.

Your exuberant claims about your development tools seem, to us, as
silly as it would no doubt seem to you if one of us claimed that a
single source-code editor pane from Eclipse, somehow taken out of its
borders and zoomed full screen and stripped of its tab row, popup
menu, balloon help, and all other capabilities that involve overlaying
something instead of changing the text inside the box, could somehow
by itself do as much or more than Eclipse as a whole can do.

What are you assuming impossible here? Lisp can do great things. No
one ever mentioned anything about impossible things or doing some kind
of magic, and, when we do, we are referring to the features that the
language have, not magic itself.

Well, your suggestion that because a certain terminal-oriented
editor's internal scripting language is a dialect of Lisp, you can
write a script for it that can drive modern display hardware and
generally do things with bits of the computer that the host
application predates by decades, is outlandish, for starters. Unless
the editor lets its scripts talk directly to the operating system (or
even the hardware) somehow, I'm fairly sure that's simply impossible.
I'm also not sure what kind of window system will cooperate if it
tried. Windows certainly won't; it makes a strict distinction between
legacy MS-DOS applications and windowed apps. The executables are not
even in the same format; one's either a DOS .COM or DOS .EXE and the
other's a form called PE (for portable executable, I think). I doubt a
DOS .COM or DOS .EXE can even *see* the APIs to do things like request
window creation and obtain a window handle, let alone successfully
obtain a window handle and use it to do more sophisticated things with
the display than could be done in the terminal window using curses.
Windows emulates true MS-DOS for those. The best they can do is try to
drive the display hardware using int16h as they would on a real MS-DOS
computer, which works dodgily at best in Windows' emulation. The last
time I checked, Win9x will try to display appropriate graphics
fullscreen by some sort of DirectX, succeed to some extent, and get
rather unstable; XP will work flawlessly if the graphics mode is plain-
VGA or worse, showing these in the terminal window, and hang if it's
super VGA, forcing a cold restart; and Vista just plain will error out
the MS-DOS application if it tries to use any graphics modes
whatsoever. (Trying to invoke an sVGA video mode from the MS-DOS
Prompt is one of the few ways to reliably crash XP. DirectX games
designed for XP give you a decent shot at it, but are random. The
other sure bets are monkeying with drivers or physically tinkering
with the case hardware, meddling with certain system files while the
system's live, or, pre-SP1, plugging in and unplugging USB devices.)

I DON'T!

You did. You have the right to change your mind, of course.

Read my last posts and

NEVER order me around like I'm your personal slave again.

You say that Java does not have a prompt where you can test and debug
things?

It has a whole IDE where you can test and debug things, full screen,
rather than a mere prompt. Although the debugger has a prompt you can
use for evaluating expressions and examining variable values.

Are you saying that Linux terminals are useless?

No, just primitive. Programming at the REPL is going to be like going
back to using "ed", and programming in a full-screen terminal mode
editor is somewhere in between the two extremes.

make / Autoconf is made on top of them.

make / Autoconf are noninteractive. You edit your makefiles or
automake files or whatever in the editor of your choice, likely a
windowed editor or at worst a screen-oriented terminal editor, and
then run make or automake or whatever on them, rather than doing all
the work at a line-oriented prompt.

Don't you compile code and download packages from the shell at all?

Both Eclipse and Netbeans provide one-click compilation, either of a
file or of a whole project. And for us, downloading packages is
typically done via a web browser, which actually lets you see where
the hell you're going and what the hell you're downloading, unlike
typing "wget http://i.pray.this.is.org/the/right/file.zip" and enter
at a shell prompt.

When we feel the need, though, we can go to a shell (DOS, bash,
whatever) and type java foo.java or invoke ant or whatever. We're just
not forced to, in the typical case.

Fan-bloody-tastic. You know that can't possibly work reliably, right?

[gratuitous personal attack]

It's one thing if the dependency analysis is done by automation when
it's an external tool like automake. It's another if it's done by part
of the same code base undergoing the dependency analysis. Now, the
dependency analysis itself might affect the dependencies, which is
precisely the kind of headache I was alluding to earlier with self-
referentiality.

Lisp way of handling things is not different from that.

Thanks for the confirmation. I think.

Please pass the aspirin.

Slime connects to the lisp environment and asks questions about where
the definition files are.

Ignoring for the time being the security implications of the editor's
internal scripting language having any direct access to the outside
world at all, this is entirely beside the point, which was the
implausibility of your implication that by running some script inside
a curses-based unix editor from the seventies you can magically get a
working modern GUI with multiple overlapping windows and menus.

It just works

If you think running lisp macros inside an editor inside a command
shell on a 386 with no video card hooked up to a keyboard and teletype
can produce a complete window system with a mouse pointer and
everything, I want to know what drugs you're on and where they are
sold!

you really should stop making so dumb arguments and learn Lisp
before anything else.

And now we're back to the boring old game of trading personal attacks.
Haven't you got anything better to do?

He is not wrong.

OK. Out with it. Both of you. Who? Which street corner? How much? Has
it ever been cut with something nasty or given you a bad trip? Don't
worry I won't tell the cops if you don't.

You tell me that Eclipse for instance can't find the source definition
of something if you ask it to do so?

Sure it can. I suppose SLIME can, too. I just question whether SLIME
can do much useful with it, without either altering the file you were
editing or else making you have to flip back and forth between
definition and call site without being able to display them side by
side like you can even with Notepad windows.

Although if you did get them displayed side by side, it would probably
just cause even more headaches. For example, how would you move the
input focus around without a mouse? Tab can't do it, since tab has to
indent/insert a tab into the code. Alt-tab can't do it, though it
would be the most intuitive to a Windows user, because a primitive C
application run from the command line can't see the "alt" keypress by
reading from stdin, just the tab (ascii 9). Control-tab doesn't work
(it would be the same as control-control-I, which is nonsense). Shift-
tab might, if that comes out as character 137 rather than (as the
usual shift = add 32 rule suggests) 41, since the latter is the right
parenthesis character, which *especially* has to do the expected thing
when one is editing Lisp code.

The limitations of the host application interface consisting of stdin
and curses seem to preclude doing this in even a remotely user-
friendly way. (Stdin and stdout would be even worse; think trying to
add MDI capabilities to "ed".)

He is serious about that

Then he needs to get a life. (Most likely, this means he needs to get
laid.)

Being serious about personal attacks on Usenet is such a waste of
time.

he is not attacking you

Uh -- he just did.

You do sound like a novel writer talking about quantum mechanics.

I know quite a lot about quantum mechanics, but I don't see the
relevance here.

You need to learn things before you can attack them, or you just don't
attack them.

Yet you just attacked me despite hardly knowing me; several of you
have flamed Java in several ways despite hardly knowing Java. And
while I may not know Lisp per se, I do know macros and I do know
static type systems and I do know dynamic type systems, all from
experience.

You won't see me in comp.lang.java [sic] unless I learn Java.

Then why am I seeing you in comp.lang.java.programmer right now?

And I certainly won't troll over there like you are trolling over
here, if anything I will complain of some little things I don't like
about Java.

I am not trolling. Lispers fired the first shots in this little teapot-
tempest, and Lispers have already done a lot of complaining abou Java
here. We have responded in kind, some of us, while others have
attempted a more reasoned debate about the merits, to no avail.

I don't know if anyone here is trolling, aside from the OP with his
umpteenth joblessness whine, to be honest.

 

[Adlai]

Considering his opinions on Jews, I'm surprised he liked blacks much
better (if he was even aware of them).

I'm pretty sure that our dear Mr Expansion is unaware of the
differences between
- Martin Luther
- Martin Luther King, Sr.
- Martin Luther King, Jr.

Series, go read about some history before you go read about Lisp,
ok?

 

[Series Expansion]

Real debugging. Lisp macros are a good deal less arcane than you seem
to think; the ones you write 95% of the time are really just
straightforward Lisp functions that act on a tree made up of conses.

Except that macros lack the natural encapsulation barrier that
surrounds functions, as explained elsethread. With all the
consequences for debugging straightforwardness that that implies.

 

[Pillsy]

Let's see:
1. The "destructive C macro" I posted adhered to the Lisp restriction
that macros have to look like, syntactically, function calls. So you
can do that with Lisp macros.

But it doesn't adhere to the Lisp restriction that macros respect
namespaces. Nor can you just redefine either standard functions or
standard macros.

2. If you really couldn't, it would mean Lisp macros were less, or
differently, rather than more, powerful.

C macros makes it easy to do things that are awful and useless, like
your example, and doing non-trivial useful things is usually very
difficult and very error-prone.

Cheers,
Pillsy

 

[Pillsy]

Except that macros lack the natural encapsulation barrier that
surrounds functions, as explained elsethread.

How the heck can you "explain" something you quite clearly know
nothing about?

Cheers,
Pillsy

 

[Series Expansion]

Lisp is not different than this.

Just as I feared.

Macros are not very different from functions. Whatever problems you
cause with macros, you cause with functions.

Except the lack of encapsulation barrier, and the ability of macros to
replace or modify existing functions of the same name.

And, whatever safety functions provide, functions also provide. You
fail to see this

Actually, it is an obvious tautology, though also quite useless.

you NEED DESPERATELY to learn Lisp

Wishful thinking?

This is not the same case as CL.

I know C better, so I used C for my examples (Java lacks macros), but
I was careful to limit myself to "macros that look like functions",
since Lisp won't allow macros that have any other syntax.

We are not dumbs.

So much irony in only four words.

Believe me when I say, this is not the case with Lisp at all. Things
work differently.

Keep on making these hand-wave assertions un-backed-up by arguments or
evidence. You'll pardon me if I keep on not believing them though.

Sorry, but, I don't follow. What is the difference? Arbitrary forms
are arbitrary code fragments. I really don't get it.

C lets you #define all kinds of code fragments. Lisp macros apparently
have to appear to be function calls, and be called in the same places
where one could make function calls.

Typos are the programmer's problem, not language's one, just like
infinite loops.

But Lisp (and C's preprocessor) allow a typo to catastrophically
affect far-away code that isn't even supposed to be interacting
directly with the part of the codebase containing the typo, and in
ways other than by causing an obvious name collision or other compile-
time error.

But not CL macros. They are VERY different.

Another hand-wave. Macros are macros are macros.

Macros are a symbol, possibly with formal parameters, that is expanded
where it is called in the code, with the formal parameters in turn
expanded into copies of the actual parameters.

It immediately follows that an actual parameter with side effects may
end up having those side effects multiple times, and that certain
other problems can arise. It also follows that the macro's internals
can be rewritten, without altering the semantics it would have if the
arguments were side-effect free, and yet cause changes in the
program's semantics if some call site uses an argument with side
effects.

Furthermore, the variable capture problems follow automatically as
well. If the macro assigns to a variable in the outermost scope in its
body, it will clobber the value of any variable of the same name
existing at the call site, since when the macro is expanded in place
at that site, the variable name in the macro becomes a reference to
that other variable. Likewise, if the macro contains a structure in
its body that creates a smaller local scope and defines a variable in
that, when expanded at the call site that becomes a nested local scope
at the call site, and the variable will hide any variable of the same
name existing in the scope enclosing the call. If the macro uses a
formal parameter inside that nested scope, and the call site uses that
variable in the corresponding actual parameter, the expansion will use
the macro's local variable instead of the one the coder intended it to
use, because the latter is hidden by the former.

This again causes an encapsulation failure: merely changing the names
of variables internally used in the macro, without altering anything
else, may cause it to behave very differently at some call sites.

And all of the above is extrapolated from the definition of "macro"
without reference to any particular language, implementation, or
anything. The only way for the above not to happen is for the "macro"
involved to violate in some manner the generic, language-independent
definition of a macro, i.e. for it not to be a macro at all but rather
something else, such as a plain-Jane function call.

 

[Adlai]

It's a text editor. A text editor won't know Lisp source from Java
source, or either from a letter to Grandma.

You missed the memo, man.

Emacs has changed a lot since whenever you last used it.

It can:
- Integrate with the native windowing system
- Understand mouse commands just like Eclipse or anything else does
- Sense that something is Lisp code, or Java code, etc
- Distinguish bits of syntax in various languages. You might need to
add some capabilities to Emacs for better syntax-sniffing and
debugging, but those scripts have been written, and in the case of
Lisp, it's called SLIME.
- Emacs nowadays can also, as Pascal pointed out, be a client for
email, newsgroups, spreadsheets, etc.
- It also has builtin regexp understanding, that you can use to
enhance search-and-replace queries on the text.

This is not some toy from the stoneage!

Your exuberant claims about your development tools seem, to us, as
silly as it would no doubt seem to you if one of us claimed that a
single source-code editor pane from Eclipse, somehow taken out of its
borders and zoomed full screen and stripped of its tab row, popup
menu, balloon help, and all other capabilities that involve overlaying
something instead of changing the text inside the box, could somehow
by itself do as much or more than Eclipse as a whole can do.

Emacs nowadays, is like all of Eclipse. You are the one who is
mistaken, by thinking that Emacs is like just the source editing pane.

You did. You have the right to change your mind, of course.

You also have the right to admit that you misunderstood what he said,
because you didn't realize how Lisp macros work, nor did you realize
how SLIME displays macroexpansions for reference and/or debugging.

NEVER order me around like I'm your personal slave again.

We're trying to help you understand Lisp. I'm not sure why so many of
us are still trying to help you, but maybe it shows that we genuinely
think that Lisp has some great ideas, and we just want to share ideas
rather than troll around.

It has a whole IDE where you can test and debug things, full screen,
rather than a mere prompt. Although the debugger has a prompt you can
use for evaluating expressions and examining variable values.

Lisp has had all of that for 20+ years, plus an interactive prompt
that you can use to "sketch" your code.

Ignoring for the time being the security implications of the editor's
internal scripting language having any direct access to the outside
world at all, this is entirely beside the point, which was the
implausibility of your implication that by running some script inside
a curses-based unix editor from the seventies you can magically get a
working modern GUI with multiple overlapping windows and menus.

Emacs (which as I pointed out in an earlier post, is at least version
22.1.1 today, updated sometime in 2007) deals with windowing and all
that stuff. Slime adds Lisp-specific capabilities that we've been
describing. If this is still confusing, please say so, and we'll try
and explain again.

If you think running lisp macros inside an editor inside a command
shell on a 386 with no video card hooked up to a keyboard and teletype
can produce a complete window system with a mouse pointer and
everything, I want to know what drugs you're on and where they are
sold!

They're not for sale -- they're free!

You can get these drugs for no cost whatsoever. Head on over to
http://www.gigamonkeys.com/book/ and you will experience a mindblowing
trip which could well last for the rest of your life.

And now we're back to the boring old game of trading personal attacks.
Haven't you got anything better to do?

Yes. It's what we're trying to do, and it's called sharing knowledge
about what we think is great -- Lisp macros, CLOS, etc.


- Adlai

 

[gugamilare]

It's a text editor. A text editor won't know Lisp source from Java
source, or either from a letter to Grandma.



Naw. Eclipse is just an IDE! There's nothing magical about it.


Yes, Eclipse is a fully-modern, graphical application that integrates
properly into the host window system, can display many different
things at once (even overlapping), and can do all kinds of things that
you simply cannot do (and sometimes cannot even fake in a half-assed
way) with a single undivided, rigid rectangular grid of ASCII-only
characters.

How can you be so sure? Visual is not everything, you know. I am
pretty sure that you never really used emacs. And Emacs can display
graphics, but it is just a visual feature, not a useful feature,
unless, perhaps, pleasing the programmer.

Furthermore, since it is an IDE rather than just an editor, it is
imbued with code that knows a heck of a lot more than how to string
ASCII characters together in large arrays, spool them to disk, and
read them back in. It contains a text editor, of course, but this is
only a small part of the whole.

Emacs + Slime is also an IDE, believe it or not. I have used Eclipse
with the extension named Cusp that allows Lisp programming, but it
happened that Eclipse + Cusp is not like Emacs + Slime to code in
Lisp.

Your exuberant claims about your development tools seem, to us, as
silly as it would no doubt seem to you if one of us claimed that a
single source-code editor pane from Eclipse, somehow taken out of its
borders and zoomed full screen and stripped of its tab row, popup
menu, balloon help, and all other capabilities that involve overlaying
something instead of changing the text inside the box, could somehow
by itself do as much or more than Eclipse as a whole can do.

It could. Instead of opening a new balloon or a message, it could only
divide the screen and show the help on half of it. It can also provide
a sequence of keys (Control-X plus right or left arrow) that works
like changing the window. It is certainly not fancy or beautiful, but
it works pretty well, I assure you.

And Emacs can also have multiple windows. I use Emacs that way. And
Emacs also have menus and buttons, but it is so much faster to use the
keyboard than the mouse that most users just ignore them.

Well, your suggestion that because a certain terminal-oriented
editor's internal scripting language is a dialect of Lisp, you can
write a script for it that can drive modern display hardware and
generally do things with bits of the computer that the host
application predates by decades, is outlandish, for starters. Unless
the editor lets its scripts talk directly to the operating system (or
even the hardware) somehow, I'm fairly sure that's simply impossible.

It certainly doesn't do that. It doesn't need to do that, since Emacs
already provide the functionality of displaying things. I don't have
any idea why you thought we where saying something like this at all.

I'm also not sure what kind of window system will cooperate if it
tried. Windows certainly won't; it makes a strict distinction between
legacy MS-DOS applications and windowed apps. The executables are not
even in the same format; one's either a DOS .COM or DOS .EXE and the
other's a form called PE (for portable executable, I think). I doubt a
DOS .COM or DOS .EXE can even *see* the APIs to do things like request
window creation and obtain a window handle, let alone successfully
obtain a window handle and use it to do more sophisticated things with
the display than could be done in the terminal window using curses.
Windows emulates true MS-DOS for those. The best they can do is try to
drive the display hardware using int16h as they would on a real MS-DOS
computer, which works dodgily at best in Windows' emulation. The last
time I checked, Win9x will try to display appropriate graphics
fullscreen by some sort of DirectX, succeed to some extent, and get
rather unstable; XP will work flawlessly if the graphics mode is plain-
VGA or worse, showing these in the terminal window, and hang if it's
super VGA, forcing a cold restart; and Vista just plain will error out
the MS-DOS application if it tries to use any graphics modes
whatsoever. (Trying to invoke an sVGA video mode from the MS-DOS
Prompt is one of the few ways to reliably crash XP. DirectX games
designed for XP give you a decent shot at it, but are random. The
other sure bets are monkeying with drivers or physically tinkering
with the case hardware, meddling with certain system files while the
system's live, or, pre-SP1, plugging in and unplugging USB devices.)



You did. You have the right to change your mind, of course.


NEVER order me around like I'm your personal slave again.

Okay, we have a deal then.

It has a whole IDE where you can test and debug things, full screen,
rather than a mere prompt. Although the debugger has a prompt you can
use for evaluating expressions and examining variable values.

So does Emacs + Slime.

No, just primitive. Programming at the REPL is going to be like going
back to using "ed", and programming in a full-screen terminal mode
editor is somewhere in between the two extremes.


make / Autoconf are noninteractive. You edit your makefiles or
automake files or whatever in the editor of your choice, likely a
windowed editor or at worst a screen-oriented terminal editor, and
then run make or automake or whatever on them, rather than doing all
the work at a line-oriented prompt.

But you invoke make from the command line. Or at least this is the way
that it is done many times.

Both Eclipse and Netbeans provide one-click compilation, either of a
file or of a whole project.

Emacs + Slime also does that.

And for us, downloading packages is
typically done via a web browser, which actually lets you see where
the hell you're going and what the hell you're downloading, unlike
typing "wgethttp://i.pray.this.is.org/the/right/file.zip" and enter
at a shell prompt.

When we feel the need, though, we can go to a shell (DOS, bash,
whatever) and type java foo.java or invoke ant or whatever. We're just
not forced to, in the typical case.

That is what he meant by what he said. You can, you are not obligated
to, use the REPL to macroexpand code. But the REPL is very handy in
many cases, specially testing.

[gratuitous personal attack]

It's one thing if the dependency analysis is done by automation when
it's an external tool like automake. It's another if it's done by part
of the same code base undergoing the dependency analysis. Now, the
dependency analysis itself might affect the dependencies, which is
precisely the kind of headache I was alluding to earlier with self-
referentiality.

Lisp way of handling things is not different from that.

Thanks for the confirmation. I think.

Please pass the aspirin.

Another very good argument!!! I can't respond to that.

Ignoring for the time being the security implications of the editor's
internal scripting language having any direct access to the outside
world at all,

Why is opening a program and communicating with it through a socket
not secure? I bet this is how Dev-c++ and other programs do with
compilers.

this is entirely beside the point, which was the
implausibility of your implication that by running some script inside
a curses-based unix editor from the seventies you can magically get a
working modern GUI with multiple overlapping windows and menus.


If you think running lisp macros inside an editor inside a command
shell on a 386 with no video card hooked up to a keyboard and teletype
can produce a complete window system with a mouse pointer and
everything, I want to know what drugs you're on and where they are
sold!

Why do you think I think that? I really have no idea of the reason you
are saying that. You don't really need the mouse, you just didn't
realize that yet.

And now we're back to the boring old game of trading personal attacks.
Haven't you got anything better to do?

This is not a personal attack! I am just saying that your arguments
here are dumb. And they are. I didn't say you are. All Lispers reading
them are thinking the same thing - that you are talking about
something that you have no idea how it works and making completely bad
arguments. I would do the same thing if I complained about Java
because I don't know Java. Archaeologists would think the same thing
about me if I just told them some strange theory I have about
something that happened in History, because I suck at History.

OK. Out with it. Both of you. Who? Which street corner? How much? Has
it ever been cut with something nasty or given you a bad trip? Don't
worry I won't tell the cops if you don't.


Sure it can. I suppose...

So why is it so hard to believe that Emacs + Slime also can?

 

[Pillsy]

You're trolling, aren't you? I checked your Google profile and
you only have posts in this thread.So I guess you saw that a
flamewar was brewing and you decided to jump in to push people's
buttons.

That would explain why his postings read like something out of those
"Top 10 Silly Myths About Lisp" articles.

Oh well. IHBT, IHL, et c.

Cheers,
Pillsy

 

[gugamilare]

Uh -- he just did.


I know quite a lot about quantum mechanics, but I don't see the
relevance here.

This is called a metaphor. I did a comparison. I novel writer talking
about quantum mechanics could only make pointless arguments because he
doesn't know anything about quantum mechanics. You know nothing about
Lisp and you are making very bad arguments for that reason.

Yet you just attacked me despite hardly knowing me; several of you
have flamed Java in several ways despite hardly knowing Java. And
while I may not know Lisp per se, I do know macros and I do know
static type systems and I do know dynamic type systems, all from
experience.

I didn't attack you. Again, I just said you don't know Lisp at all.
And you don't. And this makes you look like a fool when making your
arguments.

You won't see me in comp.lang.java [sic] unless I learn Java.

Then why am I seeing you in comp.lang.java.programmer right now?

This is the thing: I am not in c.l.j.p, I am in comp.lang.lisp, where
these posts where originated and therefore where they belong. Someone
just moved them to c.l.j.p for whatever reason, but this was initially
a c.l.l post.

 

[Adlai]

Just as I feared.


Except the lack of encapsulation barrier, and the ability of macros to
replace or modify existing functions of the same name.


Actually, it is an obvious tautology, though also quite useless.


Wishful thinking?



I know C better, so I used C for my examples (Java lacks macros), but
I was careful to limit myself to "macros that look like functions",
since Lisp won't allow macros that have any other syntax.

The problem with giving C examples, is that C macros are something
completely different from Lisp marcos. Apples and oranges.

So much irony in only four words.

Just because somebody has a tiny grammar mistake in their English,
doesn't mean that the rest of what they say doesn't have some valuable
information.

Keep on making these hand-wave assertions un-backed-up by arguments or
evidence. You'll pardon me if I keep on not believing them though.

Ok. I'll explain the Lisp macro system, briefly, at the end of this
post.

C lets you #define all kinds of code fragments. Lisp macros apparently
have to appear to be function calls, and be called in the same places
where one could make function calls.

Well, keep in mind that Lisp code IS the parse tree generated by the
compiler, while C code has to be turned into a parse tree afterwards.
Thus, in a sense, Lisp macros can be anywhere.

But Lisp (and C's preprocessor) allow a typo to catastrophically
affect far-away code that isn't even supposed to be interacting
directly with the part of the codebase containing the typo, and in
ways other than by causing an obvious name collision or other compile-
time error.

Lisp macros can't redefine an existing function or macro. If you
accidentally do that, through a typo, or if you didn't realize that
the name you were assigning to a macro already refers to some core
function, special form, or macro, you'd get an error message.

And in the cases where you do want to locally use a different
definition for a function or macro, it's possible to define local
functions or macros using forms such as FLET, LABELS, MACROLET, or
SYMBOL-MACROLET, but those definitions vanish as soon as you leave the
scope of their enclosing form. i.e.,

(macrolet ((macro1 (args)
(do-stuff-with args))
(macro2 (args)
(do-other-stuff-with-these args)))
(macro1 foo)
(macro2 bar))
;; out here, macro1 and macro2 no longer have the new definitions

Another hand-wave. Macros are macros are macros.

Macros are a symbol, possibly with formal parameters, that is expanded
where it is called in the code, with the formal parameters in turn
expanded into copies of the actual parameters.

It immediately follows that an actual parameter with side effects may
end up having those side effects multiple times, and that certain
other problems can arise. It also follows that the macro's internals
can be rewritten, without altering the semantics it would have if the
arguments were side-effect free, and yet cause changes in the
program's semantics if some call site uses an argument with side
effects.

Furthermore, the variable capture problems follow automatically as
well. If the macro assigns to a variable in the outermost scope in its
body, it will clobber the value of any variable of the same name
existing at the call site, since when the macro is expanded in place
at that site, the variable name in the macro becomes a reference to
that other variable. Likewise, if the macro contains a structure in
its body that creates a smaller local scope and defines a variable in
that, when expanded at the call site that becomes a nested local scope
at the call site, and the variable will hide any variable of the same
name existing in the scope enclosing the call. If the macro uses a
formal parameter inside that nested scope, and the call site uses that
variable in the corresponding actual parameter, the expansion will use
the macro's local variable instead of the one the coder intended it to
use, because the latter is hidden by the former.

This again causes an encapsulation failure: merely changing the names
of variables internally used in the macro, without altering anything
else, may cause it to behave very differently at some call sites.

And all of the above is extrapolated from the definition of "macro"
without reference to any particular language, implementation, or
anything. The only way for the above not to happen is for the "macro"
involved to violate in some manner the generic, language-independent
definition of a macro, i.e. for it not to be a macro at all but rather
something else, such as a plain-Jane function call.

OK, this is where I'll explain why your statement that "a macro is a
macro" is a bit of a cop-out in this situation.

(A car is a car, right? A VW bug is a car. And James Bond's high-tech
fancy shit is a car. Thus, James Bond's high-tech fancy shit turns out
to be a VW bug. Not exactly, and that's the same logical fallacy that
you made about macros.)

Lisp macros can be placed anywhere in the parse tree of a program.

A Lisp macro does not modify the compiler.

A Lisp macro could include code to define new functions, or define new
macros (the macro DEFMACRO generates code that defines a macro),
however, there would be warnings or even errors if these new
definitions conflicted with any existing definitions. For example, you
can't redefine special forms such as IF.

AFAIK, macros are used mainly for the source code transformations that
they perform -- however, these transformations only happen at the
point in the parse tree where the macro is called. Defining a macro
has no effect except for where you actually call the macro.
Additionally, a macro could have some side-effect, such as counting
the number of times a macro has been called, but I don't think this
happens often or at all. However this could be inexperience speaking.
LISP GODS are invited to correct this paragraph.

A macro receives some arguments. These arguments are not evaluated
when you pass them to the macro, they are only evaluated as the person
who writes the macro sees fit. Thus, it is quite easy to ensure that
each macro argument is evaluated only once, and that they are
evaluated in a specified order -- the natural one being from left to
right. There was an example of a C macro at one point, where passing
it a form like "i++" would end up incrementing i more than once --
this would not happen in a Lisp macro written by any half-competent
programmer.

However, macros are executed -- expanding a macro actually refers to
its execution. The exansion code is simply the result that a macro
passes back. This is why, if you look at almost every Lisp macro
definition, you'll see that the last form is quoted. To use the
example of the "anaphoric-if" macro:

I want the exansion to make a lexical (not global! lexical == local)
binding for the variable IT, bind it to the result of evaluating the
conditional, and then to act like a normal if form, on the value of
IT. The code:
(aif (some-function bar baz)
(foo it)
(frobnobdicate it))
Should expand to:
(let ((it (some-function bar baz)))
(if it
(foo it)
(frobnobdicate it)))

The macro definition should thus look like this -- notice that the
macro itself doesn't evaluate ANY of the arguments passed to it, but
rather just specifies new locations for them. That's essentially what
the backquote syntax (` and ,) does.
(defmacro aif (test if-form &optional then-form)
`(let ((it ,test))
(if it ,if-form ,then-form)))

I hope my explanation has cleared some things up here.


- Adlai

 

[Adlai]

Uh -- he just did.

I know quite a lot about quantum mechanics, but I don't see the
relevance here.

This is called a metaphor. I did a comparison. I novel writer talking
about quantum mechanics could only make pointless arguments because he
doesn't know anything about quantum mechanics. You know nothing about
Lisp and you are making very bad arguments for that reason.

Yet you just attacked me despite hardly knowing me; several of you
have flamed Java in several ways despite hardly knowing Java. And
while I may not know Lisp per se, I do know macros and I do know
static type systems and I do know dynamic type systems, all from
experience.

I didn't attack you. Again, I just said you don't know Lisp at all.
And you don't. And this makes you look like a fool when making your
arguments.

You won't see me in comp.lang.java [sic] unless I learn Java.

Then why am I seeing you in comp.lang.java.programmer right now?

This is the thing: I am not in c.l.j.p, I am in comp.lang.lisp, where
these posts where originated and therefore where they belong. Someone
just moved them to c.l.j.p for whatever reason, but this was initially
a c.l.l post.

Robert Maas's original post was cross-posted between a bunch of
groups. However, the discussions in this thread have mostly been Lisp-
oriented -- including many subtextual requests for curing of extreme
Lisp ignorance.