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

[Series Expansion]

I'm pretty sure that our dear Mr Expansion is unaware of the

None of these personal attacks have any bearing on Java *or* Lisp.
Please endeavor to stick to the topic at hand.

 

[Series Expansion]

But

As my teacher at the Academy was fond of saying, "but"s are for after-
hours pay-TV programming.

I have also leveled numerous other objections to your assertions that
nothing ever goes wrong with Lisp macros, in other posts. If you wish
to address those objections logically, I will entertain your
rebuttals. If you have little left to offer but repetition, hand-
waving, and random namecalling, however, then I confess I will not
find what you have to say very entertaining at all.

 

[Series Expansion]

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

Once again, you have attempted to rebut logic with expletives and
personal attacks. You shall not convince me by such methods, nor, I
hope and expect, shall you convince very many other people.

As I have already explained, I know a great deal about macros in the
general, and I have drawn upon that firm base of knowledge to
construct my arguments. Nothing in the implementation details of Lisp
macros can avoid many of the problems I have noted, nor even mitigate
them much, unless they are macros in name only, in which case you have
perpetrated a farce upon both newsgroups by continually describing
them as such.

And if the latter does prove to be the case, it shall make your
earlier accusations of trolling on the part of the
comp.lang.java.programmer users particularly ironic in hindsight.

 

[Series Expansion]

Just like Emacs!

That remark is in error. Eclipse most certainly is not "just like
emacs".

Just like Emacs!

Just like Emacs!

The repetition of a mantra of faith does not constitute a logical
argument, and no argument at all gains force purely by being posted in
triplicate.

Nobody's talking about a terminal-oriented editor.

I distinctly recall several mentions of emacs in this thread, and at
least one each of vi, ed, edlin, and MS-DOS Edit. There is therefore
at least one person, and likely several, talking about terminal-
oriented editors. Your statement is therefore erroneous.

Nobody's talking about a curses-based unix editor from the seventies.

Once again, and for largely the same reasons, your statement is
erroneous. The past references in this thread to emacs and vi, in
particular, by their very existence contradict your claim.

 

[Arne Vajhøj]

I would see the computer problem as an opportunity. Someone who has been
out of a job for many years needs to demonstrate general initiative,
resourcefulness, and determination as well as technical skills.

"I didn't have enough money to buy a new computer but I found one that
would do the job at a yard sale and negotiated the price down to what I
could afford.", or any of the other suggestions people have posted,
would be more likely to impress a hiring manager than "I couldn't do any
open source work because I didn't have a powerful enough computer."

Besides technically it is not true.

Software development does not necessarily require much computer
power. An old 486 with DOS 6.22 and DJGPP for C programming
does not seem slow. The editor may seem a bit primitive, but
then more thinking and less typing is usually a good thing.

Arne

 

[Series Expansion]

You missed the memo, man.

Excuse me?

Your remark is both erroneous and a non-sequitur, and it appears to
imply an ad hominem argument. Any one of those suffices to void your
argument of logical merit.

It can:

[articles of faith deleted]

I shall not endeavor to argue against a faith-based belief, on the
simple basis that it is futile. Faith is beyond logic. It is also, and
therefore, irrelevant to practical concerns, and thus has no useful
place in a technical discussion comparing two programming languages.
It can only serve to distract from the technical points and detract
from the ability of the participants to keep a "cool head".

This is not some toy from the stoneage!

No, it is a serious text editor "from the stoneage", much as a stone-
tipped spear is a serious weapon from the stone age, obsolete now but
respected in its heyday.

Emacs nowadays, is like all of Eclipse.

That is not physically possible, since its design, which crystallized
before the invention of the CGA peripheral card, inherently precludes
it being "like all of Eclipse".

Furthermore, though I did not mention this earlier, I have used it,
and I can attest from personal experience that it is most certainly
not at all like Eclipse, and indeed is far more cumbersome to use for
any purpose than either a modern programmer's text editor or Eclipse
or NetBeans, much as a spear is more cumbersome to use than a
semiautomatic handgun.

You are the one who is mistaken

No, I most certainly am not, and your resorting once again to personal
attacks is a sign that your debating position is weak.

by thinking that Emacs is like just the source editing pane.

Emacs, and any other terminal-based text editor, is, when used for
software development, inherently "just the source editing pane". A
grid of ASCII symbols is incapable of being much more, by its very
nature.

Once again, also, I have actually used it, and what it presented me
with was, indeed, "just the source editing pane", aside from a status
line and a prompt line used for certain commands such as entering
search queries. This user-interface was no substitute for NetBeans's.
Even the old MS-DOS full-screen text editor had a more developed UI,
displaying as it did a text-grid-emulated version of a Windows menu
bar and thus providing simple to use access to many common editing
commands and simultaneously documenting their hotkeys in an easy to
browse way.

As I recall, it also already possessed modern cut, copy, and paste,
albeit confined to the editor instead of shared with other
applications. Emacs lacked even those, and the last time I used it it
still did, having a primitive proto-clipboard that is much clumsier to
use, indeed is used with key bindings that are not only nonstandard
but inconsistent from place to place within the application. The
interface and documentation also extensively used programmer-centric
terminology rather than confining itself to terminology likely to be
meaningful to typical home-computer users, even to describe basic text
editing functionality, though for a software developer that would not
likely be an issue.

For a text editor, it was also rather large and slow to start up on
the systems where I used it -- typically, remote Unix systems with
relatively powerful CPUs and large volumes of memory compared to
contempory home computers, where the connection's latency rendered
remote X sessions too unstable and unresponsive to be usable, or X was
not available. Vi might have been preferable but for having an even
clumsier interface.

Fortunately, the 21st-century shift away from remote logins and
towards doing work on your own workstation and using web applications
(like Google Docs, Google Code, and Sourceforge, and even email and
Twitter) to coordinate has put an end to these difficulties, and has
even rendered network latency itself largely irrelevant, except of
course when I take a break to play Counterstrike.

You also have the right to admit that you misunderstood what he said,

Perhaps, but it is not in my nature to "admit" to crimes and
misdemeanors of which I am not guilty.

Furthermore, to suggest that I do so strikes me as rude, and perhaps
even dishonest, since it may be construed as falsely implying guilt on
my part, as well as implying a request for me to be dishonest myself.

We're trying to help you

Your form of "help" is most peculiar, consisting as it does of
publicly badmouthing and berating the individual you purport to be
"helping".

Perhaps you should stop to reformulate your strategy.

we genuinely think that Lisp has some great ideas

Perhaps it does, like a diamond in the rough. However it appears to
need polish.

and we just want to share ideas rather than troll around.

Unfortunately, the recent behavior of several people in this
newsgroup, most of them from comp.lang.lisp, evidences otherwise.
Perhaps that is not your intent; nonetheless it is the effect.

Perhaps filtering the assortment of exclamations, expletives, denials,
and insults from the ideas before sharing them will serve your stated
aims, for I have noticed that it's not the ideas themselves, but
rather the above-named contaminants, that cause the greater part of
the difficulties we are having.

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

The preceding posts have mentioned only two one-line prompts, the REPL
and the prompt at the bottom of the screen when running emacs.
Perhaps, though, there is a more modern Lisp development tool, a true
IDE resembling Eclipse or NetBeans, that none of you have yet named.
If so, it might be worth pointing to it rather than simply implying
that one exists while, conspicuously, no-one professes to actually use
anything quite that advanced except on the Java side.

Emacs (which as I pointed out in an earlier post, is at least version
22.1.1 today

Version numbers are irrelevant. I could write a crude command-line
tool that produced a one-line prompt, resembling gdb in its manner of
usage, and name it Foobar v100.0.0 and it would not magically gain,
through that naming, a superior user interface.

deals with windowing and all that stuff.

If one uses it to edit application code that presents a GUI, such as
Swing method calls in Java source code, then I suppose that last
statement is technically true.

If this is still confusing, please say so, and we'll try and explain
again.

This implied insult does not constitute a rational argument of any
sort.

I note the likelihood that one of you has made a category error of
some kind. It is rare that this kind of apparently complete failure of
communication happens otherwise. (The unflattering alternative is
willful ignorance, probably because I am arguing against an article of
faith rather than a belief founded upon evidence, experience, or
pragmatism.)

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

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

Fascinating. This claim can only be true if that web site attempts to
download a malware infection not into the user's browser, but into the
user. A wetware-targeting logic bomb? Engineered meme plague? Whatever
it may be, obviously I shall not risk becoming infected. On the other
hand, if the claim is false, the attempted deception implies an
ulterior motive and thereby also implies that the site may be
hazardous, though in that case probably in a conventional manner,
perhaps an XSS attack on my credit card or banking credentials. Most
likely, though, it would prove to be an ordinary rickrolling or some
similar harmless, but irritating and illogical, prank.

Yes.

By all means, then.

 

[Lew]

Software development does not necessarily require much computer
power. An old 486 with DOS 6.22 and DJGPP for C programming
does not seem slow. The editor may seem a bit primitive, but
then more thinking and less typing is usually a good thing.

That isn't so true when you're learning Java EE. For that you really need a
Pentium-class computer and at least a gig of RAM, if you intend to run a
modern IDE and an app server and a database and your app.

Of course, in 21st-century terms that's no longer much computer power. And if
you have a little less than that, well, someone who's bootstrapping themselves
out of a bad situation might need more patience, but it's still possible.

 

[gugamilare]

If one uses it to edit application code that presents a GUI, such as
Swing method calls in Java source code, then I suppose that last
statement is technically true.

Surprise:

http://www.gnu.org/software/emacs/tour/images/splash.png
http://www.gnu.org/software/emacs/tour/images/gdb.png
http://www.gnu.org/software/emacs/tour/images/ediff.png

You say you have personal experience with Emacs, but you probably only
used it before 1980's.

 

[Series Expansion]

How can you be so sure?

By the application of simple logic. The visual diff in NetBeans, for
instance, is physically impossible to emulate with a rigid character
grid, short of using a custom code page to fake a poor-man's graphics
mode.

(This was the only way to do graphics on the VIC-20 back in the day;
you put a 16x16 grid of the machine's character set on the screen and
then overwrote a system pointer to aim at a rather unusually-formatted
bitmap in memory. It was limited to about 128x128 pixels. Given that a
modern hardware text-mode code page is still 256 characters, and tends
to have 8x16 characters now instead of the VIC-20's 8x8 ones, one
could now obtain a 128x256 "video mode". Color would remain limited to
two colors in each 8x16 chunk of the display, though perhaps with an
unlimited total palette size instead of only 16 (in practice limited
to 512 though, two colors in each of 256 chunks). This could not of
course be done portably, and could not be made to work with remote
terminals in particular, whose code page settings would not be
remotely manipulable. Furthermore, a 128x256 pixel video display is
still insufficient to display the NetBeans visual diff tool and do
justice to it. Nor is any other rectangular display with width
divisible by eight and the same total number of pixels, as could be
obtained by arranging the 256 characters in a rectangle instead of a
square. I conclude that it is, for practical purposes, impossible to
place such a tool within a terminal-mode application of any kind.)

Visual is not everything, you know.

Whereas technically the feature-set, in the narrow sense of text
manipulation functionality, is independent of the display technology,
in practice the display technology makes for enormous differences in
the usability of features' user interfaces.

Compare reading and mentally parsing something like

foo(1);
--- for (int i = 0; i <= len; i++) {
+++ for (int i = 0; i < len; i++) {
bar(my_string, 17, i);
}

(only much longer; a typical diff file) with reading and using the
NetBeans diff viewer, or even displaying the "before" and "after"
versions side by side in two Notepad windows with using the NetBeans
diff viewer. Particularly consider the difference between the latter
two in the case that there are multiple substantial multi-line
additions and deletions. The best a terminal could manage would be a
split-screen view emulating the two Notepad windows, perhaps with the
added bonus of the Page Down key affecting both in tandem, but with
two problems, the views getting out of synch if there were multi-line
additions or deletions, and moderately long lines being truncated or
wrapped that a maximized NetBeans diff viewer window could show in
their entirety.

I am pretty sure that you never really used emacs.

Unfortunately, it seems to be a tendency of yours to frequently be
"pretty sure" of things that turn out to be inaccurate.

And Emacs can display graphics

Absent the kinds of low-level code-page tricks described above, this
is clearly physically impossible on any known text console; with the
code page tricks, it is incompatible with every known hardware
terminal or terminal emulator; and it is therefore certainly
incompatible with supporting remotely-logged-in users, which, the last
time I used it, emacs did. From this I conclude that your statement is
in error.

but it is just a visual feature, not a useful feature,

It is remarkable, but true, that the capability to display graphics is
actually a useful feature even for the task of editing text. However,
it is also quite irrelevant in a discussion centered around a console
mode application.

Emacs + Slime is also an IDE, believe it or not.

An IDE has a bunch of peripheral things around its central code-
editing text editor pane. Emacs has only the text editor pane and its
status and prompt lines. This renders it not an IDE, and indeed
renders it difficult to use for anything other than editing text files
one at a time.

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.

No doubt; Eclipse + Cusp was no doubt to Emacs + Slime as a 747 was to
a hot-air balloon with gondola sides high enough you have to stand
uncomfortably on tip-toes, while it sways about under your weight, to
see out of the thing.

At last, though, you've named a true, visual, IDE for Lisp; you've
previously hinted vaguely that such a thing exists without furnishing
any supporting evidence. Now I can google Cusp (or rather, Eclipse
Cusp) and perhaps encounter such evidence.

It could.

Fascinating. The irrational exuberance continues.

Instead of opening a new balloon or a message, it could only
divide the screen and show the help on half of it.

That would be remarkably crude and primitive. One could not use any
likely interface for such a thing but awkwardly by keyboard input
alone, and it would be quite wasteful of screen space.

It is certainly not fancy or beautiful, but it works pretty
well, I assure you.

Your hypothetical poor-man's-windows has a large number of
deficiencies compared to the real thing.

1. Splitting the screen vertically will wrap short lines. Real
windows can be not only tiled but overlapped, so the text window
could be undisturbed in dimensions while the help balloon was
displayed.
2. Multiple panes or windows are easy to navigate with a modern
graphics workstation and a mouse. They are cumbersome, at best,
with only keyboard navigation and no way to visually distinguish
active from inactive windows.
3. Terminal displays have limited screen real-estate compared to
graphical displays, even when the latter are using a fixed-width
font. Eclipse's code pane, surrounded though it is by other
doodads, can display more code at once than MS-DOS's full-screen
editor ever could.
The proportional loss of screen real-estate from window borders
is much greater, therefore, even if they are the same physical
width. In fact, the text window border will be a full character
wide instead of perhaps a couple of pixels for a tooltip border
in a GUI system. If we place a single divider of | characters
between the two panes, and eschew borders at the screen edges,
this is a full column lost for displaying code (or help) with.
If one adds titlebars to the text windows, so that one can
readily identify them and perhaps also to indicate active
state (using bold, inverse, perhaps color if available), you
additionally lose a row.
4. A horizontal split screen has its own problems. Although you
can avoid sacrificing a column, using one row both as a divider
and as the title of the bottom "window" (and inferring that
the top one is active if the bottom one appears inactive),
your source code view is reduced to half as many rows, and
rows are more precious than columns given that most source
code has lots of short lines with only the occasional longer
ones. A loss of half the columns clobbers mostly blank space
and wraps only a few lines, thus losing you perhaps 20-30%
from the amount of code you can see at a time; a loss of
half the rows automatically loses you 50%. This starting
from an amount of visible code already smaller than in an
Eclipse code pane surrounded by Eclipse's other doodads,
let alone an Eclipse code pane maximized to use almost the
whole screen.
5. There is no obvious way to get rid of the fake "balloon
help" when no longer wanted. Many graphical implementations
simply fade to transparency and vanish if ignored for
long enough with the mouse pointer outside. Your fake
version cannot do this. If it abruptly disappears on a
timer, it is liable sometimes to do so while the user is
still reading from it. There's no mouse pointer they can
put within its borders to inhibit it from disappearing,
or use to explicitly click an [X] in one corner to
immediately close it. So it will have to persist until
some hotkey is typed, which the user will struggle to
remember unless it is displayed somewhere in the
"balloon help" at all times. The right end of its "title
bar" might display this hotkey, for instance "Ctrl-P" in
place of "[X]", at the cost of space for the actual title.
Of course, there's also the matter of reminding the user
of the focus-traversal key so that they can find their
way back to the darn thing to close it, taking up more
space. Of course, once the title line displays two
hotkey reminders, remembering which is which becomes an
issue unless yet more text is added to name them there.
What a GUI can hide in a menu until the user pulls it
down, your "TUI" has to put out in plain sight because
the user has no way of pulling things down.
This could only be completely avoided by using "obvious"
bindings for both functions. Unfortunately, the three
obvious bindings all have problems:
* Alt-tab or ctrl-tab would be obvious things for the
user to try for focus-traversal. Unfortunately,
neither combination has an ASCII code, so can't be
seen by reading from C's stdin.
* Plain tab can switch to the code pane from the
help pane, but has to indent or insert a literal
tab or some spaces in the code pane, so can't be
used to go back.
* Alt-F4 is obvious for the close command, but
suffers from the same problem as alt-tab and
ctrl-tab, namely, the impossibility of ever reading
an alt-F4 keypress with getch(stdin).
(MS-DOS applications like Edit were able to read
alt-F4 and similar keys, but they did this by using
nonportable, DOS-specific conio functions. A portable
C application, especially one that is to be usable
via a unix tty or telnet session, obviously can't use
conio functions.)

It certainly doesn't do that.

Well, there you go, then.

So does Emacs + Slime.

No, Emacs has a one-line prompt at the bottom of the screen, and Slime
presumably has the REPL, also a one-line prompt. Neither of those even
comes remotely close to what I was attempting to describe in Eclipse
and NetBeans.

But you invoke make from the command line.

There's a world of difference between writing something like

../configure
make
make install

at a one-line prompt and writing an entire large-scale software
system's source code from the ground up at a one-line prompt.

Emacs + Slime also does that.

Emacs is physically incapable of providing one-click anything, unless
you mean a key-click.

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.

Perhaps. I maintain that one would not wish to actually enter the bulk
of one's code at it.

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 a scripting language we're discussing. Users and system
administrators expect that installing a new executable (or shell
script) on the system may have security implications. However,
introducing a new script into an application like a text editor should
be safe, aside from the possibility of something like Word's notorious
macro viruses, which would be limited to infecting documents prepared
with the affected application and couldn't wreak more general havoc on
the system as a whole.

If, however, the scripting language isn't sandboxed, then a hostile
script or macro virus can mess with the user's files, send email as
them, and do all manner of other mischief. Indeed, if the system
administrator uses the vulnerable application to view an infected user
file (for instance, as a result of a user complain of the file being
corrupted or otherwise altered), it could lead to a root compromise.
Then use raw sockets to unlimber a ping flood or a ton of malformed
fragmented IP datagrams. There goes the neighborhood.

Why do you think I think that?

Because you implied it.

You don't really need the mouse, you just didn't realize that yet.

This is technically true, if irrelevant, but having one is better than
not having one. Indeed, they could hardly have become so ubiquitous
were it otherwise.

This is not a personal attack!

Perhaps so; on the other hand, the utterance referred to, "you really
should stop making so[sic] dumb arguments", is.

I am just saying that your arguments here are dumb.

And here is another personal attack.

And they are.

And here is another.

One cannot win a debate on the merits by making bald assertions of
stupidity on the part of one's opponents, or by dismissing their
arguments likewise, rather than by actually addressing the points
raised in those arguments, whatever one's opinion of them or their
author.

I didn't say you are.

That much is true; you merely implied that particular falsehood.

All Lispers reading them are thinking the same thing

This combines the ad hominem fallacy with three other errors. First of
all, were your statement here actually true, it would constitute an
appeal to popularity, rather than an appeal to reason. Furthermore, it
is not true, so you have an erroneous premise in your rather
elliptical argument. Last, but not least, I submit that presuming to
speak for a large number of other people is a strategic error, since
it is quite likely to alienate many that had supported your cause.

The structure of your argument appears to be as follows:

All lispers reading this think Series Expansion's arguments are dumb.
Therefore Series Expansion's arguments are dumb.
Therefore Lisp is great, emacs and slime beat Eclipse, and Java sucks.

However, the initial premise is faulty and neither conclusion follows
from the preceding line, the first being an argument from popularity
and the second being an argumentum ad hominem.

I suggest you take some courses in logic, debate, and the basics of
philosophy before continuing this discussion. Otherwise, you are quite
likely to have what is colloquially known as "your ass handed to you".

I would do the same thing if I complained about Java because I
don't know Java.

Hence the complete lack of surprise that the various criticisms of
Java that have been posted here lately have included numerous
erroneous ones, including the pernicious "Java is slow" rumor.

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

That Slime might be able to do this, I don't doubt. It's whether it
could provide such a feature with a user interface that makes it worth
bothering with that I doubt. And given the constraints under which it
must operate, that doubt seems entirely reasonable.

 

[Series Expansion]

No, I am not.

That is because until roughly a week ago, I was a lurker in
comp.lang.java.programmer.

I did not; I have explained my motives in a direct reply to Spiros's
post.

That would explain why his postings read like something out of ...

Fascinating. Another unconvincing ad hominem argument. I calculate the
probability that Pillsy's remark will sway someone in favor of Lisp
over Java to be precisely zero.

 

[Series Expansion]

This is called a metaphor.

That is called a non-sequitur.

You know nothing about Lisp and you are making very bad
arguments for that reason.

That is called a personal attack.

Neither is a valid argument in favor of Lisp. That many of the Lispers
here frequently make such arguments might be construed as indirect
evidence in favor of Java, however.

I didn't attack you.

That, of course, is simply erroneous.

And this makes you look like a fool when making your arguments.

Remarkable. After several explanations that these ad hominem remarks
are not convincing arguments in favor of Lisp, gugamilare has authored
yet another one. I'm reminded of the time I saw a Tarkalian razor-
beast repeatedly head-butting a concrete wall. It could not make
headway, and it might have been able to get around the obstacle by
another route, but it did neither.

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.

This thread is crossposted to both groups, which your news software
should have made visible to you.

Someone just moved them to c.l.j.p for whatever reason, but
this was initially a c.l.l post.

Actually, the crossposted groups list has shrunk, not grown, over the
course of this thread. As you can see in
<[email protected]>, the initial post to this thread was
crossposted to comp.lang.lisp, comp.programming,
comp.lang.java.programmer, and ba.jobs.resumes. So it was in both
comp.lang.lisp and comp.lang.java.programmer from the beginning. At
some point, when the discussion turned towards Lisp, Seed7, and Java,
someone trimmed ba.jobs.resumes from the group list as the discussion
was no longer relevant there. Subsequently, and for unknown reasons,
someone dropped comp.programming, though it did remain relevant there.

 

[Lew]

Surprise:

http://www.gnu.org/software/emacs/tour/images/splash.png
http://www.gnu.org/software/emacs/tour/images/gdb.png
http://www.gnu.org/software/emacs/tour/images/ediff.png

You say you have personal experience with Emacs, but you probably only
used it before 1980's.

Are you kids still squabbling? Do I have to send you to your room?

You do realize that "Series" has done this before, and that no amount of proof
will get him to admit that he in any way has erred? That there is no victory
with him?

Although I did achieve victory over him in this thread myself. Of course, it
wasn't by use of logic, reason or evidence. Unless you want to behave like
me, I suggest you leave him alone henceforth.

Seriously, forget about "Series". He's not worth it. Lisp is a fine language
and very respected by intelligent people. Emacs is the best editor yet
devised. No, really, I believe that. I've been using it forever, and to this
very day. (As a GUI program, too!) You're just never going to get "Series"
to yield a millimeter even on points of basic fact.

Take comfort in the fact that he can never be real competition to you in the
programming work force. Now breathe in, and let it out in one long sigh.
Again - breathe, sigh. Feel better? Good.

 

[Series Expansion]

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

The problem with your arguments is that most of them consist of bald
assertions, unsupported by any reasoning or evidence. (And the rest
tend to be personal attacks or other equally irrelevant, and therefore
fallacious, methods of debate.)

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.

If that mistake had been made in isolation, I might agree. However, it
is part of a larger pattern.

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.

An argument only a lawyer could love.

Lisp macros can't redefine an existing function or macro.

But of course they can. A macro, by definition, substitutes itself for
anything formatted as a macro call that uses that macro's name.
Therefore, if a macro is named the same as a function, and the
function-call and macro-call syntaxes are the same, then the macro
will substitute itself for all calls to that function. It then remains
to observe that, in Lisp, the function-call and macro-call syntaxes
are the same.

The only apparent way out is to prevent macros from ever being named
the same as functions. Now obviously they can't be forced into the
same namespace, since macro processing by definition is agnostic to
the semantics of the text being transformed and only cares about its
syntax, if that, and so cannot "see" namespaces defined with respect
to that text's semantics. So the only viable mechanism would seem to
be to force macros and functions to use nonoverlapping character sets
in their identifiers, using the grammar rules of, respectively, the
macro processor and the language compiler.

C established a convention that macro names be all-uppercase and
function names contain lowercase characters, but a convention does not
form an ironclad guarantee of anything, since neither the preprocessor
nor the compiler will enforce it. Lisp appears to lack even that,
since Lisp macros and Lisp functions seem to conventionally be named
in the same manner, all-lowercase with hyphens as word separators.

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.

This appears to provide a whole new mechanism for causing trouble. An
accidental local definition (via typo or whatever) introduced into a
broad enough scope could impact much of the codebase.

If Java had such a feature, it would be safe, because the largest
scope is a single source file in Java. Anything else is either of
lesser lexical scope, or is scoped by class name, for instance
SomeClass.staticVariableName. It wouldn't be possible to mischievously
or accidentally locally replace String.length(), say, without either
doing it at the top level in every source file (replacing String.length
() or String itself) or doing it in String.java (replacing length()).
This means that if a particular source file had a problem suspected to
be caused by such a redefinition, you'd have only two places to search
for the cause, the affected source file and (if different)
String.java.

C is worse: such a redefinition placed in a commonly included header
file would wreak havoc and be difficult to locate.

Lisp, unfortunately, is the worst possible case for this, since
conceptually the entire program is apparently one long sequence of
imperative (deffoo name (args) body) and similar forms that are
executed in sequence. A top level redefinition anywhere in the entire
length of the program will affect everything below it, if not
everything period.

The safest language in this regard, interestingly, seems to be
Smalltalk. There are only three places to put any sort of declaration:
locally, in a method body; at class level; or in the system
dictionary. The latter can only declare one item with any given name
(mainly classes). A class might be replaced system-wide but cannot be
"locally overridden" in this manner. (Smalltalk actually has severe
problems in a related area, however: it lacks namespaces. All classes
and global variables have to go in the one system dictionary. This
means no two classes can have the same name, unlike in Java or most
other OO languages. Less importantly, it makes global variables even
more of a bother than they usually are. Smalltalk suffers greatly from
this problem, as it makes it hard to prevent libraries frequently
being incompatible with one another due to name collisions. The
largest ecosystem of Smalltalk code I've seen, Squeak's, uses long
prefixes on third-party classnames by convention as poor-man's-
namespaces, with consequent difficulties in the areas of conciseness,
readability, and findability -- large numbers of names sharing a
common prefix is the bane of every computer user who's had to pick an
item from a list.)

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.

In other words, instead of addressing the arguments given above, you
will launch a personal attack and direct some criticism at a
colloquialism, while ignoring the actual arguments entirely.

This is most disappointing.

I did not use "a macro is a macro" as a premise at any point; it was
just by way of introduction. The actual premise used is:

A macro is 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.

which should be accepted as an axiom, true by definition. In other
words, if that statement is false for the constructs in Lisp that you
refer to as "macros", then those constructs are not actually macros,
and this entire debate has been the result of a pointless hoax
perpetrated upon the population of comp.lang.java.programmer.

If, however, you accept that statement as true, then you must accept
everything that follows logically from them, including the conclusions
of the above arguments regarding name-hiding, variable capture, and
order of side effects.

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

I made no logical fallacy. It is more as if I argued that "an
automobile has wheels, and does not run on a track, from which it
follows that a smooth road surface that does not get too steep is
needed for best performance, and that rough terrain with close-spaced
irregularities of a scale ranging from roughly the radius of the
wheels to a few times the vehicle's length will completely impede it".

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.

This statement is equally true of C macros.

The important observation to make is that "where you actually call the
macro" may include places where you did not actually *intend* to call
the macro.

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.

This is true, but it depends on the macro author, rather than the
language ensuring a dependable and unchanging order of evaluation,
even modulo reimplementations of the macro.

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.

The problem, of course, being that "half-competent" programmers are
not the only ones on a typical development team, sad though it is to
say.

Furthermore, there are some situations that will create tradeoffs
between side effect repetition and other problems. Particularly, the
case where you need to use one of the macro's inputs twice. For
instance, consider a macro to take a string and a code snippet and
output the string and "started" to standard error, then run the code
snippet, then output the string and "stopped". This would have obvious
utility in creating logging functionality or simply in debugging.

The problem argument is the string. If an expression with side effects
might be used to compute the string, there are four choices for the
macro author.

1. Just use that argument twice in the macro and tell people to
assign any computed string to a local variable and then call the
macro with the local variable, rather than directly calling it
with the expression.
Objection: This is unsafe. Someone will forget, and a side effect
will happen twice. Requiring callers do something
unusual tends to lead to bugs. We see it in Java all
the time whenever someone tells subclassers of a class
to "call super" when overriding a particular method and
they forget.
2. Assign the argument to a local variable in the macro once and then
use that local variable twice.
Objection: if the macro is used in a scope with the same variable
name, it will get captured.
3. Same as 2, only create a nested scope to hold the local variable
and do everything in there; equivalent to a C macro with the form
#define foo(x,y) { char *t = x; ... } and avoiding variable
capture.
Objection: now any local variable named t in the call site scope
gets hidden, and if that variable was used in either of
the macro's arguments, the code will break.
4. Create a global variable, preferably buried in some obscure
namespace, such as "mypackage_internal", and assign the first
argument to that. This avoids variable capture and variable
hiding.
Objection: global variables are evil. Even tucked away in
"mypackage_internal" it makes the macro non-reentrant
and not thread-safe. Making it thread-safe requires
acquiring a lock at the start of the macro and
releasing it at the end, which makes the macro a
concurrency bottleneck, and still non-reentrant.

I see no way out within the constraints imposed by a) the definition
of a macro (and even just your own explicit statements about them
above) and b) the way lexical scoping works.

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.

I know exactly what the backquote syntax does, of course*. I also know
at least one thing it does not do: get you out of the four-horned
dilemma noted above that arises when you *don't* want variable
capture.

In fact, you've simply confirmed that no peculiarity in the nature of
Lisp macros exempts them.

* In the above code, the ` means instead of evaluating the forms, it
just returns them; the , before test, if-form, and then-form causes
the arguments to be substituted instead of a literal "test", "if-
form", and "then-form" emerging, so you get

(let ((it (some-function bar baz)))
(if it
(foo it)
(frobnobdicate it)))

instead of

(let ((it test))
(if it if-form then-form))

See, I do know quite a bit more about Lisp than you gave me credit for.

 

[Series Expansion]

The above personal attack, directed at me, is addressed in more detail
in my direct response to gugamilare.

The above personal attack, directed at me, is addressed in more detail
in my direct response to gugamilare.

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.

Cross-posted among a bunch of groups.

However, the discussions in this thread have mostly been Lisp-
oriented

It seems to me that the progression has been thus:

Robert Maas's joblessnss
Seed7
Seed7 comparison to Lisp and Java
Comparisons between Lisp and Java, with a smattering of C

then branching out into

Lisp maturity, esp. library support
Lisp macros
Lisp project scalability
Lisp development methodologies
The Lispers' development tools
Java speed, bloat, and other considerations
Programming language market shares

within the context of a comparison of Java and Lisp.

In particular, that wider context means it remains on-topic on
comp.lang.java.programmer, even where the comparison is made
implicitly.

Unfortunately, an additional topic has arisen lately that is not
particularly relevant, nor socially desirable:

Opinions regarding the personal and professional worth of several of
the participants.

including many subtextual requests for curing of extreme
Lisp ignorance.

And that last, undesired topic arises again in the form of a thinly-
veiled personal attack directed against a Java-user; most likely the
intended target is me.

 

[Paul Donnelly]

No "poor c.l.j.p reader could be misled" if you'd just take this
thread off of c.l.j.p. Please.

Advocacy for other programming languages is not the purpose of
c.l.j.p., no matter how excellent the other languages.

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.

 

[Series Expansion]

Ah!!! I didn't know that! Now I know why C macros fail.

That was your own earlier self that wrote that.

And why this is so difficult for you to understand

That was an unprovoked personal attack and not a valid argument in
favor of Lisp. I am in fact finding nothing difficult to understand
save your insistence on using such unconvincing forms of
argumentation.

Now you get it.

As I explained in several other posts, this limitation does not render
Lisp macros particularly safe. I even demonstrated a C macro that
adheres to the above limitation, "have to appear to be function calls,
and be called in the same places where one could make function calls",
and manages to wreak havoc to rival any unsafe C macro. If I knew just
a little bit more Lisp I could undoubtedly construct an equivalent in
that language.

The only difference between macros and functions is
when it is called, and the type of arguments it receives.

No, there are two others. They live in different namespaces, and the
scope of a piece of macro-generated code is nested within the scope of
the call site, unlike a function body's scope, with all the
consequences that entails vis-a-vis variable capture, hiding, and the
like.

Believe me, all the power we are talking about come from such a
simple feature. Whether you believe it or not, this simple
feature is already enough to make all the things we said.
Period.

I don't doubt it. What I doubt is the ability for them to do so
reliably and safely under all the circumstances in which a function
call would be reliable and safe. I also suspect that an error in a
macro is capable of generating much more difficult bugs to track down
than any error in a function, for reasons outlined previously that are
also unaffected by the restriction of macro use to function-call
syntax.

Furthermore, I have yet to see a use of macros described that cannot
be done more safely by using closures, save for one: the intentional
use of variable capture to assign to a variable named "it". And I am
not sure I'd consider that especially desirable. I am reminded
somewhat of global variables, and even a little bit of goto. It is
likely to have unforeseen consequences, and simply enabling it creates
the risk of accidentally introducing bugs belonging to a whole class
that is otherwise avoidable, that instead becomes difficult *to* avoid
even with great care and consideration; bugs that I suspect would tend
to be quite difficult and laborious to track down when they did occur.

The Lisp compiler always complains about name collisions, whether it
is a macro-macro, function-function or macro-function call.

The third of those is not logically possible, since functions don't
even exist, just abstract syntax trees or character sequences, at the
time of macro evaluation, and macros no longer exist at the time of
function evaluation, having already been replaced with their
expansions by that time.

No. Every language implements everything in a different way.

Implementation details are irrelevant, as I have already explained.
Macros can and will cause some combination of four problems listed in
my previous post, for the reasons listed there, independently of how
the macro processor is implemented, so long as the one invariant of
all macros is preserved: that a macro is evaluated by replacing the
macro with its output, and within the output replacing the macro's
formal parameters with the actual parameters, to generate the expanded
code at that spot.

This is easily handled in lisp using local variables

As has already been explained, using local variables does indeed solve
that problem but at the cost of introducing a new one.

Side-effects and variable-collision safe. Just simple as that.

No; as demonstrated in several earlier posts of mine, side-effect
safety and variable-collision safety are mutually exclusive. To obtain
either requires compromising the other. The closest one can come is to
use a global variable, which has its own problems, or to use a long
and obscure variable name, which can greatly reduce, but never
eliminate, the risk of collision, and will tend to do so at the cost
of readability.

Do you really think that 50 years of coding and Lisp programmers are
amateurs enough to make such bad mistakes? Again you fail to
understand this.

Again you resort to ad hominem arguments and hand waves rather than
intelligent debate. From this behavior I can infer that you have been
backed into a corner.

Nintendo 64 was implemented using Lisp. So was Mario 64.

This is not a refutation of the statements made above. Indeed, games
tend to be relatively easy to code even in languages with poor support
for avoiding name collisions, long-range interactions, and other
problems that limit scalability. Most games have a relatively small
amount of code, with much of the work going into creating the content
-- levels, creatures, animations, and so forth -- instead.

ITA Software is a well known company that uses Common Lisp.

Every single one of the current Fortune 500 companies uses Microsoft
Windows, at least on office cubicle computers and laptops; this does
not demonstrate that Windows is superior to, say, Linux.

There are at least 2 commercial Lisp implementations that sell CL
environments with many features and charge over a thousand dollars
on a single license.

The Coca-Cola bottling company charges two dollars a bottle for tap
water from vending machines under the brand name Dasani.

Microsoft charges several hundred dollars for volume license keys for
Windows Vista.

The movie Waterworld carried a price tag of one hundred *million*
dollars or so.

Price is, at best, only loosely correlated with quality.

Many really experienced programmers like Paul Graham use Lisp (and not
only Lisp).

Many also use Windows.

Many people really experienced in life, as evidenced by their age, use
astrology, Scientology, homeopathic healing, or any of a number of
other practices that have been scientifically demonstrated to lack
value.

This, too, is not a strong argument that Lisp is superior to Java.

And you are the first one to ever see these problems.

I certainly am not. A Google search for "variable capture" alone
suffices to soundly disprove that claim, much as it would boost my ego
were it otherwise.

 

[Series Expansion]

Oh, he was talking about my English. Ok, I might have made English
mistakes throughout the thread, I am not a native English speaker so
understand that writing things in English is not as intuitive and as
easy as it is to you, even though I am not bad in English. If you
think I am stupid just because my English is not as good as yours, you
don't have a point.

I assume at least the latter portions of this rant are directed at me.

If it were only your English, I would indeed not have a point.

 

[Series Expansion]

Emacs can also have a large grid.

It is limited by the text modes the hardware can support. A graphics
display, especially using a proportional font, can easily have three
times the number of columns and double the number of rows; six times
the total effective display area.

It has windows.

Faking windows with ASCII has been done before, and always fails to
impress, or to achieve as high a level of usability as an actual GUI.

Don't you think Emacs has Unicode support?

Of course not. An ASCII editor lacks Unicode support by definition.
The best it can hope for is supporting a few different European
languages, though only one at a time, through the configuration of
different code pages in the host's BIOS.

Emacs is not a frozen ancient application, it has evolved, and that
is why it still exists.

A large amount of COBOL code used in financial institutions "has
evolved" and still exists. Those are still legacy applications, and
using them is still cumbersome.

A thing cannot evolve beyond the constraints imposed early in its
existence by the design decisions made then. Those design decisions
become implicit assumptions underlying everything in the codebase,
effectively frozen in. Superficial new features can be added, or other
things tweaked, but it is bound by its basic structure unless it is
completely rewritten from scratch. And then it is no longer the same
program.

Emacs cannot be modernized sufficiently to be usable by modern
software-usability standards without ceasing to be emacs.

Emacs is not different.

Illogical. How do you propose it would display a dangling plug?
Perhaps as

=|'

or something similar? This is not going to have the same intuitive and
immediate readability that a properly formatted graphic would, and
something larger, like

### @
---#### @@
####@@@
---####
###

will consume far too much space on the screen. Furthermore, navigating
among these faked GUI controls via arrow keys or tab will be far more
cumbersome than using a pointing device on a real GUI.

Wow! Emacs does that.

As noted above, window interfaces faked in text tend to be harder to
read and considerably more cumbersome to use. Even MS-DOS applications
from the early 90s that had these, and, via nonportable code, pointing
device support, tended to be more cumbersome to use than their
subsequent Windows ports.

A portable, terminal mode application doing the same thing is going to
be even more cumbersome. Terminals, as you well know, lack pointing
devices, and furthermore they tend to have far less screen real-estate
available than even MS-DOS did, typically only eighty columns and
thirty or fewer rows. Portability will mean the keys that can be read
are limited to those that produce distinct ASCII codes when typed,
which removes alt-combinations and some control-combinations, and most
combinations involving multiple modifiers. It will also prevent the
use of a pointing device. Though this assumes C, or a similar directly-
machine-hosted language. Java and C# provide portable access to these
through the abstraction of a virtual machine, but those do not tend to
work well for designing terminal mode applications. You can use them
to fake one, perhaps even with a telnet-like network protocol for
remote use, but this would be like deciding to design the 2010 Chevy
Volt to emulate a Model T's crank start mechanism. There would be no
logic in doing so.

In short, the user would peer at such an application through a keyhole
and talk to it in pidgin, and, particularly, would never get the
feeling of being in direct control of the application, hands on the
wheel and directly manipulating data.

You don't need multiple windows to copy and paste code

I suspect a misunderstanding has ensued. Though they are not logically
required to go together, in practice, a true GUI and a systemwide
clipboard do tend to go together. So what emacs will lack is system
clipboard integration. I have used it; I'm well aware that it has its
own internal pseudo-clipboard. However, it is more cumbersome to use
than a real one and, crucially, it cannot be used to copy data to, or
paste it in from, other applications.

You clearly didn't ever use Emacs.

Actually, I did. And like nearly all text based applications, one
tends to view a single screen at a time. From each screen of such an
application, one can typically move to certain other screens. What one
cannot do is fluidly use several at the same time, or easily move
among them without feeling that he is having to instruct an electronic
butler to do or fetch something instead of being capable to do it
himself. The application seems unresponsive, even when it is not
really so, and workflow is constrained to particular patterns or
sequences of screens and of actions on each screen. Generally there
are a few paths of least resistance through the user interface. With a
real GUI, and even with some of the better text-based fake GUIs, it's
possible to forge your own paths and arrange things to smooth your
particular choice of workflow instead of being forced to conform to
the application designer's idea of how things should be. Emacs, sadly,
has neither; it has a very rudimentary text-based fake GUI that is too
cumbersome to use except very sparingly, because of all the arcane key-
combinations one must memorize in order to open and close "windows"
and navigate among them, and the complete inability to overlap rather
than tile these "windows". As a result, one's emacs workflow tends to
devolve into: open document, do some work in it, close document, open
a different document, do some work in it, close document, and so
forth. So while the interface technically allows a less linear pattern
of use, in practice, it is still constraining. To use a metaphor,
emacs provides a low, level road that's perfectly linear, and also a
winding network of rocky dirt paths in mountainous terrain that must
be hiked to travel them, sometimes even with climbing gear. Users will
gravitate towards the former, as it is the path of least resistance.

Most pre-1990 text editors are like this; even with its more
sophisticated user interface, MS-DOS Edit is among them. Lowly Notepad
evades the trap easily, since it is easy to create many Notepad
windows, arrange them around the screen as you see fit, switch among
them, and copy and paste among them, though it is sadly deficient in
many other areas, notably in having poor search.

Emacs have even an extension that is a browser inside Emacs.

What was said about Lynx applies equally to any text-terminal Web
browser.

Emacs can display pictures that the webpages have.

How, by generating corresponding ASCII art to display in-line? Or do
you mean it can save them to disk for viewing in an external
application? Neither alternative particularly floats my boat. (Though
I'd hesitate to call anything a Web browser that lacked "save image
as..." and "save link as..." capabilities.)

(Someone already said that he uses Emacs to surf on the web, but,
conveniently, you just ignored him).

The remark was irrelevant where it occurred. Also, I have a fairly
high standard for what constitutes surfing the Web. In particular, it
requires that the browser get out of the way so that I can focus on
the actual Web, rather than on the mechanics of operating the browser.

More generally, one cannot use emacs, Lynx, or most other terminal
applications without devoting a fair amount of one's attention to the
mechanics of operating the interface instead of to the actual task at
hand; freedom from this particular work-slowing distraction is one of
the principal benefits of true GUIs.

For the thousandth time, Emacs have a window system.

A text-based fakery of one that is that quite cumbersome to use, and
therefore entirely fails to support user multitasking.

Furthermore, if you'd bothered to keep reading before interjecting
that remark, you'd have found that by "user multitasking" I did not
merely mean switching among several simultaneously-open text files to
edit instead of only one at a time. I meant switching among several
entirely unrelated applications and having the ability to
asynchronously receive alerts of varying degrees of obtrusiveness from
these and from the operating system of the computer, instead of for
example doing nothing but emacs, then doing nothing but trn, then
nothing but elm, and then nothing but Lynx, in a linear sequence.

[snip]

(Unfortunately, or fortunately, depending on your point of view,
gugamilare's post appears to have gotten truncated in transit. It ends
in the middle of a large block of quoted material, but it's not just
that the rest of the quoted material was accidentally left untrimmed
after gugamilare's last word, since the entire remainder of my
original post is not quoted, only part of it. Of course it's possible
that both happened, with the truncation occurring partway through the
untrimmed terminal chunk of quoted text.)

 

[Series Expansion]

But used only invalid arguments

That is incorrect. Moreover, it is, ironically, itself an example of
an invalid argument, since it merely makes unsupported assertions (and
implied ad hominem attacks) rather than actually, you know, *arguing*.

 

[Series Expansion]

I think there have been some good explanations in some of my threads
explaining how Emacs IS A GRAPHICAL SYSTEM

This is not only a non-sequitur as a response to the deeper-nested
quoted text, it is also patently false, unless one's definition of a
"graphical system" includes faking on in ASCII ala the old MS-DOS
QBasic application.

and is much much much much much much more than just a text
editor.

The addition of what are known in the vernacular as "bells and
whistles" does not magically transform a legacy application into a
modern one, a text editor into an IDE, or do very much else to impress
me.

I also had a very detailed
post about an hour ago about the Lisp macro system. Please spend your
time on explanatory posts, not flammatory ones.

This is an odd request, considering that I do spend my time on
explanatory posts, whereas you do a considerable amount of flaming.

(yet the thread continues to grow apace, with the author of the above
line prominent among the authors of the newest posts)

Dude, it's been said 5 or 6 times already

And so it should be apparent that yet more repetition will not
convince me to change my mind.

If you just don't want to learn about Lisp, just say so. However, at
that point, we'll probably start ignoring you, rather than trying to
show you where you can fill in gaps in your knowledge.

I interpret the above to mean "if you just don't want to spend a lot
of time and probably a bit of money to read a lengthy book parts of
which you probably already know and much of which is probably
completely irrelevant to this debate, we'll probably start ignoring
you, rather than continue to make insulting insinuations about you in
public".

Therefore, if your aim had been to convince me *not* to read the
thing, then you would have succeeded quite admirably.